Re: [soa-rm] Opacity calumny

[Ken Laskey <klaskey@mitre.org>]

Frank,

To agree even more violently, this raises (and I allude to a little in the 
draft) the question of how to provide a means to publish metadata as it is 
found to be needed but in a way that supports a consistent use of the 
metadata in evaluating an entity against unambiguously stated a/c/p, which 
themselves can be augmented and will evolve to meet business needs of the 
users (where if I am a design engineer, my business need is to find the 
technically correct solution engine).

This represents a much ignored need as well as a terrible run-on sentence. :-)

Ken

At 04:10 PM 7/11/2005, Frank McCabe wrote:
>Ken:
>
>   I think we are in violent agreement. The essence of the Java
>execution engine example is that it is precisely that the
>implementation is important -- not whether or not its good style!!
>
>   Incidentally, if it is important to know who wrote the
>implementation, then that too should be part of the public description.
>
>   Perhaps another aspect concerns the on-the-wire vs. resource model
>of service semantics. In the resource pov, issues of implementation
>(transparent or otherwise) figure prominently. In the on-the-wire
>pov, you only look at the message traffic; and do not even consider
>the implementation.
>
>  They are related of course: a message is valid if it is well formed
>(in some communication language) and if the implied predicate is
>satisfied (there really is money in your bank account).
>
>  But, a Service Oriented Semantics (SOS) would focus on the on-the- wire 
> interpretation and require that the service participants
>faithfully reflect the messages in their systems. I.e., it is similar
>to the model/proof theory distinction: provided that the service
>implementation is a correct Interpretation of the communication, the
>participants can focus on the Formulae being communicated.
>
>That all being said, there are definite limits to descriptions. I.e.,
>there will always be unstated (unstateable?) assumptions that are
>required to be shared for successful interactions.
>
>Frank
>
>On Jul 11, 2005, at 12:49 PM, Ken Laskey wrote:
>
>>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                                              /
>>
>>---------------------------------------------------------------------- 
>>------------
>>
>>
>

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