3.2 The ESB in Global Manufacturing

   

A global company in the manufacturing sector is an example of an end-user IT organization that helped to catalyze the ESB. This manufacturing company is made up of at least five different major business units located around the world. Their goal was to have a common integration backbone based on message-oriented middleware infrastructure and standards-based interfaces. This effort was started and restarted several times, and had a resurgence of interest a few years ago, when the Java Message Service was first introduced as a way of providing standard interfaces to a common messaging backbone. This manufacturing company had many "islands of integration" and departmental pockets of proprietary and third-party message buses, which had been installed and controlled at a departmental or business-unit level. The requirement was that all departments and business units be integrated with each other to form a more consistent environment in which to plug in applications.

Their IT organization was looking to JMS to provide a standardized interface and common behavioral semantics across all applications, across all departments, across all business units. While many of us in the JMS business were excited about this, the reality is that JMS alone can't meet that requirement. The company also needed integration broker functionality such as routing based on rules and data transformation, all based on an abstraction of loosely coupled shared service interfaces.

At the time, the manufacturing company was faced with a dilemma caused by several things. While JMS had been selected as part of the solution, not all of the messaging vendors supported it. The existing messaging vendors and integration broker hubs that were entrenched in the various business units couldn't support the highly distributed approach required to span across global business units in a reasonable and manageable way. Some of the newer messaging vendors had the right JMS support, as well as the right security, firewall traversal, and message broker clustering to support the distributed topologies required to bring the geographically dispersed business units of the company together. However, there was no model in place for a service abstraction layer upon which to build an SOA, nor did the rest of the integration-stack layers exist that were required to integrate all of those applications across the organization.

Some of the forward-thinking IT leaders in this manufacturing company started working with the forward-thinking JMS and MOM providers. Through the course of such work in this global company and in others like it, many of the details of what eventually grew into early blueprints for the ESB were fleshed out.

The need was identified for a loosely coupled design center of event-driven services that could be coordinated across a common middleware substrate. The solution was to define a stack of functionality that consisted of a standards-based integration backbone, making use of JMS, SOA, XML, transformation and routing, and adapters. This approach went a long way, but still couldn't solve the connectivity issues.

The IT architects at the company realized that they couldn't just make a mandate saying, "On this date, all applications will be required to support JMS." It just was not practical. The same can also be said for web services. IT staff is too busy just trying to keep up with their daily work to embark on a mission that takes every application across the organization and retrofits it into one particular connectivity style.

Common APIs and event-driven service interfaces are a core part of the design center of an ESB. However, diversity in connectivity options is critical to the adoption of an integration strategy. Another need that was identified was a way to bring the infrastructure to the applications, allowing the applications to plug into the infrastructure in whatever manner made sense for them and facilitating an incremental approach to adoption. This is how the requirement of multiple client types, connectivity protocols, application adapters, and MOM bridges became a core part of the definition of an ESB. The various IT departments across the business units needed to protect their investments in existing messaging and integration broker installations, and be able to reach the other corporate applications as shared services in a nonintrusive way.

3.2.1 Putting It to the Test

In an effort to provide customers, suppliers, and vendors with one unified view of their diversified business units, the manufacturing company embarked on a major strategic operations initiative. The goal of the initiative was to provide one-stop shopping for customer service, invoice and payment tracking, inventory management and ordering, and so on, as opposed to forcing constituents to deal with five different product units (Figure 3-2).

Figure 3-2. Loosely coupled, autonomous business units sharing a common integration backbone based on messaging and standard interfaces
figs/esb_0302.gif


The overall goal of the project was the creation of a single corporate IT backbone for integrating the payment processing applications across all the various product divisions worldwide.

The manufacturing company built its "payment automation" application on top of an early rendition of an ESB. This was the first test of the vision of a shared services network. The payment automation is based on an ESB-like implementation that serves as an enterprise-scale, centralized payment processing clearinghouse for all product divisions.

The payment automation backbone is a standard corporate payment service used by all divisions that allows the company to centrally manage, track, and clear orders for payment to vendors and suppliers worldwide. Because this project used an early ESB prototype, a corporate-wide payment service could be shared by all the business units, as a service plugged into the bus. Payment processing could now be routed through one shared business function, versus having to be cleared through a variety of geographically dispersed banks and banking systems.



Enterprise Service Bus
Enterprise Service Bus: Theory in Practice
ISBN: 0596006756
EAN: 2147483647
Year: 2006
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net