Use Cases (whole)

Introduction

The examples provide coding level details for implementing particular aspects of ServiceMix. This document extends the coding examples into their business use. The following use cases are documented:

• Basic
• File Binding
• BPEL Binding
• JMS Binding
• HTTP Binding
• Quartz Binding
• RSS Binding

Business Use Case for the Basic Example

ServiceMix is an Enterprise Service Bus (ESB) that is based on the Java Business Integration (JBI) standard JSR 208. The JBI-based design specifies a standards-based pluggable architecture with a JVM-based runtime component called the Normalized Message Router (NMR). The Basic example demonstrates how applications communicate via the ServiceMix ESB, and the role that the NMR plays in that communication. Similar techniques could be used to plug any external ¹ application or service into ServiceMix (e.g. SAP, Peoplesoft, spreadsheets, POJOs, Webservices and EJBs) and allow it to communicate with other external applications or components using ServiceMix.

A hypothetical business scenario, which extends the Basic Example, is that of a department store distributor. This distributor sells products from multiple wholesalers (suppliers) to various retailers (customers). The distributor presents a common interface for product ordering to each of its department store customers. However, the distributor must work with a different ordering interface for each wholesale suppliers for the products they are buying for distribution.

Using an ESB, the distributor has developed a number of components to receive department store orders and then dynamically route and transform these orders to the appropriate wholesaler. The order processing flow is described as follows:

1. Using the distributor's web interface, a department store customer submits an order for multiple products. An HTTP request is sent to the OrderReceiver, an HTTP binding component (BC). ³
2. The OrderReceiver sends the message to an OrderRouter service engine (SE) ⁴ component. This SE is responsible for parsing the order and deciding, based on the message content, which OrderTransformer should receive which part of the message (i.e., an order for a product).
3. The OrderRouter publishes the orders to the appropriate message topics based on the message content. Specifically, the OrderRouter publishes the messages based on which wholesaler sells the item.
4. The OrderTransformer is a service engine component, which modifies the message and puts it in a format which is readable by the wholesaler interface that will fulfill the order.
5. Each OrderTransformer sends the modified message to the OrderProcessor.
6. The OrderProcessor is a binding component that has two functions:
   a. It places an order to the appropriate wholesaler through the wholesaler's Webservice or proprietary interface.
   b. It also publishes a message about the order on a topic.
7. The message on the topic is subsequently picked up by the BusinessMonitor component via the jmsTrace component.
8. The BusinessMonitor component monitors the orders for quality assurance and business analytics, such as data mining.

The following diagram illustrates the procedure outlined above:

1. External means the application is outside of the ESB.
2. Resource Adapter: a resource adapter provides connectivity between a specific external application and the ESB. In the Basic example the jencks container provides a JMS resource adapater.
3. Binding Component (BC): a BC provides connectivity to applications that are external to the ESB.
4. Service Engine (SE): a service engine provides business logic and transformation services to other components within the enterprise service bus.

Business Use Case for the File Binding Example

The file binding example shows how components of ServiceMix can interact with the file system. This is important because there are applications that write files out to a directory on disk and other applications that may need access to those files. This is a simple example of how a ServiceMix component can read a file from the disk, process it into a normalized message, then send it via the NMR to another ServiceMix component. The receiving component can process the message (which contains the file) and write it out to another location on disk.

A hypothetical business scenario: An online wholesale distributor of books and music CDs, receives a nightly order from a retail store. The nightly order is transmitted to the distributor as a file and placed in a particular directory on disk. There is a ServiceMix component (getOrders) that continually scans that directory looking for order files. When it sees a file, it reads it from the disk, then transforms it into a normalized message. It sends the message over the bus (NMR) to another component called "placeOrders." The placeOrders program divides the order into separate orders for its' suppliers, e.g., one order will be placed with the distributor's book supplier, one order will go to the CD supplier, etc. At some later point, the suppliers will log in and retrieve their order files - this is not shown here, but can have an automatic or manual implementation and this process could also be integrated with ServiceMix.

The following diagram illustrates this:

Business Use Case for the BPEL Example

The BPEL example shows how to integrate the PXE BPEL Engine with ServiceMix. Business Process Execution Language (BPEL) defines a notation for specifying business process behavior based on Web Services. PXE is a runtime component for executing processes defined by the BPEL4WS 1.1 specification and forthcoming WS-BPEL 2.0 OASIS standard. The PXE BPEL engine uses JMX to provide management and introspection functionality.

