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.