Re: [soa-rm] Opaqueness and Transactions

[Don Flinn <flinn@alum.mit.edu>]

Diane

I disagree that a service could allow Java Classes as a parameter.  This
implies how the service is implemented.  Even if the service can
translate the Java Classes to some other model, it forces the service to
understand Java Classes.  

Also, WS-BusinessActivity permits partial or "tentative" results to be
made available to the Coordination Service. There are times when partial
results are needed to synchronize services in a business activity.  IMO,
one of the major benefits of an SOA the ability to handle complex,
multi-service business activities.

I realize that these examples are concrete, but I believe that we must
validate our model against the specific concrete situations.

Don

On Fri, 2005-04-22 at 07:20 -0700, Duane Nickull wrote:
> 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
> 
> >  
> >
> 
-- 
Don Flinn
President, Flint Security LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail: flinn@alum.mit.edu
http://flintsecurity.com