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] Public Review Comment


see inline.

On Mar 22, 2006, at 9:26 AM, Miko Matsumura wrote:

> Hi folks.
>
> I have a comment on this section:
> A service is opaque in that its implementation is typically hidden  
> from the service consumer 273
>
> except for (1) the information and behavior models exposed through the  
> service interface and (2) 274
>
> the information required by service consumers to determine whether a  
> given service is 275
>
> appropriate for their needs. 276
>
> I am curious about this definition because it appears to exclude in  
> the definition of the service description any additional information  
> used by service providers for the purpose of maintaining a service.  
> This is just one example of a purpose and a constituency which does  
> not appear to be sufficiently served by this definition. In my  
> experience, services are "viewed" by a diverse set of provider and  
> consumer constituencies which each require information about the  
> service implementation. An example would be lifecycle management of a  
> service from the perspective of a service provider. Or would this be  
> viewed as a part of the implementation? In this case, substantial  
> metadata description is needed within the implementation.

First, the RM also says there is no one "right" set of info to  
exclusively make up the description.  Thus, there is plenty of room for  
lifecycle info but that is too specific to be mandated in the RM.  I  
could also argue that at the RA level, there are numerous descriptors  
that can be associated with a service and, in general, such descriptors  
would be defined by (1) a describing term, (2) a vocabulary/reference  
where the term is defined, and (3) an optional mechanism (possibly  
another service) that could evaluate this service (or capability or  
other resource) and automatically assign the descriptor in (1)  
according to the rules in (2).  But again this is architecture and not  
RM.

We could, however, generalize lines 275-276 to widen the community of  
interest.

>
> It is also referred to in an earlier section here:
>
> In general, entities (people and organizations) offer capabilities and  
> act as service providers. 172
>
> Those with needs who make use of services are referred to as service  
> consumers. The service 173
>
> description allows prospective consumers to decide if the service is  
> suitable for their current 174
>
> needs and establishes whether a consumer satisfies any requirements of  
> the service provider. 175
>
> Services are wonderfully opaque. This is good stuff. Abstracting away  
> the implementation is one of the benefits and provides a degree of  
> commoditization of the implementation. Very handy. However, in  
> practice, dealing with services requires a great deal of service  
> description --only some of which is targeted at service consumers.

The explanation and consideration to generalize the audience is also  
appropriate here.

>
> One interpretation is that you could define, for example, someone who  
> is a member of the provider organization, but who is managing the  
> promotion of a service from development stage to production as a  
> "service consumer" in that they are "making use" of the service, and  
> modifying . But I think this definition is a little awkward

Even at RA, I don't think we'd want to get that detailed on the  
categories of prospective users.  A general enabling description is  
much more robust.

Ken

>
> Thoughts?
>
> Miko
>
>
------------------------------------------------------------------------ 
------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508



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