Coarse grain of SOA

Terry Coatta explains in his article From Here to There, The SOA Way how SOA isn't a silver bullet when it comes to resolving the issues of distributed systems.

I often come across the myth that web services (or as we often say, SOA services) are slower than more traditional architectures.  Terry explains that (properly implemented) SOA resolves this issue through having coarse grained services.  Essentially, you have to consider the data, bandwidth and latency of a particular issue first.  For example instead of making multiple service calls (say, to retrieve each data component from an object independently) you should probably return all the data in a single call. 

Objects are still a very good way to model systems and they function reasonably efficiently in the local context. But they don't distribute well, particularly if one tries to use them in a naive way. A service-oriented architecture solves this problem by dealing with the latency issues up front. It does this by looking at the patterns of data access in a system and designing the service-layer interfaces to aggregate data in such a way as to optimize bandwidth, usage, and latency.

I've seen several novice attempts to "serviceify" objects directly -- essentially making API's directly to object interfaces -- and I can confirm that they don't work well at all.  This is one of the primary reasons that I feel that web services are best governed by SOA, and not haphazardly created.  That's not to say that such governance need be bureaucratic... but better to spend a little time scoping your services than to create poorly performing or unsustainable ones.

I agree with Terry's assertion that there's nothing fundamentally new about service-oriented architectures, and that "distributed computing has always been about the same set of problems".  Really, success of SOA is dependent following a good set of best practices about service creation.  It really is a different way of thinking about problems than most people are used to.