In this post, I want to talk about service granularity in a smart client application. By service granularity, I am referring to the continuum of the scope of data that can be returned by a call to service. On the low end of the continuum, I would get a single data element (that’s extreme and nobody that I know of does this in today’s distributed applications – that’s more akin to CORBA and DCE, both of which are no longer current). On the other extreme, I’d get a complete object graph for a given business entity. In fact, the dilemma is the granularity of the data transfer objects (refer to Martin Fowler’s documented enterprise application pattern at http://www.martinfowler.com/eaaCatalog/dataTransferObject.html).
In smart client applications, I often use several tabs to display information about something. For example, I could have a customer screen with a personal information tab, account tab, preferences tab, and order history tab. Now I have a choice: (1) make one call to a service and get a data transfer object to represent the customer and related information for all the tabs in one fell swoop; or (2) make a service call to get a data transfer object for the personal information tab, and make an additional 3 separate calls to the service in the background and fill the tabs when the information comes back. The advantage of doing this is that the call to fill the first tab results in a smaller payload and thus should result in a faster response. The disadvantage is that a total of 4 calls were made and it would be easy to fall into the trap of designing the services to fit a particular UI paradigm, a no-no in “service oriented architectures.”
I am trying to find a happy medium where I first think about what the service should look like from a business perspective, while accounting for different ways in which UIs might consume the service.
Please post your comments on this topic as I am interested in finding out what others’ experiences are in this area.