4.2 Applications Bend, but Don't Break An application and its external data representation can be extended without breaking the links between it and the other applications it shares data with. XML is extensible, in that portions of an existing XML document can be modified or enhanced without affecting other portions of the document. For example, additional data elements and attributes can be added to a portion of an XML document, and only the application that will be accessing that new element needs to be modified. Other applications that don't require the extended data can continue to work without modification. Let's explore this point by examining a scenario. Say you need to increase the operational efficiency of a supply chain. In a supply chain that moves billions of dollars of goods per year, even a nominal increase in operational efficiency, such as reducing the time from order placement to delivery of goods to receipt of payment, can have an impact of millions of dollars in savings per year. Improving the time it takes to fulfill the actual order can be a significant factor in reducing the overall cycle time in the supply chain process. In this scenario, improving the order fulfillment time involves adding more details to the shipping address. With XML, we can extend data without adversely affecting all the producing and consuming applications that need to exchange that data. Consider the following XML fragment, which represents the body of message M1: <ShipInfo > <Address> <Street>...</Street> <City>...</City> <State>...</State> <PostalCode>...</PostalCode> </Address> </ShipInfo>
XML is extensible in that a data element may have attributes added to it, such as serviceLevel="overnight" in the following listing: <ShipInfo serviceLevel="overnight" > <Address> <Street>...</Street> <City>...</City> <State>...</State> <PostalCode>...</PostalCode> </Address> </ShipInfo>
This attribute is additional information, but for applications that don't know about serviceLevel, its existence is unimportant. The structure didn't change, the values didn't change, so it's all good. Another simple thing we can do to decrease the overall time of the order fulfillment process is to upgrade the shipping address data to make use of nine-digit postal codes instead of just the five-digit prefix. (The U.S. postal code routing system requires that a minimum five-digit postal code be used. An optional four-digit predicate allows the postal delivery service to more efficiently route the package to its destination.) A simple business requirement such as this can be the driver for why applications need to change to produce and consume the new data formats. In our postal code example, this requirement is driven by the consuming applications, such as the ones responsible for the logistical processing (e.g., printing the shipping labels). To support the full nine-digit postal code, we need to make changes to the data structures themselves. The following listing shows message M2 with an additional Plus4 that represents the optional additional four digits: <ShipInfo serviceLevel="overnight" > <Address> <Street>...</Street> <City>...</City> <State>...</State> <PostalCode> 01730 <Plus4>????</Plus4> </PostalCode> </Address> </ShipInfo>
The process by which message M1 becomes M2 by adding the Plus4 element across all applications can be done incrementally. This is largely driven by the requirements of the receiving applications that need to consume the data with the enhanced format. In some cases, the Plus4 element may not be necessary. For example, the invoicing application that generates the itemized invoice containing the ShipTo address could do without the Plus4 information. Eventually, it may be nice to have it there for consistency's sake, but the urgency to upgrade that application is not as high as extending the application that prints the physical shipping label. XML thus reinforces the ESB philosophy of "leave and layer," allowing you to selectively upgrade interfaces and data structures as time permits. To illustrate this point, let's consider a simple example of two applications, X1 and Y1, which exchange message M1 (Figure 4-1). Figure 4-1. Simple XML exchange between applications 
Now let's say that a new application, Y2, needs to consume the new data as represented by message M2, as illustrated in Figure 4-2. Figure 4-2. Modified XML can be read by old applications in some cases 
Assume that a new business requirement is introduced where the receivers need to process the extended data, message M2, which includes the Plus4 element. The new application, Y2, needs to process the extended address data as represented by message M2. The producing application, X2, has been upgraded to send the new datatype, but one of the consuming applications can't be upgraded until there's room in the budget. This is OK, provided that the receiving application was written using XPath, DOM, or SAX parsers to extract the data. Introduction to XPath XPath is an expression language for accessing nodes in an XML document. It allows the use of XML element names separated by forward slashes (/) to delineate the hierarchy of XML elements. Regular-expression pattern matching is also possible to identify levels in the XML element hierarchy. Consider the following XML fragment: <?xml version="1.0"?> <A> <B x="1">aa</B> <C x="2" y="3">bb</C> <C x="4" y="5" z="6">cc</C> <D y="7"> <E z="8">dd</E> </D> </A>
The following table shows the results of applying an XPath operator to that XML fragment: Operator XPath Expression Result = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = / /A/B <B x="1">aa</B> @ /A/B/@x 1 [ ] /A/C[@x=4]/text( ) cc // //@z 68 * /A/*/@x 124 . /A/C/@x[.=2] 2 .. /A/D/E/../@y 7
XPath also allows the use of inline scripting functions to perform runtime evaluation of XML items. For example: normalize-space( ) - ignores whitespace such as newlines, tab characters, etc. concat( ) - concatenates the results of XPath expressions. text( ) - returns the content of an XML element as text.
|
If the application or the routing logic is using XPath to examine the contents, it doesn't matter whether the message is structured as M1 or M2. The XPath expression to access PostalCode is the same: normalize-space(/ShipInfo/Address/PostalCode/text( )) 01730
But applications that know the extended structure of M2 can access the additional element: normalize-space(/ShipInfo/Address/PostalCode/Plus4/text( ))
To access the full element as 01730-1234, the following XPath expression can be used: concat(normalize-space(/ShipInfo/Address/PostalCode/text( )),'-', normalize-space(/ShipInfo/Address/PostalCode/Plus4/text( )))"
The intrinsic extensibility of XML combined with best practices for extending an XML schema and for accessing the data in XML provides the ESB with a loosely coupled data model. This loosely coupled data model is a key aspect of the ESB, with significant benefits for development, deployment, and maintenance of the integration infrastructure. Because of the extensibility of XML, producers and consumers of XML messages can be upgraded independently of one another to deal with the extended data structure. X1 can begin to send message M2 without any changes to either of the consumers; consumers Y1 and Y2 can be upgraded to process M2 independently of each other and of the producers. This scenario will work even if all the producers are not updated in tandem with the consumers. Because XML parsing technology is largely event-driven and data-driven, a receiving application can be written such that the additional information (in this case, Plus4) will be processed only if the data in the XML message contains it. This means that if an element is not present, there is no error! Now, you might say that building a system in which missing data is not an error is bad design, and there is some truth to that. But the ESB will help you handle these business rules too. There are cases in which incomplete data is acceptable, and should not generate a fatal error. The "business rules" surrounding the use of a postal code is a good example. The use of the Plus4 element of a postal code means that efficiency and expediency of delivery of the physical goods can be improved. However, if the application that receives message M can use only the five-digit postal code, it's not fatal to the application. The package will still get to its destination, just not as efficiently as it would using the nine-digit postal code. | 