1 Reply Latest reply on Nov 1, 2010 7:36 PM by Keith Babo

    Examples mapping onto API

    Tom Cunningham Master

      One of our recent internal checklist items was to take a brief look at a number of the examples and see how they map onto the SwitchYard API.

       

       

      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.

       


      CustomAction : The CustomAction quickstart reveals two areas that would have to be handled under the new API : a list of custom-defined process methods, and a custom property setter.

       

      List of process methods defined in configuration file (StatefulAction.java) :

       

      <action name="fourth"  class="org.jboss.soa.esb.samples.quickstart.customaction.StatefulAction"  process="methodOne,methodTwo,displayCount" >
                  <property name="exceptionMethod" value="exceptionHandler" />
      </action>

       

      Doing something like this would be possible through the configuration, where we store ExchangeHandler functions to be executed, but it should be discussed whether the ability to execute multiple process methods in the place of handle or exchangeIn/exchangeOut is something which should transfer over from ESB4.

       

      Property setter (jboss-esb.xml) :

      <action name="seventh"  class="org.jboss.soa.esb.samples.quickstart.customaction.CustomBeanConfigAction">
                  <property name="information" value="Hola Mundo" />
                  <property name="repeatCount" value="5"/>                                         
      </action>
      

       

      CustomBeanConfigAction.java :

       

              private String information;
              private Integer repeatCount;
      
              public void setInformation(String information) {
                 this.information = information;
              }
      
              public void setRepeatCount(Integer repeatCount) {
                 this.repeatCount = repeatCount;
              }
              
              public Message process(Message message) throws ActionProcessingException {
                System.out.println("[" + serviceCategory + ":" + serviceName + "] Repeat message: " + information + " " + repeatCount + " times:");
                  for (int i=0; i < repeatCount; i++) {
                    System.out.println(information);
                  }
          }
      

       

      In the example above, both the information and the repeatCount variables are set by automatic setters.    The use of custom property setters and the ability to use those variables automatically is something that probably should be looked at in ExchangeHandler.

       


      HelloWorldFileAction : The only thing really missing here is a File component.     The HelloWorldFileAction quickstart employs a little bit of build trickery (an ant copy filterset) to rename the configuration file and to hard-code a few locations into it.     The configuration file contains a number of options that are sent to a fs-message-filter (directory, input-suffix, work-suffix, post-delete, post-directory, post-suffix, error-delete, error-directory, error-suffix).      Some of these are options that would need to be incorporated into the FileComponent and others are options that could be configured just by specifying a java.io.FileFilter and passing a number of properties to it.

       


      SecurityBasic, SecuritySAML : In ESB4, the container's security implementation is leveraged to protect ESB services.     In SecurityBasic, a security moduleName is specified within the Service definition in the configuration, and that module name is added to login-config.xml.    

       

      In terms of the API, there likely will have to be an extensible Security interface (like SecurityService in ESB) and checks/privileged execution added to the handler processing.   In ESB4, ActionProcessingPipeline.java does the following :

       

                          // Authenticate the caller
                          securityService.authenticate(securityConf, securityContext, authRequest);
      
                          // Store the encrypted security context. Will be re-attached to outgoing messages.
                          SecurityContext.setSecurityContext(SecurityContext.encryptContext(securityContext));
                   ...
      
                          return (Boolean) Subject.doAsPrivileged(securityContext.getSubject(), getPrivilegedAction(message), null);
      

       

      Security credentials should also be able to be passed in directly through a Context.    Would this fit under Correlation or Exchange scope?

       

       

       

      TransformXML2POJO : The interesting part of TransformXML2POJO is the use of SmooksAction - the rest of the quickstart is custom actions to display the message and to convert a POJO into message/String form.   

       

      In the configuration, the location of the smooks configuration file is specified as well as a resultType :

       

      <action name="transform" class="org.jboss.soa.esb.smooks.SmooksAction">
                          <property name="smooksConfig" value="/smooks-res.xml" />
                          <property name="resultType" value="JAVA" />
                          <!-- property name="reportPath" value="/zap/smooks-report.html" / -->
      </action>
      

       

      The ESB4 SmooksAction looks like it would be a pretty straight translation from Action to SwitchYard component.     The SmooksAction looks for a number of ConfigTree properties (resultType, smooksConfig, reportPath, mappedContextObjects, message profile) which would be passed into the component.

       

       

       

      MessageFilter / SimpleCBR : The interesting part of both the MessageFilter and SimpleCBR quickstarts is the ContentBasedRouter.     We'll look at MessageFilter :

       

      <action class="org.jboss.soa.esb.actions.MessageFilter" name="MessageFilter">
                          <property name="ruleSet" value="FilterRules.drl"/>
                          <property name="ruleReload" value="true"/>
                          <property name="destinations">
                              <route-to destination-name="DemoDestination" service-category="Test" service-name="NextService"/>
                          </property>
                          <property name="object-paths">
                              <object-path esb="body.'org.jboss.soa.esb.message.defaultEntry'" />
                          </property>
      </action>
      

       

      Most of the magic here happens in ContentBasedWiretap, where the rules are executed based on the ruleSet.     This looks like it will require a ContentBasedRouting component, but the one interesting part of the ContentBasedRouter is that it is making ServiceInvoker calls and looks like it will require the use of the service registry in Switchyard.

        • 1. Re: Examples mapping onto API
          Keith Babo Master

          Tom - thanks for putting this all together and sorry for not replying earlier.  I would like to get a level deeper with each of these examples, but I think it's best to probably split out an individual thread for each one.  I will split one off for HelloWorld and once we beat that one to death we can move on to the other ones.

           

          One general thing I would like to point out is the difference I see between handlers in SwitchYard and actions in JBoss ESB.  A handler is something that you use to process the low level details of a message exchange between service consumer and provider.  While it's certainly possible to implement your business logic using a handler, my hope is that there will be much more appropriate ways to do this from SwitchYard (e.g. implementing a service using a CDI bean).  You would write/use a handler if you wanted to implement a logger, transform message formats, process protocol-specific headers, perform policy checks, etc.  These are details outside the scope of your business logic.  The other thing about action chains in JBoss ESB is that they provide a routing pipeline, which allows you to chain multiple pieces of business logic together.  I don't think handlers should be used for this either.  There are other tools available to handle this (jBPM, Camel, etc.) outside of the low-level handler chain.