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

[James Odell <email@jamesodell.com>]

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

Frank,

Interesting dichotomy between “thick” and “thin” views of service.
Am wondering if we can have both at some level:

Thin view – here, the service virtually exists (i.e., “access a capability and is, ideally, completely transparent.”)

Thick view — from the “outside,” the service does exists — whether virtually or not — and can therefore be referred to as a first-class entity.  How that object exists does not matter, as long as it can be treated as an existing thing.  That is, thick can be thin, and the consumer would not need to know.  :-)

-Jim

 


On 1/29/09 10:37 PM, "Francis McCabe" indited:

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