Task: Apply Services Litmus Tests
This task describes the requirement to qualify candidate services to ensure those that are developed further actually meet the needs of the business.
Relationships
RolesMain: Additional: Assisting:
InputsMandatory: Optional: External:
  • None
Outputs
Main Description

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.

Steps
Ensure Service is Business Aligned

The first test of a service is about its Business Alignment. If the service is not traceable back to a business task or goal, it may not yield benefits required for SOA implementation. The following questions, if all are answered positively, mean the service is aligned with the business.

  • Does the service provide a required business functionality that supports business processes and goals? (see Task: Business Process Analysis )
  • Is the business willing to fund the service through its lifecycle: provisioning, management, governance and maintenance?
  • Is the business willing to share the service internally or externally with clients or business partners? For example, implications may be additional costs, business secrets, security, etc.
  • Are there existing or future opportunities within the enterprise to reuse the service?
Ensure Service is Composable

Composability is defined as an attribute that enables the service to participate in a service composition. Applications can be created using both types of composition. (The two kinds or composite services may be identified: 1. Hardwired composite services Hardwired composite services are characterized by low flexibility, owing to pre-defined flow and control of services where the flow and control is not externalized. These types of services have attractive Qualities of Service attributes such as performance . 2.Loosely wired composite services Loosely wired composite services - these are characterized by high flexibility where composing services into business processes is accomplished by externalizing flow and control. The flow description of the composition is externalized. This type of composition exploits modeling tools, dynamic variability through rules, and static variability through modeling. Composition using BPEL is an example).

  • Does the service meet the required Quality of Service attributes as defined in the composition's Non-Functional Requirements?
  • Is the service stateless? (see Guideline: State Management for Services)
  • Is the service self-contained? Can the service be deployed independently to meet a business goal although it may cooperate with other services at run-time to perform business processes? There are no implicit dependencies of the service on other embedded functionality. All dependent services are either replaceable or self-contained.
  • Is the service's implementation technology neutral? Technology neutral means that the service does not impose support of non-standard (and unknown to the consumer) protocols or devices, for example, the constituent component requires intervention through a non-standard application interface.
    This test applies only when the service is deployed in the consumer's environment. For example: A business provides an image retrieval service to its customers. It can provide this capability to its subscribed customers via a web service. Alternatively, the business can hand over to its customer the image retrieval capability exposed as a web service, and a collection of images. Here, the customer will be burdened by the implementation of the technology search.
Ensure Service has External Description

The most basic property of a service is that it has an externalized service description. The externalized service description may either be that is either generated automatically via tools or manually

  • Does the service have an externalized service description that is distinct and separate from the underlying physical implementation? A current example of this is WSDL.
  • Can the service be discovered and bound using the service description?
  • Does the service description contain meta-data about itself? That is, the service description must be self-sufficient, containing or referencing all of the information necessary to understand the message exchange between consumer and provider of a service.
Ensure Service is Reusable

Can this service be used by the business stakeholder within all processes where its function is required?

Ensure Service is Technically Feasible

Technical Feasibility ensures that the service can actually be realized (implemented and deployed) according to functional and non-functional requirements using available technologies.

  • Is the implementation and management effort for the service reasonable and readily achievable given either the requirements or infrastructure of the implementation?
    This is done after Realization's Technical Feasibility Exploration
Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable

©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.