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.
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.