|I *was* going to ask why we are revisiting this. But then I reread the RM; and now I think I understand. I does not meet our 'loose coupling' criterion.|
My 2 cents (repeated from earlier discussions)
1. There is some desire to distinguish the 'potential' aspect of service from the 'actual' performance of service. Both senses are used and it is therefore easy to talk at cross-purposes.
2. There is also the 'thick' view of service compared to the 'thin' view. If you are a user of a service then you will see the service 'head-on' as it where, and it becomes essentially a window onto the capability you are trying to access. From the head-on view, you do not really see the service itself, you only 'see' the capability -- through a glass darkly as it were.
From the 'sideways' view, you see the service as an entity in its own right that needs policies, management, deployment, testing etc. etc. This is the thick view of service: thick because there is tangible 'stuff' between the users of service and the providers, stuff that you need to know about.
Again, I think that both aspects are legitimate but confusion can reign if you do not distinguish these.
(a) A service is an [abstract] resource that permits actors to provide and access capabilities, together with descriptions that characterize the capabilities and the means to access them.
(b) A service is a coherent set of potential objectives that an actor (or actors) are predisposed to adopt, together with descriptions that characterize the requirements and the potential objectives.
The second definition is, of course, informed by Section 3 :) I can also see people scratching their heads about it.
On Jul 17, 2010, at 8:02 PM, Ken Laskey wrote:
In an attempt to provide a starting point for the RM meeting discussion, I provide the following as a capture: a summary definition that tries to capture previous points and suggested changes beyond that.
A service (in the context of SOA) is a capability that exposes a business function in the context of the following constraints:
- The service is offered and packaged by a provider and made accessible to consumers
- access is provided using a prescribed interface that abstracts (or hides) the implementation details of the capability or function, and
- the service is exercised consistent with the contracts and policies as specified by its description.
In general, the specifics of the business function should be known independent of the service that exposes it.
specific suggested changes:
1. “access is provided using a prescribed interface, and”
and drop “that abstracts (or hides) the implementation details of the capability or function”
2. A service (in the context of SOA) is a capability that **is exposed as a** business function in the context of the following constraints…
rather than **exposes**
3. “A service (in the context of SOA) is a business-aligned capability …” or more specifically, “A service (in the context of SOA) is a business-aligned IT capability …”
4. Additionally: “A capability is the ability to perform a function or set of functions based on expertise and capacity.”
I did not try to capture discussions that did not offer specific wording. This is meant without prejudice to those discussions, but I found no way to do those justice. Also, while those discussions bring up important points for additional expansions, I do not think they materially affect the summary.
Feel free to augment my capture.
I look forward to reaching consensus.
P.S. We will also need to decide what to do with the result. At one point I raised the possibility “I suggest we write it up as a white paper that is endorsed by the TC, have it announced as appropriate by OASIS, and ask the TC members to include appropriate discussion of this in their blogs.
” Other suggestions are welcome, including a new version of the RM. Give the possibilities some thought.
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379