Ideally people should be able to just write their own DestinationFactory ( i.e. the GeronimoDestinationFactory) - and that will be used to listen for asynchronous replies on the client side or to construct endpoints on the server side.
This is a bit of a complex issue, but I can try and give a rundown of how things work and why things are the way they are currently if thats of any help. From a Client point of view, if you send a message that has a non-anonymous ReplyTo, the HTTPConduit is currently responsible for setting up a server endpoint for receiving the reply message. You can access this destination via Conduit.getBackChannel(). Currently this logic hard codes Jetty into it. On the server side, the HTTPDestination is in charge of deciding which method to send your response message via Destination.getBackChannel(). For instance, if you are sending a reply message on a non-anonymous back channel (i.e. an HTTP server, not putting the message on the HTTP response), getBackChannel() will create a new HTTPConduit. getBackChannel() also looks to see if the message being sent over the potential conduit is a "partial response." A partial response is a just a response message on the synchronous reply of either a) a one way request or b) a two way message with a non-anonymous ReplyTo. This happens most often in WS-RM when we have to send a <sequenceAcknowledgement> on the back of one way messages because firewalls won't let us establish a new connection to the client. The reason that this is in the transport layer is because in the HTTP case we need to do transport specific actions - namely set a response code of 202 for case (b) above. I would like to see the decoupling moved out of the transport layer, and just give transports a chance to customize messages if they need to via a PartialResponseSupport interface or the like. - Dan On 2/5/07, Jarek Gawor <[EMAIL PROTECTED]> wrote:
Dan, This is great news. I ran into the same issue and was just about to write an email about HTTPConduit dependency on Jetty API. Btw, I haven't looked at this in detail, but was that dependency necessary to handle asynchronous requests? If so, would it be possible to plug in a different server provider so that for example when running in an app server, the app server container would be used instead? Jarek On 2/5/07, Dan Diephouse < [EMAIL PROTECTED]> wrote: > Hi All, > > I'm working with someone who is looking to use CXF as a web service client. > Currently we require a lot of jars[1], which is a topic for another thread. > However there are two specific problems I see with things currently. > > 1. We require jetty to be on the classpath if people want to use a web > service client. I'm very strongly against requiring Jetty to do simple HTTP > clients. XFire already has people annoyed because of its dependency list > [2], I would hate to imagine the the response if we required Jetty to do a > simple web service client. > > I tried an initial fix of removing the inner classes from HTTPConduit which > reference Jetty, but HTTPConduit has a dependency on ServerEngine which > references AbstractHttpHandler, so its not quite so straightforward. > > 2. The HTTPConduit explicitly uses Jetty instead of depending on our > Destination API. What if someone is deployed in a servlet environment and > only port 80 is open? We should be We should be able to set up a decoupled > listener on the servlet transport as well. Anyone know what the point is of > explicitly referencing Jetty's APIs? > > -- > > One solution would be to use the Destination API explicitly in the > HTTPConduit instead of using the Jetty APIs. Another would be to of removing > decoupling from the transport layer. I would appreciate it if others spoke > up and gave their input as well though. > > I am of course for the latter. We have so much added complexity because of > this (Decoupled* classes, ServerEngine references, extra Conduit APIs, the > ugly Destination.getBackChannel(...), etc.) Its very feasible to do this and > I still don't see what we have to lose by doing separating this all out. But > I'm repeating myself... > > - Dan > > 1. Jars required currently: > > XmlSchema-1.1.jar > activation-1.1.jar > aopalliance-1.0.jar > commons-logging-1.1.jar > cxf-api-2.0-incubator-RC-SNAPSHOT.jar > cxf-common-schemas-2.0-incubator-RC-SNAPSHOT.jar > cxf-common-utilities-2.0-incubator-RC-SNAPSHOT.jar > cxf-metacode-2.0-incubator-RC-SNAPSHOT.jar > cxf-rt-bindings-soap-2.0-incubator-RC-SNAPSHOT.jar > cxf-rt-core-2.0-incubator-RC-SNAPSHOT.jar > cxf-rt-databinding-jaxb-2.0-incubator-RC-SNAPSHOT.jar > cxf-rt-frontend-jaxws-2.0-incubator-RC-SNAPSHOT.jar > cxf-rt-transports-http-2.0-incubator-RC-SNAPSHOT.jar > cxf-tools-common-2.0-incubator-RC-SNAPSHOT.jar > jaxb-api-2.0.jar > jaxb-impl-2.0.3.jar > jaxb-xjc-2.0.3.jar > jaxws-api-2.0.jar > jsr181-api-1.0-MR1.jar > jsr250-api-1.0.jar > mail-1.4.jar > org.mortbay.jetty-5.1.11.jar > saaj-api-1.3.jar > saaj-impl-1.3.jar > spring-aop-2.0.jar > spring-beans-2.0.jar > spring-context-2.0.jar > spring-core-2.0.jar > stax-api-1.0.1.jar > wsdl4j-1.6.1.jar > wstx-asl-3.2.0.jar > > I'll be able to make SAAJ, Spring, and aopalliance optional as well with a > little more tweaking... > > 2. One recent example of many - > http://jroller.com/page/fate?entry=dodgy_benchmarks#comment2 - I could work > my way through the xfire user archives, but I don't really have the time. > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog > >
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
