sapienti sat: Making SOA Ready for the Enterprise

Or what u-boats and 20-engine planes have to do with delivering on the original promise of SOA

When I was younger (a lot younger) I lived by an airfield and after a year or so driving past the flight school billboards I decided that I would like to learn to fly. So one day I stopped by and looked at the classes they were offering. One thing that struck me as odd was that in order to fly a twin engine plane one had to take much longer classes and pay significantly more money. Intuitively that did not make sense – twin engine aircraft seemed conceptually the same as a singe engine one only twice as safe. Well actually it is the other way around – it is enough for one of the engines to fail for the entire thing to become really unstable and virtually uncontrollable in the hands of an unskilled pilot, making it actually twice less safe… What does it have to do with SOA? Well the old “monolithic” [this is supposed to be a derogatory term in the SOA-speak] applications behaved like U-boats – at the end of the day either everyone was fine and victorious or everyone was dead. Now we transition into a wonderful world of SOA and break it into a Composite Application consuming couple dozen enterprise services (some of which might be outside of the domain of control where the new application belongs) we effectively turned our U-boat into a twenty-engine plane: it is enough for any one of those services to go down or become otherwise unavailable for the entire application to get into serious trouble. For those less statistically inclined, this decreases expected reliability by a factor of twenty – not good.

When SOA was sold to the IT and business communities back at the turn of the century, it came with a beautiful vision called find-bind-execute. It promised composite applications and services dynamically finding other services they need in registries and other target-rich environments and if the one they use goes down a replacement can be located before the operator can say “trouble ticket”. Sometimes I close my eyes and can still see it – makes me feel warm all over. However this vision did not eventuate, primarily because computers can not do semantics and figure out on their own how to invoke a replacement service which supposedly does the same thing but uses slightly different interface and protocol. A contributing factor was also that registries, which were suppose to enable all this splendor, once they implemented all the security, workflow, federation and extensibility features, have become too heavy-weight to support real-life find-bind-execute scenarios. So the pendulum have swung the other way and now everyone doing SOA is supposed to look services up in a registry at design time, import the WSDL into their tool of choice at development time and write their consumers to a specific service implementation. It seems that the entire SOA world is busy building twenty-engine planes… Makes you wonder why there are no high profile SOA disaster stories like: company transforms core business applications to SOA, suffers meltdown due to service outages in the news yet. My guess is that we will se some in the coming year. And with computer’s ability to “understand” WSDLs and replace unavailable services with “similar” ones at least a decade out, is there a hope for SOA, or is it one of those technologies that came before it’s time?

We think that there is. In our SOA Governance solution we could not get all the way back to the original vision, but we built a set of technologies that got us at least half-way there. Here is how SGF solves the above problem and enables building self-healing composite applications:

1. Our Governance platform clearly separates the functional and non-functional aspects of enterprise services and enables SOA participants to express them in the form of reusable Service Components and Governance Contracts that can be combined together to form consumable Service Offerings.
2. Developers can code their consumers to the functional components, and implement the find-(re)bind-execute logic using queries like: find me the offering for the credit card processing service that implements the ChargeCreditCard component and provides a supported security mechanism, guarantees 99.99% availability and has the lowest per-transaction costs.
3. Consumer-side convenience API can hide some of the complexities from the developers and where possible provide automatic re-binding to alternate services based on configurable business policies.
4. Combined with a service lease feature it will result in significantly higher dependability of Composite Applications.
5. Having all of this build on top of a formal Governance Information Model (GIM), guarantees reliable and unambiguous interoperability between all participants in a SOA ecosystem.

This is why we introduced a separate SPECIFY Aspect Enforcement Level in GIM, which allows us to designate Governance Aspects that support dynamic (re)binding.

While this approach does not completely resolve the problem of excessive engines on our big SOA plane, it allows to bring aboard enough spares and other safety features to feel confident about the journey. Roger that, wing leader!

Please bookmark with social media, your votes are noticed and appreciated: