4 Tenets or Service Oriented Architectures

I was chatting to an ex colleague the other day, and he was saying that at work he was about to start working on a set of web services for one of their web projects. The conversation carried on down the web services design route for a bit. One comment that made me wince a little was, “they are just like online dynamic link libraries”. Well they could be seen as online dll’s I guess, but to produce a proper service oriented architecture you need to follow a few firm rules / principles. It isn’t the first time I have heard of web services described in this way, so I thought I would add a post briefly explaining the 4 tenets of services oriented architectures.

Service boundaries are explicit

Any service is always confined behind boundaries such as technology and location. The service should not make the nature of these boundaries known to its clients by exposing contracts and data types that betray its technology or location. Adhering to this will make aspects such as technology and location irrelevant. Another way of thinking about this is that the more the client knows about the implementation of the service, the more the client is coupled to the service.

Services are autonomous

A service should not need anything from its clients or other services. A service should be operated and versioned separately from other services. This will enable the service to evolve separately from the client.





Services share operational contracts and data schema, not type and technology specific meta data

Any data the service decides to expose over the service boundary should be technology neutral. The service must convert any technology specific data to some neutral representation. A service must also not expose any local implementation details such as instance management or concurrency. A service only exposes logical operations.




Services are compatible based on policy

A service should publish a policy indicating what it can do and how clients can interact with it. Any access constraints expressed in the policy should be separate from the service implementation details. Not all clients can interact with all services. It is perfectly valid to have an incompatibility that prevents a particular client from consuming the service. The published policy should be the only way a client can decide if it can interact with the service.

These are the main published rules around web services. There are also some other principles that are good practice to follow: First, services should be secure. Even if this only means securing the transport (ie SSL). The client should also have a way to authenticate with the service.

Services must leave the system in a consistent state. If an operation fails part way though, the service should be able to leave itself in a consistent state. This could be via transactions or any other method of maintaining consistency.

Services should be thread safe and designed so that it can sustain concurrent access from multiple clients. Services should also be reliable (yeah seriously). When a client calls a service, it will always know in a deterministic manner if the message was received. Messages should also be processed in the order that they were sent. As well as being reliable, the service should also be robust enough to isolate its faults, preventing them from taking down itself or other services. Well I hope that clears that up :-)