You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/04/27 00:21:56 UTC
Re: http
Replying to the dev list if you don't mind ;-)
On 4/26/07, Thomas TERMIN <tt...@blue-elephant-systems.com> wrote:
>
>
> Is this HttpProviderEndpoint an replacement for the ProviderProcessor?
>
>
> http://svn.apache.org/viewvc/incubator/servicemix/trunk/deployables/bindingcomponents/servicemix-http/src/main/java/org/apache/servicemix/http/endpoints/HttpProviderEndpoint.java?view=markup&pathrev=508584
>
>
This is a work I began some time ago to better support soap, split the
provider endpoints from the consumer endpoints This is clearly
unfinished.... The goal was to rewrite the HTTP endpoints so that they are
easier to extend. There are some derived endpoints that use the new soap2
module for a better SOAP support. The server side is in a workable state,
but the client side has not been finished.
I have also worked on integrating Apache CXF (which is the "next" version of
XFire) ... And it seems to be quite usable so we have two components that I
checked in this week. The main point is that it should bring a better
jax-ws support, including on the tooling side, and also add support for
WS-RM on the BC side.
I don't think maintaining the soap2 module is a good idea given that CXF
provides a better support and has a load of developers to support it. At
the same time, the work that has been done on HTTP and JMS endpoints is
good. I don't think CXF has enough support for HTTP / JMS when not using
SOAP.
Thoughts ?
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: http
Posted by Guillaume Nodet <gn...@gmail.com>.
Agreed. I don't think CXF is easy enough to extend so that we can drop our
components at this point.
However, the problem comes when dealing with SOAP: do we only delegate to
CXF for that ?
It also means that the transports will be configured differently if you use
SOAP or not.
I guess it's not that a big problem though ....
On 4/27/07, Bruce Snyder <br...@gmail.com> wrote:
>
>
> Agreed - support for CXF is very good step for ServiceMix because we
> no longer have to handle SOAP directly. But I think that we should
> continue developing our own HTTP and JMS components. I like the split
> that has been done between the consumer and provider endpoints. I
> think it's a step in the right direction for allowing easier extension
> to support additional scenarios.
>
> Bruce
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: http
Posted by Bruce Snyder <br...@gmail.com>.
On 4/26/07, Guillaume Nodet <gn...@gmail.com> wrote:
> Replying to the dev list if you don't mind ;-)
>
> On 4/26/07, Thomas TERMIN <tt...@blue-elephant-systems.com> wrote:
> >
> >
> > Is this HttpProviderEndpoint an replacement for the ProviderProcessor?
> >
> >
> > http://svn.apache.org/viewvc/incubator/servicemix/trunk/deployables/bindingcomponents/servicemix-http/src/main/java/org/apache/servicemix/http/endpoints/HttpProviderEndpoint.java?view=markup&pathrev=508584
> >
> >
> This is a work I began some time ago to better support soap, split the
> provider endpoints from the consumer endpoints This is clearly
> unfinished.... The goal was to rewrite the HTTP endpoints so that they are
> easier to extend. There are some derived endpoints that use the new soap2
> module for a better SOAP support. The server side is in a workable state,
> but the client side has not been finished.
>
> I have also worked on integrating Apache CXF (which is the "next" version of
> XFire) ... And it seems to be quite usable so we have two components that I
> checked in this week. The main point is that it should bring a better
> jax-ws support, including on the tooling side, and also add support for
> WS-RM on the BC side.
>
> I don't think maintaining the soap2 module is a good idea given that CXF
> provides a better support and has a load of developers to support it. At
> the same time, the work that has been done on HTTP and JMS endpoints is
> good. I don't think CXF has enough support for HTTP / JMS when not using
> SOAP.
>
> Thoughts ?
Agreed - support for CXF is very good step for ServiceMix because we
no longer have to handle SOAP directly. But I think that we should
continue developing our own HTTP and JMS components. I like the split
that has been done between the consumer and provider endpoints. I
think it's a step in the right direction for allowing easier extension
to support additional scenarios.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/