OK, it appears I misunderstood - MakeConnection is for retrieving things like a TerminateSequence from the Server because it can't send that message.
Looks like I missed part of the RM 1.1 spec on anonymous IRIs too: During creation of a Sequence the RM Source MAY specify the WS-Addressing anonymous IRI as the address of the AcksTo EPR for that Sequence. When the RM Source specifies the WS-Addressing anonymous IRI as the address of the AcksTo EPR, the RM Destination MUST Transmit any SequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be Transmitted on the protocol binding-specific channel. Such a channel is provided by the context of a Received message containing a SOAP envelope that contains a Sequence header block and/or a AckRequested header block for that same Sequence identifier So it seems we're stuck with partial responses! I would feel better about the spec though if it was modeled as a one way message which just happened to be on the backchannel and it also included an action uri. :-) - Dan On 1/11/07, Andrea Smyth <[EMAIL PROTECTED]> wrote:
Hi Dan, I think partial respones and the MakeConnection feature are very different things: The purpose of partial responses is to use an *existing connection* to piggyback acks on them. Creating a new connectionon may be a solution for acknowledging responses received from the server in the absence of further application request, but anonymous acksTo means that acknowledgements should be sent over the existing HTTP connection. Andrea. Dan Diephouse wrote: > My point wasn't that we should use the MakeConnection from 1.1. It was > that > instead of doing partial responses we *could* invent our own proprietary > operation which is similar to MakeConnection. > > On 1/11/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote: > >> >> >> >> > -----Original Message----- >> > From: Dan Diephouse [mailto:[EMAIL PROTECTED] >> > Sent: 10 January 2007 22:41 >> > To: [email protected] >> > Subject: Re: Understanding Partial Responses [Re: >> > Identification of Partial Responses] >> > >> > On 1/10/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote: >> > > >> > > >> > > Essentially we took a view on how to plug a hole in the >> > WS-RM spec. We >> > > did this in a way that other RM implementors (and >> > contributors to the >> > > WS-RX spec) also had in mind. This approach happens to go >> > against the >> > > chapter and verse of the WS-I Basic Profile (R2714), but it >> > has been >> > > argued that BP was in error on this point. >> > > *snip* >> > >> > >> > And they ultimately decided against including such a feature >> > inside the spec. >> > >> > http://www.oasis-open.org/committees/download.php/14147/Reliab >> > leMessagingIssues.xml#i012 >> >> Again, note that the WS-RX TC decided against this approach for _1.1_. >> >> However that was no help to _1.0_ implementors such as ourselves, who >> still had to figure out a way of solving the problem within the >> framework of the 1.0 spec ... and in fact in many cases had already come >> to a de facto work-around before MakeConnection was even a twinkle in >> the spec writers' eye. >> >> > That doesn't necessarily mean it isn't useful though. I've >> > done some more in depth poking around and it appears other >> > people are doing it, so I believe it is a justified feature. >> >> Hallelujah! :) >> >> > Also I've done some more research into how other frameworks >> > do this and have some findings, which I'll bring up in the >> > original identification thread. >> > >> > >> > > >> > > I don't think it would be a good idea to support a hodge-podge of >> > > WS-RM 1.0 and 1.1, for a number of reasons ... the 1.1 >> > namespaces are >> > > all different, 1.1 is based on a different version of WS-A, and 1.1 >> > > removes some features we support (e.g. the LastMessage marker). >> > > >> > > So I think we'd be much better off waiting for 1.1 to be finalized, >> > > then going for it in one fell swoop. >> > >> > >> > Shouldn't we be able to support both versions eventually? >> >> Sure, for reasons of backward compatability and wider interop ... just >> as we currently have multi-version support for WS-A. >> >> But my point was that we shouldn't support a hybrid version (i.e. mostly >> 1.0, but with MakeConnection thrown in). >> >> So a discrete choice would be made at runtime for each RMS->RMD >> interaction, either fully 1.0 or fully 1.1, but not a mixture of both. >> >> Cheers, >> Eoghan >> > > >
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
