Re: [soa-rm] Opacity calumny

[Ken Laskey <klaskey@mitre.org>]

Frank,

Opacity/transparency is not a dimension on which to distinguish 
services;  it is more of a fallacy that we may need to explain our way 
around.  This ties in very much with what I've tried to say about metadata 
and how metadata characterizing an instance is often the basis upon which 
the instance is evaluated in the context of assumptions, constraints, and 
policies (a/c/p) of providers and consumers.  In some circumstances, the 
amount of information that needs to be published about an entity may 
maintain little in the way of its opacity, but that is more likely related 
to a/c/p than it is to WSDL.

See more inline.

At 03:23 PM 7/11/2005, Frank McCabe wrote:
>I read the revised section on services. And an issue that made me
>uneasy before has resurfaced -- about opacity.
>
>I think that the opacity/transparency dimension is not a good basis
>for distinguishing services. I am aware of the intuition: that
>somehow when you use a service you should not have to worry about the
>implementation. But what does it mean to say: "the implementation is
>hidden from the service consumer"? If the service is to add lists of
>numbers then its implementation is hidden provided numbers are added
>up correctly. (I.e., we should not care about whether its in C++ or
>C#; multi-threaded or federated).

So here the service adds numbers and while we can imagine what is 
happening, we care no more of the specific than we do when we punch numbers 
into a calculator.

>But, some services are explicitly about implementation issues:
>security services, workload distribution services, java remote
>execution engine services etc. etc. I.e., it is of the essence that
>to use a Java remote execution service, you have to send it a java
>class to execute. In that sense, the implementation is critical.

But you call a java remote execution engine when you have an appropriate 
java class to execute.  If it is a general service that is implemented as a 
java remote execution then the WS interface should more likely be a 
collector of information that (inside the service) is rewritten as the 
necessary java class.  You could require a java class as input but I'm not 
sure that would be considered "good style".

>A clearer distinction is public/private. A service is characterized
>by a public description of its functionality. The public description
>should be sufficient to be able to successfully interact with the
>service; and no additional information should be required.

Not really because what you consider part of the private information I 
might consider very pertinent to deciding whether your service is suitable 
for my purposes, i.e. I need it to be public.  For an extreme example, I 
used to work for your company and I know one of your developers is clearly 
incompetent and I'd never use anything that idiot touched.

The challenge is in defining "should be sufficient to be able to 
successfully interact with the service".  I think we need to discuss 
opacity in these terms because it is strongly connected with SOA and may be 
more useful as a vague concept than as an absolute measure.

>Frank
>

Ken






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