cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: [PROPOSAL] Client and Conduit changes
Date Wed, 28 Mar 2007 16:13:17 GMT


> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 28 March 2007 15:49
> To: cxf-dev@incubator.apache.org
> Subject: Re: [PROPOSAL] Client and Conduit changes
> 
> We hashed out, but didn't come to any great resolution. I 
> proposed a solution, and as I understand (hopefully I haven't 
> misinterpreted), you agree that my solution is completely 
> feasible, it just isn't your preference.


Well my recollection of that discussion was mostly you repeatedly
questioning the need for partial responses, and me repeatedly explaining
why we needed them.

Please remind me of your proposal if you want to reactivate that
discussion (on a separate thread).

But if you're referring to your proposal that the RM layer sets the 202
response code directly, then my objection wasn't on the basis of my
personal preferences. Instead IIRC I argued on the basis of keeping RM
transport-neutral.

/Eoghan

 
> But we've heard a few of the concerns over the complexity of 
> the transport APIs in this thread (Willem, Dan, Eric, 
> myself), and I've heard many more offline. People see for 
> simplifying the transport APIs, provided its feasible for the 
> partial response cases. And it is possible.
> 
> - Dan
> 
> On 3/28/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Daniel Kulp [mailto:dkulp@apache.org]
> > > Sent: 27 March 2007 19:00
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: [PROPOSAL] Client and Conduit changes
> > >
> > >
> > > Just to jump in here....
> > >
> > > I haven't had the time to grok all the details of all the 
> proposals 
> > > and stuff, but I have to say one thing:
> > >
> > > IMO, the current transport API's/etc...  are way to complex.   The
> > > decoupled cases and partial messages and stuff have polluted that 
> > > layer
> > > too much.    All of that makes writing new transports much
> > > harder than
> > > it should be.
> >
> >
> > DanD's proposal has nothing whatsoever to do with partial responses.
> >
> > That's a completely different issue. That we thrashed out 
> on this list 
> > at extreme length months ago.
> >
> > /Eoghan
> >
> >
> > > Thus, if Dan's proposal simplifies that, I'm completely +1 for it.
> > >
> > >
> > > Sometime, I'd like to take some time and re-read all of this, but 
> > > that
> > > requires a bit of time I just don't have right now.    :-(
> > >
> > >
> > > Dan
> > >
> > >
> > >
> > > On Friday 16 March 2007 18:19, Dan Diephouse wrote:
> > > > For those of you who haven't been following the long
> > > discussion Eoghan
> > > > and I have been having, I'm going to take a moment to 
> summarize my 
> > > > proposal here. I consider it rather important. If we don't
> > > reach any
> > > > consensus on the proposal (it sucks/doesn't suck) or if
> > > Eoghan & I are
> > > > the only ones who participate, I'll probably start a vote.
> > > So do your
> > > > communal duty and participate so I don't have to do that! :-)
> > > >
> > > > I propose the following:
> > > >
> > > > 1. API to set an Asynchronous EndpointReference I believe we 
> > > > should create a simple method on the Client which 
> allows the user
> > > to specify
> > > > the asynchronous endpoint that they wish to have used for 
> > > > decoupled
> > > > responses:
> > > >
> > > > Client.getAsynchronousEndpoint(EndpointReferenceType epr);
> > > >
> > > > The Client would check to see if this EPR was set. If 
> so, it would 
> > > > call DestinationFactory.getDestination(epr) for the EPR and
> > > use that
> > > > as the asynchronous destination. This would result in a
> > > standard way
> > > > to automatically set up the decoupled destination when
> > > using the API.
> > > >
> > > > While it has been said that this isn't generic enough for
> > > JMS, I don't
> > > > agree. First, I believe that JMS will eventually get a self
> > > contained
> > > > IRI format which can be stuck in an EPR. We could even
> > > create our own
> > > > proprietary format. Second, JMS is an edge case. There 
> are other 
> > > > transports beside just JMS and HTTP, like XMPP or TCP 
> or FTP which 
> > > > work just fine with URIs. JMS is the odd ball in the sense that 
> > > > historically it has needed stuff outside the EPR.
> > > >
> > > > 2. Access to the Conduits and Destinations I would like 
> to add the 
> > > > following methods to the Client:
> > > >
> > > > void setConduit(Conduit) - this allows a user to easily 
> specify an 
> > > > alternate Conduit.
> > > > void setAsynchronousDestination(Destination) - this allows
> > > a user to
> > > > easily specify a decoupled endpoint. It's address would be used 
> > > > for WS-Addressing interactions. If no Async destination exists,
> > > then the
> > > > Client will only listen on the Conduit.
> > > > Destination getAsynchronousDestination() - utility method to 
> > > > easily get the asynchronous destination
> > > >
> > > > 3. Client.close();
> > > > We need a way to shutdown the decouled endpoints (regardless of 
> > > > whether or not #1 & #2 are adopted). I think there is 
> pretty good 
> > > > conensus we need a Client.close() method which will do
> > > this. It will
> > > > call getConduit().close() and
> > > getAsynchronousDestination().shutdown().
> > > >
> > > > (Ideally we'd like to be able to shut down RM at this same
> > > time. I'm
> > > > going to guess that this would require the addition of a client 
> > > > lifecycle interface which allows RM to listen for
> > > Client.close(). This
> > > > is an issue no matter which route we go though, so I'll 
> defer this 
> > > > conversation for another thread)
> > > >
> > > > 4. Remove the setup of decoupled destinations from inside
> > > the Conduit
> > > > Currently, the Conduits are responsible for setting up the
> > > decoupled
> > > > destinations. We've already got a perfectly good API 
> for creating 
> > > > destinations, lets use it! Creating another API to create 
> > > > decoupled destinations introduces inconsistencies into 
> our APIs. 
> > > > Right now if you want to create different endpoints for 
> receiving 
> > > > ReplyTos and FaultTos you have configure the ReplyTos using the 
> > > > Conduit
> > > API and the
> > > > FaultTos using the destination API. Creating those endpoints in 
> > > > different ways is bad IMO.
> > > >
> > > > Putting in decoupled destinations inside the Conduit 
> also makes it 
> > > > more complex for transport writers or people trying to
> > > understand the
> > > > API. IMO, people intuitively expect this to be outside 
> the Conduit 
> > > > class.
> > > >
> > > > 5. Client Configuration
> > > > I would propose that we make the decoupled destination
> > > configuration
> > > > part of the Client
> > > >
> > > > <jaxws:client id="...SomePort">
> > > >   <jaxws:asynchronousEndpoint>
> > > >     <wsa:Address>http://my.decoupled/endpoint</wsa:Address>
> > > >   </jaxws:asynchronousEndpoint>
> > > > </jaxws:client>
> > > >
> > > > <jaxws:client id="...SomePort">
> > > >
> > > >
> > > 
> <jaxws:asynchronousDestination><http:destination...></jaxws:asynchro
> > > no
> > > >usDestination> </jaxws:client>
> > > >
> > > > As an added bonus, we can now wire together clients and
> > > destinations
> > > > however we want. I wouldn't *have* to create a <conduit> config

> > > > element with the port name inside it. Instead I could simply do:
> > > >
> > > > <jaxws:client id="...SomePort">
> > > >    <jaxws:conduit> <http:conduit... /> </jaxws:conduit>

> > > > </jaxws:client>
> > > >
> > > > It also creates a central place to embed Client
> > > configuration - such
> > > > as enabling MTOM or configuring WS-*:
> > > > <jaxws:client id="...SomePort">
> > > >    <jaxws:conduit>...</jaxws:conduit>
> > > >    <jaxws:binding mtomEnabled="true">
> > > >      <jaxws:requestContext>
> > > >        <map><entry key="javax.xml.ws.session.maintain"
> > > > value="true"/></map> </jaxws:requestContext>
> > > >    </jaxws:binding>
> > > >    <jaxws:features>
> > > >      <wsrm:reliability timeout="10000" .../>
> > > >    </jaxws:features>
> > > > </jaxws:client>
> > > >
> > > > Users could still use the <http:conduit id="PORT"/> 
> syntax if they 
> > > > wanted to though.
> > > >
> > > > (Note: I haven't written the jaxws:client Spring schema
> > > yet, but its
> > > > on my todo list. The feature stuff will hopefully be part
> > > of my commit
> > > > with WS-Security)
> > > >
> > > > 6. Bring back Destination.getDestination(EndpointReferenceType)
> > > > This method would be needed for the API that I propose in #1.
> > > >
> > > > 7. Make the JAX-WS dispatch use the client.
> > > >
> > > > ----
> > > >
> > > > In summary:
> > > > a) This simplifies the API. We've created an API to set up
> > > decoupled
> > > > endpoints easily. We've reduced the complexity inside 
> Conduits and 
> > > > have avoided introducing new complexity onto the Conduit
> > > interface to
> > > > specify a decoupled destination.
> > > >
> > > > b) It creates a consistent API for working with 
> decoupled endpoints.
> > > > There is no reason to go writing a new API for setting up 
> > > > decoupled endpoints - which is only used sometimes.
> > > >
> > > > c) Dependency Injenction: By putting the Conduit &
> > > Destination on the
> > > > Client we've made it much friendlier to people using Spring
> > > or other
> > > > DI containers.
> > > >
> > > > d) Improved configuration: I think the jaxws:client is a
> > > more natural
> > > > place to setup the conduit and destination configuration as
> > > opposed to
> > > > nesting the destination configuration inside the conduit.
> > > >
> > > > e) Setting up decoupled destinations is not the job of 
> the conduit 
> > > > IMO. We're giving Conduits a dual task unnecessarily. If
> > > all Conduits
> > > > share the same code for setting up decoupled destinations,
> > > that is a
> > > > sign to me that we can take it out of the Conduit.
> > > >
> > > > I of course would be volunteering to do all this work.
> > > > --
> > > >
> > > > Alternatives: While Eoghan can elaborate, I believe he would 
> > > > rather see 1. The decoupled endpoint remain part of the conduit.
> > > He views a
> > > > decoupled endpoint as part of the Conduit contract.
> > > > 2. An API on the Conduit to set up the decoupled 
> endpoint like so:
> > > > Client.get(Conduit.class
> > > > ).getClientPolicy().setDecoupledEndpoint(EndpointReferenceType)
> > > > 3. The Client.getConduit/setConduit methods go away and 
> have the 
> > > > Conduit be an optional part of the Client 4. No 
> > > > Client.setAsynchronousDestination method.
> > > > 5. Keep the decoupled endpoint configuration as part of the 
> > > > conduit instead of the client.
> > > >
> > > > Regards,
> > > > - Dan
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727    C: 508-380-7194
> > > daniel.kulp@iona.com
> > > http://www.dankulp.com/blog
> > >
> >
> 
> 
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Mime
View raw message