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:
http://flintsecurity.com
