Time for action – running the quickstart

Follow these steps to run the transform_XML2XML_simple quickstart:

  1. Change your current directory to the quickstart's directory samples/quickstarts/transform_XML2XML_simple.
  2. Deploy the quickstart using the ant deploy command.
  3. Before running the quickstart, review the original message that is used by the quickstart. Note the 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>
  4. Run the quickstart using the ant runtest command.
  5. Review the quickstart's output in the 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>].

What just happened?

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.

Routers

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:

  • Aggregator:

    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)

  • EchoRouter:

    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.

  • HttpRouter:

    org.jboss.soa.esb.actions.routing.HttpRouter This router sends the incoming message to an HTTP URL that you define in the action.

  • JMSRouter:

    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.

  • StaticRouter:

    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.

  • StaticWiretap:

    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.

  • ContentBasedRouter:

    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.

..................Content has been hidden....................

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