[Design of JBoss ESB] - Re: Action Processing Pipelines on Listeners/Pollers...
by tfennelly
"estebanschifman" wrote : Shouldn't the element lie within the element
| as in the example code ? We could thus have different listeners performing different sequence of actions.
|
|
| | <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"
| | >
| |
| | <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>
| | </ListenerConfig>
| |
| | </EsbConfig>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971056#3971056
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971056
19 years, 6 months
[Design of JBoss ESB] - Re: Action Processing Pipelines on Listeners/Pollers...
by estebanschifman
Shouldn't the element lie within the element
as in the example code ? We could thus have different listeners performing different sequence of actions.
| <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"
| >
|
| <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>
| </ListenerConfig>
|
| </EsbConfig>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971054#3971054
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971054
19 years, 6 months
[Design of JBoss ESB] - Re: Action Processing Pipelines on Listeners/Pollers...
by tfennelly
Very sorry - the forum software removed some words I had in angle brackets. The last part should have read as follows....
anonymous wrote :
| So on the ListenerConfig 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 Actions 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 Action 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.
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971030#3971030
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971030
19 years, 6 months
[Design of JBoss ESB] - Action Processing Pipelines on Listeners/Pollers...
by tfennelly
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971026#3971026
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971026
19 years, 6 months