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] Opacity calumny


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                                              /
>      
> ---------------------------------------------------------------------- 
> ------------
>
>
>



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