lustratus LiteBytes

It looks like there is still some level of debate over the definition of an SOA service, according to the excellent Loraine Lawson’s recent post.

This was a topic covered in detail in a free Lustratus paper in 2007, entitled ‘What is an SOA Service?’ (catchy title). Now, I haven’t read the referenced article in Loraine’s post, but it seems a good time to take one more stab at this at a reasonably non-technical, simplistic level. I like to look at SOA not in isolation, which can result in the person with the loudest voice claiming the right definition, but in terms of its place in the evolution of IT.

People started with programs. Because they were hard to understand, particularly if you hadn’t written them yourself, structured program was introduced including things like subroutines. Then people realized that if these subroutines and other programs were put together in an encapsulated fashion, with clearly specified inputs and outputs, they became like little black boxes that could be used to build a bigger program – these reusable components were called Objects. But now users started to have multiple platforms and application environments, and the need arose to be able to get these components to talk to each other, so messaging was introduced to provide a communications pipe, usually asynchronous in nature to provide more flexibility. A value-add layer on the communications pipe dealt with issues of different components being based in different environments, for example, and EAI (Enterprise Application Integration) was born.

But all this was still at an IT level, and for years business executives had been pushing for better business alignment of IT. So the next development was to move the IT components onto business boundaries as opposed to technology ones, through SOA (service-oriented architecture). This helps provide a business-oriented view of both design and operations. Of course, being an evolution, SOA retained a lot of the other developments discussed above – so an SOA service is not only business rather than technically oriented, but is self-contained with clearly described inputs and outputs, reusable and accessible from anywhere through a communications pipe (often an ESB, Enterprise Service Bus) that offers value add services such as transformation and routing.

So, in summary, an SOA service

• represents a clearly defined business operation
• Is self-contained and reusable
• is accessible from anywhere
• responds to well-defined inputs with well-defined outputs

I realize this is a gross simplification, but I hope it is helpful.

Steve