Object-Oriented Messaging with XML

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.

Table 16-1 Object-Oriented Messaging with XML: Message Logical Data Structure

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.

Table 16-2 Object-Oriented Messaging with XML: Message Physical Data Structure

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.

Table 16-3 Object-Oriented Messaging with XML: Message Logical Data Structure With Default Integer Unsigned

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>

Should XML be Used for Messaging?

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.

• Using IDLs, serialized objects must be accessed via class methods

• Using XML, which is no less self-describing than as Java program or a database schema, object data can be easily examine if/when the software fails.

Using XML or IDL?

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,...

Using XML Serialization as Part of Your User Interface Strategy

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:

• Bean Markup Language (BML)

• XML BeanMaker

• XML-CORBA Link (XORBA)

• Koala Object Markup Language (KOML)

• Coins, an XML-based alternative to JavaBeans

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.