SOA Basics 1

So I thought I'd go over some basics here. It may take a few entries to get to the bottom of this. I've been thinking about it for about a week and there is so much to cover.

SOA has been around for quite some time. People working with distributed applications have been using service-oriented approaches since the days of DCE, COM and CORBA (and before). It's not to be confused with moving data around, e.g. EAI. It can often be confused with Object Oriented methodologies and technologies. And I think it's important to remember that.

I developed a SOA at a large telecommunication company back in 1994. We used a proprietary messaging transport and build our own service dispatcher for CICS based transactions and programs. How is this related to "modern" day SOAs? Well it has everything to do with the idea of service contracts and service level agreements. We developed well defined message contracts that allowed different organizations to reuse services within our provisioning department applications. Users were often unaware that they were CICS Cobol programs behind these service contracts - though to be honest most people were aware of this - BUT they didn't need to know anything about how to contact the mainframe.

SOA is about providing well defined service contracts while at the same time hiding the implementation of that service. One can imagine that ordering a book on Amazon during its early years is not much different than ordering a book on Amazon today. There might be some newer features but basically the service hasn't changed much. However I imagine, in fact we've all heard, that in the early days an order on Amazon generated a print-out that someone ripped off a printer and went and processed very much by hand. Today I'm sure the implementation has changed dramatically!!

We've seen contacts expressed in such technologies as COM and CORBA IDL, Java interfaces, COBOL Copybooks, and today Web Services Description Language (WSDL). I'll cover more on the power of WSDL on a later post.

The contract doesn't just merely express the data required by the service in order for it to successfully process, but it can also express such service level agreements as security and the services ability to participate in a distributed transaction etc.

One of the problems I see from the COM and CORBA days is that though many were developing SOA with these technologies there were also many that brought a lot of OO baggage with them. I've discussed this on an earlier post. Many OO techniques didn't translate into good services. The Gang of 4's Design Patterns, though a wonderful book, was often as far as many architects got when it came to using patterns in distributed technologies. Being a consultant at the time I'd often run into people touting OO techniques or patterns from using Smalltalk or C++ that didn't translate into distributed patterns. (An example was passing objects around by value and in the craziest way or another was bad patterns of inheritance).

One interesting aspect of Service Oriented Architecture is how well it maps to procedural and functional programming. I'll be covering that in my next entry in more detail but it seems that SOA might bring about a resurrection in 3GL technologies like C (especially in the ever expanding embedded world), and broader inclusion of languages like Python and Perl in SOA based systems - as more 1st class citizens.