RE: [soa-rm] Opaqueness and Transactions

[<McGregor.Wesley@tbs-sct.gc.ca>]

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:dnickull@adobe.com] 
Sent:	April 22, 2005 10:21 AM
To:	McGregor, Wesley
Cc:	soa-rm@lists.oasis-open.org
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
***********