Summary
It's high time we all face up to reality. The network is and will remain "heteregenous". In spite of the sincere efforts of vendors and standards organizations to homogenize the network, the networks insists that it is indeed heteregenous.

It's high time we all face up to reality. The network is and will remain "heteregenous". In spite of the sincere efforts of vendors and standards organizations to homogenize the network, the networks insists that it is indeed heteregenous. That is, the network will continue to use different standards for communication, as such it's high time we have to deal with it.

The reasons are too obviously clear. The crux of the problem is people, people and the organizations they paricipate in, assimilate knowledge at different speeds, and act on that knowledge in different ways. Furthermore, it's human nature when the needs of the one outweigh the needs of the many.

Even if the valiant attempts at standards for interoperable communications (i.e. Webservices), attempts have fallen flat. It took 3 years for the WebServices vendors (i.e. the promoters of SOAP, WSDL, UDDI) to address the its growing interoperability problems. That's despite the fact that the intention of the group was to support interoperability in the first place!

If we could build an architecture that would take into account the heteregenous nature of the network, how then would that look like. For starters, inteoperability is achieved through agreements in how information is exchanged.

However, information interchange happens at different layers. We can imagine an interoperability stack. At the bottom of this stack we decide the transport mechanism (HTTP/s, SMTP). The next layer we define the messaging envelope (SOAP, S/MIME, ebMS). Inside the envelope we decide on the document syntax (XML, EDI, IIOP, BER encoding). Next we define the schema of this syntax (XML Schema, RelaxNG, DTD, ASN.1, RDF Schema). We can additionally define a service description (WSDL, IDL). Then on top of that we can define the choreography (BPEL, BPML, WfMC).

All the above are agreements in syntax and agreements in the semantics of interaction. However, semantics of the information contained in the payload is obviously necessary. We could standardize on a generic vocabulary (i.e. UBL) and build from there a ontology for a specific domain. Turnkey functionality is a bit out of reality today, however, there are standards present on how to define knowledge (i.e. UML, RDF, OWL, KIF etc.)

An architecture to handle the heterogeneity of the network should allow for a compsosable interoperability stack. That is, at every layer, we can selectively accomodate the varying choices of the partner we communicate with.

The question of course arises, what are the interfaces for the different layers? I mean it's nice in theory to envision this stack, however how can one compose it?

Java Business Integration (JBI) is a JCP attempt to address this very problem. The pundits have scoffed at it as something coming too late to the webservices party. However, they they've simply missed the point. The webservice folks are in the quest of the holy grail to homogenize the network, unfortunately the first step in solving a problem is to understand the problem.

JBI defines the mechanisms for vendors to create components that will plug into this interoperability stack. The mechanism is via providing SPI (System Programming Interfaces) that will allow vendors to plug into a "Normalized Message Bus". It's not to uncommon to find a tool like Collaxa with great orchestration capabilities, however with no standardized mechanism for supporting a standard like ebXML messaging.

The authors of JSR-208 have hit the nail on the head. Accepting the fact that the network is heteregenous is the first step in solving the interoperability problem.

Talk Back!

Have an opinion? Be the first to post a comment about this weblog entry.

RSS Feed

If you'd like to be notified whenever Carlos Perez adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Carlos E. Perez has been an object-oriented practitioner for over a decade. He holds a Bachelor's Degree in Physics and a Master's Degree in Computer Science from the University of Massachusetts. He has polished his craft while working in IBM's Internet Division and IBM's TJ Watson Research Center in Hawthorne, New York. He now works for a startup 1/100,000th the size of his former employer. He writes about topics covering emerging aspect and object oriented paradigms, loosely coupled architecture, open source projects and Java evangelism.