Enterprise Service Bus: Theory in Practice

Let's now take some of these concepts and put them to practical use by examining the details of a partner integration in the manufacturing supply chain area. This is a continuation of the case study introduced in Chapter 3, in which a manufacturer deploys an ESB to link itself with its distributors and implement improved inventory management and an Availability To Promise (ATP) system.

This manufacturer chose to deploy ESB service containers at the remote partner sites. As illustrated in Figure 8-16, secure JMS-based MOM links connect the partners with the main supplier. The secure MOM link carries xCBL-formatted XML documents across the ESB to the inventory application, which is linked into the ESB using an SAP business connector.

The manufacturer chose to use xCBL (Common Business Library) as an internal standard canonical format for representing XML as it flows across the bus. The benefits of establishing a common XML dialect within and across the ESB are discussed in Chapter 4. xCBL is a standard for describing things such as addresses, purchase orders, and so on, and was jointly developed by SAP and CommerceOne during the days of dotcom and public exchanges. Like many other standards efforts, xCBL has not dominated the XML industry. However, because it was codeveloped by SAP, the message schema has a high degree of affinity to SAP's IDOC (Intermediate Document) elements and terminology. For this reason, xCBL was a good choice for them to make, as it simplified the writing of custom adapters.

8.3.1 Secure DMZ Deployment

The secure MOM link is enabled by deploying a clustered ESB message broker in the DMZ (De-Militarized Zone). As illustrated in Figure 8-17, the ESB message broker is securely deployed between an "external" firewall and an "internal" firewall. The external firewall allows only SSL connections into the ESB message broker, which are mutually authenticated between the remote ESB containers and the ESB broker using digital certificates on both ends.

The internal firewall is configured to allow traffic only between the ESB message broker in the DMZ and the ESB message broker behind the firewall of the manufacturer. This link can be either another authenticated SSL channel or a plain TCP connection listening on a preconfigured port. This depends entirely on individual security policies and comfort levels on a per-organization basis.

The message channels are restricted by ACLs, which allow only authenticated partners to read and write designated message queues and topics.

Because the brokers are clustered together, they automatically route messages between the brokers as necessary to get the message to where it needs to go. This configuration is transparent to the level of coordination that occurs at the ESB endpoints. An ESB business process coordinates the routing of messages between the partner and the ESB endpoint that represents the SAP adapter.

8.3.2 Availability To Promise (ATP)

Meanwhile, implementing the ATP function as a separate project, the manufacturer. decided to use a direct web services link between itself and its distributors (Figure 8-18).

The distributor applications send a SOAP message containing an xCBL AvailabilityCheckRequest document as a payload in an HTTP POST request to a proxy server that is sitting in the manufacturer's DMZ. According to the proxy's rules, that request is forwarded to an "HTTP direct" listener on the internal ESB message broker that has been configured to place incoming messages onto a message queue. The message queue transport provides a special XML message type that allows it to carry SOAP messages, or multipart-MIME messages that can carry XML along with other types of opaque binary data. On the other side of that message queue is a custom ESB service that serves as an adapter to the SAP application that performs the ATP lookup.

In this case the incoming HTTP listener is set up to perform a synchronous request/reply. While the ESB is by and large intended to be asynchronous in nature, it is also capable of carrying synchronous request/reply messages from an HTTP request, across a MOM queue (or pub/sub topic), through an adapter, and back again with a reply.

8.3.3 The SAP Adapter: A Custom ESB Service

At the other end of the ATP queue is a custom ESB service, written in Java, which acts as an adapter into the SAP system. This is an alternative approach to the adapter strategy that was used in the inventory scenario. Here, the ESB service receives a message that is delivered as an xCBL-formatted XML document.

The service is configured with multiple listeners, each on its own separate listener thread. The service happens to use Castor for the Java<->XML binding, which is used to unmarshal the document in preparation for invoking an SAP Remote Function Call (RFC). The service uses the SAP Java Connector (also known as JCo) library to do the RFC invocation (Figure 8-19).

