service, capability, and concise description

[Ken Laskey <klaskey@mitre.org>]

Following today's animated discussions, I am making an attempt at words that pull together a number of the pieces into a clear, concise package.  I am not advocating exactly where it goes but submit it for your consideration and continued discussion.

Ken

++++++

As defined in SOA-RM, 

A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.  

As shown in Figure 20, the service description provides information on: 

- what a service does (its functionality and the resulting real world effects), 

- how to reach the service (protocols and the endpoint of service reachability), 

- how to communicate with the service (the information and behavior models that make up the service interface),

- what are the conditions of use (service policies and contracts), and

- what measurements of performance are available and how can these be accessed (service metrics).

The capability the service is accessing may be a single resource or a composite of multiple resources and/or other services, and the specific service exposes some subset (possibly all) of the capability's functions and corresponding real world effects.  The automated teller machine (ATM) example in SOA-RM discusses a service exposing only certain aspects of an underlying capability.

While the capability may be accessed by other means (or by other services), the description of the capability is important only to the extent that it is reflected in the service description.  In particular, it is not important what functionality or real world effects can be realized from the underlying capability if those effects are not accessible through this service.  Similarly, policies related to the capability but not involved with the functionality being accessed by the service are not relevant.

In designing a service, it is important to consider how straightforward it is to provide a service description.  Note the description will have multiple users, including:

- developers who need to find functionality, decide whether the conditions for use are acceptable, and code to service reachability and the service interface;

- consumers who also need to consider functionality and conditions or use, but are interested to know about service availability (presence) and performance (metrics), and must also consider whether they can provide information needed by the service interface;

- managers who are interested in service presence and other metrics for service performance and use, and possibly service functionality if they are engaged in service protfolio management.

The service description provides a common, consistent collection of information for the multiple users for discovery, evaluation,  and use.  Thus, if it is not possible to generate a clear, concise description of a service, it is reasonable to ask whether the combination of actions, effects, and policies, and other descriptive elements would best be served by separate services that are more focused and more straightforward to understand and use.  The aggregate of the information in the service description makes effective use of the service possible.

[Note, the last sentence could have a tie-in with something providing the overall picture attempted by Figure 26.]

------------------------------------------------------------------------------------------

Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508