I'm currently working on integrating Smooks into the current ESB architecture (http://jira.jboss.com/jira/browse/JBESB-15). In order to do this in any meaningful way I need to modify the current architecture to support what we're currently calling "Action Processing Pipelines".
The existing architecture allows you to specify only 1 "Action" class per Listener/Poller configuration. In order to perform Transformation (or any other pre/post processing operations) we need to be able to specify a list ("pipeline") of message processing actions on a per Listener/Poller basis. I've started this and have it to a stage now where I can offer something for feedback to the community. All the work I've done is on a "tfennelly" workspace branch, so no need to worry about pollution.
So, to Jump straight in. The listener configurations now look as follows (note, this is just a mockup config for illustration purposes):
<EsbConfig command-queue-class="org.jboss.soa.esb.command.InMemoryCommandQueue" command-queue-name="test-queue" > <ListenerConfig listenerClass="org.jboss.soa.esb.util.MockPoller" actions="X12N837-to-HL7V3, Process-HL7V3-Claim, HL7V3-to-X12N837, Route-to-Claims" maxThreads="1" > </ListenerConfig> <Actions> <!-- Under the new architecture I think these will be equivalent to "Contracts Definitions"? --> <Action name="X12N837-to-HL7V3" processor="Smooks" /> <Action name="Process-HL7V3-Claim" processor="ClaimsProcessor" /> <Action name="HL7V3-to-X12N837" processor="Smooks" /> <Action name="Route-to-Claims" processor="SocketRouter"> <property name="address" value="xxxxx" /> </Action> <ProcessorAliases> <!-- Under the new architecture I think these will be equivalent to "Services"? The alias "name" being like the Service URN. --> <Alias name="Smooks" class="org.jboss.soa.esb.actions.SmooksTransformActionProcessor" /> <Alias name="ClaimsProcessor" class="com.acme.health.ClaimsProcessor" /> <Alias name="JmsRouter" class="org.jboss.soa.esb.actions.JmsRouter" /> <Alias name="SocketRouter" class="org.jboss.soa.esb.actions.SocketRouter" /> </ProcessorAliases> </Actions> </EsbConfig>
So on the we now specify a set of 1+ "actions" to be performed on the message payload picked up by the Listener/Poller. In the current arch we only specify a single "actionClass".
So with what I've done so far, these actions have names that are mapped to the ActionProcessor implementation that performs that processing action on the message payload. This mapping is done in the section. From the sample config above you'll see that in this model an ActionProcessor can perform multiple message processing actions. You'll also see that each config can have 1+ property settings associated with it.
The ability to support multiple "message processing actions" through a single ActionProcessor impl is of particular use to a Transformation Service (e.g. a Smooks based Service). The name of the action can be interpretted as the transformation to be performed on the message payload.
To see a simple JUnit test that uses this new model see GpListenerUnitTest.java in SVN. The config file this test uses is GpListener-Config-01.xml and the test ActionProcessor implementations it uses are in the actions package under the test folder.
I won't go into any more detail here now. Hopefully I'll get some feedback and I'll let that drive the thread.