Return-Path: 
 <cxf-dev-return-1913-apmail-incubator-cxf-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org
Received: (qmail 83734 invoked from network); 18 Jan 2007 14:08:57 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 18 Jan 2007 14:08:56 -0000
Received: (qmail 34834 invoked by uid 500); 18 Jan 2007 14:09:02 -0000
Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org
Received: (qmail 34793 invoked by uid 500); 18 Jan 2007 14:09:02 -0000
Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cxf-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:cxf-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:cxf-dev@incubator.apache.org>
List-Id: <cxf-dev.incubator.apache.org>
Reply-To: cxf-dev@incubator.apache.org
Delivered-To: mailing list cxf-dev@incubator.apache.org
Received: (qmail 34784 invoked by uid 99); 18 Jan 2007 14:09:02 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Jan 2007 06:09:02 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of eoghan.glynn@iona.com
 designates 62.221.12.33 as permitted sender)
Received: from [62.221.12.33] (HELO emea-smg1.iona.com) (62.221.12.33)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Jan 2007 06:08:53 -0800
Received: from emea-ems1.ionaglobal.com (dutec.ie [10.2.1.125])
	by emea-smg1.iona.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
 l0IF6Nea012390
	for <cxf-dev@incubator.apache.org>; Thu, 18 Jan 2007 15:06:23 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposal for Decoupling and Issues with CXFServlet
Date: Thu, 18 Jan 2007 14:08:28 -0000
Message-ID: <FA1787F64A095C4090E76EBAF8B183E071FB8A@owa-emea.iona.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Proposal for Decoupling and Issues with CXFServlet
Thread-Index: Acc6dPMUW9I/aEVyQJiuQiDmRzzinQAhsiCA
From: "Glynn, Eoghan" <eoghan.glynn@iona.com>
To: <cxf-dev@incubator.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

=20

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]=20
> Sent: 17 January 2007 20:19
> To: cxf-dev@incubator.apache.org
> Subject: Re: Proposal for Decoupling and Issues with CXFServlet
>=20
> OK, still thinking about #1 here and the ramifications of=20
> what that would mean. Question: do you really only need one=20
> config for the scenario you raised? I think it might be two.=20
> First your client http-conduit config:
>=20
>     <bean name=3D"{
> http://apache.org/hello_world_soap_http}SoapPort.http-conduit"
> abstract=3D"true">
>         <property name=3D"client">
>             <value>
>                 <http-conf:client DecoupledEndpoint=3D"
> http://localhost:9000/decoupled_endpoint"/>
>             </value>
>         </property>
>     </bean>
>=20
> Second your Jetty Destination config:
>=20
> <bean name=3D"org.apache.cxf.transport.http.JettyServerEngine.9000"
> abstract=3D"true">
>    <property name=3D"listener">
>        <value>
>            <http-conf:listener>
>                <MaxThreads>5</MaxThreads>
>            </http-conf:listener>
>        <value>
>    </property>
> </bean>

Sure there are two config beans required (which is just an artefact of
how the HTTP config schema was organized) ... but the point is that they
are both transport-level config, and are thus more likely to be
considered by the user as a group, and modified as such.
=20
> (Upon further looking at the code though I don't think its=20
> even possible to supply configuration to your decoupled=20
> destination right now.
> setupDestination operates directly on the JettyServerEngine=20
> and doesn't supply any configuration.)

Well, HTTPConduit.setupDecoupledDestination() calls the static
JettyHTTPServerEngine.getForPort() factory method, which then applies
Configurer.configure() to the newly created JettyHTTPServerEngine. So
the HTTPListenerConfigBean stuff will have been injected, and the
MaxThreads setting should apply.

So I think this is actually OK.

What is missing though is the SSLServerPolicy. Normally this is injected
into the JettyHTTPDestination in the first instance and then passed onto
JettyHTTPServerEngine.getForPort(). We're going to have to figure some
other way of getting a handle on this in the decoupled case (which has a
listener but not a destination from the point of view of HTTP config).
Maybe in this case, it's the SSLClientPolicy that should be applied to
the decoupled listener ... or more properly, we come up with a generic
SSLPolicy that can apply to both the HTTPconduit and
JettyHTTPServerEngine in the decoupled case.
=20
> While one could specify a listener in the=20
> SoapPort.http-conduit config, I don't think that would make=20
> very much sense. You don't want to configure your MaxThreads=20
> for the particular URL path, you want to configure it for the=20
> whole Jetty instance on one particular port. So lets say I=20
> want to listen for decoupled responses on the same port as=20
> I'm listening for service requests on - port 80 (for firewall=20
> reasons?). I want my MaxThreads to apply to all destinations=20
> on that port, not just my one particular decoupled endpoint. =20
> Hence you'll need two configurations.  I don't really see how=20
> you could combine the two either. Am I missing something?

