<= Home
The Economics of Understandings over Contracts
The Inefficient Contract
With so many SOA and WS fanatics out there many discuss on how using an industry standard contract (by contracts I mean a XML schema) interoperability between systems can be easy if not transparent.
To illustrate the “standardized contracts” world, a current example would be the travel industry. They have created a standard message contract called the OTA specification. Theoretically, if I desired to get quotes on airfare tickets it is simple to communicate with each airline carrier services since they receive and respond to the same OTA message contract (schema). A client system could consume any airline carrier service without any extra development effort, just a change of the endpoint address.
As great as it sounds, this concept reveals its flaws as soon as you apply economics. In economics, every action has at least 1 of 3 types of incentives behind it. Generalizing, most business decisions are driven by a monetary incentive with the desired end result of making a profit. Look at the businesses that provide products and/or services, in our example the airline carriers, and why they would choose to standardize contracts. Initially you could reason that by using an industry standard message, the businesses would maximize the potential of distributing whatever they are selling, as client (consumer) systems would more readily and easily be able to access the businesses goods and/or services. No extra development should be needed for a system that was coded to communicate in OTA schema contracts to talk to another OTA compliant system.
Where the all goes wrong though is that most businesses, in an effort to raise profits, attempt to provide different competitive advantages over their competitors. To continue our illustration, say the hypothetical airline carrier Skyway has a new fleet of aircraft that provide power outlets in ever other row to plug in a laptop. They want to provide the ability to request a power outlet row when submitting a reservation request to attract more business travelers. What happens if the standard contract doesn’t support this? How is Skyway to offer its competitive advantage? If the business wants to introduce new concepts into an existing schema, typically the standard contract needs to get abandoned. The other potential resolution is for the committee responsible for an industry standard contract to continue to evolve the contract by extending it often which leads to a bloated and convoluted schema, making it hard for consumer clients and business to keep up with the evolving contract.
The example is simplified, but these problems occur when several competing businesses attempt to use an industry standard contract. The real root of the problem is the XML schemas have limitations. An XML schema only enables the ability to dictate a message structure and the data types (i.e. date, string). A contract in this sense is an agreed structure of communication. Businesses are then limited when they wish to provide something that does not fit into the agreed structure. A more robust way is needed to support data integration amongst systems. Schemas are too constrictive and also do not provide enough meaning.
Ontologies = Understandings
Ontologies can fill these needs. Ontologies are more commonly referred to when talking about the semantic web. But ontologies can be utilized as a tool for data integration a.k.a. Semantic Web Services (SWS). How? If we took the OTA specification and represented the information in travel ontology versus a rigid contract, we would be able to provide both desired goals:
Goal 1: Simple Integration between Systems
A system that understands our travel ontology can communicate with other systems that utilized our same travel ontology with little or no effort.
Goal 2: Highly Adaptable and Extendable
New ontologies representing additional information can be introduced without breaking standard compatibility of systems. A system can ignore ontologies it does not understand. Another reason ontologies are highly adaptable for data integration is that OWL (Web Ontology Language) easily enables ontologies to be mapped together. If you have a message following contract “A“, and wish to convert it to contract “B”, you would have to create conversion/mapping logic, usually in code. With ontologies it is possible to connect concepts of different ontologies through the ontologies themselves, thus potentially eliminating conversion logic.
The term understandings when talking about ontologies represents where contracts go wrong and where ontologies excel. Instead of a system rejecting messages because the structure doesn’t conform, a system can handle messages that it understands. Using ontologies a system can communicate meanings with other systems that understand the same meanings.
Ontology inferring engines have some evolving, but it is good to still look at ontologies for integration with external partners and integration internally in an enterprise. More to come on implementing ontologies…