| 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). Figure 4-3. An ESB business process definition combines a series of logical steps 
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 Y1, and Y2 is the only version running (Figure 4-4). However, X1 (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 X1 working, and still satisfying the extended information needs of Y2. This can be accomplished by inserting a transformation step into the message flow between X1 and Y2. 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 X1 can still send document M1, as long as the transformation from M1 to M2 is done before the data arrives at Y2 (Figure 4-4). Figure 4-4. XML transformation service converts message M1 to message M2 
In the future, when X1 is upgraded to behave like X2, 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. Extending XSLT XSLT extensions can be used to make callouts to external code. Depending on the XSLT processor, calls can be made to Java, JavaScript, C#, or VBScript. A stylesheet can be used to supply the template for the PostalCode and Plus4 conversion, and scripting code can be written to do a table lookup or make a web service invocation. If the data being used to enrich the content is stored in an XML file, web service, or XML database, XQuery can be used as a replacement for XSLT. Depending on the maturity of the tools that are supplied with the ESB, the creation of the XSL Transforms and XQuery expressions can be supported through development tools that support these languages. |
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 M1 must be upgraded to M2. What happens when message type M3 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 X1 and the consumer Y1. 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 M1 or M2. If the message is of type M1, it can be routed automatically to another special service that fills in the missing pieces of data (Figure 4-5). Figure 4-5. Content-based routing can identify the need for transformation 
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. |