With the help of the JCo library, the ESB service manages an SAP connection pool. The ESB container thread ID becomes the SAP connection poolname. The SAP connection parameters are configured administratively as ESB container initialization parameters.

The service invokes the appropriate SAP RFC to perform the AvailabilityToPromise request, and waits for a synchronous reply to occur. To create the reply to the ATP query, an xCBL 3.5 AvailabilityCheckResult document is retrieved from the ESB directory service. Using the results of the SAP RFC call, the AvailabilityCheckResult document is populated using the setter methods on the Castor object that represents it. The Castor object is then marshaled to the ESB container's outgoing exit endpoint, which is configured to use a default ReplyTo endpoint. The ReplyTo endpoint is in turn routed back to the HTTP direct listener, and back to the distributor system as an HTTP reply to the POST. Figure 8-20 illustrates the round-trip process end to end.

8.3.4 EDI Transportation and Transformation

A fair number of the manufacturer's partners are already accustomed to communicating using EDI. In order to continue to provide the same EDI interface with the partners in a nondisruptive fashion yet still migrate toward an ESB enablement, the manufacturer chose to continue using the EDI VAN between the partners and headquarters (for now). Once inside the manufacturer's headquarters, the EDI messages are placed onto the bus using a custom ESB service that acts as an EDI gateway (Figure 8-21).

The custom service places an EDI X12 document onto a reliable message queue, which then gets routed to another ESB service that has been set up for the purpose of interfacing with an EDI translator. In this case it is using a third-party EDI translator called Inovis Trusted Link Enterprise (TLE). TLE converts the X12 message to an SAP IDOC message, which then gets sent on to the SAP application for processing.

8.3.5 Removing the Dependency on the EDI VAN

Over time, the use of the EDI VAN can be eliminated completely by using a remote ESB container directly at the partner site; this container can be used to transfer the EDI data over a secure, reliable ESB channel. In Figure 8-22, the partner system has an EDI translator linked to its JD Edwards application. Using a custom ESB service type that acts as an EDI gateway, EDI documents are placed onto a JMS queue to be transported securely and reliably through the ESB to headquarters.

The EDI gateway at the partner site is a custom ESB file-drop service. This service knows how to read and write files to and from a filesystem directory that is shared by the file-drop service and the ERP system's EDI interface, as illustrated in Figure 8-23.

The JD Edwards application at the partner site doesn't need to know that it has just joined into an ESB infrastructure; it simply continues to interface with the EDI translator that it is linked to. The EDI translator, which has a filesystem interface built into it, doesn't need to know either. It simply reads and writes EDI messages from and to a filesystem directory. The ESB picks up the EDI message from the deposited file and places it on a reliable message queue to be delivered to one or more destinations within the manufacturer's headquarters.

8.3.6 Looking Ahead

With all of the connection options, data formats, and adapters into SAP, the manufacturer could benefit tremendously by adopting a generic data-exchange architecture, as described in Chapter 4. They are already partially there by having adopted xCBL as the data format for much of the data that travels through the bus. In some cases, such as the EDI interface, the data remains in the X12 format throughout its journey.

So far, we have examined two ways of exchanging data with partners (a remote ESB container and web services), two different formats for carrying information from the source to the destination (xCBL and X12), and three different ways of linking into SAP, all of which were done using a custom ESB service (SAP business connector, Castor/JCo/RFC connector, and Inovis TLE).

Since the ESB also supports a pure web services-based SOAP listener, they could have had a deployment that looks more like Figure 8-17 (the secure message broker in the DMZ). This has the clustered broker in the DMZ enabled as an HTTP direct listener, which speaks cross-cluster to another broker inside the firewall.

The interface to SAP and JD Edwards applications happened to use a combination of simple custom solutions, but it could have used a third-party adapter designed for a more general-purpose integration into those respective ERP systems.

This highlights one of the strong points of the ESB the flexibility to connect and send data across the bus using the best means for the particular situation, instead of trying to build a one-size-fits-all solution. In addition, the manufacturer now has a set of generic approaches and ESB service types that can be mixed and matched to suit their needs.