With Smooks 1.4 we added support for OSGI in the form of making the smooks-all.jar into a bundle. This jar contains all the Smooks classes and resources and is a convenience jar that can be used if you don’t want to keep track of all the individual jars that make up Smooks. During this work we also added a few classes to make Smooks work well inside an OSGI container.

For some background and more details about the Smooks-OSGI work please take a look at this wiki page.

Using Smooks in an OSGI Container (with Camel and ServiceMix)
With 1.4 we added Camel support which has had OSGI support for a long time. We added a few basic examples but it turned out that this was not the best solution. The solution in 1.4 required users to explicitly specify the packages the client bundle required and this made maintenance difficult.
Using Smooks in Camel should not require anything more then declaring that the client bundle uses Camel and perhaps Spring. Client bundles now only need to declare that they import packages for Camel, for example:

Manifest-Version: 1.0
Export-Package: example;uses:="org.apache.camel,
    org.springframework.context.support,
    org.springframework.context"
Bundle-Version: 1.0
Bundle-Name: Milyn Smooks Example - Smooks Camel CVS to XML
Bundle-ManifestVersion: 2
Import-Package:
    example,org.apache.camel;version="2.6",
    org.springframework.context;version="1.2.0",
    org.springframework.context.support;version="1.2.0"
Bundle-SymbolicName: milyn-smooks-example-camel-csv-to-xml

Simplified deployment to ServiceMix
ServiceMix users will hopefully be glad to know that we now generate a features.xml file for easy deployment into service mix. A features.xml specifies all the bundles that a feature need and can be installed/uninstalled as a single unit.
For example, to install the Smooks bundle you can use the following commands:

karaf@root> features:addUrl mvn:org.milyn/milyn-smooks-all/1.5-SNAPSHOT/xml/features
karaf@root> features:install smooks


UN/EDIFACT
Smooks has UN/EDIFACT support which includes pre-generated artifacts that are available in maven. As part of the OSGi work, we have modified these artifacts so as to make them OSGi fragment bundles

Users can now install the mappings and binding as fragment bundles and these will attach to a specific version of the Smooks bundle. This is what this looks like running in Apache ServiceMix 4.3.0.1-fuse:

[ 430] [Active ] [ ] [ ] [ 60] Smooks OSGi (1.5.0.SNAPSHOT)
Fragments: 439,441
[ 439] [Resolved ] [ ] [ ] [ 60] Smooks EDI - UN/EDIFACT - D96A - Bindings (1.4)
Hosts: 430
[ 441] [Resolved ] [ ] [ ] [ 60] Smooks EDI - UN/EDIFACT - D96A - Mapping Model (1.4)
Hosts: 430
[ 448] [Active ] [ ] [Started] [ 60] Milyn Smooks Example - Smooks Camel UNEDIFACT to String (1.0)

Above we can see that the binding (id=439) and the mapping (id=441) have been attached to the Smooks bundle (id=420). More fragment bundles can be attached as required and you can attach the same fragment to different version of the Smooks bundle since we specify a version on the Fragment-Host header.

As mentioned earlier in this post you can find more information and details about this work on this wiki page.

The new UN/EDIFACT support allows you to process UN/EDIFACT Interchanges by either or both of the following methods:

1. Conversion to XML, allowing you to use standard XML tools (or other Smooks extensions) for further processing.
2. Binding the interchange message data into pre-built Java object models, or custom models if you prefer to use your own.

All the required artifacts for reading any of the UN/EDIFACT directories (and converting to XML) are available in Maven, as are all of the pre-built Java Object models for all the messages defined in all of the UN/EDIFACT directories.  To use them, all you need to do is include the appropriate artifacts into your project.  See the User Guide.

The new Apache Camel integration allows you to hook Smooks into your Camel routes as a Camel Component or Camel DataFormat.  Another important part of the Camel integration are the Smooks extensions that allow you to perform inline routing of Smooks BeanContext data to Camel endpoints i.e. you can also process huge (GB+) data streams.

Putting these two new capabilities together allows us to provide some interesting functionality with respect to Splitting and Routing UN/EDIFACT message Interchanges.  We use Smooks to perform the reading, conversion (to XML and/or Java) and splitting of the interchanges and then use Camel to to perform the inline routing of the Java or XML (using the new Camel extensions for Smooks).

We created an example that demonstrates this capability:

• See the Screencast.
• Get the code and try it yourself (the “splitting-camel” example).

See more here on the Smooks Wiki.

The UN/EDIFACT Editor for Eclipse is cool, but I think the wider impact of these capabilities is even cooler.  This is really important work because it will open a number of really important doors in terms of our ability to process and transform not just UN/EDIFACT, but EDI in general (X.12, HL7 etc).  Our long-term goal is to add support for X.12, HL7 etc to ECT (i.e. build conversion tools for these standards).  Once we do this, we will be able to provide out-of-the-box support for these EDI formats on the Smooks Runtime.  We hope it will also mean that we can use this work that Renat is doing to automate building of Ecore/XMI models for these same formats.  Once we have these Ecore/XMI models, we hope we will be able to:

1. Build and provide XML Schemas (XSDs) for all of these messages.
2. Make use of Eclipse EMF Compare to compare models e.g. compare 2 different versions (D93 and D96) of a UN/EDIFACT Invoice specification.
3. Make use of Eclipse EMF M2M to create a transformation model between 2 different models e.g. between UN/EDIFACT and X.12 Invoices.

Note that this will not hit the main codebase until after we have released Smooks v1.4 i.e. we hope to make it available with Smooks v1.5.

This is awesome stuff.  Keep up the great work Renat!!!

The problem with the above approach is:

1. It makes the framework configuration more verbose than it should be.  Also (in some cases), the embedding framework does not provide a rich enough configuration model for defining this information, resulting in ugly/un-intuitive configuration hacks for defining the result.
2. It means the user needs to read and understand the Smooks configuration and then make the framework level configurations, based on what they have interpreted from the Smooks configuration.  This is a pain!
3. Adding support for new Result types usually involves modifications to the framework integration.
4. It typically only supports mapping of one result type, restricting the use of Smooks.

When doing the Camel integration, we started to encounter this issue again.  The solution that we came up with was to add a configuration element to the Smooks core namespace, pulling all of this configuration back into the Smooks configuration and providing a richer configuration model:

The newly added exports element declares the results that are produced by this Smooks configuration. A export element can contain one or more result elements. A framework that uses Smooks could then perform filtering like this:

// Get the Exported types that were configured.
Exports exports = Exports.getExports(smooks.getApplicationContext());
if (exports.hasExports())
{
    // Create the instances of the Result types.
    // (Only the types, i.e the Class type are declared in the 'type' attribute.
    Result[] results = exports.createResults();
    smooks.filterSource(executionContext, getSource(exchange), results);
    // The Results(s) will now be populate by Smooks filtering process and
    // available to the framework in question.
}

There might also be cases where you only want a portion of the result extracted and returned. You can use the ‘extract’ attribute to specify this:

The extract attribute is intended to be used when you are only interested in a sub-section of a produced result. In the example above we are saying that we only want the object named orderBean to be exported. The other contents of the JavaResult will be ignored. Another example where you might want to use this kind of extracting could be when you only want a ValidationResult of a certain type, for example to only return validation errors.

Below is an example of using the extracts option from an embedded framework

// Get the Exported types that were configured.
Exports exports = Exports.getExports(smooks.getApplicationContext());
if (exports.hasExports())
{
    // Create the instances of the Result types.
    // (Only the types, i.e the Class type are declared in the 'type' attribute.
    Result[] results = exports.createResults();
    smooks.filterSource(executionContext, getSource(exchange), results);
    List