cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: HTTP dependency/decoupling issue
Date Mon, 05 Feb 2007 19:52:48 GMT
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 <jgawor@gmail.com> 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 < dan@envoisolutions.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message