Follow these steps to run the transform_XML2XML_simple
quickstart:
samples/quickstarts/transform_XML2XML_simple
.ant deploy
command.ProductID
, price
, and quantity
elements. These are the elements that were defined in the smooks-res.xml
file:<Order orderId="1" orderDate="Wed Nov 15 13:45:28 EST 2006" statusCode="0" netAmount="59.97" totalAmount="64.92" tax="4.95"> <Customer userName="user1" firstName="Harry" lastName="Fletcher" state="SD"/> <OrderLines> <OrderLine position="1" quantity="1"> <Product productId="364" title="The 40-Year-Old Virgin " price="29.98"/> </OrderLine> <OrderLine position="2" quantity="1"> <Product productId="299" title="Pulp Fiction" price="29.99"/> </OrderLine> </OrderLines> </Order>
ant runtest
command.server.log
file. Make note of how the data from the message has been transformed into a new format:2011-07-17 18:16:59,258 INFO [STDOUT] (pool-33-thread-1)[transform_XML2XML_simple] Message after transformation: 2011-07-17 18:16:59,258 INFO [STDOUT] (pool-33-thread-1) [<Order netAmount="59.97" orderDate="Wed Nov 15 13:45:28 EST 2006"orderId="1" statusCode="0" tax="4.95" totalAmount="64.92"> <Customer firstName="Harry" lastName="Fletcher" state="SD" userName="user1"></Customer> <OrderLines> <line-item> <product>364</product> <price>29.98</price> <quantity>1</quantity> </line-item> <line-item> <product>299</product> <price>29.99</price> <quantity>1</quantity> </line-item> </OrderLines> </Order>].
As you can see from the server output, the original message is printed out, the message is transformed and then it is printed out again. The smooks resource file specifies a transform which changes <OrderLine/>
elements into <line-item/>
elements and a number of subsequent attributes into child elements.
JBoss ESB supports static routing of messages to services, where messages are always routed to the same service based on the configuration. However, JBoss ESB also supports multiple approaches for content-based routing, where a message's route is determined dynamically at run-time, based on the content of the message.
You've probably noticed by now that in our examining the features provided by JBoss ESB, one recurring theme is that, on the ESB, "everything is either a service or a message". In order to make sure that our services can communicate via messages, JBoss ESB has to have a way to get messages to the right service. The ESB does this through message routing.
JBoss ESB supports multiple routing-related actions, these are as follows:
org.jboss.soa.esb.actions.Aggregator
This action aggregates information from multiple messages. For example, if you want to collect information from a message that contains a customer's mailing address with information about that customer's country's import/export laws. The Aggregator
action is an implementation of the Aggregator Enterprise Integration Pattern (http://www.enterpriseintegrationpatterns.com/Aggregator.html)
org.jboss.soa.esb.actions.routing.EchoRouter
This router is much simpler. As its name implies, it simply echos the incoming message to the server log and then returns the message.
org.jboss.soa.esb.actions.routing.HttpRouter
This router sends the incoming message to an HTTP URL that you define in the action.
org.jboss.soa.esb.actions.routing.JMSRouter
One of the ways in which you can achieve the loose coupling that we want in a service-oriented architecture is by using asynchronous messaging. In this approach, the sending service inserts messages into a JMS queue or topic for a receiving service to retrieve. What makes this asynchronous is that the sending service does not have to wait for the receiving service to "pick up" the message. The sending service is able to continue to perform tasks without blocking or waiting for the receiving service.
org.jboss.soa.esb.actions.StaticRouter
In some cases, messages will always follow the same route. For example, messages from the sales service will always be directed to the credit check service. For static routes such as these, StaticRouter
can be used.
org.jboss.soa.esb.actions.StaticWiretap
This action implements the Enterprise Integration Pattern for a wiretap (http://www.enterpriseintegrationpatterns.com/WireTap.html).
The action enables you to inspect each processed message, without otherwise changing the actions performed. It lets you "listen in" on the messages, without actually changing them.
org.jboss.soa.esb.actions.ContentBasedRouter
The most interesting set of OOTB router actions deals with content-based routing. For these actions, the content in the messages determines the route that a message will follow.
JBoss ESB supports multiple ways to perform content-based routing. You can define XPath semantics or regular expression pattern matching in the action definition. For example:
<action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter"> <property name="cbrAlias" value="XPath"/> <property name="destinations"> <namespace prefix="ord" uri="http://org.jboss.soa.esb/Order" /> <route-to service-category="BlueTeam" service-name="GoBlue" expression="/ord:Order[@statusCode='0']" /> <route-to service-category="RedTeam" service-name="GoRed" expression="/ord:Order[@statusCode='1']" /> <route-to service-category="GreenTeam" service-name="GoGreen" expression="/ord:Order[@statusCode='2']" /> </property> </action>
The expression
defines the XPath pattern that must be matched to route messages to the desired service.
JBoss ESB also supports using JBoss Drools to define the content-based routing. We'll look at the JBoss ESB-Drools integration later in this chapter. Drools provides a declarative, "rules based" programming model for routing patterns too complicated to be easily handled by XPath semantics or a regular expression pattern. Finally, JBoss ESB also supports using JBoss Smooks for content-based routing. Smooks is the best choice if you also want to perform tasks such as message splitting as part of the content-based routing. We will also look at the JBoss ESB-Smooks integration later in this chapter.
Let's look at an example.