Right Granularity of SOA Web Services - An architecture decision

Granularity of Web Services is an important design consideration. The concept of granularity is a relative measure of how broad the interaction between a Service consumer and provider must be in order to address the need at hand. In a broad sense, the granularity can be classified as seen in the figure below.

Now let us try to explain this concept by taking an example. Let us consider we are developing a Web Service to retrieve Employee Details. Employee has the following associated characteristics

1)      Dependents (An Array of Persons)

2)      Skills (An Array of Skills)

3)      Peers (An Array of Employees)

4)      Direct Reports (An Array of Employees)

So when designing the Web Service to retrieve the employee, you have multiple ways of designing the Web Service.

Fine grained Approach

Figure below illustrates what is known as the “Fine grained” approach.

The biggest advantage of this approach is that, there is great flexibility in what client wants to get from the Web Service. If a Client is interested in getting Only Employee Skills that can be accomplished very easily by calling the corresponding web method. The problem though is that if a Client wants to get the Entire details of the Employee, there has to be 5 calls made to the Web Service provider, which increases the amount of Network traffic. Each Network call made is costly and can also affect performance negatively.

Coarse grained approach

Figure below illustrates what is known as the “Coarse grained” approach.

The Key advantage of this approach is that the Network Traffic is reduced as the number of calls is reduced. There are few disadvantages though; now the DTO has become bulky, which contributes to the amount of data sent on the Network. Further, the Client has lost the flexibility of deciding what should be sent back. One more problem is that Client might not want to know about the “Peers” Data, but the server takes time to fetch that information from the Database, which again slows down the Web Service. The Coarse grained approach makes use of the Façade design pattern.

Dynamic Determination

Some of the designs adopt a “dynamic approach” to determine the granularity. The Dynamic approach is an attempt to make the service more versatile. Consider the following scenario. Along with he empID parameter to the getEmployee(), we pass the following Key Value Pairs

fetchSkills – true

fetchDRs – false

fetchPeers – true

fetchDependents – false

The Server side code can read these inputs and determine what should be populated on the Employee DTO. This approach solves the problem of too many Services to call, and also optimizes size of the DTO. But there are certain pitfalls. One of the most important ones is that it tightly couples the Server side code to the structure of the Key value Pairs. Server side code is assuming the existence of certain predefined strings being passed in a Generic Data Structure. The sanctity of the Contract can be easily violated, as there is not much of information about the generic data structure when the contract is formed. Also this nullifies the validation capabilities based on compile time structures as a generic data structure is passed in the call.

Note: The dynamic granularity approach works very well with REST based Services due to the absence of the contract.

Designing Web Services with the correct granularity

Concept of granularity is not absolute. There is no objective way to quantify the granularity of a Service. Determining the right granularity is always an “it depends” question. Yet, this concept of granularity is incredibly important to the enterprise architect because it has a direct impact on two major goals of Service orientation: the composability of loosely-coupled Services, and the reusability of individual Services in different contexts. Before an architect can go about designing a Service Contract, they must first somehow come up with the requirements for that Service.

  

An architect has two general approaches to identifying Services: starting from the business-process or a business model and decomposing that into sub-processes or sub-models recursively until some condition is met by which it can’t be decomposed any further. Alternatively, an architect can start from the IT systems already implemented, expose Service interfaces from the APIs and access points that already exist, create Service Contracts on top of those interfaces, and then compose them together until the business process requirements are met. While top-down approaches are generally favored to achieve the “right” level of granularity, in reality, proper Service-oriented approaches combine both top-down and bottom-up in a continuous and iterative manner.