OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [soa-rm] summary of service definition suggestions

You should read the whole email. 
On Jul 19, 2010, at 6:07 PM, Lublinsky, Boris wrote:

service is not a resource. Service is a verb, while a resource is a noun. A given resource can hava multiple methods aka services.

From: Francis McCabe [fmccabe@gmail.com]
Sent: Monday, July 19, 2010 5:22 PM
To: Ken Laskey
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] summary of service definition suggestions

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:

I suggest you all reread the threads (see http://www.oasis-open.org/apps/org/workgroup/soa-rm/email/archives/201004/msg00026.html and http://www.oasis-open.org/apps/org/workgroup/soa-rm/email/archives/201004/msg00061.html for beginning of threads).  They show an order of magnitude more insight than the best of other discussions.
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.”
</ startingPoint >
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.
Dr. Kenneth Laskey
MITRE Corporation, M/S H305              phone: 703-983-7934
7515 Colshire Drive                                    fax:        703-983-1379
McLean VA 22102-7508

The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]