Once candidate services have been selected and documented in the (categorized) Service Portfolio, we then need to determine which ones should be exposed as services. Although, in theory, any candidate service could be exposed by exporting its interface as a service description, not every candidate service should be. It may not be economically and practically (non-functional requirements may be compromised) feasible to do so. In particular, the naive decision to expose "all methods from all classes" will result in an overwhelming and often unmanageable number of services leading to the "Service Proliferation Syndrome". This creates huge performance and service management problems, not to mention the fact that we may be giving away the company's intellectual capital. Moreover, we must remember that there is a cost associated with every service we choose to expose: the funding, governance and the underlying infrastructure (its security, performance, management) of the service and the components that will implement them must be taken into account.

Therefore, some criteria are needed to help decide whether to expose a service and most importantly, whether to fund the creation of the service component that will provide the functionality of the service as well as the maintenance, monitoring, security, performance and other service level agreements of the service. 

Service Litmus Tests

Project experiences indicate a set of criteria in the form of the Service Litmus Test can and should be used to filter the collections of candidate services. This metaphor is used to denote a set of tests, that when applied, will determine if a given service should be eligible for exposure using a service description. These tests are employed together and help answer questions such as: From the list of candidate services, which ones should be exposed? And thus, which ones should we fund? Which ones have business value?

On the one extreme, every business use case might be considered to be a candidate service. On the other, only a few services are selected for exposure. Applying the Service Litmus Test usually gives something in the middle: a manageable set of services that the business wants to expose and that can later be used within compositions.

Candidate services that pass all of the Service Litmus Tests should then be exposed as services in the SOA. There may be candidate services that did not pass the Service Litmus Test but which are still implemented as services. Service Litmus Test is an aid to determine which services to expose; if a business chooses to expose candidate services that did not pass the Service Litmus Test, the implication is that benefits associated with a SOA will not be realized.

Candidate services that do not meet the Service Litmus Test will have to be implemented in some fashion as they are required to fulfill business needs. They may be implemented as methods on service components and will not require the generation of WSDL or other forms of service definitions; or they may be used as non-exposable entities.

Considerations

Application of Service Litmus Tests is an iterative process. For the first phase of elaboration, decisions should be made based on current knowledge. Service Litmus Tests should then be revisited as more information is obtained throughout the design process.

Service Litmus Tests for each candidate service should be applied and reviewed with the appropriate Subject Matter Experts or Stakeholders.

Reviewing results of the Service Litmus Tests are a useful way to track the appropriateness of the criteria and service granularity. For example, if too many candidate services are passing a particular test, that test definition may be too broad or the service level granularity may be appropriate.

A service may fail one or more of the Service Litmus Tests but may still be exposed due to some project specific decision (business or IT). This is ok. There may be an architectural or business decision made to expose a service despite the Service Litmus Tests.