On SOA, Indigo and Services
John Cavnar Johnson posted an article entitled "Taking up the Turner Challenge or Once more into the breach" where he takes up the challenge I laid out in one of my recent posts on SOA. In my post, I ask (in reference to vendor's claims that they have a SOA): "if you've got an architecture that will help solve real business problems, then show me the picture. Don't list products to me - show me the generally applicable architecture and principles which drive that architecture". When I wrote this, I should have been clearer and stated something more like "if you're a technology products company and you have a Service Oriented Architecture that will help solve real business problems, then show me the picture. Don't list products to me - show me the generally applicable architecture and principles which drive that architecture".
My original challenge was based on my frustration that so many companies offering products of all kinds are making statements that such-and-such a product is a SOA. The height of this lunacy for me was when I recieved a press-release from a company proudly announcing their "SOA Identity Management solution". Huh? A what???
John points out that as an Enterprise Architect, he models his enterprise along Service Oriented principles and enjoys great benefits from doing so. As such, he therefore has a SOA - a Service Oriented Architecture. By following the principles of SO, he enjoys loose coupling, better interop and has an easier time communicating what a given part of a system does to the business. I don't quite concur with his assertion that services in a SOA must communicate using asynchronous messages, but will totally agree that by doing so, a system may exhibit improved scalability, performance, etc.
John then goes on to say that he feels we've got it all wrong with Indigo. He feels that we get in the way too much and that "this enormous pile of OO attribute-driven goo"obscures his view of the world. He asks why we can't just create programming constructs that let him create messages and send them. Huh?We can and we do. You create a data structure that you've adorned with the attributes necessary to describe the construct to the world and you then send it via your binding of choice to the destination endpoint.Your binding is then responsible for signing & encrypting, communicating reliably, serializing and transporting the message.
He also complains that we force him to have to understand too much about pointy brackets, transports, WSDL, etc.I have posted previously On Contract First & Pointy Brackets in general and agree that we should get away from pointy bracketed considerations as much as possible, but I don't understand why he says that if you want to use Indigo you have to process XML, WSDL and SOAP. In fact, Indigo enables you to represent and consume messages encoded in XML or Binary-Encoded-XML out of the box, and if you want to represent your messages in other formats, then go ahead and write/buy an Indigo serializer that uses the format that makes sense to you.
John also complains that he doesn't want to "slurp another service's operations and messages directly into my object model". Fine. if you'd rather do the work of independently creating message structures which are wire-compatible with other endpoints by hand rather than using a tool to do the work for you then go ahead. You can start from a contract defined in WSDL. WSDL is generally used because it is very expressive and is the most interoperable contract definition language around right now, although it is indeed somewhat flawed and often a little inconsistent. You can then use a tool that we provide that spits out skeleton or proxy classes mapping agains the WSDL (and associated XSD) simplifying the task of implementing the service or the callers of the service. You don't want to use WSDL? Then design your own contract definition language and proxy/stub generator - this is all perfectly feasible.
If you want message-oriented view of the world, we will get out of your way and give you an almost totally unobscured view of the world if you want us to. If you prefer a more object-oriented view of the world, then we give that to you too. You want to mix and match both world views, go ahead, no problem.
But herein lies an important point. OO is still an extremely effective way of constructing complex systems, and is absolutely applicable for use when constructing the inner workings of a service. The OO constructs and metaphors use expose with Indigo in VB.NET, C# and C++ are largely born from the fact that these are OO languages and we're trying to expand the OO world's experience into the realms of Services when constructing distributed systems. Will there, at some time in the future be SO programming languages? Maybe, but until then, let's try and get to a point where developers don't have to re-skill and re-tool any more than they're already expected to in order to adopt powerful new metaphors such as SO.
