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!!!

• UN/EDIFACT processing with Smooks
• Reusing existing data layer to persist multi format data streams
• Smooks Sopera DI Components

1. A new UN/EDIFACT Interchange Reader (<unedifact:reader>), which allows Smooks to process UN/EFIFACT message Interchanges (one or more UN/EDIFACT messages wrapped in the UN/EDIFACT Interchange control segments).
2. A new Maven/Ant tool called the “EDI Conversion Tool” (ECT) that can take the official UN/EDIFACT message definition directory zip files and from them, generate a jar file containing a set of equivalent Smooks EDI Mapping Models.  This tool is very easy to configure and use, but we are in the processing of pre-generating a library of these jars for all the UN/EDIFACT message sets and making them available trough the central maven repository, making it even easier to consume UN/EDIFACT messages with Smooks.  We hope to add support for other formats (X.12, HL7 etc) in future releases of Smooks.

So that’s what’s available in the current 1.4 codebase (1.4-SNAPSHOT), but we’re also in the process of making more additions to this for Smooks v1.4.  We’re extending the EDI Java Compiler (EJC) tools to support Java Model generation from the EDI Mapping Model sets generated by the ECT tool (mentioned above).  We’ll also make these available as pre-built jar files from the Maven repository.

Another improvement we’ve made in the 1.4 codebase is the addition of support for Java Model to EDI serialization on the EJC generated Java object models, meaning we’ll be able to do full round trip binding of an EDI (and UN/EDIFACT) message to a populated Java Object model that can be modified and then serialize back out to an EDI stream.  Or, your app can “manually” construct the same Java Object models and serialize them out to an EDI Stream (think JAXB).

Generating a Mapping Model Set using ECT

The easiest way to consume UN/EDIFACT messages using Smooks is to use ECT (EDI Conversion Tool) to generate the EDI Mapping Model set (if we haven’t already pre-built them).  The steps are really easy:

1. Download the official UN/EDIFACT message definitions directory zip file you are interested in from the UNECE website.
2. Create a maven module for the EDI Mapping Model set to be generated and add the maven-ect-plugin (see below) to it’s POM.
3. Execute “mvn clean install” in your maven module and the EDI Mapping Model set jar file will be generated as normal in the modules target folder, and installed into your local maven repository.

The following is an example of the maven module POM for generating the EDI Mapping Model set jar for the d03b.zip definitions directory zip file.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.milyn.edi.unedifact</groupId>
    <artifactId>d03b-mapping</artifactId>
    <version>1.0.SNAPSHOT</version>
    <name>UN/EDIFACT - D03B - Mapping Model</name>

    <build>
        <plugins>
            <plugin>
                <groupId>org.milyn</groupId>
                <artifactId>maven-ect-plugin</artifactId>
		        <version>1.4-SNAPSHOT</version>
                <configuration>
                    <src>d03b.zip</src>
                    <srcType>UNEDIFACT</srcType>
                </configuration>
                <executions>
                    <execution>
                        <goals><goal>generate</goal>
                    </goals></execution>
                </executions>
            </plugin>
        </plugins>
    </build>

</project>

Of course when we execute this step, we will perform “mvn clean deploy” and install the jar file in the public maven repository, making it publicly available and thereby removing the need for you to perform this step.  A peek into the public SNAPSHOT repo shows that we’ve started this process.

Using a Mapping Model Set on the UN/EDIFACT Reader

Using a generated EDI Mapping Model set jar in your application (via Smooks) is trivial.  You need to:

1. Add the generated EDI Mapping Model set jar to your classpath (e.g. using a maven dependency configuration).
2. Add the <unedifact:reader> configuration to your Smooks configuration, using the generated jar’s maven groupId, artifactId and version to reference that particular mapping model set through a URN (see below).

An example of the <unedifact:reader> configuration for the above generated EDI Mapping Model set jar for the d03b.zip definitions directory zip file would be as follows:

<unedifact:reader
     mappingModel="urn:org.milyn.edi.unedifact:d03b-mapping:1.0-SNAPSHOT" />

Using the “urn:<groupId>:<artifactId>:<version>” URN pattern, Smooks can find the EDI Mapping Model set jar file on the classpath,

And that’s about it.  The associated Smooks instance will accept a UN/EDIFACT message interchange containing one or more messages defined in the d03b.zip definitions directory zip file, and will generate a stream of SAX events into Smooks, which can be processed using all the other Smooks capabilities (Java Binding, Validation, Templating etc).  As stated earlier, the improvements we are working on for EJC will result in us being able to generate Java Object models from an EDI Mapping Model set jar.

Play with the Examples… and please give feedback

Check out and build the Smooks examples from https://svn.codehaus.org/milyn/trunk/smooks-examples (mvn install).

Change into the “ect-unedifact” directory after building all the examples (must build them all so as to install the poms) and run the example using mvn exec:java. The ect-unedifact example depends on the “d03b-mapping” module which has been pre-built and is available in the public SNAPSHOT repo.

And guys…. PLEASE let us know how you get on with this stuff… things you like and dislike etc !!!