Granularity of service
The most important aspect in determining granularity is probably re usability if a piece of software is (or will be) used by more than one consumer, this piece of software should be a separate service. If not, we can incorporate this piece of software in a larger composite to hide it.
More specifically, for SOA composites this would mean:
- If a component (e.g., a business rule, a BPEL component, etc.) is reusable, create a dedicated SOA composite to contain it.
- If not, embed the non-reusable component in an existing SOA composite or merge it with another SOA composite to create something that is (re)usable.
Other than reusability, you should also take into account organizational and administrative considerations like –
- Rate of change: fast changing components should be separated from more stable ones.
- Availability: it makes sense to create a separate SOA composite for something that needs to be available 24/7 in order to keep it separate from other components that are less critical and not in constant use.
- Ownership: ideally, a service or process should have a single (business) owner. If more than one owner is identified, the composite might be too big.
It also depends on the approach you are following for SOA design and architecture. If it’s top-down means – defining problem, designing architecture and developing solutions then this means that the business unit (user) drives the requirements and essentially (but, not directly) the service granularity.
By definition a coarse-grained service operation has broader scope than a fine-grained service.
Coarse-grained service requires increased design complexity but can reduce the number of calls required to complete a task.
The four key factors to consider when designing for optimal granularity are performance, message size, transaction and business function:
Performance – Web services are accessed remotely and calls to web service operation create more networks overhead. Reducing the number of service requests reduces that overhead. This means Business Process layer services should be coarse-grained and while fixing a naming convention to them – use a NOUN. Examples like – Insurance Quote Service and Inventory Service and not process quote, add employee etc.
Message size – Coarse-grained services may pass more data than fine-grained services, including data that is not specifically required for the task. Reducing message size may require adding a more fine-grained operation.
Transaction – For conceptual clarity each service operation should perform a single transaction. This also simplifies error recovery, and typically eases design.
Business Function – Ideally, each service operation maps to a single business function, although if a single operation can provide multiple functions without adding design complexity or increasing message sizes, this generality can reduce implementation and usage costs.
Conclusion – Focusing on the actions (verbs) rather than the service (nouns) creates fine grained services. Hence use verbs for Business Service and Nouns for Business Process services.