Nope, that's exactly why the HTTP destination and listener
configurations are specified separately.

The JettyHTTPServerEngines (which encapsulate a Jetty SocketListener)
are keyed on port, not on the particular URL path of an individual
destination.

Multiple URL paths with the same port also share the same listener, so
in this case the same max threads would be shared across the multiple
target URLs (whether decoupled response endpoints in the decoupled case,
or full-on Destinations).=20

So I think this is covered.

> I'll concur on #2, replyTos on alternate transports are a bit=20
> contrived.

Cool.
=20
> For #3, I think its really just a matter of naming. You're=20
> right, my proposed name of RMDestination gives the wrong=20
> impression. But RMSupport, RMDestinationSupport, or=20
> RMProtocolSupport or something similar wouldn't be bad. I=20
> think it would be pretty clear that this isn't needed though=20
> as it would be in an WS0RM package in the api module and=20
> would be clearly documented as optional. Does that address=20
> your concerns?

I'd be less against this if the RM association was dropped from the
name.=20

So if we must have a sub-interface of Destination, how about something
generic like PartialResponder?=20
=20
> (FWIW, I don't think it would be all that worthwhile to add a=20
> special interface at this point as the only case we would=20
> need it is the two way partial response. Seems much simpler=20
> to just put in a message.put(RESPONSE_CODE,
> 202) in RM like we do in SOAP for the time being. If we had=20
> another transport which required special syntax we could add=20
> extension points at that time.)

Ok we're just going to have to agree to disagree on this.

I really don't like setting the response code from outside the
transport.

There's also the issue that I pointed out before that its easier for the
JettyHTTPDestination to know that it's the HTTPTransportFactory it needs
to use as ConduitInitiator for the outgoing decoupled connection, wheras
obviously the WS-A layer would have to work this out for itself (maybe
requiring a getTransportId() or some-such on Destination).

/Eoghan

