Re: [soa-rm-ra] service, capability, and concise description

[Francis McCabe <frankmccabe@mac.com>]

Continuing the discussion ... :)

On May 21, 2008, at 2:17 PM, Ken Laskey wrote:

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

I think that from a methodological perspective, we may well wish to  
state that a service enables access to a single capability. Of course  
the realization of that capability is another matter. The reason for  
this is that it provides some guidance as to what constitutes a  
service. It is also justified from the perspective of loose coupling  
-- if one service offers more than one capability, then that sets up a  
unnecessary dependency between the capabilities being offered (they  
must be maintained together, upgraded together, described together  
etc. etc.)

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

I kind of see this. What occurred to me however, was that we might be  
better to focus on the purposes of a description:

-- Supporting the decision whether or not to use/offer a service
-- Supporting the task of using a service
-- Supporting the engineering of realizing a service
-- Supporting the management of services (note: not all management of  
services is done by 'management', some of it is done by customers as a  
way of managing their requirements)

Then you can show how these uses are met by different aspects of the  
description.

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

I think that talking about underlying capabilities is kind of a  
slippery slope. We have always understood that the realization of  
services was private. By implication, if a service exposes less than  
what could be exposed, that is a private choice of the provider of the  
service; and should remain private. The simple story of one service =  
one capability leaves open the choice of implementation (e.g., in  
terms of a larger more powerful 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.

There is something of a gray area in here (notwithstanding comments  
above). I can see that different stakeholders will have different  
understanding of the capabilities on offer. A management policy, for  
example, may need a different understanding than a security policy.



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

Agreed.

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

Well, also agreed. I think that the loose coupling principle applies  
here: the coupling between different elements of a service should not  
be stronger than those implied by the semantics of the service  
elements themselves.

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