Granularity
The granularity of a service is often ambiguous and has different interpretation. But there is no doubt that the granularity affects the architecture of a system. As we come to service oriented development from object oriented and passing component oriented, the granularity is believed to increase. The services provide access to application where each application is composed of various component services.
It is difficult to define granularity in terms of number because the concepts defining granularity are vague and subjective in nature. If we choose an activity supported by the service to determine its granularity then we cannot have one fixed value instead a hierarchical list of answers; where an activity can either refer to a simple state change, any action performed by an actor or a complete business process. [1][2]
Hazem and Sims have also supported the hierarchical nature of components granularity. A component functionality is composed of various fine grained components and thus leads to a hierarchy level of granularity. [3]
According to [4], the granularity of a component is inversely related to various non functional qualities such as customization and maintainaibility.
The following section provides some views regarding the granularity based on various research papers.
- The correct granularity of a component or a service is dependent upon the time. The various supporting technologies that evolve during time can also be an important factor to define the level of vertical decomposition. [3]
- A good candidate for a service should be independent upon the implementation but depends upon the understandability of domain experts.
[2, 3]
- A service should be an autonomous reusable component and should support various cohesion such as functional (group similar functions), temporal(change in the service should not affect other services),run-time(allocate similar runtime environment for similar jobs; eg. provide same address space for jobs of similar computing intensity) and actor ( a component should provide service to similar users).
- A service should not support huge number of operations. If it happens, it will affect high number of customers on any change and there will be no unified view on the functionality. [2]
- A service should provide transaction integrity and compensation. The activities supported by a service should be within the scope of one transaction. Additionally, the compensation should be provided when the transaction fails. [2,5]
- The notion of right granularity is more important than that of fine or coarse. It depends upon the usage condition and moreover is about balancing various qualities such as reusability, network usage, completeness of context etc. [2, 6]
- The level of abstraction of the services should reflect the level of real world business activities. [7]
Dimension of service granularity:
The factors affecting the granularity of any service is presented by R3 model. The three dimensions of the model are as given below:
Reach: It gives answer to “Who can use the functionality? ”. It provides the levels the functionality of service is accessible from. It can be a customer, the customers within an organization, supplier etc.
Range: It gives answer to “Which functionality is available? ”. It provides the level of information shared with other systems. It can be a simple data access, a transaction, message transfer etc.
Realm: It gives answer to “What kind of functionality? “. It focuses more on the functionality in terms of business value which is the value as perceived by the stakeholders. [7]
Fig: R3 model to present various level of granularity
Another interpretation but similar approach has also been published, which presents three different criteria to affect granularity of any service.
Data granularity: It evaluates how much data is passed to the interface of the service or returned by the service.
Business value granularity: It measures the inclination of the service towards the business. The business value can be predicted by e3 approach or i* framework. Moreover, it considers contribution of service towards the achievement of business goals and values.
Functionality granularity: It refers to the default functionality offered by the service as well as additional optional functionalities provided by the service.
[2]
An additional contribution to defining the granularity has been made when the differentiating features of distributed system are taken into consideration. The granularity of a service depends upon the coupling and cohesion. In order to find the right granularity for a service, we need to balance between coupling and cohesion.
The coupling can be determined from the dependency graph between a service and its consumers. The goal is to minimize the coupling of individual service and to the application as a whole.
The cohesion is evaluated by the likeliness of the operations supported by the service. It considers that higher the similarities among the operations, higher the cohesion is. [8][9][10]
References:
References:
http://link.springer.com/chapter/10.1007/978-3-540-69534-9_29
http://dl.acm.org/citation.cfm?id=555657, Herzum and Sims
. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1347298, Vitharana
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4724572&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4724572
There are no subpages or files.