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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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


Subject: RE: [ws-rx] Proposal to resolve Issue 006 - refined argument


I'm going to weigh in here at a higher level.

I am concerned that this is starting to violate one of the core tenets
of SOA - the opacity of a service or more accurately, a service's
ability to autonomously control its' level of transparency.  

My $0.02 CAD ( about $0.0145 USD):

Services are opaque by nature and this TC should not be poking holes
into service boundaries.  The consumer should only see ultimate success
or failure, not try to see behind the service.  This introduces all
kinds of architecturally un-elegant tight coupling and dependencies.

A service consumer (which may be RMS) should only see certain visible
properties of a service IMO.  The relationship between the SMD and AD is
a privileged communication (for lack of a better term) and is not
something the RMS should see.  To do so creates a tight coupling.

This is consistent with the W3C Web Services Architecture Technical Note
and the OASIS SOA Reference Model TC.  More importantly, I think it is
architecturally more elegant to keep services as opaque as possible.

Duane


-----Original Message-----
From: Tom Rutt [mailto:tom@coastin.com] 
Sent: Thursday, October 13, 2005 9:08 AM
To: Anish Karmarkar
Cc: wsrx
Subject: Re: [ws-rx] Proposal to resolve Issue 006 - refined argument

Anish Karmarkar wrote:

> Tom Rutt wrote:
>
>> Description
>>
>>                Is there a requirement that the sender can assert that

>> the receiver must
>>                deliver a particular reliability assurance on a given 
>> sequence?
>>
>> Discussion         It has been agreed that the protocol is the same 
>> on any ws -rm Sequence, regardless of DA level agreements in place 
>> between RMD and Destination Application.    There is no need to have 
>> a standard protocol mechanism for the RMS to signal DA requirments on

>> the sequence for the RMD.
>>
>> If reliaiblity policy is attached to a destination endpoint at a 
>> finer level of granularity than endpoint subject level,  an 
>> implementaton (extension beyond normal conformance) would have to use

>> means outside the scope of this standard to convey such requirements 
>> (e.g., RMD could be aware of the wsdl description).
>>
>
> I don't see this issue as being tied to finer level of granularity. 
> Say the granularity is at the message-level or operation-level. When 
> the receiver receives a message, it is clear from the message which 
> operation is being invoked.
>
> The issue is about -- how does a sender indicate to the receiver that 
> a particular QoS is required for a particular Sequence? This may be 
> needed because the receiver supports multiple QoS and the sender wants

> to choose OR the sender is not aware of the QoS being implemented and 
> wants to assert the QoS for the Sequence (and have the receiver fault 
> on the CS message if it cannot).
>
> One way I can think of doing this is to include the 
> wsrm:DeliveryAssertion (as defined by the resolution of issue i009) as

> an optional element in the CreateSequence message and define a 
> specific fault that the RMD can send when the wsrm:DeliveryAssertion 
> is not supported/allowed.
>
> -Anish
> -- 
>
I beleive that such a negotiation mechanism is the best way to handle 
multiple levels of DA on the same endpoint.

My point is either we have this negotiation level, and support operation

level DA at the destination,
or we support only endpoint level DA attachemnt at the destination 
without the sender negotiation.

Knowing what is invoked is not the problem.  The problem is that it is 
impossible for the RMD to know what the operation type of a missing 
message in a sequence is.

As I already stated in my response to Marc G:

Say one operation type (opA) on the port only needs at most once, while 
the other
(opB) needs exactly once in order DA.  Only obB needs to have its 
messages buffered, while waiting for a prior.  if both operations are 
send over the same sequence, the opA request messages will be in the 
same sequence as the opB request messages. 

If a obB message number 101 is received by the rmd, and message 100 was 
not yet received, that message 101 must be held waiting for 100 to be 
delivered before 101 is delivered.

Now suppose message 102 is a request for opA, it does not require 
ordered delivery,
and if it  were on a sequence which did not have ordered delivery DA in 
place it would
be delivered immediately.

Now, according to the comment from Anish, if the rmd knows the operation

level DA
requirements it could deliver the request message 102 immediately, since

it can detect
opA  signature in the soap body.

However message 101 will be held until message 100 is received, even 
though message
100 is a request for opA.  

So I stand corrected, in that the problem is less severe than I thought,

given the RMD
has knowledge of the operation type and the operation level
requirements.

One important point remains: placing all opA requests on one sequence
which
is negotiated at creation to support At least once at the RMS/RA 
agreement, and
placing all opB requests on another sequence which is negotiated to 
support exactly
once in order, simplifies greatly the implementation of the RMD.  It 
would not have to know the operation type to do its job.

My own position is that endpoint policy attachment for WSRM should be 
the default,
with finer grained attachment an extension point.  This default 
mechanism would not
require negotation of DA  on a sequence at creation time,. or RMD 
awareness of
operation level requirements

Users of the extension point would have to also define how the rms 
determines which
operation types to put on each of multiple concurrent sequences between 
the rms and
rmd, and which sequence has which DA level at destination.


>> Proposed resolution to Issue 006:
>>
>> close issue with no changes to specfication.
>>
>>
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133




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