Doug:
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 ;-)
Regards,
jacques
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
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
<JDurand@us.fujitsu.com>
03/27/2006 09:47 PM
|
|
To
|
Christopher B Ferris/Waltham/IBM@IBMUS
|
|
cc
|
ws-rx@lists.oasis-open.org
|
|
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:chrisfer@us.ibm.com]
Sent: Thursday, March 23, 2006 5:32 AM
To: Jacques Durand
Cc: ws-rx@lists.oasis-open.org
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: 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