RE: [soa-rm] Public Review Comment

["Duane Nickull" <dnickull@adobe.com>]

Comments inline:

*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT  http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
******************************* 


-----Original Message-----
From: Miko Matsumura [mailto:mmatsumura@infravio.com] 
Sent: Wednesday, March 22, 2006 6:26 AM
To: Duane Nickull; soa-rm@lists.oasis-open.org
Subject: [soa-rm] Public Review Comment

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.

DN: You may be confusing the abstract model with concrete implementation
issues.  Keeping in mind that this is purely an abstract model with a
purpose to guide architects, we cannot constrain any relationship in a
manner which is concrete.  The gist of this section is that managed
transparency is a key aspect of services.  Service implementers will need to
ascertain a level of detail they provide to potential consumers in each
case.  There will probably never be a one size fits all rule WRT this given
each service has substantially differing purposes.  The RM should only note
that Metadata is required, but not specify the set of metadata elements and
attributes given each implementations may differ.  This was discussed in
great detail (see - "metadata" in the diagram entitled "sinkhole").

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. 

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

DN: This is afar too concrete.  This would be better suited for a reference
architecture or perhaps SOA blueprints (hint hint).

;-)

Duane

smime.p7s