Re: [soa-rm] Opaqueness and Transactions

[Matthew MacKenzie <mattm@adobe.com>]

On 21-Apr-05, at 2:51 PM, McGregor.Wesley@tbs-sct.gc.ca wrote:

> Hi All,
>
> I would like clarification on the following items if possible:
>
> Opaqueness
>
> I believe there are degrees of opaqueness. If a service interface 
> allows JAVA classes as a parameter to the actual call, one definitely 
> knows that the service supports JAVA at some level, implying the 
> consumer has some knowledge about the internals of the service (not 
> much but some). The service is not completely opaque.

Just because a consumer determines from a service description that the 
service takes a java class as a parameter does not really mean that the 
consumer now knows what or how the service is performing its task(s).  
It could be argued that accepting any parameter renders a service "not 
completely opaque".

>
> If the service only allowed XML as incoming data and object 
> constructs, then the parser of choice could be in any language or any 
> other combination of service calls.  I would then say the service is 
> more opaque.

Ah.  The issue is programming language then.  Tell me...is an interface 
defined in IDL opaque?  How is an object any different from an XML 
construct considering that by looking at the XML you can determine how 
things are likely working within the service just as easily as 
decomposing an object instance?

>
> Proposal: There are degrees of opaqueness within the SOA RM and we 
> need to define them.

I'm not convinced.  This is, however, an interesting discussion.

>
> Transactions
>
> If a service is a combination service, example, service A is composed 
> of service B and C, are we going to describe the method by which B and 
> C asynchronous responses are delivered to the appropriate reception 
> point within service A?

The reference model cares not about how a service is composed, rather, 
it is only interested in the fact that a service is available.  We are 
not defining a protocol.

>
> Proposal: We need to describe by what method or model we support 
> service composition at run-time.

I feel this is out of our scope here, but may not be for future 
reference architecture work.

-Matt