Almost since the beginning of computer programming, there have been containers.  I grant you that the very first programmer’s had the entire machine to themselves and their “programs” sat right on top of the hardware its self; but very quickly, as computing power grew, computers became general purpose systems that would run more than one program at a time an the container was born – the very first being the operating system.  In later years, the container evolved through mainframe Transaction Process Manager’s like CICS and TPF on into the JVM powered App-Servers of the Unix/Java world.  Somewhat late to the game came Microsoft’s .NET runtime - the CLR, which when paired with Servers like IIS or BizTalk, can provide a very rich environment indeed.

So what’s the point of container based programming?  Simply the recognition that there are many functions that programs need to perform in order simply to exist, but that these functions have nothing to do with the algorithmic work of supporting the business functionality (the reason they were written in the first place).  Jobs like memory management can be done in each program of course, but the are quite simply better done by the container – for two reasons: firstly, not every programmer has the same level of skill at many “infrastructure” problems, like memory management or perhaps more obviously credential management.  It is not only unlikely that every company that needs to engage in program production could master these things, but it is in any case wasteful of resources.  Much better then is to rely on the experts within the manufacturer of your favorite container, and leverage this service across all your applications – think about it, many of you could do a decent job of writing a basic operating system, but how would that actually payback in terms of the job your company needs you to do; better then to rely on one of the OS commercially available (however imperfect they may seem).

Secondly, and this is an argument that we fought long and hard when transitioning C++ programmers to C#, it is quite true that a very skilled programmer with intimate knowledge of their application can probably manage their resources more efficiently than the container can, but:  that matters if you are a game programmer, not so much if you write Enterprise applications.  The enterprise programmer’s code will run side by side with many other applications - which will all compete for constrained resources.  If every programmer is allowed to optimize resource use based solely on their own code’s needs, the system as a whole will suffer.  Only the container can have the holistic view necessary to optimize system wide – after all, that is the very principle behind the ultimate container – the OS.

What has all this to do with SOA?  Well it turns out that it is a useful metaphor to better understand SOA - consider it in terms of being an enterprise wide container.  Instead of optimizing resources local to a machine, we are attempting to do this for the entire IT infrastructure.  Likewise, we are attempting to promote the use of “infrastructure services” in place of writing infrastructure code in every application.  To complicate matters, this must be done in a platform neutral manner so that any application can benefit from the federal services without regard to the language in which the application is expressed, or the OS or hardware upon which it is run.  Easily said, not so easily done.  More thoughts on this “uber-container” later…