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

[Rex Brooks <rexb@starbourne.com>]

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 ;-)

Cheers,
Rex

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