Let's see how notifiers work. Follow these steps:
- Change your current directory to the quickstart's directory
samples/quickstarts/helloworld_file_notifier. - Deploy the quickstart using the
ant deploycommand. - Before you run the quickstart, review the
jboss-esb.xmlfile and see how the message is routed to two different services—one which displays the message and the other which notifies the console and a file. - You might notice that this quickstart has a
jboss-esb-unfiltered.xmlfile. This is because it contains a bit ofant buildformatting to allow the ant script to insert the absolute location of the quickstart directory in thejboss-esb.xml. - Run the quickstart using the
ant runtestcommand. - Review the quickstart's output in the
server.logfile. Check theresults.logfile for the contents of the message.
In this quickstart, the runtest target sends a message to a service which routes the message to two different services. One of the services displays the message to System.out, and the other one calls a notifier—which writes the message to the console and a results.log file.
This action group contains only one out-of-the-box action (org.jboss.soa.esb.services.jbpm.actions.BpmProcessor), but that one action supports the JBoss ESB-jBPM integration within JBoss ESB. This integration enables your services to make calls to a jBPM process through the jBPM Command API. Of the commands in the command API, the following (three) are available for use from ESB:
- NewProcessInstanceCommand: This creates a new
ProcessInstanceusing a process definition that has already been deployed to jBPM. The process instance is left in the start state so that tasks referenced by start node are executed. - StartProcessInstanceCommand: This is the same as
NewProcessInstanceCommand, except that the process instance that is created is moved from the start position to the first node in the process graph. - CancelProcessInstanceCommand: As its name implies, this cancels a process instance.
However, this is only part of the JBoss ESB-jBPM integration. The integration also supports the orchestration of services from jBPM processes. The appendix to this book includes more details on JBoss ESB-jBPM integration, including the orchestration of services from jBPM processes.
JBoss ESB can use Drools as its rules processing engine through the BusinessRulesProcessor action. The following is an example of the use of the BusinessRulesProcessor in the business_rules_processor quickstart:
<action class="org.jboss.soa.esb.actions.BusinessRulesProcessor"
name="BRP">
<property name="ruleSet" value="MyBusinessRules.drl"/>
<property name="ruleReload" value="true"/>
<property name="object-paths">
<object-path esb="body.orderHeader"/>
<object-path esb="body.customer"/>
</property>
</action>The rules are contained in a .drl file, in this instance, MyBusinessRules.drl. The object-paths listed here are MVEL (http://mvel.codehaus.org) expressions that are used to extract objects from those locations in the message, in this instance, the OrderHeader object from the body, and the Customer object from the body. Those objects then can be used within your rules file.
The appendix to this book includes more details on JBoss ESB-Drools integration.
JBoss ESB also supports integration with JBoss Riftsaw (http://www.jboss.org/riftsaw). Riftsaw is an open source WS-BPEL 2.0 engine that is based on Apache ODE (http://ode.apache.org/). With its Riftsaw integration, JBoss ESB services can directly invoke a RiftSaw BPEL process by using the OOTB BPELInvoke action (org.jboss.soa.esb.actions.bpel.BPELInvoke).
The JBoss ESB-Riftsaw integration uses web services to support a two-way integration:
- Riftsaw works by exposing BPEL processes as web services. JBoss ESB actions can invoke those Riftsaw BPEL processes by invoking the web service that Riftsaw exposes, through its WSDL interface, and in the other direction.
- A BPEL process can invoke a JBoss ESB service that is accessible as a web service. For example, a service that is exposed by a proxied web service. In this case, the BPEL process invokes the JBoss ESB service just as if it was any other web service.
Note
Note that Riftsaw and its JBoss ESB quickstarts and user documentation is not installed by default with JBoss ESB. To make use of the JBoss ESB-Riftsaw integration, you have to download and install Riftsaw from http://www.jboss.org/riftsaw/downloads and install it into a JBoss AS installation.
The appendix to this book includes more details on the JBossESB - Riftsaw integration.
- When writing a custom action, what method handles a message?
a. That's really up to you. Hey, it's a "custom" action, isn't it?
b. The
processmethod.c. It's a trick question; custom actions can't handle messages.
- How can you have messages routed to the correct services based on the information in the messages?
a. You have to write custom actions to "break open" the messages.
b. The routes are all based on unique message ID properties.
c. With content-based routing.
- What would you use to send an ESB-aware message outside the ESB?
a. Why would you want to do that? It's scary outside there!
b. With a notifier OOTB action.
c. This is the type of task that requires a custom action.
- How do you convert content in a message from one form to another?
a. Dust off your old Perl books.
b. With a converter/transformer OOTB action.
c. With a notifier OOTB action.
- Which OOTB action allows you to expose a web service?
a. The
SOAPProcessoraction—you write a web service that calls your web service and exposes it through JBoss ESB listeners.b. The
WebserviceExpose-Amatic—it's an OOTB action and a kitchen appliance.c. You're on your own—you have to create a custom action for this task.