|
In general, I think it is too late to say one service = one capability unless you explain it as one "effective" capability and get into the rest of the discussion below. There is really no reason to avoid this because the RM is out there and anything else would be a major contradiction.
More inline.
Ken
On May 21, 2008, at 6:28 PM, Francis McCabe wrote: 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.
Well, I see yours too but I was thinking of pointing out the modular pieces rather than the use and then combining as below where I address the different users.
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.
The point is it is irrelevant what a capability offers. The critical point is what the service offers. Note in my versioning write-up, I found it sufficient to only track the service version and the service description version.
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.
Well, that isn't what I had in mind and I'm not sure I see the point. Maybe we should just stop at agreeing :-)
[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
------------------------------------------------------------------------------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 |