So far in this column on SOA for Analysts, I have talked about the use and re-use of services as building blocks to put together new or better business applications. Now you are getting familiar with this concept, I need to peel away a layer of the SOA onion and expose you to a few tears by revealing this as a half-truth.
Services in the context of SOA are not building blocks, because building blocks tend to be very same-y. The bricklayers among you will agree that if you had to build a house using IT service objects it would be very tedious and difficult because they are not standard sizes and colours. In fact if you have two services the same size and shape, you have failed to understand what SOA is all about. Each service should be unique, although with a standardised interface so you join them together (from which came the shaky building analogy).
Many SOA teams go through a stage of having duplicate or very similar services due to a classic development problem that has been around since Ada Lovelace starting coding for Babbage's Difference Engine. This is that if more than one person (or a single forgetful person) is developing programmes/services/objects there is an increasing chance that the same problem will be solved in two identical or similar ways, leading to duplication of function, increased maintenance and all the problems that SOA was supposed to fix.
Of course, old lags like me knew that this would happen because the new generation of programmers (or SOA Architects, Web Wizards, or whatever they call themselves these days) never learnt the old tricks that we sweated blood to overcome, and, with the impetuousness of youth, believe that as the new Masters of the Universe (or at least the Linux-verse) they already know how to solve all known problems, although the nature vs nurture argument isn't proven on this point.
In the old days (think Apollo moon landings) we developed the concept of a programme library that catalogued the code we wrote, and had to be checked out and checked in again from the library to prevent duplication or corruption of the programmes. Hardly radical, but it worked. For the majority of the big programmes running the big companies on big mainframes, this is still the case. And jolly effective it is too.
However, in a nod to changing times, we have renamed and jazzed up this concept into what is grandly called a 'Service Registry and Repository'. Or a library for those who remember when books didn't have an e- in front of them and were made of yellowing paper held together with sticky tape.
Although it can be a single utility, the terms 'Registry' and 'Repository' accurately describe the functions of the new library. The Registry acts as a pointer to the correct version or instance of a service to be invoked at run-time (another layer of the SOA onion is the difficulty in managing complex environments, where the same service is used by multiple processes, making maintenance and patching of these services a logistical nightmare). The Service Repository provides the more traditional library function, and provides a rich set of tags and identifiers to track what services are available, what function they provide, and where they are currently being used (although Mr. Moot might point to the Registry providing this ability).
So we now have recreated the governance over our development that we had forty years ago. There's progress for you!
BTW, IBM's version of this is called the 'WebSphere Service Registry and Repository' (WSRR - and pronounced Wizzer... although it has improved since its first release to Wizzer 2.0).
Author: John Moe is Principal Consultant at J Moe Associates, and writes and presents widely on SOA and BPM. With over 25 years experience delivering application development and business transformation programmes, John has made most of the mistakes you will ever make and is keen to pass on this knowledge to help you avoid them yourself. In return he just expects undying gratitude and free drinks wherever he goes.