Great - I added a simple placeholder to the glossary for now. I hope
the editing team can smooth it over bit however.
Good weekend to you too.
Duane
wrote:
>Hi Duane,
>
>I can live with your definition of opaqueness. I just thought that opaqueness and transparency are at opposite ends of a spectrum. In physics they are.
>
>I totally agree that we must define these terms. Next week though. Too tired now.
>
>Enjoy your weekend!
>
>Wes
>
> -----Original Message-----
>From: Duane Nickull [mailto:]
>Sent: April 22, 2005 10:21 AM
>To: McGregor, Wesley
>Cc:
>Subject: Re: [soa-rm] Opaqueness and Transactions
>
>Wes:
>
>Does your case actually mean semi-transparency? A service definitely
>could allow Java Classes as a parameter to the call, but it is still
>opaque as to what happens behind the scene. The java version, native
>wrappers (JINI) or other specific nuances may be implemented behind the
>scenes. A human will likely assume that it is Java because that would
>be the most logical, however it cannot be assumed.
>
>To me, opaque means that you cannot see intermediate or partial
>results. The service completes its operations once invoked, and only
>the final results (in alignment with the service description, policy and
>metadata) are presented back to the consumer. Alternatively, the
>service may through a flag to indicate an unsuccessful attempt at
>execution or time out (based on its policy).
>
>Opaque also means that you cannot detect "how" the service performs its
>tasks, only get the final result.
>
>Does this make sense? I think we will need to define what we mean by
>opaque in our glossary.
>
>Duane
>
>
>
>>
>>
>>
>>
>
>
>
--
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Adobe Enterprise Developer Resources - http://www.adobe.com/enterprise/developer/main.html
***********
