cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Understanding Partial Responses [Re: Identification of Partial Responses]
Date Thu, 11 Jan 2007 17:27:05 GMT
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 <andrea.smyth@iona.com> 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 <eoghan.glynn@iona.com> wrote:
> >
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> >> > Sent: 10 January 2007 22:41
> >> > To: cxf-dev@incubator.apache.org
> >> > Subject: Re: Understanding Partial Responses [Re:
> >> > Identification of Partial Responses]
> >> >
> >> > On 1/10/07, Glynn, Eoghan <eoghan.glynn@iona.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message