There still appears to be some debate about whether a service is an operation or a collection of operations.
I have no idea why because it really is pretty straight-forward, a service has to be thought of as a collection, or maybe more accurately as a container.
A service is a mechanism to enable access to one or more capabilitiesSo says the OASIS SOA Reference Model and there is a very good reason for it. If capabilities were 1-to-1 matched to service then there would be no point having services, we'd all just go straight to the capabilities. Ah ha! I hear the people wearing the pointed hats say, so we don't need services.
No that isn't what it says, what it says is that there are lots of capabilities and these need to be presented in a sensible way that enables them to be consumed. This is not likely if they are just sand on the beach and you've got to find the right grain. By enabling a service to provide access to a set of capabilities provides those elements with some degree of cohesion, this makes understanding them much simpler and enables you to put in place consistent policies for defined sets of capabilities.
The other power that this approach gives you is that a capability could be accessed via more than one service. This means that if its sensible for a given capability to be exposed in two places... that is okay as long as you are aware of the versioning problems etc. As an example of this, booking a British Airways airline ticket is a capability provided BA.com, their call-centre and via expedia, travelocity and the rest. One capability here has been surfaced via multiple services (thanks in no small part to standardisation in the services that live behind them). This gives us another bonus, the service you access the capability via might not own the capability. Again that is okay, in fact it can be one of the ways of getting a flexible and powerful system.All of this goes out the window if operation = service, then you have millions of services all the same, no aggregation of perspective just aggregation of function.
Operation = Service is 100% the same as CICS, but with out the power and sophistication.
A service enables access to one or more capabilities. End of discussion.
Technorati Tags: SOA, Service Architecture
3 comments:
Hi Steve,
Thanks for the article. If Service is container of capabilities with each capability being defines as operation in Service , then is there any thumb rule in determining the granularity of the operation.
Obvious answer... read my book "Enterprise SOA Adoption Strategies" ;) but the real point is to look top down rather than bottom up.
As a guide however I've tended to find that services fall in a 3-8 capabilities to service ratio depending on whether its data manipulation (more capabilities) or actual business process (less capabilities)
Hi Steve:
I have discussed this issue with you at yahoo and I am still a little unclear about the basis on which one groups certain operations together into a service. I refer you to this from your post:
No that isn't what it says, what it says is that there are lots of capabilities and these need to be presented in a sensible way that enables them to be consumed. This is not likely if they are just sand on the beach and you've got to find the right grain. By enabling a service to provide access to a set of capabilities provides those elements with some degree of cohesion, this makes understanding them much simpler and enables you to put in place consistent policies for defined sets of capabilities.
Can you elaborate on what kind of cohesion you are referring to here? Can you say anything more on precisely what the operations (of a service) have in common with one another?
If someone were to ask me this same question, here is what my answer would be: the servive provides access to a set of operations which are all fundamentally related to a specific business function. Therefore, as I believe you said in the yahoo group, it makes sense to "manage access" to this set of operations through a single service.
Post a Comment