Governance Information Model
In a recent post I proclaimed a need for a formal Governance Information Model and a foundation for a proper SOA Governance platform. Today I would like to get a bit deeper and introduce the model that we have developed over the last three years. For those who prefer pictures to words or do not have the patience you can go straight to the main and auxiliary models.
For the rest of you, especially for those who are uttering the dreaded word proprietary, I will start with:
Why?
We started with looking at the existing standards, including UDDI, ebXML, WS-Policy to start with. None of them seemed appropriate because although all of them have been designed to be infinitely extendible and expressive all of them lacked the key first-class abstractions that exist in the SOA problem domain. Those of us with the data-modeling background know that everything can be expressed as name-value pairs (which I think are the highest normal form) but such representation does not lead to intuitive, maintainable or robust designs. As a result every one who have tried to use these standards for Governance, ended up using them in highly proprietary ways. Let me illustrate with a simple WS-Policy document:
<wsp:Policy xmlns:L7p="http://www.layer7tech.com/ws/policy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy">
<wsp:All wsp:Usage="Required"> <L7p:HttpBasic/>
<L7p:SpecificUser>
<L7p:UserLogin stringValue="admin"/>
<L7p:UserUid stringValue="3"/>
<L7p:IdentityProviderOid longValue="-2"/>
<L7p:UserName stringValue="admin"/>
</L7p:SpecificUser>
<L7p:AuditAssertion/>
<L7p:HttpRoutingAssertion>
<L7p:ProtectedServiceUrl stringValue="http://www.jasongaylord.com/webservices/zipcodes.asmx"/>
</L7p:HttpRoutingAssertion> </wsp:All>
</wsp:Policy>
I highlighted in blue all the lines that come from the standard specification, and the rest is – yes you guessed it right, proprietary! And thus requires the same degree of coupling (i.e. shared knowledge) as a completely proprietary model, yet they have to fit into Procrustean bed of syntax designed to meet someone else’s purpose. Actually we came fairly close to mapping our GIM to ebXML RIM 3.0 which was the closest fit between the three candidates, but about that time the future of Sun Service Registry became much less certain.
How?
Having reached that conclusion we set out to define the model. We wanted it to strike the right balance between strictness (strongly typed, verifiable, validatable and ultimately executable) and extendibility (because we can never think of everyone’s requirements). We wanted it to reflect the key view points (which later evolved into roles). As a result at the heart of the model are 3 objects: Service Component, Governance Contract and Service Offering representing the points of view of SOA Developer, Business Analyst and Governance Officer respectively.
What?
This is what we ended up with. Was it a success? We think so. It served a basis for six different versions of SGF, survived several implementations, dozens real-life use cases. We used that same model to derive the data model that serves as our registry/repository, the XML schemas that are used on the wire, and even the Java language classes that run inside our solution. For the last 2 years it had no significant changes. Now let us see if it survives the public scrutiny.
