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

I really concern if we go with "IT-oriented definitions" in a White Paper, in SOA-RAF or anywhere else. If SOA-RAF limits itself by "IT-oriented definitions", it will be huge step BACK regarding modern understanding of SOA in enterprises: SOA is really , day by day, getting across the boundaries of IT into Business. SOA in between is the IDEAL position and the definitions of the SOA service should follow this positioning IMO.

- Michael Poulin

-----Original Message-----
From: Rex Brooks <rexb@starbourne.com>
To: Francis McCabe <fmccabe@gmail.com>
Cc: Ken Laskey <klaskey@mitre.org>; soa-rm@lists.oasis-open.org
Sent: Tue, Jul 20, 2010 1:35 am
Subject: Re: [soa-rm] summary of service definition suggestions

I think that Ken's suggestion of putting this discussion of notional and IT-oriented definitions of service into a White Paper that includes citing the other definitions is spot on. Let's not spend more time wrestling that alligator. I suggest we hold that discussion in a series of RM meetings separate from finishing up the SOA-RAF. 
I did not bother even getting started on my own hobby horse here. Suffice it to say that I will contribute it to the White Paper effort. 
Count yourselves lucky... for now ;-) 
Francis McCabe wrote: 
> 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. 

> Suggestions: 

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

> Frank 

> On Jul 17, 2010, at 8:02 PM, Ken Laskey wrote: 

>> All, 
>> 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. 
>> <startingPoint> 
>> *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. 
>> Ken 
>> 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 

-- Rex Brooks 
President, CEO 
Starbourne Communications Design 
GeoAddress: 1361-A Addison 
Berkeley, CA 94702 
Tel: 510-898-0670 
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail. Follow this link to all your TCs in OASIS at: 

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