| XML as Glue The latest technical strategies for the future of computing, .NET from
Microsoft, e-speak from HP, Open Network Environment from Sun, and similar visions from
IBM, Oracle and others, all involve a key element of platform agnosticism. Mainframes,
Unix servers and legacy client/server platforms can all participate equally well as peers
in the democratic world of web services. The 20-somethings who know only Java and Oracle
are just advertising their own ignorance of modern technology when they implicitly consign
the legacy platforms to the dustbin of history. Phasing out legacy platforms should be
done for good and valid business reasons, not simply to enable web access to that
application.
Two other aspects of these advanced computing architectures
are relevant to this discussion: loosely coupled messaging and XML. Like the Internet in
general, these strategies all depend on loosely coupled messaging, not tightly coupled
remote procedure calls (RPC's). Messaging provides simplicity, which in turn provides
robustness, and removes the need for the user to any knowledge of the platform processing
the message. Most mainframe transaction processing applications were designed on a
messaging model, not an RPC model, so these are usually more or less conformant already.
However, this may be a problem for many client/server systems.
The key to all these advanced designs is XML based data
exchange. When two applications need to exchange data, the most critical problems that
arise are always in one of two forms, if not both. First, there is the obvious problem of
the format of the data records themselves. One format may have NAME as a single field,
while the other may break it out into LAST-NAME and FIRST-NAME. NAME may be one field of
50 bytes for the one format, while the other format may have two fields of 30 bytes each,
and so on.
Second, there is the problem of the meaning of the data. We
may think we know what LAST-NAME and FIRST-NAME both mean, but what about in
Spanish-speaking countries where people commonly have two family names? What about Asian
countries where the family name is commonly given first? What about those countries where
people commonly have only a single name? Then there is the format problem, best known
since Y2K for date fields. For example, one application could have SETTLEMENT-DATE (MMDDYY
format) versus SETTLEDATE (ISO format), and so on. More subtly, one application could have
settlement as 3 days after transaction date, while the other might be 1 day after. The
larger the scope of integration, the more the problem of data definition and translation
comes to dominate the design. |
