0 Replies Latest reply on Nov 1, 2010 9:27 PM by Keith Babo

    QS : HelloWorld

    Keith Babo Master

      Splitting off the HelloWorld QS discussion from this thread:

      http://community.jboss.org/thread/158181?tstart=0

       

      Tom Cunningham wrote:

       

      HelloWorld : HelloWorld is pretty basic and I don't see anything different here than what is in InOnlyTest.java or InOnlyOutTest.java in the core/runtime module.      The only difference really is that in ESB 4.x, a JMSListener is used to receive the message.      Obviously one of the requirements for Switchyard will be a JMS component - that would be needed to duplicate the message input.

       

      I have pasted in the jboss-esb.xml for HelloWorld at the bottom of this post for reference.  I think that there are some pretty significant differences between how HelloWorld will run in SwitchYard vs. JBoss ESB.   Let's start with what I think the quickstart is attempting to demonstrate:

      • I have implemented by business logic in "MyJMSListenerAction.java"
      • I would like to log messages that come into my service, so I'm using the ESB's SystemPrintln logger
      • The service implementation consists of the actions listed in the action chain
      • I would like to expose my service over JMS

       

      How I think this will look in SwitchYard:

      • A POJO component (e.g. Weld) that hosts the POJO providing the business logic.  The POJO component represents the service provider and will register the service with SwitchYard.
      • A JMS component which is repsonsible for binding the service to a JMS destination.  The JMS component represents the service consumer and will create exchanges to invoke the service as it receives messages from the destination it's configured to listen on.
      • A single handler which implements the logging.
      • There is no routing logic other than connecting the service consumer to the service provider.

       

      The main objective with the above is to start to establish a clean model for implementing and exposing services.  Things like:

      • The protocol binding for a service should not be part of the service definition itself.
      • Cross cutting concerns should not be a concern of the service implementation.
      • Routing logic belongs in routing engines and not in the service defiition (unless it's a routing component, natch ;-) ).

       

       

       

      <providers>
            <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
            <jms-bus busid="quickstartGwChannel">
               <jms-message-filter
                  dest-type="QUEUE"
                  dest-name="queue/quickstart_helloworld_Request_gw"/>
            </jms-bus>
            <jms-bus busid="quickstartEsbChannel">
               <jms-message-filter
                  dest-type="QUEUE"
                  dest-name="queue/quickstart_helloworld_Request_esb"/>
            </jms-bus>
         </jms-provider>
      </providers>
      
      <services>
         <service 
            category="FirstServiceESB" 
            name="SimpleListener" 
            description="Hello World">
      
             <listeners>
                <jms-listener name="JMS-Gateway" busidref="quickstartGwChannel" is-gateway="true"/>
                <jms-listener name="helloWorld" busidref="quickstartEsbChannel"/>
              </listeners>
      
              <actions mep="OneWay">
                  <action name="action1" 
                     class="org.jboss.soa.esb.samples.quickstart.helloworld.MyJMSListenerAction" 
                     process="displayMessage"/>      
                  <action name="action2" class="org.jboss.soa.esb.actions.SystemPrintln">
                      <property name="printfull" value="false"/>
                   </action>
                   <!-- The next action is for Continuous Integration testing -->
                   <action name="testStore" class="org.jboss.soa.esb.actions.TestMessageStore"/>
               </actions>
         </service>
      </services>