XmlAndCorba

Last edit September 11, 2003

At OtNinetyNine there was a lot of discussion about combining the ExtensibleMarkupLanguage and the CommonObjectRequestBrokerArchitecture. In general, this seems to involve using Corba to define service interfaces, which change relatively slowly, and XML to define parameter types, which change more often. This makes things a little like DistributedSmalltalk in that the method names are fixed in the code, but not the contents of the parameters.

There was a lot of discussion about keeping client and server data types in sync, where to keep your DocumentTypeDefinition's, whether to validate parameter strings or not, etc. The most common use for this technique was in financial systems and the potential for supporting StraightThroughProcessing looks very promising.

Another approach, which we heard on the train going home, is to make relevant parameters of type Any. As before, this means that the interface remains constant but the parameter types can be varied. The proposed advantage of this approach is that the marshalling and unmarshalling is done for you and there should be fewer bytes on the wire than using ExtensibleMarkupLanguage.

Sounds like a job for NDR (DCE RPC data representation, like C types), not XML. Why make these damn things more complicated than they need to be?

NetworkDataRepresentation (NDR), commonly used for RemoteProcedureCalls (RPCs), contains practically no metadata; one relies on the InterfaceDefinitionLanguage (IDL) to ensure that you're reading the right types in the right order. So, to use NetworkDataRepresentation for dynamically changing interfaces, you'd have to implement another protocol layer on top of it, to transfer data type and possibly field name information.

The CORBA "Any" type contains type information, but not "field name" information. That is, the receiving end can dynamically determine the data type of the object it just received, and use that to extract its value. But the CORBA "Any" type does not give you field names: You can determine that they gave you a vector of three strings, but are these "first, middle and last name" or "address, city and state"?

XML gives you significant metadata, such as field names, even without a DataTypeDefinition (DTD). However, by using XML, you might just be reducing your CORBA usage to being a file transfer interface. You might do this to avoid changing CORBA interfaces over time. (I've heard that there's a good idiom for handling versioning issues in CORBA, but I'm still trying to find it! ;-)

On a CORBA project I worked on in 1999, we used the "Any" type to support vectors of name-value pairs. And the values could be vectors of name-value pairs, etc. So we had XML-style hierarchical data sets. -- JeffGrigg

I can't answer the NDR challenge directly, although I suspect that it's similar to the CORBA data type referenced below.

We've found each interface style to have strengths and weaknesses. The attributes we considered were convenience, performance, maintainability, and the implications for session management.

Defining questions:

	Convenience

How easy is it for our clients (human and machine) to create a parameter or process a return value in this format?

	Performance

Does the component's speed or throughput degrade below an acceptable threshold during normal (if high) usage?

	Maintainability

How easy is it to make evolutionary changes to the data content? Will changes to the content model break client code?

	Session Management

Does the interface force or require state-altering messages to be sent within a bounded transaction? This adds complexity to both the client and the server.

Our experience with wide internal deployment of CORBA components led us to the following taxonomy of trade-offs:

Fine-grained Distributed Objects

	Convenience: +
	Performance: -
	Maintainability: +
	Session Management: -

Primitive (CORBA IDL) Data Types and Structures

	Convenience: +
	Performance: +
	Maintainability: -
	Session Management: +

Flexible Data Schema (e.g. proprietary, name/value pairs, and XML)

	Convenience: -
	Performance: +
	Maintainability: +
	Session Management: +

Concerning the last option...

We've shied away from proprietary data schemes. They would require awkward code on our clients' systems.
Name/value pairs can't describe rich, hierarchical data structures without devising a proprietary data scheme.
XML is a industry-standard format that can describe complex data.

As you can see, we haven't found a perfect solution. Our current position is that XML best meets our needs. It's simple, flexible, and increasingly supported by tool vendors. We expect that its convenience "minus" will become less negative over time.

-JamesCollins

Couldn't XML also be used to represent the interfaces as well? This would allow you to send multiple queries as part of one request and get back the results in one lump sum. Of course that this would mean that CORBA becomes somewhat irrelevant. This could be set up into some type of InformationBus structure based on XML. --GlenStampoultzis

Call it the XmlAcceptorPattern. ;->

This makes things a little like DistributedSmalltalk in that the method names are fixed in the code, but not the contents of the parameters.

''Or use the even more general "doit(any)" so the other side must dispatch the operation as well.''

See also: SimpleObjectAccessProtocol ( = RemoteProcedureCalls (RPC) using ExtensibleMarkupLanguage (XML) as a TransportProtocol.)