In my simple terminology I use the term ‘Semantic Integration Contract’ or ‘Semantic Contract’ to refer to an artifact which is both declarative, executable, and human readable, which can be exchanged between a service provider and service consumer to enable a consumer of my service to better understand the static and dynamic formation rules of well-formedness I am imposing on requests to my service.
XML Schema will allow me to specify which base types, structures and elements need to be present in any given instance document being punted towards my service endpoint. However as we rely on the power of XML to accommodate more flexible and eXtensible data structures which become increasingly normalised and therefore data-driven, we need something else to compensate for the deficiencies of XSD in adequately expressing the formation rules of that XML. As such the semantic contract takes us to the next level by offering capabilities such as those listed below:
- Expression of element interdependencies and rules that rely on instance data and dynamic conditions to be evaluated. For example ‘if element <ProductType> is present in the instance document, and if it’s value is ‘SuperWidget’, then we must have child elements of <SuperPowers> and <SuperTariff> within the <ProductType> data structure…
- Expression of complex or conditional element content formatting rules beyond the primitive capability of the XSD vocabulary, with the extension point to reference external complex type libraries containing conditional constraints similar to those in the earlier item.
- Expression of the actual meaning and intended usage of the complex entities expressed within the XML instance document, based on a supporting, formalised vocabulary within the context of the integration transaction.
These few examples of classes of capability I believe we need to introduce into the formalised artifacts associated with an integration contract such that we reverse the trend away from XSD towards informal word documents or excel spreadsheets to compensate for the descriptive and constraining expressions we need to be aware of as implementors of the emitters or consumers of XML instance documents in a progressive integration context.
I believe there are emerging standards that can be harnessed for aspects of the declarative solution but we are then left with the question of how to effectively introduce this into an agile integration engineering process…
Semantic Integration Therapy 