Service Reusability

Service Reusability

One of the most vital principles of Service Oriented Architecture is that of service reusability. And in today’s day and age, it can be said that we have been making a lot of progress towards improving both this central tenet and Service Oriented Architecture in general.

One sign that a significant degree of progress in the field has been made is the fact that more and more questions regarding Service Oriented Architecture these days are aimed at the architecture itself, rather than infrastructure and implementation. One question that has come up in recent years is: Should all services be reusable?

This question has a deceptively simple answer. Since it is one of the tenets of Service Oriented Architecture to build services that are reusable, then indeed all of them should be, right?

Upon further examination, finding an answer to this question may require greater demands of subtlety – as well as deeper thinking in architectural terms. In this essay, we will explore the correct answer to this question, while also examining the notion of deep architectural thinking.

Top Down Service Oriented Architecture Thinking

When asking whether or not all services should be reusable, we are led to ask two more questions. Depending on which question you choose to ask, you will be able to determine whether you are thinking about architecture in a bottom up or top down manner.

The top down approach to Service Oriented Architecture thinking begins with a picture of all Business processes that exist in a Business. The thinking then turns to the decomposition of such processes with an eye towards the identification of redundant areas that may indicate good candidates for services.

As such a top down method focuses mostly on meeting the objectives of a Business while increasing efficiency through a reduction of redundancy and a subsequent increase in reusability, the main question architects should ask themselves is whether or not a maximization of reusability is the smartest practice, or whether other priorities should also be taken in to consideration.

The fact is that while reusability may indeed be one of the most important aspects for determining what services are to be built, there are other aspects that must be taken in to consideration by the architect in order to go about meeting the ever-changing requirements of the organization via Service Oriented Architecture abstraction. To be precise, services’ evolvability is something that every architect should take in to consideration.

While some services might have more than one application, they might nevertheless experience several requirement changes as time wears on. There are in fact situations in which agility instead of reusability will be the driving force behind the design of a service.

A certain service might have only one consuming application; this being the case, what should dictate the design of the service is the fact that it is subject to constantly changing requirements -- not its reusability. In such instances, it will be a lot more cost effective to put the necessary overhead in place as a means of ensuring the loose coupling that is required for such services, even though they might only have one consumer.

There is yet another example whereby reusability may not be the service design’s top priority. That is in those instances where loose coupling owing to the contracted nature of the interface becomes the top priority – particularly in Business-to-Business environments.

Two Businesses that are attempting to improve their automated interactions may very well struggle with limitations that are specific to implementation, such as getting a Java based application at one organization to interact with a mainframe based application at the other organization.

In these instances, the building of services with contracted interfaces that abstract the underlying implementation can ease the process faced by such interactions, even though such services will really only be valuable for that precise, point to point interaction.

12