Enterprise Service Bus: Theory in Practice

So far, we have been focusing on the generic benefits of using XML as the means for exchanging data between applications. The generic benefits of data-driven parsing technology and XPath expressions for pattern matching can provide a certain degree of loose coupling between applications, and allow for some improvements in data structures over time without forcing a simultaneous upgrade of all the applications concerned.

XML can provide a great deal of resilience to changes in applications, as long as you're just adding data or enhancing structure, and not actually changing the structure. However, this can get you only so far. What's important to understand about the previous example is that the PostalCode field still has its original raw data, but now it also has additional element field names that help to structure PostalCode data for use separately. The structure changed it got richer but the ability to access the PostalCode field remains basically the same in both versions of the message.

We can improve upon this by applying some basic ESB concepts: a business process definition, content-based routing, and data transformation. All of these concepts are inherently part of the ESB.

A business process definition represents a series of steps in a flow between applications. For example, a purchase order document might follow these basic, logical steps: credit check, inventory check, order fulfillment, and invoice (Figure 4-3).

In the ESB, these steps may be mapped into service endpoints that represent physical applications. Using a business process definition, it is possible to administratively insert additional steps into that path of control flow, without modifying the applications directly.

What kinds of things might you insert into a business process? In the PostalCode example, the components would be specialized services that can alter the path or otherwise affect the content of the message. The path of execution, or the message flow, between the producers and the consumers can be augmented by adding a transformation service into the business process.

Let's assume that we have shut down Y_1, and Y₂ is the only version running (Figure 4-4). However, X₁ (the original application) must remain online for another year, waiting for the allocation of money and time to upgrade it. There needs to be a strategy for keeping X₁ working, and still satisfying the extended information needs of Y₂. This can be accomplished by inserting a transformation step into the message flow between X₁ and Y₂.

Transformation is performed using a stylesheet language called XSLT (eXtensible Stylesheet Language Transformation). XSLT can restructure XML documents from one format to another, as well as transforming or enhancing the content. By applying an XSLT transformation, application X₁ can still send document M₁, as long as the transformation from M₁ to M₂ is done before the data arrives at Y₂ (Figure 4-4).

In the future, when X₁ is upgraded to behave like X₂, this transformation won't be necessary.

For this XML transformation to work, it needs to make an external call to a database lookup using the street and city to obtain the extended Plus4 element. Advanced lookup capabilities using XQuery will be explored in later chapters.

What we've seen so far is that by combining the extensibility of XML and the transformation power of XSLT processing services that are inherently built into the fabric of the ESB, we can provide resilience to change in more complex situations. While this approach has its merits, it doesn't necessarily work well as the problem starts to scale up. The downside of this approach is that it requires direct knowledge of each point-to-point interaction between the various flavors of X and Y applications, and of when and where message M₁ must be upgraded to M₂. What happens when message type M₃ is introduced?

This process can be further automated and generalized by introducing another ESB concept, Content-Based Routing (CBR). A CBR service can be plugged into the message flow between the producer X₁ and the consumer Y₁. This CBR service can be a lightweight process with the sole purpose of applying an XPath expression, such as the one used in our example, to determine whether the message conforms to the format of M₁ or M₂. If the message is of type M₁, it can be routed automatically to another special service that fills in the missing pieces of data (Figure 4-5).

This transformation service can apply some simple rules to convert the five-digit postal code to a nine-digit format. The method by which this is done depends on the implementation of the service. It can be done simply by writing code to do a table lookup based on some values stored in a database, or implemented as an XSLT transformation that applies a stylesheet to produce the desired result. It can even make a call to an external web service using an outbound SOAP request. Structured integration patterns for performing Validate, Enrich, Transform, (Route,) and Operate (VETO, VETRO) will be explained in Chapter 11.

Inserting the routing and transformation into the process between the producers and consumers of the postal code gives us an advantage that we didn't have with XML alone. Through a sequence of inspection, routing, and transformation combined with the use of XML documents, we can handle a wide array of complex integration tasks and add a great deal of resilience to changing data in the underlying applications. We can also think about these formats, routes, and transformations separately from the underlying applications.

The integration architect can use the ESB's process management and XML processing facilities to improve the message data without ever modifying the sending applications. Using this model, only the consuming applications need to be modified to support the improvement in data. And as we have seen, not all the consumers need to be upgraded either. For the ones that do, the upgrade can happen independently of the data translation upgrades, allowing greater flexibility in the coordination of development timelines of the applications that are driving the requirement.