Enterprise Service Bus: Theory in Practice

   

XML, the eXtensible Markup Language, is accepted by the industry as the ideal vehicle for sharing structured data among applications and organizations. Putting aside for a moment the benefits of web services technologies such as SOAP and WSDL, there is much to be gained by simply adopting XML as the means for representing data that is shared between applications. XML has many benefits, including the following:

XML is becoming universally understood.

XML has become a lingua franca for representing data and interfaces between applications. Many packaged-application vendors provide inputs and outputs in XML. Think about your own applications and how they could better integrate and share data if they accepted and emitted XML.

XML provides a richer data model

The power of XML to represent data is one reason that it's been adopted so broadly. XML lets you model hierarchies, lists, and complex types directly in the data structure. This is in contrast to an RDBMS, which requires table joins, special schema features, and mapping routines to achieve the same thing.

XML makes data self-describing

XML embeds metadata that describes the hierarchy and data element names. This is the basis for XML parser technology that can use the tags and associated schema to identify elements of data by name and datatype.

XML is dynamic

An XML document is loosely coupled with its schema, unlike data structures in relational tables, which are hard-wired to their schemas. This means that programs that extract data directly from the XML structure using standard XML expressions such as XPath are independent of the schema and loosely coupled with the structure itself.

XML eliminates fixed formats

The order in which the data elements appear in a document doesn't need to be fixed. Each element can be of a variable length and can include a variable number of other fields.

When combined, these principles allow XML to encode the entire contents of a database all its tables, columns, rows, and constraints in a single XML file.

4.1.1 XML Is Human-Readable

Well, some would say that is up for debate, but it is certainly more human-readable than some of its predecessors, such as EDI. XML is generally readable by many tools. You can view XML documents in Microsoft Explorer, and most developer tools have viewers or editors for XML. XML is also writable. XML is well suited for integration tools that can visually create and manage sophisticated data mappings.

Any well-formed XML document is parseable by a variety of standard parsers. This contrasts starkly with most other data representations, such as EDI, which required specialized parsers based upon the type of data being represented.

Consider the following EDI fragment:

LOC+147+0090305::5' MEA+WT++KGM:22500' LOC+9+NLRTM' LOC+11+SGSIN' RFF+BM+933' EQD+CN+ABCU2334536+2210+++5' NAD+CA+ABC:172:20'

This is not very self-describing. It is also very fixed. In this case, we at least have an EDI standard that defines "LOC" and "NAD" as having special meaning, and the "+" operator has special syntactic meaning to something that is parsing and interpreting the data. However, many implementations of EDI emitters and consumers vary in interpretation, and are prone to interoperability issues.

When not using an EDI link, it is more common to have proprietary data formats that can be as simple as a comma-separated list of data:

0090305, 22500. NLRTM, SGSIN, 933, ABC

Inevitably, this data needs to be shared with other applications. It may be obtainable through some application-level interfaces, or it may be accessible only through an ETL type of dump and load. If you have some kind of schema to help recognize and parse the data, some custom data translation can be applied to get the data into an appropriate form for another application's consumption.

In contrast, data represented by XML is more readable and consumable. It is more easily read by humans, and easier to consume using parsing technology because it carries more context, or information about the nature of the content. Here is the XML equivalent of the previous EDI fragment:

<EDI_Message> <Address> <AddressType>Stowage location</AddressType> <AddressLine>0090305</AddressLine> <CodeList>ISO</CodeList> </Address> <Quantity> <QuantityType>Weight</QuantityType> <QuantityNumber>22500</QuantityNumber> <QuantityUnits>KGM</QuantityUnits> </Quantity> <Address> <AddressType>Loading port</AddressType> <AddressLine>NLRTM</AddressLine> <Codelist>UNLOCODE</Codelist> </Address> <Address> <AddressType>Discharging port</AddressType> <AddressLine>SGSIN</AddressLine> <Codelist>UNLOCODE</Codelist> </Address> <Documentation> <DocumentationType>Bill of Lading</DocumentationType> <DocumentationNumber>933</DocumentationNumber> </Documentation> <Address> <AddressType>Carrier</AddressType> <AddressLine>ABC</AddressLine> <CodeList>BIC</CodeList> </Address> </EDI_Message>

As we will see in the next section, individual XML elements can be identified and consumed independently from the rest of the XML document.

Категории

© amp.flylib.com,