Semantic Interoperability(SI) of Service Oriented Architecture(SOA) in Travel domain

We most often ignore Semantic Interoperability (SI) when designing service interfaces, unless it is mandated by an organizational discipline of standard. I have been working on providing a REST (Representational State Transfer) based APIs to one of our COTS vendors. Our discussions were mostly around the following aspects.

1.     Are the interfaces portable: – What language it supports? Whether it supports both .NET WCF as well as JAX-RS? Can JQuery be used to integrate them? Can the vendor use Ruby on Rails? Can python scripts be used to build the test rigs, Can it provide JSON data etc.

2.     Are they interoperable: – The thoughts were again similar to the portability?  Additionally we debated a lot about whether it should be a publish-subscribe or point-to-point and how it could work across legacy platforms. Basically, all about syntactic interoperability!

3.     Architecture excellence: – How to impose highest cohesion with lose coupling? What is the package size and what would be network utilization and security?  How to avoid the MIM (Man in the middle) attack and what are the QoS aspects?

Well, all of the above aspects are critical to the building of interfaces support SOA. However, building many point to point (P2P) integration often results in uncontrolled proliferation of interfaces in the domain.  This is quite analogues to the old day telephone lines. There used to be one wire to each subscriber from exchange. 

What’s semantic interoperability (SI)?

One of the fundamental challenges in service oriented integration is the use of different terminology and nomenclature used by different parties in the same domain. The current SAAS (Software as service platforms) often doesn’t provide a domain based Ontology.  Although the organisations such has open group is trying to address issue through common system architecture and SOA ontologies, but they aren’t penetrating deep into SOA designers   

This is probably the case with most of the business domains. I have been working with travel domain for many years and I do integrate different services. The lack of coherence is felt even within the different business areas as well as software modules in my company. For example, the vendors such as Sabre, Navitaire all have their own dictionary of terms.  The Associations such as ABTA and IATA are no different.  One of the solution to this problem is to establish a domain specific ontology. In other ways whoever understands the Ontology of the domain can exchange information more effectively.  Bitter and Donnelly explain this concept nicely in their paper (http://www.acsu.buffalo.edu/~md63/BittnerGeosemOnt.pdf) accessed on 09th June, 2013). They describe four steps communication process typically used in an interoperable interface. They are

1.     Building the message syntax, 

2.      Sending it across to a pre-established channel,

3.     Translating,

4.      Interpreting the message and mapping to the business entities.

The first step and last step can only be successful in long term by assuring semantic interoperability. The semantic interoperability is the ability to interpret the messages accurately. A schema definition (XSD), WSDL (SOAP) or WADL validators can enforce a syntactical interoperability, however there is no general standard to enforce semantic interoperability. The solution to this problem is to build domain based integration mechanism based on a standard Ontology. However there are thoughts on how this can be standardised across the domains.  The standardization efforts by IEEE and Open Group are mentioned below.

Open Group

The open group has established a subject area (http://www.opengroup.org/subjectareas/si). They recognise the importance of SI (Semantic Interoperability) to enforce the Boundary-less information flow (which is the foundation of TOGAF). As per open group, the effort spends on resolving semantic integration issues are as high as 80%. The open group solution to this problem is UDEF (The Universal Data Element Framework). The UDEF (http://www3.opengroup.org/subjectareas/si/udef) define a standard which integrate with W3C’s RDF (Resource Description Framework). The UDEF is based on indexed Ontology.

Travel Industry and SI

One of the most collaborated business domains is Travel. This collaboration makes a travel companies work out of the corner shop and premium agents such as TUI, Thomas cook  and  Abercrombie and Kent all sustainable.  There are thousands and thousands of travel agents in the world rely on integrated platform. This caused mushrooming of travel integration platforms and GDS (Global Distribution System) or CRS (Computer reservation system). The Abacus (http://www.abacus.com.sg/ majorly used by Asian careers) and Amadeus (http://www.amadeus.com/) conventionally dominated the market, however Sabre, Navitaire are now taking a big pie especially in Airline world. The issue is none of this platform ensures full semantic interoperability (although they claim partial SI).

The Open Travel Alliance and Hotel Technology Next Generation

The OTA is a non-profit organization which is dedicated to building interfaces and electronic data exchange standards for the travel industry. The OTA works across the industry such as hotels, airlines, car rentals, cruises, railways and GDS etc., The OTA standards achieve semantic interoperability through OpenTravel Lexis (http://www.opentravel.org/).  The Architecture workgroup’s   Open Travel 2 XML Objects have come up a lot of changes in their 2013 schema (http://www.opentravel.org/Specifications/Default.aspx) which is expected to make Travel APIs 100% semantically interoperable. The Hotel Technology Next Generation (HTNG) is also in the process of building a set of specs (http://www.htng.org/specifications-by-product-type) to assure semantics interoperability.

Conclusion

The service oriented middleware, cloud and SAAS made huge advances in integration and interoperation in the recent years. However there is still lot to be done in enforce semantic interoperability. It’s hence important for domain as well as application architect to stress on this. The absence of proper attention in SI can create a plethora of islands of integration like complex and tangled mesh.

Posted in Architecture, Travel Technologies