Time for action – implementing content-based routing

The fun_cbr quickstart performs content based routing, where the contents of a message dynamically "fire" procedural rules defined in JBoss Drools to determine the message's route. The quickstart action chain, including message routing, is initiated when a JMS message is inserted into a queue on which a JMS gateway listener is monitoring. When the gateway detects the message, it passes it to an ESB-aware listener, which in turn passes the message to the routing action. Based on the contents of the message, the message is delivered to one of three destination JMS queues.

Follow these steps to run the quickstart:

  1. Like most of the other quickstarts, fun_cbr is deployed using the ant deploy command.
  2. Running this quickstart, however, is a little different. As we mentioned earlier, messages, based on their content, are routed to one of three output queues. Each of these queues is monitored by a client. Each client represents one of three teams of order processors named for colors; red, blue, and green. When a client detects that a message has been received, it displays the message. So, before you run the quickstart, you have to open up three terminal windows, and start a client in each of them with one of these commands:
    ant receiveBlue
    ant receiveRed
    ant receiveGreen
    
  3. The clients have been started, now let's run the quickstart:
    ant runtest
    

What just happened

In its out of the box configuration, the quickstart sends a message to the blue team. The message routing depends on the statusCode attribute in the SampleOrder.xml file from which the input message is generated. The message starts in the form of a SOAP request as is seen in SampleOrder.xml. The output shown by the receiveBlue client looks like this:

receiveBlue: [echo] Runs Test JMS Receiver
[java] Receiving on: queue/quickstart_Fun_CBR_Blue_Alert
[java] 11:18:09,506 DEBUG [main][TimedSocketFactory] createSocket, hostAddr:
                localhost/127.0.0.1, port: 1099, localAddr: null, localPort: 0, timeout: 0
[java] Initialised
[java] *********************************************************
[java] <Order xmlns="http://org.jboss.soa.esb/Order" orderId="1" orderDate="Wed
                Nov 15 13:45:28 EST 2006" statusCode="0"
[java] netAmount="59.97" totalAmount="64.92" tax="4.95">
[java] <Customer userName="user1" firstName="Harry" lastName="Fletcher"
                state="SD"/>
[java] <OrderLines>
[java] <OrderLine position="1" quantity="1">
[java] <Product productId="364" title="The 40-Year-Old Virgin " price="29.98"/>
[java] </OrderLine>
[java] <OrderLine position="2" quantity="1">
[java] <Product productId="299" title="Pulp Fiction" price="29.99"/>
[java] </OrderLine>
[java] </OrderLines>
[java] </Order>

Have a go hero

To get a better idea of how content-based routing works, change the status code in the quickstart's SampleOrder.xml to a value of 1 or 2 and watch the message be routed to the green and red clients. But, don't stop there! Try your hand at modifying the rules that govern the quickstart's message routing.

Notifiers

How do you move an ESB message out of your service into ESB-unaware services like a JMS queue, a file, or a SQL table? Notifiers convert ESB-aware messages into data in a format these services can understand.

Notifiers are specified within a NotificationList, which allows you to specify more than one notifier at the same time. This allows you to notify multiple targets, like a JMS queue and the console.

Note that notifiers are to be used only to communicate with ESB-unaware services. Do not try to notify JMS queues that contain ESB-aware messages.

Another thing to note is that while the action pipeline generally works sequentially, it has two stages—normal processing and outcome processing. Notifiers do not perform any processing of messages during that first stage of "normal processing". They send notifications during the second stage. The notification occurs after the processing of the action pipeline, in the outcome processing phase. This means that you should be careful when designing your action chain that you understand that if you place actions in a chain subsequent to a notifier, those actions might be performed before the notifier.

The following notification targets (the names are very self-explanatory) are supported by the JBoss ESB:

  • NotifyConsole: Prints the contents of the ESB message to the server log
  • NotifyFiles: Prints the message contents to a file or files
  • NotifySQLTable: Inserts the message contents into an existing database table
  • NotifyFTP: Prints the message contents to a file and then sends the file to a server via FTP
  • NotifyQueues and NotifyTopics: Writes the message contents into a JMS message and adds the JMS message to a specified JMS queue or topic
  • NotifyEmail: Sends the message contents in a mail message
..................Content has been hidden....................

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