RE: [soa-rm] Public Review Comment

["Miko Matsumura" <mmatsumura@infravio.com>]

Thanks Ken. Very helpful comments!
 
I would like to widen the community of interest beyond the consumers only, point well taken wrt Architecture and implementation levels of abstraction...

	-----Original Message----- 
	From: Ken Laskey [mailto:klaskey@mitre.org] 
	Sent: Wed 3/22/2006 10:25 PM 
	To: Miko Matsumura 
	Cc: Duane Nickull; soa-rm@lists.oasis-open.org 
	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