In my last blog entry I posited that an intuitive way to think of SOA was as the über-container; an Enterprise Wide, virtual container, in which all our business applications run.  This über-container would provide infrastructure services to provide for all the housekeeping necessities that are not actually related to the business purpose at hand: from managing security requirements (authorization, authentication, encryption etc.) through reporting on performance and availability characteristics – all the things we would expect to be able to leverage from a well written local container (like the .NET CLR or the J2EE environment) but applied universally across the enterprise without regard to platform or language.

Assuming for a moment that you buy into this concept, what can we infer about this über-container’s capabilities?  Well, for a start communication is a prime example.  Without ubiquitous communication across the disparate stacks, we can’t expect to achieve much at all.  Clearly, in the past 20 years, IP route-ability has made the ability to transfer a packet, the basic message, from point A to point B a given.  There are however, at least three higher order problems with communication at this stage:

1) We are likely to need so level of logical indirection to control the point of delivery for the message.  It is possible to hardcode the endpoint of course, but this quickly cases issues even before we get as far as new versions.  We can assume that what ever “services” we are going to develop will need to travel through the Test, Stage and perhaps User Acceptance environments before reaching production – even this one version will have multiple endpoints on its way through this development process.  Furthermore, it is also possible that we will want the ability to scale out the service, thus there may be many physical endpoints that serve one logical one.

This problem has been solved before of course, DNS for machine names and perhaps more applicably the infamous “Registry” that translates CLSID’s into DLL’s under Windows.  This über-container will need some logical name to physical name mapping service (let us call this the Repository for now and just assume it exists somehow, somewhere – we will revisit this concept in detail later).

2) Even if we deliver it to the right place, we need to make sure that the receiver can read the message that the sender wrote.  We have two fundamental choices here: a common language or an interpretation system.  If we insist on a common language (imagine the UN declaring English is the only acceptable language for discussion), then we have really just moved the interpretation problem to someone else’s plate (or more precisely everyone else’s plate).  Furthermore, we will spend forever agreeing which language will be the official one (there is obviously a huge advantage to ensuring it is your own “native” language).  It is tempting to say that XML has become the definitive solution to this problem so everyone should just accept that (we can ignore the encoding issue to keep things simple), but XML is fairly standard because it is pretty much the lowest common denominator.  Does this make sense in an environment where Java to Java or .NET to .NET communication could be so much faster and so much more bandwidth efficient?

In my view the container needs to allow native to native communication where ever possible and only get involved in translation issues if it absolutely needs to.  Again, if we fall back on this concept of a Repository then we can add to our endpoint address information that can tell the container what language (or languages) it can accept and it can translate if necessary.

3)  Having defined where to send the message, and what language to send it in, the remaining obstacle is to understand what content is required in this message.  I can send a check to the billing department all day and I can even send it in English if required, but if I don’t tell them which account I am trying to pay it probable won’t help!  Again, this seems like something we would want to store in our Repository.

So if we create a system that allows us to define a logical to physical endpoint mapping, provide enough information to allow translation to occur as and when required and defines the overall content of our messages, have we built the über-container?  No, definitely not…but it’s a good start.  In my next blog entry I will try to continue this thought process to cover some more of the missing functionality...