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
---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php