Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of eoghan.glynn@iona.com
 designates 62.221.12.33 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Understanding Partial Responses [Re: Identification of Partial
 Responses]
Date: Thu, 11 Jan 2007 09:45:51 -0000
Message-ID: <FA1787F64A095C4090E76EBAF8B183E071FB71@owa-emea.iona.com>
Thread-Topic: Understanding Partial Responses [Re: Identification of Partial
 Responses]
Thread-Index: Acc1CY87Nk3RubRhTzCTKbld+oX0BwAWgOlQ
From: "Glynn, Eoghan" <eoghan.glynn@iona.com>
To: <cxf-dev@incubator.apache.org>

=20

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]=20
> Sent: 10 January 2007 22:41
> To: cxf-dev@incubator.apache.org
> Subject: Re: Understanding Partial Responses [Re:=20
> Identification of Partial Responses]
>=20
> On 1/10/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> >
> >
> > Essentially we took a view on how to plug a hole in the=20
> WS-RM spec. We=20
> > did this in a way that other RM implementors (and=20
> contributors to the=20
> > WS-RX spec) also had in mind. This approach happens to go=20
> against the=20
> > chapter and verse of the WS-I Basic Profile (R2714), but it=20
> has been=20
> > argued that BP was in error on this point.
> > *snip*
>=20
>=20
> And they ultimately decided against including such a feature=20
> inside the spec.
>=20
> 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_.=20

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. =20

> That doesn't necessarily mean it isn't useful though. I've=20
> done some more in depth poking around and it appears other=20
> people are doing it, so I believe it is a justified feature.=20

Hallelujah! :)

> Also I've done some more research into how other frameworks=20
> do this and have some findings, which I'll bring up in the=20
> original identification thread.
>=20
>=20
> >
> > I don't think it would be a good idea to support a hodge-podge of=20
> > WS-RM 1.0 and 1.1, for a number of reasons  ... the 1.1=20
> namespaces are=20
> > all different, 1.1 is based on a different version of WS-A, and 1.1=20
> > 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,=20
> > then going for it in one fell swoop.
>=20
>=20
> 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.=20

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