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] Groups - Application Notes for WSRM (AppNotes-061-WSR M.doc) uploaded



No question about it - these interop snags you mention all seem to belong to an app notes doc.

Although my company did not participate yet in the interop rounds that revealed these [potential] implementation-time issues, I have seen the same happening over and over again for other specs.

And that could be good profile raw material, or at least good "agreement" material.

We are quite open on the content of this doc, as long as at the end of the day, developers find their answers in either one (or combination) of {spec,appnotes,profile} for their interop questions.

Agree we don't need to repeat things - though not convinced yet that everything in current draft is repeat ;-)







From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, March 29, 2006 7:30 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Groups - Application Notes for WSRM (AppNotes-061-WSR M.doc) uploaded


  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.


Jacques Durand <JDurand@us.fujitsu.com>

03/27/2006 09:47 PM


Christopher B Ferris/Waltham/IBM@IBMUS




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




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 ;-)


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Thursday, March 23, 2006 5:32 AM
Jacques Durand
Re: [ws-rx] Groups - Application Notes for WSRM (AppNotes-061-WSRM.doc) uploaded



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.


Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

jdurand@us.fujitsu.com 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

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