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
>
