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.

Services Orchestration Design Principles & Best Practices

In real life SOA implementation services collaborate and executes in a particular fashion to perform a process. Process implementation uses Orchestration and Choreography of services. In this blog entry, I would like to focus on services orchestration.

From my experience on Oracle Fusion, TIBCO, Aqualogic and WebMethods I have collected some Services Orchestration Design Principle & Best Practices. I am listing those, independent of Tools/Platforms:

1. Keep Orchestration depth to manageable limit. (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/01/composite-services-complexity-measure.html)
2. Keep service dependency in manageable limit (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/01/inter-service-dependency-model.html)
3. Keep granularity of services under predefined criteria. Visit this criterion regularly.
4. Avoid recursive service calls.
5. Classify services as technical and business
6. Avoid complex and huge service contracts
7. Handle anticipated Faults and Exceptions
8. Keep Fault handling and Exception logic out of main process flow
9. Develop compensatory processes
10. Pay attention to Quality of Service (QoS) of services involved in Orchestration
11. Pay governance policies to services involved in Orchestration
12. Remember Separation of concerns
13. Validate messages flowing in a process – in process, and in out of the process
14. Pay heed to vendor specific best practices and design principles
15. Last but not least: Test, test, test, …

Service Design Principles

As we all know SOA is an architectural style to building systems from autonomous services. So what are services? Services are software programs that interact with well defined messages over network.

Keeping these propositions in sight, SOA ecosystem robustness and architectural value is greatly influenced by how Services are designed as consumer and provider.

While designing a service one should consider following perspectives:

1. Provider perspective
2. Consumer perspective
3. Implementation perspective
4. Administration perspective

The design goal service should be similar to any software system. These are:

1. Loose coupling: Basic objective of SOA
2. Encapsulation: Basic objective of Object Orientation
3. Polymorphism: Basic objective of Object Orientation
4. Autonomy: Basic objective of SOA and distributed computing
5. Orthogonality: Basic objective concept of layered architecture and Object Orientation
6. Idempotency: Basic concept of distributed computing
7. Cohesion: Division of labour and specialization

So partial list of design and building principles of services:

1. Services should be designed for availability and stability.
a. Once services are deployed in production environment change in their availability & scalability is undesirable
b. Infrastructure support for service should be continually evaluated and updated to cater increased load and stress.
2. Service configurations are designed and built for change
a. With the passage of time and changing business needs, service configurations changes with respect to functional and non functional aspects.
b. Service’s deployment options with respect to physical location, policy, topology changes
3. Service invocations are subject to famous EIGHT fallacies of distributed computing.
4. Use Object based ( programming language - Java objects or XML documents à object/document may represent business event not actual business documents) operation/method parameters and return type
5. Keep service surface area minimum. The more operations/methods a service exposes the more difficult to manage them.
6. Avoid Service Hell
a. Service granularity must be managed. Too coarse grained service hinders re-usability. Too fine grained services create a jungle of services.
b. Service versioning should be managed
7. Adopt pessimistic view while designing a service (consider both views: Provider & Consumer)
a. Design and build services with extensive exception and error framework in foundation.
b. When service acts as provider validate one and all inputs
c. When service acts as consumer design for unreliable provider with respect to availability and performance
8. Services contract should be deployed & versioned independent of:
a. The system they are deployed
b. The inter implementation
9. Idempotency (Repeatability): Service must be idempotent with respect to one and multiple consumers.
10. Service nomenclature should be in sync with business not with development team. This especially true for business services.
11. Services must be stateless.
12. Services should have multiple interfaces either using ESB or without it.
13. Service should support patch like mechanism to facilitate upgrade.
14. Service operations/methods should be designed for concurrency.
15. Carefully decide (use both business and technical perspectives) which service should have compensatory service
16. Avoid transactions
17. To track state during long running service use track identifier at each milestone of process.