A hypothetical business scenario, which illustrates the BPEL example, is a travel agent airline ticketing system that offers online reservations to its customers. When a customer books a flight, the reserveTicket class of the online ticket reservation system publishes its request to the ticketing topic. The Binding Component, which is capable of communicating both to the external reserveTicket class and the Airline Reservation System, is a subscriber to the ticketing topic and thus receives the request. The Binding Component then forwards the request via the NMR to the Airline Reservation System inside the PxeBpelEngine service container. The Airline Reservation System checks its database to see if it can still accommodate the request and generates a response. After that, the Airline Reservation system sends the response back to the Binding Component again via the NMR. The Binding Component then publishes it on the ticketing topic. The reserveTicket class is also a subscriber of the topic and thus receives the message. Whether the request is granted or not, the reply is published to the customer.

The following diagram illustrates this:

Business Use Case for the JMS Binding Example

The JMS Binding example shows how to connect the JMS bindings to a simple service component inside ServiceMix.

A hypothetical business scenario, which encompasses the JMS Binding example, is that of a web application making a request for a Tax ID Number (TIN). This example is based on a web-based Tax ID Application form, in which a user enters data, such as first and last name, date of birth, and place of birth. The web Tax ID Applicatoin form sends the request to the "JMSServlet" servlet. The servlet publishes the request on the JMS submission topic. The applicationFormReceiver, which is a JMS Binding component that subscribes to the submission topic, receives the request. The applicationFormReceiver sends the data to the formProcessor via the Normalized Message Router (NMR). The formProcessor is a service engine that assigns the appropriate TIN to the user. The formProcessor then publishes the response to the result topic. A Message Driven Bean (MDB) then subscribes to the result topic, receives the response message, updates the Tax ID database with the new TIN, and notifies the user that the request has been fulfilled. The user can then check the database to get the requested TIN.

The steps below detail the workflow outlined above:

1. The user fills in the web Tax ID application form, entering data such as first and last name, date of birth, and place of birth, etc.
2. The web form submits the request to a servlet running in an application server.
3. The JMSServlet creates a record for the submitter in a database table. Let's say the table contains a RECORD ID, USERNAME and TAXID fields.
4. The servlet then responds to the user with a page that has a message and a link. The message says, "Check your email for a message that will contain a link for checking TIN status." It also sends an email to the person with a link that says "Click here to retrieve your record." The link contains the record ID and points to a JSP or servlet that can retrieve the user's record. Initially the TAXID field will say "PENDING".
5. The JMSServlet then publishes the request to the submission topic.
6. The applicationFormReceiver, which is a JMS Binding component that subscribes to the submission topic, receives the request.
7. The applicationFormReceiver creates a normalized message and sends it to the formProcessor via the NMR.
8. The formProcessor assigns the appropriate TIN to the user. The formProcessor then publishes the response to the result topic.
9. A MDB is also running in the same application server as the servlet. The MDB is listening on the Result topic for the result from the formProcessor.
10. When the MDB reads the TIN, it updates the user's record in the database.
11. Now, when the user clicks the link, the TAXID field will have the TIN and it will no longer say, "PENDING"

The diagram below illustrates the process described above:

Business Use Case for the HTTP Binding Example

The HTTP binding example shows how to use the HTTP bindings to handle a simple http post.

A hypothetical business scenario, which illustrates the HTTP Binding example, is that of a Department of Public Works Online Project Monitoring System. The head engineer uses this web based system to check the budget availability for a work item. Only if there is sufficient budget for the work item will it be implemented.

This example starts at the isBudgetAvailable class of the Department of Public Works Project Monitoring System when it posts a request on URL http://localhost:8912. Included in this posted request, is the budget allocation ID of the related work item. The HTTP Server listens on this URL and receives the request. The HTTP Server then forwards the request to the Saaj Binding Component, as this component is capable of communicating to an UrlEndpoint. The UrlEndpoint is the Budget Checking System. The Budget Checking system checks to determin if the funding level is still sufficient for the implementation of the work item, then formulates the appropriate response and sends the response back to Saaj Binding Component. In turn, the Saaj Binding Component sends the response back to HTTP receiver via the normalized message router. The HTTP receiver then sends the message to the http://localhost:8912. The message is picked up by the isBudgetAvailable class. Finally, the respone message is printed on the console.

The following diagram illustrates this:

Business Use Case for the Quartz Binding Example

The Quartz binding example shows how to use Quartz timer.

A hypothetical business scenario, which illustrates the Quartz Binding example, is a network status monitoring system that will prompt System/Network Administrators when a network connection becomes disconnected. Every 5 seconds, the timer component will invoke a service that will determine whether or not the network is connected. If a problem is found this monitoring system will alert the Network Administrators.

The following diagram illustrates this:

Business Use Case for the RSS Example

The RSS binding example shows how to use the RSS bindings to poll RSS feeds for updates. RSS is an XML format designed for sharing web content between sites.

A hypothetical business scenario, which uses RSS, is a web site constantly polling RSS feeds for its "What's New" section. Whenever rssPoller detects a change in one of the RSS feeds, rssPoller will send an updated list of URLs to displayNewSites. The displayNewSites component will then auomatically update the web site's "What's New" section accordingly.

The following diagram illustrates this: