Coarse grain versus fine grain services. That was a big debate when SOA first raised it's head. A couple of years later I'm seeing a lot of discussion on reuse or the lack there of in SOA. I am wondering if folks are deploying really coarse grain services and trying to get the reuse at that level. Getting reuse out of a service that really does a lot is going to be very challenging.
My design approach over the past couple of years has been to focus on fine grain services. There is more potential for reuse at that level and in fact that is what has played out in my organizations. These services can also be connected to make a more sophisticated higher level service which tends to focus on a specific business problem and has limited reuse capability. There is nothing wrong with coarse grain services but expecting a lot of reuse is probably not realistic.
Another area which tends to limited reuse is your XML schema and WSDL design for those of you using the web services implementation approach. Putting to much of the validation effort into your XML schema can lead to a lot of rework for every new invocation of a service that has slightly different variation(also hampers interoperability). I have found it best not to put to much strain on the XML and leave more of the validation to the implementation. You could certainly argue that service versioning and multiple implementations of the service could solve that as well. Both ways have their merit. I would save the multiple implementation method for situations that require a significant change in the implementation(which should be the minority).
In the end you will have a mixed bag of coarse grain (few of these) and fine grain services. Most of the reuse potential is going to come from your fine grain services. If you are expecting your business analyst to dynamically weave together your coarse grains services as they see fit and when they see fit then you might have issues with reality that should be addressed with some sort of on-site SOA therapist.
1 comment:
I should probably clarify what I mean by fine grain services. I not talking about services like getDate or calculateDateDifference which are really low level generic services. My fine grain definition is still business functions that have a narrow focus and do one specific thing. Some would argue that these are really coarse grain services but I think not. I tend to think of higher level services as services that orchestrate lower level services. Some would call these composite services but I think they are really the same thing.
Post a Comment