OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [soa-rm] Opaqueness and Transactions

My comments in-line.

 -----Original Message-----
From: 	Matthew MacKenzie [mailto:mattm@adobe.com] 
Sent:	April 25, 2005 10:37 AM
To:	McGregor, Wesley
Cc:	soa-rm@lists.oasis-open.org
Subject:	Re: [soa-rm] Opaqueness and Transactions

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".

You are correct! My discussion focused on defining opaqueness as a degree of knowledge. As long as the definition of opaqueness is unambiguous, we are OK.

> 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?

You are missing the point. The service parameters by their type assert certain knowledge which is what I was trying to get at. The question remains "how are we defining opaqueness and transparency and do we need to?" I say yes.

> 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.

I am convinced that an RM must account and allow for varying degrees of opaqueness as determined by the service provider.

> 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.

I disagree on the thought but agree on the protocol aspect. If we are going to say that services can be combined, which I am sure we will, what value-add does the RM give someone with respect to combining those services if not a model for doing so? 

> 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.

The reference architecture work should more concretely define service composition as contexted by the model.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]