=20
> - Dan
>=20
> On 1/16/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 15 January 2007 23:17
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: Proposal for Decoupling and Issues with CXFServlet
> > >
> > > Hi Eoghan,
> > >
> > > I would say your characterizations about me desiring the=20
> WS-A layer=20
> > > to manage the transports correct. I'm not sure that I see=20
> what the=20
> > > big problem with this is though from your message. So I=20
> want to take=20
> > > a look at your objections to moving the decoupling out of the=20
> > > transport layer:
> >
> > OK, let me explain further where the problems lie as I see it ...
> >
> > > 1. This would require configuration to be in the WS-A=20
> layer instead=20
> > > of the transport layer
> > >
> > > Putting this in the WS-A layer would be overly complex as=20
> you imply.=20
> > > But that isn't our only option. Most likely we would want this=20
> > > configured as part of the Client/Server. Which is how most=20
> > > frameworks do this actually.
> > > For example, I would create a Client with a ReplyTo EPR of=20
> > > http://some/url.
> > > Most frameworks even make this part of the Client interface -=20
> > > client.setReplyTo(new EPR(...));
> > >
> > > This really doesn't add any complexity - if anything it=20
> simplifies.=20
> > > Right now people need to create a separate configuration snippet=20
> > > which is not only specific to the transport, but also to=20
> the client.=20
> > > For example:
> > >
> > > <bean
> > >=20
> =
name=3D"{http://apache.org/hello_world_soap_http}SoapPort.http-conduit"
> > > abstract=3D"true">
> > >
> > > This bean is specific to both HTTP and a specific client=20
> port. To me=20
> > > it would be more intuitive to just embed their ReplyTo in an=20
> > > existing client configuration, rather than require a=20
> separate bean.
> > >
> > > <bean name=3D"{http://apache.org/hello_world_soap_http}SoapPort"
> > > abstract=3D"true">
> > >   <replyTo>htp://localhost/some/url</replyTo>
> > >    ... other configuration values which already exist are here=20
> > > </bean>
> > >
> > > Not saying that should be the exact syntax, but I think=20
> it makes my=20
> > > point.
> >
> > My argument isn't based on complexity versus simplicity, rather on=20
> > proper separation of concerns.
> >
> > My position is that the decoupled response endpoint is an aspect of=20
> > the transport, not an aspect of the Client or the WS-A=20
> layer. Hence it=20
> > should be configured as such.
> >
> > Lets do a quick gedanken experiment, and consider what your=20
> proposal=20
> > would look like in a non-trivial case.
> >
> > Say I want to configure a decoupled replyTo, but my client=20
> is running=20
> > on a resource-poor platform so I need to ensure that the=20
> embedded HTTP=20
> > listener consumes no more than 5 threads when servicing the=20
> incoming=20
> > decoupled responses. Here's the sort of thing we'd end up with ...=20
> > (Don't worry about the precise config syntax, its off the top of my=20
> > head, so may be slightly off base)
> >
> > <bean name=3D"{http://apache.org/hello_world_soap_http}SoapPort"
> > abstract=3D"true">
> >    <replyTo>http://localhost:9000/some/url</replyTo>
> > </bean>
> >
> > <!-- a bunch of other config stuff -->
> >
> > <bean name=3D"org.apache.cxf.transport.http.JettyServerEngine.9000"
> > abstract=3D"true">
> >    <property name=3D"listener">
> >        <value>
> >            <http-conf:listener>
> >                <MaxThreads>5</MaxThreads>
> >            </http-conf:listener>
> >        <value>
> >    </property>
> > </bean>
> >
> > Lets concentrate on what we've got here essentially ... two=20
> displaced,=20
> > yet intimately related, elements of config. This will end up being=20
> > error-prone in practice.
> >
> > For example, consider what happens when I hit a port clash=20
> with some=20
> > other developer also running CXF demos against port 9000 on=20
> the same=20
> > host? I need to change my decoupled response endpoint to=20
> listen on say=20
> > 9001 instead. In order to do so, I need to remember to change two=20
> > displaced elements of config (the client-level replyTo and the=20
> > transport-level listener). Chances are I forget to change=20
> the latter,=20
> > and my 5 thread restriction is no longer honored.
> >
> > A contrived example? Well maybe so, but it demonstrates a general=20
> > point ... related stuff should be=20
> instantiated/managed/configured together.
> >
>=20
> > > 2. WS-A wouldn't be knowledgable about whether or not a=20
> ReplyTo EPR=20
> > > is cabable of being used
> > >
> > > "From the physical contract (e.g. the target portType in=20
> the WSDL),=20
> > > WS-A would have no way of knowing that the server-side=20
> would even be=20
> > > capable of responing using such a replyTo EPR."
> > >
> > > Just because there is not currently a WSDL extension that enables=20
> > > this scenario, doesn't mean that it shouldn't be=20
> supported. What if=20
> > > I want to receive a message via HTTP and respond via SMTP? So I=20
> > > would consider not being able to have a ReplyTo with a different=20
> > > transport a problem with the current code.
> > >
> > > Second, if we do move decoupling support out of the=20
> transport layer,=20
> > > this certainly doesn't change any functionality we have=20
> now. It only=20
> > > expands our functionality!
> > >
> > > (The only thing I can think of that this would make hard is a=20
> > > scenario where a user doesn't create a ReplyTo EPR and we're=20
> > > supposed to create a non-anonymous one for them. I'm not=20
> sure that=20
> > > we even support this now - do we? If we wanted to support this we=20
> > > could add a Destination.getDestination() method to automatically=20
> > > create a destination on a EPR of its choice.)
> >
> > Ouch, hoist by my own petard :)
> >
> > I intended the different-transport-in-replyTo argument to=20
> demonstrate=20
> > the fragility of your scheme, whereas you're probably thinking ...=20
> > wow, this would give us extra flexibility!
> >
> > But is it worth having a 'feature' that just *might* work=20
> if all the=20
> > ducks line up?
> >
> > Remember we'd have *no way of knowing* that the server-side=20
> is capable=20
> > of understanding and/or acting upon a replyTo EPR for any other=20
> > transport apart from that advertized in the target EPR or=20
> WSDL portType or whatever.
> >
> > Even if we had an inkling that the server-side stack might=20
> support say=20
> > JMS as well as HTTP (regardless of fact that the target portType=20
> > specifies only a HTTP URI), there's no standard JMS URI=20
> scheme as yet=20
> > ... so even if our suspicion that the server-side is=20
> JMS-aware turns=20
> > out to be correct, we still don't know if it understands whatever=20
> > non-standard JMS URI we cook up for the replyTo.
> >
> > Even if we thought we were certain that the stack used on the=20
> > server-side supports the different replyTo transport and definitely=20
> > understands the URI scheme, we still can't be sure if this=20
> particular=20
> > instance of the server-side stack is configured/deployed in=20
> such a way=20
> > as to be capable of doing anything with the replyTo. For example it=20
> > may have a pluggable architecture, and we'd have no way of=20
> knowing if=20
> > the required transport plugin was available. It could instead be a=20
> > minimal deployment hosted by say a servlet container,=20
> without support=20
> > for any non-essential features or transports.
> >
> > The point is that all we have to go on is the physical contract=20
> > exposed by the server-side, e.g. the WSDL. If we jump to any=20
> > conclusions not directly supported by this contract, we're acting=20
> > ultra vires ... and while it *may* work, its just as likely=20
> to blow up in our face.
> >
> > Now the WS-A spec doesn't explicitly require that the outbound and=20
> > inbound transports match. But I would argue that practical=20
> > considerations support such a de facto restriction.
> >
> > And CXF isn't the only WS engine to take this position ...=20
> Axis2 does=20
> > also (see=20
> >=20
> http://mail-archives.apache.org/mod_mbox/ws-axis-user/200605.mbox/%3C0
> > 5668670AA9BAD4695A071CED7A496D201BFDE45@mclean.sra.com%3E
> > )
> >
> > > 3. Partial responses require transport specific semantics=20
> (from an=20
> > > earlier
> > > message)
> > >
> > > As we've already discovered on the other thread, this=20
> isn't actually=20
> > > true.
> > > We can just return with the default one way response code - 200.
> >
> > I'm sounding like a broken record now, but yet again, I=20
> must point out=20
> > that partial responses may be required for twoways as well=20
> as oneways=20
> > (I spelt out the reasons for this at length, and then some, in the=20
> > thread "Identification of Partial Responses").
> >
> > So just because Systinet uses the 200 response code for partial=20
> > response to oneways, it doesn't mean we can just fall back=20
> to 200 for=20
> > all partial responses, specifically it would make no sense for the=20
> > partial response to a twoway. Again, I explained this before.
> >
> > > Even if we desired a special transport semantics this=20
> could be done=20
> > > more cleanly via an RMDestination interface which allowed=20
> > > customization in a well contained method. It doesn't=20
> follow that we=20
> > > need partial responses in the transport layer because we=20
> would need=20
> > > to add transport specific semantics just as we wouldn't=20
> put SOAP in=20
> > > the transport layer.
> >
> > Again I don't see this as being any cleaner, in fact the=20
> opposite. I=20
> > feel sure that calling the separate interface "RMDestination" will=20
> > cause a LOT more confusion.
> >
> > Why? Because it gives the false impression that the=20
> reliability logic=20
> > is hosted in the transport. Remember "RMDestination" is=20
> label given by=20
> > the RM spec to the endpoint that receives & ACKs incoming reliable=20
> > messages. The receiver-side "reliability envelope" extends up and=20
> > including the RMD, but no further ... once the message has=20
> been ACKed=20
> > by the RMD, its no longer within the domain of WS-RM and=20
> may in fact=20
> > be lost before the implementor up-call occurs. Giving the=20
> impression=20
> > that this window for message loss extends from the=20
> transport upwards=20
> > on the server-side would be completely wrong.
> >
> > OK, you say, lets call it RMTransport instead. But again=20
> I'd consider=20
> > this to be misleading. The transport isn't tied to RM,=20
> instead it just=20
> > happens to provide a generic service, the sending of partial=20
> > responses. The only user of this service currently happens=20
> to be RM,=20
> > but that's the extent of the relationship between=20
> RMTransport/Destination and RM.
> >
> > /Eoghan
> >
> > > --
> > >
> > > In summary, I'm not sure that I see any reasons why we=20
> should keep=20
> > > decoupling in the transport layer. And as I've said there=20
> are many=20
> > > reasons to move it out
> > > - It simplifies transport writing
> > > - It follows the principle of least astonishment [1]. I would not=20
> > > expect as a transport writer to have to worry about WS-A/RM while=20
> > > writing a transport
> > > - RM semantics should be in the RM module. This is the=20
> same policy=20
> > > we have for everything else - i.e. SOAP
> > > - Our HTTP decoupling is dependent on specific=20
> implementations (i.e.=20
> > > the client is dependent on Jetty)
> > > - ReplyTo on alternate transports aren't supported
> > >
> > > Regards,
> > > - Dan
> > >
> > > 1. http://en.wikipedia.org/wiki/Principle_of_least_astonishment
> > >
> > > On 1/15/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> > > >
> > > >
> > > > > > Are you objecting just to the HTTPConduit having a=20
> reference=20
> > > > > > to the ServerEngine, or to the presence of a ServerEngine
> > > instance in
> > > > > > the client-side runtime?
> > > > > >
> > > > > > If the latter, how would the client-side arrange to receive
> > > > > decoupled
> > > > > > responses without some sort of HTTP listener being launched
> > > > > in-process?
> > > > > > Shouldn't this client-side HTTP listener re-use the
> > > > > server-side logic?
> > > > > > Or are you thinking that the client-side should only embed
> > > > > a minimal
> > > > > > HTTP listener (like nanoHTTPD)?
> > > > >
> > > > > Sorry if I wasn't clear. I'm objecting to maintaining=20
> the server=20
> > > > > side connection in the client code. And vis a versa.
> > > > > Instead of registering the Client MessageObserver like this:
> > > > >
> > > > > Destination d =3D conduit.getBackChannel(); // this=20
> sets up a back=20
> > > > > channel via the JettyHTTPServerEngine.getForPort(...)
> > > > > method d.setMessageObserver(client);
> > > >
> > > > Well that's not the way things work currently on the=20
> client-side.
> > > >
> > > > We do not set a separate MessageObserver on the back-channel=20
> > > > destination, whether decoupled or not.
> > > >
> > > > Instead, the MessageObserver already set for the Conduit is
> > > implicitly
> > > > also used for the back-channel. The ClientImpl just provides a
> > > > *single* MessageObserver, and the response messages are
> > > delivered to
> > > > this regardless of whether they arrived on the=20
> back-channel of the=20
> > > > outgoing client->server connection or on a separate
> > > server->client connection.
> > > >
> > > > The idea is that only the transport needs to be aware that it's=20
> > > > configured in decoupled mode.
> > > >
> > > > The WS-A layer just asks the transport for a=20
> back-channel URI. If=20
> > > > something non-null is returned, this is encoded as the
> > > wsa:replyTo in
> > > > the outgoing message. Otherwise the fallback is the=20
> anonymous URI.
> > > >
> > > > I think we've a different understanding of what the=20
> primary task=20
> > > > of the WS-A layer is, and where the division of=20
> responsibilities=20
> > > > vis- -vis the transport lies.
> > > >
> > > > My understanding is that job of the WS-A layer is to gather
> > > together
> > > > the information relating to addressing, and to encode=20
> this in the=20
> > > > out-going message. Some of this information is in the domain of=20
> > > > the transport, such as the backchannel address, and the
> > > transport should
> > > > drive the creation of this. WS-A in my view simply provides
> > > a standard
> > > > transport-independent way of encoding transport-specific
> > > information.
> > > > In my view, the WS-A layer is is the aggregator, not=20
> the instigator.
> > > >
> > > > You on the other hand, I think, see the WS-A layer in=20
> the driving=20
> > > > seat, causing the transport to create a particular=20
> back-channel.=20
> > > > Is that a fair characterization?
> > > >
> > > > > Just doing this instead:
> > > > >
> > > > > Destination d =3D =
destinationFactory.getDestination(replyToEPR);
> > > > > d.setMessageObserver(client);
> > > > >
> > > > > This would mean that any HTTP Destination could be=20
> used with any=20
> > > > > HTTP Conduit. It also simplifies the code as the http=20
> > > > > conduits/destinations don't need to worry about each other.
> > > > > Is there a reason this wouldn't be possible?
> > > >
> > > > Not impossible, just not the best way of doing it IMO.
> > > >
> > > > For a start it would probably involve the WS-A layer being
> > > configured
> > > > with the replyTo EPR (instead of the transport, as is
> > > currently the case).
> > > >
> > > > In such a scenario, how would WS-A validate that the
> > > replyTo EPR even
> > > > makes any sense vis- -vis the outgoing transport? Supposing for=20
> > > > example WS-A is configured with a JMS replyTo EPR, when=20
> the target=20
> > > > endpoint is HTTP-based. From the physical contract (e.g. the=20
> > > > target portType in the WSDL), WS-A would have no way of knowing=20
> > > > that the server-side would even be capable of responing=20
> using such=20
> > > > a
> > > replyTo EPR.
> > > >
> > > > > > >    -  As I mentioned above, RM has HTTP specific
> > > > > semantics and those
> > > > > > >    should be contained inside the RM module. This is the
> > > > > same policy
> > > > > > > we have
> > > > > > >    with things like the SOAP binding. This does not mean
> > > > > it has to
> > > > > > > be hardcoded
> > > > > > >    into the partial response logic. The RM module
> > > could discover
> > > > > > > different
> > > > > > >    transport specific logic. i.e. we could have an
> > > RMTransport
> > > > > > > interface
> > > > > > >    which has something like a "void=20
> > > > > > > setupPartialResponse(Message)" method.
> > > > > >
> > > > > > Would this RMTransport be like a sub-interface of=20
> Destination,=20
> > > > > > that the RM layer would down-cast to as required?
> > > > > >
> > > > > > If so, any wouldn't transport that we're likely to want to
> > > > > run RM over
> > > > > > would have to implement RMTransport as opposed to
> > > > > Destination, so that
> > > > > > we end up in effect with as much (or as little,
> > > depending on your
> > > > > > point of view) RM pollution of the transport as before?
> > > > > >
> > > > >
> > > > > I think it could be done one of two ways. The first is as you=20
> > > > > mention. I would imagine in this case the RMTransport=20
> interface=20
> > > > > would become part of the API module. The second would be
> > > to make it
> > > > > its own independent interface which is discovered like the=20
> > > > > transports currently are. The first is probably easier.
> > > > >
> > > > > I don't think it would be equivalent to the current code.
> > > It would
> > > > > be in one well contained method, and isn't run unless we
> > > are doing a
> > > > > partial response in RM. It would also not need to be=20
> implemented=20
> > > > > unless a transport needed to support customizing a
> > > partial response
> > > > > - i.e. an HTTP 202 accepted response status. JMS=20
> wouldn't need=20
> > > > > to implement anything.
> > > > > Completely optional. Also my motivation for doing so would be=20
> > > > > not only to remove the partial response handling, but=20
> also the=20
> > > > > decoupling support built into the HTTP transport as well (for=20
> > > > > reasons I won't repeat...)
> > > >
> > > > Yep, there's an argument alright for allowing a transport
> > > opt out of
> > > > the whole partial response mechanism if its incapable=20
> of providing=20
> > > > those semantics.
> > > >
> > > > But this could be achieved more simply via some
> > > distinguished return
> > > > from Destination.backChannel(), e.g. just return null if the=20
> > > > partialResponse parameter is non-null. As things currently
> > > stand, WS-A
> > > > would be tolerant to this and will simply avoid sending the
> > > partial response in this case.
> > > >
> > > > > > > Furthermore, I'm really not a fan of B, which makes me
> > > > > less inclined
> > > > > > > to like A.  Why?
> > > > > > >
> > > > > > >    - Encapsulating the decoupling logic complicates
> > > > > transports: For
> > > > > > >    instance, methods we've added for encapsulation of the
> > > > > decoupling
> > > > > > > include:
> > > > > > >    Conduit.getBackChannel(), Destination.getBackChannel(),
> > > > > > >    ConduitInitiator.getConduit(EndpointInfo,
> > > > > EndpointReferenceTarget).
> > > > > >
> > > > > > Well, I guess we could simplify things a bit by
> > > factoring out the
> > > > > > logic related to partial response into a separate
> > > sub-interface of
> > > > > > Destination (assuming that's what you intended with the
> > > > > suggested RMTransport).
> > > > > >
> > > > >
> > > > > I'm suggesting we
> > > > > - remove the Conduit.getBackChannel()
> > > > > - make Destination.getBackChannel() have no arguments=20
> and only=20
> > > > > return the anonymous back channel
> > > > > - remove the Conduit.getConduit(EndpointInfo,
> > > > > EndpointReferenceTarget) method
> > > > >
> > > > > This would move the decoupling support out of the=20
> HTTP layer and=20
> > > > > into the WS-A layer. That is the WS-A layer would be
> > > responsible for
> > > > > creating a non anonymous ReplyTo conduit, setting up=20
> a decoupled=20
> > > > > Client destination, etc.
> > > >
> > > > I disagree with this division of responsibility between=20
> WS-A and=20
> > > > transport. See above for reasoning.
> > > >
> > > > > > I'm not sure I understand how you'd intend to get=20
> away without=20
> > > > > > worrying about a decoupled Destination on the
> > > client-side ... how
> > > > > > would the client be capable of receiving decoupled=20
> responses?
> > > > > >
> > > > >
> > > > > I'm not trying to get rid of the decoupled Destination.
> > > > > Simply trying to move the decoupling logic elsewhere.
> > > Does the above
> > > > > help explain what I mean better?
> > > >
> > > > Yep, I see where you're going, but don't agree :)
> > > >
> > > > Cheers,
> > > > Eoghan
> > > >
> > >
> > >
> > >
> > > --
> > > Dan Diephouse
> > > Envoi Solutions
> > > http://envoisolutions.com | http://netzooid.com/blog
> > >
> >
>=20
>=20
>=20
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>=20