cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnson, Eric" <Eric.John...@iona.com>
Subject RE: [PROPOSAL] Client and Conduit changes
Date Sat, 17 Mar 2007 19:04:37 GMT
I've been trying to follow the thread about this stuff, but was getting
lost in the details. This is a great way to bring clarity.
I'd be very interested in hearing Eoghan's alternate proposal-or
rebuttal.

I've commented in-line.

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: Friday, March 16, 2007 6:20 PM
> To: cxf-dev@incubator.apache.org
> Subject: [PROPOSAL] Client and Conduit changes
> 
> 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.

Just because JMS is the only current edge case I don't think it should
be dismissed so lightly. There are other possible transport
impmentations that will need information 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.
Given this explanation, I'm +1 on moving the decoupled distination set
up from the conduit. It seems cleaner if it is not part of the conduit.
What is the reason for placing the code in there in the first place? I'm
guessing there was a compelling reason and it would be good to make sure
we are not overiding a good decision for the sake of a clean API.
> 
> 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:as
> ynchronousDestination>
> </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.
I'd like to hear a clear explanation of this point from Eoghan, or
someone else, before saying which was the best approach.
> 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
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Mime
View raw message