Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup

h2. Introduction
The [Examples|http://www.servicemix.org/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|#Basic Use Case]
* [File Binding|Business Use Case for the File Binding Example]

h2. {#Basic Use Case} 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|http://www.jcp.org/en/jsr/detail?id=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|http://docs.codehaus.org/display/SM/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 ^1^ 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:

# 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). ^3^
# The _OrderReceiver_ sends the message to an _OrderRouter_ service engine (SE) ^4^ 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).
# 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.
# 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.
# Each _OrderTransformer_ sends the modified message to the _OrderProcessor_.
# 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.
# The message on the topic is subsequently picked up by the _BusinessMonitor_ component via the _jmsTrace_ component. 
# The _BusinessMonitor_ component monitors the orders for quality assurance and business analytics, such as data mining.


The following diagram illustrates the procedure outlined above:
{panel:title= Department Store Distributor's Order Processing System|borderStyle=solid|borderColor=#ccc}
!basicflow_as_usecase.jpg|align=center!
{panel}


# _External_ means the application is outside of the ESB.
# _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.
# _Binding Component (BC)_: a BC provides connectivity to applications that are external to the ESB.
# _Service Engine (SE)_: a service engine provides business logic and transformation services to other components within the enterprise service bus.


h2. [#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:
{panel:title= Online Distributor's Order Processing System|borderStyle=solid|borderColor=#ccc}
!filebinding_as_usecase.jpg|align=center!
{panel}

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 Use Case 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 1 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). 3
  2. The OrderReceiver sends the message to an OrderRouter service engine (SE) 4 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:

Panel
borderColor#ccc
titleDepartment Store Distributor's Order Processing System
borderStylesolid

Image Removed

  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:

Panel
borderColor#ccc
titleOnline Distributor's Order Processing System
borderStylesolid
Image Removed