Udi Dahan posted an excellent and thoughtful opinion about one of my posts on intermediation. I really like his thinking. One thing though, is that I don’t see a lot of disagreement about concepts… it appears to be more about terminology.
It is so much more fun to disagree on the actual concepts. Alas, terminology haunts us in this business. That’s why I really like the article by Shy Cohen in this month’s Architectural Journal that goes into the differences between service types.
From what I can tell, Udi was failing to find value in intermediation because his Process Services already handled the composition of other Activity and Capability services under the covers. Therefore, intermediating between the composing application and the process service didn’t make sense.
My statement was there is value in intermediating between the process and the capability services and/or intermediating between the activity and capability services. There is also value in intermediating between the capability and entity services.
I agree with Udi in this: There is less visible value in intermediating between a composed application and a process service.
IMHO, this is because there is usually a great deal of business context implied in a process service. Therefore, the ability to get value out of intermediation of a service is inversely proportional to the amount of deep business context that the service encapsulates. That doesn’t mean that it is impossible. It is not. But it is more difficult. So if you want your apps to call the top-level services using a non-interceptable protocol, that is probably not a major obstacle to agility. Of course, in the world of SQL Service Broker, this is nearly never the place where a service call is being made.
As far as differentiating composable vs. non-composable services: many entity services and a few bus services are not composable. I don’t think that all services need to be. Some clearly do, and those need to be centrally managed. Non-composable services have their place.
I hope this clears up what appears to be a disagreement between Udi and I. We are on the same page. We are just using the same words in a different way.
Nick,
Thanks for the compliments. I see two areas of agreement:
1. Low value of intermediation between high-level business services.
2. More value in using intermediation within a high-level business service.
I just don’t think that the things we’re intermediating are services.
The place where I still seem to disagree, apparently with Shy as well, is that, for me, there are no other kinds of services. We already have names for other things; components, databases, networks, etc.
From Shy’s article:
"Bus Services are typically purchased or centrally built components …"
So, is a service just some kind of component? Not in my opinion.
Is my view that Entity Services and Activity Services are an anti-pattern also one you agree with?
Finally, let me just say thanks. I find these conversations extremely valuable.
Looking forward to hearing more from you.
Hi Udi,
Thank you for your show of kind respect. I consider you to be a thought leader in this space.
Your last question was interesting enough for me to attempt to answer in a seperate blog entry.
Your first question: is a service just some kind of component? No. I don’t believe that anyone thinks that, including Shy. However, some services are fairly low level. We have a service name indirection service that we are building, so that we can isolate the name of the service from its location (DNS style). That’s not a component. It’s service infrastructure.
Nick,
My already over-inflated ego is just about ready to burst 🙂 but it is you who leads. I just pick up bits and pieces here and there and try to make sense of things for myself.
I’ve got another clarfication question for you:
Would not that "name indirection" be better described as a capability/feature of your infrastructure?
I apologize for my getting stuck on the issue of what a service isn’t, but I find it improves my pattern language.
By the way, I’m all for name indirection – I consider it a critical capability in order to handle what I call "spatial coupling", which I wrote about here:
http://udidahan.weblogs.us/2006/03/20/location-transparency-soa-esb/