Tuesday, July 17, 2007

Interoperabiility

Interoperability is one of the buzzword that with the Advent of web 2.0 is become famous day by day. Every now and then some company announces that their product is fully-interoperable etc. Slowly it is becoming one of the most abused terms as well, like many other terms associated with Semantic Web like Ontology, Taxonomy etc.

According to Wiki the term interoperability with respect to software is defined as, the capability of different programs to exchange data via a common set of business procedures, and to read and write the same file formats and use the same protocols. (The ability to execute the same binary code on different processor platforms is 'not' assumed to be part of the interoperability definition!)

In a simple sense the term interoperability can be defined as Ability to work with each other, Without knowing the details of how it works. But it is easier said than done. We do have some standards like Web Services(WS) which can very well be useful to achieve interoperability but at what cost? If we use WS then we are tied to the input and output message structure and given the case sensitive nature of XML it becomes a nightmare at times (at-least to debug).

But at the same time if we can achieve the persistent publish and read mechanism for the systems then it should not be a problem as I see. What is required here is:
  1. A common structure at least in theory which could be understood by an application at runtime. What I mean here is we should have the data and data structure (metadata) also persisted somewhere. So that application can pickup metadata and parse it to understand the data. Upto an extent XML, XSD or RDF and RDFS can solve this issue. The XML (along with its subsidiary technologies) is the best bet here though there are numerous overheads associated with it.
  2. URI (URL) based access of data. So that one application can save the data to a location which is picked up by another application. Also the consideration must be made to ensure that it accidentally does not erase data written by another application if the space is shared by many applications.
  3. Some way to notify application that data is persisted so that another application can read the data. Alternatively the message for recipient can be written in a common pool which the recipient inquires periodically to see if it has an incoming message. A Message Queue implementation (JMS, MSMQ) will be handy here.
  4. A parser at both Sender and Receiver end to parse the metadat and then interpret the data. For reasoning the metadata and data both OWL-S can be used. Not sure how much helpful it will be to use Description Logic here though.
I guess this is just the beginning and I am going to collect all these bits and pieces sometime to bring them together.

Until Next Time.... :)

0 comments: