Out-of-the-box (OOTB) actions—how and when to use them

The out-of-the-box actions implemented in JBoss ESB are divided into the following functional groups:

  • Scripting: Automating tasks in scripting languages
  • EJBs: Invoking EJBs
  • Web services/SOAP: Support for web services
  • Transformers/Converters: How your services can change data from one form to another
  • Smooks message fragment processing: How your services can split, enrich, or validate data with Smooks
  • Routers: How your services can move messages between services
  • Notifiers: How your services can send messages to destinations outside ESB
  • Business Process Management: Integrating with JBoss jBPM
  • Rules Services: Integrating with Drools
  • BPEL Processes: Integrating with Riftsaw
  • Miscellaneous: There's also a miscellaneous group that includes only one very simple action—org.jboss.soa.esb.actions.SystemPrintln. This action prints off a message.

We'll examine each of these groups of out-of-the-box actions in the sections that follow.

Scripting

Scripting actions make it possible for you to actually create custom actions, from within an OOTB action, by writing the custom code using a scripting language. This approach mirrors the way in which scripting languages are being used instead of compiled code to greater and greater degrees every year. As of release 4.10 of JBoss ESB, the following scripting actions are supported:

  • GroovyActionProcessor:

    org.jboss.soa.esb.actions.scripting.GroovyActionProcessor The name is a dead give-away; as this action enables you to use Groovy scripts. Here's an example of an action that invokes the OOTB GroovyActionProcessor action:

    <action name="groovyHelloWorld"
        class="org.jboss.soa.esb.actions.scripting.GroovyActionProcessor">
    <property name="script" value="/scripts/helloWorld.groovy" />
</action>
  • ScriptingAction:

    org.jboss.soa.esb.actions.scripting.ScriptingAction This action enables you to use the Bean Scripting Framework (BSF—http://jakarta.apache.org/bsf/). This framework supports BeanShell, Jython, and JRuby scripts. Here's an example of an action that invokes the OOTB ScriptingAction action:

    <action name="add_beanshell_link" class="org.jboss.soa.esb.actions.scripting.ScriptingAction">
   <!-- use a .beanshell extension vs. bsh or the BeanShellDeployer will pick it up inadvertently -->
   <property name="script" value="/scripts/link.beanshell" />
</action>

Pay attention to the comment. If you use a .bsh file extension, the BeanShellDeployer (this is a tool that enables you to deploy scripts or services for one-time use—see http://community.jboss.org/wiki/BSHDeployer) will deploy the script.

Services—invoking EJBs

As we've mentioned more than once already, one of the great strengths of JBoss ESB is how it makes it possible for you to integrate different types of services and systems together, and have them communicate through a loosely coupled architecture, by sending messages over the ESB. One way in which JBoss ESB makes this integration possible is by enabling you to interact with EJBs.

The EJBProcessor (org.jboss.soa.esb.actions.EJBProcessor) action accepts a message and uses it to locate and invoke an EJB. You can send parameters to an EJB and retrieve values from EJBs. Let's look at an example of an action that invokes an EJB, and sends it parameters.

<action name="EJBTestVoid"
        class="org.jboss.soa.esb.actions.EJBProcessor">
    <property name="ejb3" value="true" />
    <property name="method" value="printMessage" />
    <property name="jndi-name" value="SimpleSLSB/remote" />
    <property name="initial-context-factory"
              value="org.jnp.interfaces.NamingContextFactory" />
    <property name="provider-url" value="localhost:1099" />
    <property name="ejb-params">
        <arg0 type="java.lang.String">
            org.jboss.soa.esb.message.defaultEntry
        </arg0>
    </property>
</action>

What's interesting to note here is that in order for the EJBProcessor action to be able to locate the EJB and find the right method to invoke, the parameter list includes as message properties the EJB's jndi-name, its initial-context-factory and the other parameters needed by the EJB.

Note

Note that JBoss ESB supports both EJB2 and EJB3 through this action.

Web services/SOAP

There are three web service-related out-of-the-box actions in JBoss ESB. Each serves a different function and they are detailed in the following:

  • SOAPProcessor: This action is used to expose web service endpoints. Write a service wrapper web service (JSR181) that calls your target web service and exposes it through JBoss ESB listeners. These three types of JBoss WS web service endpoints can be exposed through JBoss ESB listeners using this action:
    • Web service bundled into a JBoss ESB .esb archive: When the web service .war is bundled into a deployed .esb archive
    • Web service bundled into a .ear: When the .war is bundled into a deployed .ear
    • Standalone web service: When the web service .war is deployed
  • WISE SOAPClient: This action uses the WISE client service to create a JAX-WS client class and then call the target service. The message is then routed to that service.
  • SOAPClient: This action uses the soapUI client service to create a SOAP message and then route that message to the target service.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset