cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: Understanding Partial Responses [Re: Identification of Partial Responses]
Date Thu, 11 Jan 2007 17:01:51 GMT
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
>>
>
>
>


Mime
View raw message