HTTP dependency/decoupling issue

[Dan Diephouse <da...@envoisolutions.com>]

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

Re: HTTP dependency/decoupling issue

[Dan Diephouse <da...@envoisolutions.com>]

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 <jg...@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

Re: HTTP dependency/decoupling issue

[Jarek Gawor <jg...@gmail.com>]

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 <da...@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
>
>