Oracle8i Application Developer's Guide - XML Release 3 (8.1.7) Part Number A86030-01 |
|
Building n-Tier Architectures for Media-Rich Management using XML: ArtesiaTech, 5 of 13
Messages are specifically formatted data describing events, requests and replies, and as such, messaging is the process of exchanging messages between the functional areas of a system. XML-based messaging enable applications, or specific services, to communicate across disparate programming environments, irrespective of operating system, language, or compiler, as processes in each environment need only understand the common messaging format and protocol. At the most fundamental level, this means each environment need only access to an XML parser via some API, which are now readily available for prominent programming languages such as C, C++, and Java on all of the principal operating systems: Windows, MacOS, Solaris, and Linux.
Messages are intrinsically just data structures, which can be serialized in a variety of ways. For example, consider the following C++ data structure, an array of five (5) integers:
int array[5] = {-9,0,-2,1,0};
Table 16-1 shows the logical data structure of the message.
Array size | index 0 value | index 1 value | index 2 value | Index 3 value | index 4 value |
---|---|---|---|---|---|
5 |
-9 |
0 |
-2 |
1 |
0 |
However, physically, the actual bits, on an 8-bit machine are stored as shown in Table 16-2.
Array size | index 0 bits | index 1 bits | index 2 bits | Index 3 bits | index 4 value |
---|---|---|---|---|---|
00000101 |
11110111 |
00000000 |
11111110 |
00000001 |
00000000 |
Now, if this array is passed as part of a message from object-1 residing on machine A to object-2 persisting on machine B, special care must be taken to assure that the destination object's view of this data is identical to the source object's interpretation, as this is by no means a certainty.
For example, the default definition of an integer on machine two may be unsigned, in which case, the logical view of the data structure is shown in Table 16-3.
Array size | index 0 value | index 1 value | index 2 value | Index 3 value | index 4 value |
---|---|---|---|---|---|
5 |
247 |
0 |
254 |
1 |
0 |
Furthermore, on some platforms, integers are multi-byte, 16-bit, 32-bit, and soon, if not already, 64-bit. Add to this the big endian/little endian uncertainties, and quickly, one discovers that language, compiler, or platform specific message serializations are not solutions conducive to promoting function shipping.
The XML serialization of the same array is very straightforward.
<array size='5'> <integer value='-9'/> <integer value= '0'/> <integer value='-2'/> <integer value= '1'/> <integer value= '0'/> </array>
The natural question to ask is of course, "should XML be used for messaging?" Historically, definitions of data formats intended for cross-platform transport were specified using Interface Definition Languages (IDLs) in conjunction with middleware solutions like CORBA. In difference to XML, which incurs the nominal overhead of self-describing, human-readable data, IDLs define packets of transient, machine-readable data.
However, while XML and IDLs both provide techniques to save the state of objects, it is often desirable to have a human-readable, and thus editable, persistent state format for objects, as serialized component may be rendered inoperable by changes to class definitions.
As to the question of when to use IDLs and when to use XML, opinions vary. Some argue that using XML to bind together components of a distributed system is expensive and pointless. Nevertheless, one cannot ignore that XML provides a platform neutral, programming language independent, self-describing, and thus self-documenting, mechanism for encoding object persistence.
Very few would argue that all application programs should be written in assembly language, as opposed to third or fourth generation languages, just because it is more efficient. Similarly, it should not be argued that IDLs should supplant XML in all cases as an object-oriented messaging format. Profilers can be used to judiciously apply each based upon the issues facing a software developer: time/cost ratio for implementation, maintainability, performance,...
Software developers at Artesia Technologies employ XML serialization as a part of its user interface deployment strategy, as an alternative to the object serialization provided in the Java Swing library. Historically, subsequent versions were incompatible with serializations produced by preceding versions. In serializing GUI components to XML, this issue has been eliminated.
Among the numerous standards that exist for XML serialization of objects are the following:
These, as well as product specific formats, such as Artesia Technologies' XML Persistent Interchange Syntax for Assets (PISA), can readily be transported using any number of protocols, including RPC, RMI, and HTTP.
|
Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|