soa reuse and composability
Mon, Jul 3, 2006
The SOA behemoth is starting to awaken and gain some momentum, if only in the accronym workshops of eLearning. The latest JISC eFramework newsletter had this interesting arcticle from zapThink, entitled Should All Services Be Reusable?
Before you go read it, perhaps you could read a post I made ages ago about reusability - Code reuse and Learning Objects. People are starting to think about reusable services without really knowing the consequences.
The zapThink article talks about top-down SOA architecture. What this basically amounts to is business service normalisation and the services that are eventually identified depend to what nth degree of normalisation a business is prepared to go to. I don’t see how this can meet business requirements though as there are presumably services of some sort in place, already meeting business requirements. A business would only go through the process of normalisation if there was money to be made, either in the form of increased productivity with lower maintenance costs or they intended to sell those services. In my experience of service design though, internal services are never a candidate for reuse outside the company or the sector in which the company works. They’re vertically oriented services. The gains from making those services usable outside the sector rarely justify the cost and effort.
The real SOA is touched on by the quote “There may be Services that realistically have only one application” . Well, yes, that’s what a real service is. It’s a functional unit. The article then gets a bit mixed up with how services are specified and how they are developed: “there are situations where agility rather than reusability is the driving force for Service design”. Resusability has nothing to do with agility. Agility is in the implementation of the service requirements. If the requirements change so much that the service becomes non-reusable, then an architect would take the decision to decompose the service. Say to the customer, “what you really need is two services”.
The normal way of using a service is to provide the service with all the data it requires to perform it’s stated function. For example, let’s take an addition service that takes two numbers, adds them and returns the result. The normal way of doing this is to pass the service two numbers and get the result back.
So how does all this tie in to reusability? As I said before in my previous post, when you design a service, you have no idea how it will be used in the real world. People are creative creatures and the sum is always greater than the parts when building big things out of wee things. An example, two services, an addition service and a multiplication service. A client has the requirement to multiply two numbers and add the result to a third number. The client has a multiplication and an addition service. hmmm, they think, it would be great if I could just pipe the result from the multiplication service direct to the add service and give it the other number to add.
There are two ways to do this. In the zapThink article, one way would be to design the add service in such a way that it is completely configurable/extensible for all scenarios (changing requirements). In this case it would mean bolting another interface to the service. It’s still an addition service but now it has a new way of getting it’s data. One number comes from the client, the other from another service. The service bears the burden of client workflow. This is clearly untenable.
The other and better way to do it is to organise atomic services into client-side workflows. Service orchestration. The service designer implements the service and issues the contract (WSDL perhaps). Clients then build workflows composed of multiple services. The requirements on the services never change. It’s the client’s requirements that change.
That leads us nicely to service composition and where should it be done? Should a service provider try to envisage all uses of it’s services? Or should it decompose all services to increase granularity and let clients build complex services from workflows? Depends on how much normalisation a business wants to do on it’s services. Either a business could decide to offer a complete package of one service that takes a formidable set of data and works on it. Or it could decompose the service into atomic parts and let clients compose their own larger services from those smaller ones. Make the services composable.
This touches on a very important point and one that pops up a lot in software development and code reuse. Should a service be composable at all? To be of any use, yes, it should be. And the best way to ensure composability is to advertise an unambiguous contract for the service, with clearly defined inputs and outputs. But the I/O formats may depend on the workflow engine being used by the client and it starts to go round in circles of every changing requirements. To summarise, SOA services should: