Service Composability

The principle of Service Oriented Architecture known as Service Composability can be broken up into two basic principles: Service Discoverability and Service Composition. When it comes to the realm of Service Design, a lot of attention is paid to the enabling of those characteristics that are so commonly associated with Service Oriented Architecture marketing – reuse and loose coupling.

While these two aspects are undoubtedly vital, indeed critical to the attainment of long term Service Oriented Architecture transition projects, there is a lot more that should be taken into consideration. Though abstraction can be utilized to support the realization of loosely coupled, reusable services, we have to confront the fact that even the services that are most reusable will not be useful if they cannot be found by those who are responsible for the creation of potential clients.

Moreover, even loosely coupled services will not have a great deal of reuse potential if they are not able to be assembled into compositions in an effective fashion. Thus, it is vital to take into consideration the principles of Service Composition and service discoverability. We will focus on the latter first.

Service Discoverability

Service Discoverability is meant to help one avoid the accidental creation of services that are either redundant or implement logic that is redundant. Owing to the fact that each particular service operation is meant to provide a potentially reusable piece of automation logic, metadata that comes attached to a service must describe not only the service’s overall purpose in an efficient manner, but also the functionality that its individual operations offer.

This particular principle of Service Orientation is similar to Discoverability on the level of architecture, in which case the term “Service Discoverability” is meant to refer to the technology architecture’s ability to provide a mechanism of discovery, for example a service directory or registry. Such extensions effectively become part of the overall infrastructure that is meant to support the implementation of a Service Oriented Architecture.

On the level of service, the discoverability principle can be referred to the design of an individual service so that it becomes as discoverable as possible – no matter whether the discoverability extension or product actually exists in the surrounding implementation environment.

The reason behind this is that even if there is no need for a service registry owing to the fact that there is not enough of a service inventory to warrant the need for one, services should consistently be designed as resources that are highly discoverable in some fashion. By doing so, the evolutionary governance off those services can be better managed when the service portfolio increases in size, as each service will then be equipped with the metadata that is required to properly communicate its capabilities and meaning.