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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

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


Subject: Re: [soa-rm-ra] Service & Capability


This is consistent with what I was saying, and as I said, I think 
we're getting closer. However I think we're not there yet.

I may actually, finally, get a chance to reread the whole spec this 
weekend (knock wood), but it looks a lot like that's the last break 
for me for the foreseeable future, as we have another large Emergency 
Management spec poised for submission of its Requirements to the EM 
TC in mid-Feb and it is due to land in the lap of the SC I co-chair 
just about the time the small profile spec I'm editing goes out for 
its 60-Day Public Review. Unfortunately, there's another big one in 
the pipeline due to land sometime in March.

It looks like we should be able to get the RA out for its second, 
and, hopefully, last, 60-Day Public Review by end of Feb, yes?

Cheers,
Rex

At 7:37 PM -0800 1/29/09, Francis McCabe wrote:
>Following on from Ken's intro....
>
>We use action in at least two distinct ways; communication is action 
>and using a service also involves action. I think that there are 
>other layers of action beyond this; involving governance and social 
>structures for example.
>
>From the perspective of an actor in the ecosystem, his interest is 
>in 'getting something done'. Using a service is one of the tools 
>that he may employ to get his needs met. In order for an actor to 
>use a service to get his needs met, he has to engage in 
>communication -- which is also action.
>
>Furthermore, just as communication is impossible without both a 
>speaker and a listener, so service action is also impossible without 
>all the participants -- hence the concept of *joint action*.
>
>As for capability v action, it seems to me that capability is 
>potential action; using a capability is kinetic action.
>
>Although we do commit to message exchange in the RA for service 
>interaction; we do not commit to that in the RM. Because of this, 
>there would be significant push back adopting a communications' 
>oriented view of capability. The *real* (IMO) essence is the 
>potential for crossing ownership boundaries: *he* is asking *her* to 
>do something.
>
>There is some debate about a 'thick' view versus a 'thin' view of 
>services. In the thick view, service is a tangible entity in its own 
>right, separate from any back-end resources. In the thin view, a 
>service is a means to access a capability and is, ideally, 
>completely transparent.
>
>Personally, I think that if you are a software agent executing code 
>that involves using or offering a service, the thin view seems the 
>most appropriate. If you are a manager then the thick view is the 
>most appropriate.
>
>In the ecosystem view, I believe that the thin view of service is 
>dominant. In the realizing view the thick view dominates; and in the 
>owning view it is a mixture.
>
>
>
>On Jan 29, 2009, at 6:20 PM, James Odell wrote:
>
>>Hi Ken,
>>
>>So if "a capability is something that can be brought to bear to 
>>address some set of needs" -- then if "an action is the application 
>>of intent", couldn't an Action be one of those "somethings"?  I 
>>find it quite common to hear how capability of a service be 
>>expressed in terms of the actions/operations provided by the 
>>service.  I don't know if you want to adopt this way of speaking. 
>> In fact, in some dictionaries, capability is the ability or power 
>>of action.  If "capability" is the ability to "do something", then 
>>action is certainly on of them.  In RFC 2703, "a capability is an 
>>attribute of a sender or receiver that indicates an ability to 
>>process."
>>
>>
>>It other published approaches, action is just one of several 
>>features of expressing capability.  In some books, capability 
>>descriptors can include goals, plans, protocols, actions, and so 
>>on.  
>>
>>My 2 cents.
>>
>>-Jim
>>
>>
>>
>>On 1/29/09 6:34 PM, "Ken Laskey" indited:
>>
>>>Jim,
>>>
>>>First, what is meant by Action has been a continuing source of 
>>>debate, and I'm not sure it's been resolved with respect to 
>>>section 3.
>>>
>>>With that as a caveat, my interpretation is
>>>1. A capability is something that can be brought to bear to 
>>>address some set of needs.
>>>2. The results of using a capabilities are a set of real world 
>>>effects that represent an effect on (and ideally a satisfaction 
>>>of) the needs.
>>>3. SOA services access capabilities and thus by exercising those 
>>>capabilities, results in certain real world effects.  Note the 
>>>real world effects of the service may not merely match the real 
>>>world effects of the service because more things may be going on 
>>>than accessing a single capability.
>>>4. (This gets touchier.) An action is the application of intent 
>>>(by a consumer) that somehow has the service do its stuff and 
>>>producing real world effects.  But when a service receives a 
>>>message, a Web Services implementation would kick off a WSDL 
>>>operation, and there is a certain extent to which Action as 
>>>connected to description and interaction maps to that WSDL 
>>>operation.  I have no doubt others will further muddy this point.
>>>
>>>Ken
>>>
>>>On Jan 29, 2009, at 5:40 PM, James Odell wrote:
>>>
>>>>Hi all,
>>>>
>>>>  OK, just one last question for today.
>>>>
>>>>  In 4.3.2, Services perform Actions that cause Real World Effects.
>>>>  In 3.3.1, Services have Capabilities that achieve Real World Effects.
>>>>
>>>>  It would seem that there Actions and Capabilities have some 
>>>>close conceptual tie, here.  Are Capabilities defined in terms of 
>>>>the Action(s) they provide?  Or, ...?
>>>>
>>>>
>>>>  -Jim
>>>>   
>>>>
>>>
>>>
>>>-----------------------------------------------------------------------------
>>>Ken Laskey
>>>MITRE Corporation, M/S H305      phone: 703-983-7934
>>>7515 Colshire Drive                         fax:       703-983-1379
>>>McLean VA 22102-7508
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>Attachment converted: Macintosh HD:smime 993.p7s (    /    ) (0124AA3C)


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670


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