6 Replies Latest reply on Sep 13, 2006 12:35 PM by tfennelly

    Action Processing Pipelines on Listeners/Pollers...

    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.

        • 1. Re: Action Processing Pipelines on Listeners/Pollers...
          tfennelly

          Very sorry - the forum software removed some words I had in angle brackets. The last part should have read as follows....


          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 <a href="http://anonsvn.labs.jboss.com/labs/jbossesb/workspace/tfennelly/product/core/listeners/src/org/jboss/soa/esb/actions/ActionProcessor.java">ActionProcessor</a> 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 <a href="http://anonsvn.labs.jboss.com/labs/jbossesb/workspace/tfennelly/product/core/listeners/tests/src/org/jboss/soa/esb/listeners/">GpListenerUnitTest.java in SVN</a>. The config file this test uses is <a href="http://anonsvn.labs.jboss.com/labs/jbossesb/workspace/tfennelly/product/core/listeners/tests/src/org/jboss/soa/esb/listeners/GpListener-Config-01.xml">GpListener-Config-01.xml</a> and the test ActionProcessor implementations it uses are in the <a href="http://anonsvn.labs.jboss.com/labs/jbossesb/workspace/tfennelly/product/core/listeners/tests/src/org/jboss/soa/esb/actions/">actions package</a> 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.


          • 2. Re: Action Processing Pipelines on Listeners/Pollers...
            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>


            • 3. Re: Action Processing Pipelines on Listeners/Pollers...
              tfennelly

               

              "estebanschifman" wrote:
              Shouldn't the <Actions> element lie within the <ListenerConfig> 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>


              • 4. Re: Action Processing Pipelines on Listeners/Pollers...
                tfennelly

                OK, at this stage I must hold the record for the most screwups when posting to threads here. However, I've no idea why only half the material got posted this time. Anyway, here's what was supposed to follow Estebans quote....

                In some ways it's a matter of taste I guess. I purposely didn't nest them simply because I thought it made more sense to define all the Actions in one place and reuse them across the ListenerConfigs where needed. This is common on IoC container configs such as with Spring i.e. define a bean in one place and ref it somewhere else in a completely seperate configuration subtree.

                • 5. Re: Action Processing Pipelines on Listeners/Pollers...
                  marklittle

                  We'll need to figure out how this can fit in with the dispatcher work. Maybe you've already got that worked out ;-)?

                  • 6. Re: Action Processing Pipelines on Listeners/Pollers...
                    tfennelly

                    Another enhancement to this could be the ability to configure "default" pre-processing ActionProcessors for specific listener classes - these actions get inserted at the start of the configured pipeline.

                    This could be used e.g. for message normalisation (a hot topic at the moment ;-) ). So for e.g. the JMSListener you could have a default action processor that "normalises" the based on a combo of JMS and your chosen normalisation strategy.

                    So the "Actions" config might look something like:

                    <Actions>
                     <!-- Action configs .... -->
                     <!-- ProcessorAliases configs .... -->
                    
                     <DefaultActions listener="listenerA" actions="action-list..." />
                     <DefaultActions listener="listenerB" actions="action-list..." />
                     </Actions>