Service Design Principles

Service is a computational functionality exposed over network. So any computational resource which can expose its functionality over network can be treated as service. But do we need such type of services in SOA ecosystem. Definitely NOT. In SOA ecosystem, service must demonstrate some traits:

• Compose-ability
• Statelessness
• Context unawareness
• Discoverability over network
• Reusability
• Decoupling of service implementation and contract/interface
• Adherence to standards

To make sure that a service demonstrates outlined traits, following design principles must be followed while designing a service in any SOA ecosystem.

1. Standard Service Contract/Interface
2. Optimal Service Granularity
3. Service Re-usability
4. Stateless Service
5. Context Unaware Service
6. Compose-ability of Service
7. Service discover-ability
8. Service Autonomy
9. Service context abstraction
10. Externalization of non core aspects
11. Service versioning
12. Multi contract/interface availability
13. Idempotent Service
14. Coupling Management


1. Standard Service Contract/Interface: Service in a defined inventory must have standardized contract for availing the intended business functionality. Standardization keeps needs of data transformation minimal and also brings in predictability and increases comfort level of calling party.

2. Optimum Service Granularity: Service granularity is one of the joint decisions of Business and Technical teams with respect to service design. On the basis of granularity services can be classified as:

a. Atomic: Service which can enforce transaction related features to its exposed operations.
b. Molecular: Services which can not enforce transaction related features but can have compensatory features. This type of services is composition of underlying atomic and molecular services. Some time it is very difficult to differentiate between a molecular service and a process because process can also be exposed as service.

3. Service Re-usability: Service re-usability is one of the driving forces of SOA ecosystem. Service re-usability is function of granularity, contract/interface standardization, compose ability, context abstraction, idempotent nature, context unawareness and versioning. In SOA ecosystem, re-usability of service is big driver of molecular composite service.

4. Stateless Service: In a SOA ecosystem, services must be stateless whether atomic or molecular. Stateless of service facilitates compose-ability. But as service moves from pure service to process keeping statelessness become difficult but it is always desirable.

a. Current result of service execution must not be affect by any of previous result.

5. Context Unaware Service: Context unawareness of a service is contributing factor for statelessness. Context unawareness essentially about two main concepts:
a. Who is calling? (may be negated in serving versioning, testing/training mode)
b. Who is called me earlier? ( Make sure that service behavior must not change depending upon previous calling party)

6. Compose-ability of Service: for an SOA ecosystem, one of the important metric is number of services reused. This reuse of service may be of three types:
a. Consuming a service in an application
b. Consuming a service in process
c. Consuming a service in creation of another service

Last two type of service consumption is mainly result of compose-ability of a service.

While designing a service pay attention to following aspects:
a. Ability to compose other services
b. Ability of to be composed
c. How deep composition should be?

7. Service Discover-ability: In a SOA ecosystem, service are discovered in following manner:
Consumer discovers a provider at design time:
i. Developer/Designer refer some list manually
ii. IDE presents pre-listed ( with IDE or pre-configured Registry)
d. Consumer discovers a provider at run time:
i. Consumer discovers a provider while looking at repository where provider is listed. This process happens at first call to provider. Discovery process gets repeated if consumer lost the information about provider. Discovery process also happens if provider becomes unavailable.
ii. Consumer discovers provider with each call via trip to repository.

Each discovery scheme has its own pro and cons. Most of the time discover-ability of service is not only function of service interface/contract design but also infrastructure capability of SOA ecosystem.

8. Service Autonomy: For any atomic service, the implementation is in some component and some persistence layer to hold data. In spirit of component re-usability, one can reuse components in two or more services. This reuse of components can be of two types:
a. Different installations of same component ( different binaries) are utilized
b. Same installation of a component is used in two or more services

At persistence layer services can again utilize one or multiple instances of same data. While deciding what type of persistence layer is shared also raises difficult question of integration (EAI).

In Molecular services, services composed also constitute big role while deciding Service autonomy.

9. Service context abstraction: Service context abstraction idea is borrowed from encapsulation of object oriented world. In Bjarne Stroustrup's words - expose minimal but complete. On the lighter side “Exposed contract/interface is like Bikini. What does it reveal is sufficient to arouse, but what it conceals is vital”. The service contract/interface should consider exposing following aspects:
a. Functional aspects
b. Technical aspects
c. Non Functional and non technical ( abilities) aspects

10. Externalization of non core aspects: In any good software design non core aspects of that software must be externalize to keep focus on business logic and keeping the code simple. The concept of externalization can also be understood from Aspect Oriented Programming perspective.

If we move into conventional software design, following considerations must be in mind:
a. Configuration parameters ( generally technical attributes)
b. Rules ( generally business rules/attributes)
c. Hot deploy-able vs. non hot deploy-able
d. Design time vs. run-time change in attributes.

11. Service versioning: Service must be able to support versioning to cater its evolution. The versioning support for a service level can be handled at platform level or at service level or at deployment level. All schemes of versioning support have their own pros and cons.

While catering for service versioning need, pay attention to:
a. Context unawareness of service
b. Multi version contract/interface
c. Multi version deployment of service


12. Multi contract/interface availability: In some cases, especially when SHE (Service Hosting) is not used, service is made available at multiple channels. If this is the need then pays attention to availability of multi channel interface/contract.

13. Idempotent Service: If service to be called by same consumer, its response must not be affected in any way. This is one of the important design aspect while realizing context unawareness and statelessness.

14. Coupling Management: In any software system one of the important goals is reduced coupling. But in real life coupling can not reach to zero it can be minimized or transferred from one face to another. In SOA ecosystem, coupling with respect to service can be understood as:

a. Semantic coupling: Coupling between consumer and producer with respect to data structure passed while service is called for consumption.
b. Ontological coupling: Coupling between consumer and producer with respect to nomenclature of service operation/method/function.
c. Temporal Coupling: Coupling between consumer and producer with respect to time and calling sequence.
d. Spatial Coupling: Coupling between consumer and producer with respect to address and addressing scheme
e. Stamp Coupling: Where two services modify common data.