RE: [ws-rx] Groups - Application Notes for WSRM (AppNotes-061-WSR M.doc) uploaded

Jacques,

  In thinking about an app-notes
doc I wanted to offer a suggestion... as was stated at the F2F last week,
restating what is already stated in RM or WSA may not be viewed as useful
as something that helps explain some of the finer points of the RM spec
to implementors.  For example, during the interop we ran into an issue
of an RMD blocking upon receipt of a message even though it was a one way.
 It did this because a Fault may have been generated and since the
default replyTo/faultsTo is anonymous it decided that it needed to wait
until it knew for sure that no fault needed to flow back.  This caused
a deadlock situation because the RMS decided to have just one sending thread.

  One possible solution is that
perhaps an RMD should never block - it should always immediately return
a 202 (or an Ack) and should only send back a response message (assuming
anon replyTo/faultTo) if there happens to be a response/fault available
immediately.  While this is just one implementation choice, and I'm
sure there are others, explaining some of the pros/cons around the various
implementation choices might be very useful to a developer.

  Other possible issues could include:
piggy-backing of Acks, how an RMS chooses a sequence (e.g. do responses
and faults use the same sequence) or why/when it may choose to create a
new sequence instead of using an existing one - and the implications this
has, sequence rollover, why DAs are not mentioned in the spec

  Not sure all of these are appropriate
(just brainstorming) but these are the kinds of things that I think could
be very helpful for someone new to the spec.  And as long as they
do not necessarily promote one implementation choice over another (unless
the TC agrees that's the right thing to do for that one case), and instead
simply talks about some the things an implementer needs to consider then
it could be quite helpful.

  And of course, the questions/options
raised in this doc could lead directly into some Profile narrowing the
list of choices to aid interop.

thanks,

-Doug

Jacques Durand <>

03/27/2006 09:47 PM

To

Christopher B Ferris/Waltham/IBM@IBMUS

cc



Subject

RE: [ws-rx] Groups - Application
Notes for WSRM (AppNotes-061-WSR        M.doc)
uploaded

Chris:

 

Statement should have been
removed - was from a previous version...

 

No linkage is attempted between
bindings of these two patterns in the latest app notes draft as you can
see.

 

It was referring to the fact
that in some cases - expected to be not so uncommon -, the need to restrict
the binding option(s) being used is due to constraints that apply to all
patterns. E.g. a client that cannot receive incoming requests. 

 

It remains that we need to
take a position on where to provide guidance about the use of 3rd
party specifications that  contribute to the deployment and use of
WS-ReliableMessaging, such as need to secure sequences, use of wsa for
controlling the response messages (e.g. CSR), etc. (The latter has actually
been illustrated in the interop tests so I think it will appear in whatever
form of report comes out of it.)

Might be useful to agree on
some criteria for deciding whether such material:

- is core spec material

- is app notes / impl guidelines
material

- is profile material 

Everyone seems to have his/her
own opinion on this...      

 

Cheering back ;-)

Jacques

From: Christopher B Ferris [mailto:]

Sent: Thursday, March 23, 2006 5:32 AM

To: Jacques Durand

Cc: 

Subject: Re: [ws-rx] Groups - Application Notes for WSRM (AppNotes-061-WSRM.doc)
uploaded

 

Jacques, 

In section 2.2, Binding Options for the Acknowledgement Patterns, it says:

"It is often necessary that the
same binding option(s) be used between an RMS and an RMD, for all patterns.
In particular, in case the synchronous sequence management binding is used
exclusively due to restrictions previously mentioned, then it is likely
that the same restrictions apply to the acknowledgement pattern as well

The binding option for this pattern are
indicated using the AcksTo element of CreateSequence message with value:
<wsa:Address>http://www.w3c.org/2005/08/addressing/anonymous</wsa:Address>

If the wsa:ReplyTo element is used on
the requested version of the acknowledgement pattern, then it should not
have a value that conflicts with the binding option (i.e. should have value
"anonymous")."

What makes you think that "it is
often necessary"? As I said in my previous note on the subject, there
should be NO constraint that the exchange pattern/binding used for the
CreateSequence (and other lifecycle operations) to share the same pattern/binding
as the messages within a Sequence. None.

I appreciate what you are trying to accomplish
here, but frankly am a little concerned with the direction this is taking.

Cheers,

Christopher Ferris

STSM, Software Group Standards Strategy

email: 

blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

phone: +1 508 377 9295 

 wrote on 03/23/2006 12:20:49 AM:

> Corrections made (unnecessary restrictions lifted when aligning with

> WS-Addressing.)

> 

>  -- Mr Jacques Durand

> 

> The document revision named Application Notes for WSRM

> (AppNotes-061-WSRM.doc) has been submitted by Mr Jacques Durand to
the

> OASIS Web Services Reliable Exchange (WS-RX) TC document repository.
 This

> document is revision #1 of AppNotes-05-WSRM.doc.

> 

> Document Description:

> Draft of complementary notes for the Web Services Reliable Messaging

> specification, useful for implementers of the specification or for
the

> deployment of an implementation. In particular, the document identifies

> binding options to an underlying 2-way protocol and investigates how
these

> may affect interoperability.

> 

> View Document Details:

> http://www.oasis-open.org/apps/org/workgroup/ws-rx/document.php?

> document_id=17345

> 

> Download Document:  

> http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.

> php/17345/AppNotes-061-WSRM.doc

> 

> Revision:

> This document is revision #1 of AppNotes-05-WSRM.doc.  The document
details

> page referenced above will show the complete revision history.

> 

> 

> PLEASE NOTE:  If the above links do not work for you, your email
application

> may be breaking the link into two pieces.  You may be able to
copy and paste

> the entire link address into the address field of your web browser.

> 

> -OASIS Open Administration