Operations in a Service Interface v 7.0

This is fifth stage of evolution - good or bad, no idea.

I am trying to list all possible technical, non business oriented operations possible. In my view any  business operation is just bunch of technical operations arranged in smart way ( a.ka. BPEL).

Am I still missing after 7 iterations?

Operations in a Service Interface v 5.0

Operations in a Service Interface v 4.0

Now the fourth version

Operations in a Service Interface v 3.0

I have listed the operations a service should exposes in my earlier post. I have revised the list. The latest is:

Operations in a Service Interface v 2.0

I have listed the operations a service should exposes in my earlier post. I have revised the list. The latest is:

Operations in a Service Interface

In a service interface various operations are exposed. These operations can be grouped in few categories. I have tried listing these categories as:

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.

Single Service: Multiple Interfaces – Service Design Pattern

In one of my recent project, I encountered an interesting challenge. There was couple of services. Each of these services needs to serve various consumers which have diverse background. Few of the customers were interested in one type of interface (Web Service) while other set of consumers were demanding SOAP over JMS, CORBA calls and few more. This was interesting situation. My SOA instinct told me to look for solution in ESB. But none of ESB was able to provide such diverse channel transformation. Then I discovered that solution lies some where else.

“A service should have multiple interfaces in terms of technology & business needs if ESB fails to provide.”

I realized from analysis of various other projects that this is a pattern which is quite prevalent but not explained in detail. I call this pattern Single Service: Multiple Interfaces.






Discovery of this pattern also leads to another pattern – Separation of Service Implementation and Service Interfaces. I will discuss this pattern in detail in some future post.

Anatomy of Service

Service is one of the basic component of SOA. But what is Service and what are the different attributes of a service and how to interact with each other and across different services?

In simplistic terms service is logically grouped set of operations capable of performing related unit of work and operates over a message.

So service is units of processing logic, which are closely related.

Therefore service has two major components:

1. Message: Data required to complete partial or all parts of a unit of work.
2. Operation: The logic required to process message in order to complete a unit of work.




A well-designed service should have following attributes:

1. Service should be reusable
2. Service should exposes a formal interface contract
3. Service should abstract underlying logic
4. Service should be composable
5. Service should be autonomous
6. Service should be stateless
7. Service should be discoverable
8. Service should be available over network

In addition of these, if we consider SOA as confederation of services on more attribute is desired:

9. Services must be loosely coupled.

So how these attributes interact!!



Services may also be viewed from application perspective over which they are written or which they make in some composable fashion. The second perspective is process perspective, which view services from enterprise process perspective.



Application perspective of Service




Process perspective of Service




Hybrid perspective of services

Service Interface / Contract Definition

Recently I have developed a document which will be helpful in documenting service interface or contact. This document is in MS EXCEL format. The document is structured in technology independent way. I will certainly welcome any suggestion and changes with respect to technology and platform.

I hope this document will be helpful tool to lot of us to sail through SOA universe.

The document can be downloaded from Scribd.com.