You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Bruce Snyder <br...@gmail.com> on 2007/11/16 15:14:33 UTC
HTTP support in ServiceMix
Currently the HTTP support in ServiceMix is a bit disjointed. So far there is:
* lw HTTP components
* old smx-http endpoints
* new smx-http endpoints
* cxf-bc http endpoint
And now in ServiceMix 4 we are probably going to use Apache Camel's
HTTP component. So let's address this in two sections:
ServiceMix 3.x:
Currently in ServiceMix 3.x, as noted above there are simply too many
ways to skin the HTTP cat. The first thing we need to do is create a
document that addresses and explains this. Beyond there being multiple
classes providing support for both HTTP consumption and HTTP
production, there are some shortcomings in the newest servicemix-http
provider endpoint.
ACTION 1: Create a document explaining each HTTP component/endpoint
The HttpProviderEndpoint currently uses the Jetty client to provide
messages to HTTP endpoints. While this works well, the Jetty client
does not support SSL and there is no immediate plan to make it do so.
Not only does the HttpProviderEndpoint need SSL support, but it also
needs to support asynchronous HTTP requests. The Jakarta Commons
HttpClient 3.x supports SSL but only 4.0-alpha2 provides support for
async HTTP and it seems that this work is now stalled (see
http://wiki.apache.org/jakarta-httpclient/HttpAsyncThreadingDesign).
IMO, the HttpProviderEndpoint implementation needs to be refactored
now to use the Jakarta Commons HttpClient (JHC)
(http://jakarta.apache.org/httpcomponents/httpclient-3.x/index.html)
instead of the Jetty client. The HttpProviderEndpoint API should not
be changed at all, just the underlying implementation. But I'd also
like to be able to slide in the 4.x line of JHC into the
HttpProviderEndpoint for testing purposes. I'm wondering about
something Adrian Co suggested, but I have no idea if the 3.x and 4.x
APIs of JHC match or not. Adrian's suggestion was to create an API to
decouple any HTTP client from the endpoint so that it isn't tightly
coupled at all. I prefer to do exactly this, but I need to look into
it a bit more.
ACTION 2: Refactor the HttpProviderEndpoint to use JHC
ServiceMix 4.x:
In ServiceMix 4.x, the overall plan involves refactoring the entire
container from the ground up. Much work has already taken place toward
this effort, mostly by Guillaume Nodet (see
https://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0).
So far the idea for HTTP support in SMX 4 is to use the Apache Camel
HTTP component (this still needs to be discussed further in order to
figure out how the Apache CXF SE will work with both HTTP and JMS
endpoints, but this is a separate topic for another discussion).
Thoughts? Comments?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: HTTP support in ServiceMix
Posted by Adrian Co <ac...@exist.com>.
Added https://issues.apache.org/activemq/browse/SM-1169 to track this issue.
Bruce Snyder wrote:
> On Nov 16, 2007 8:11 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>
>
>> The work on the 4.x http components is not stalled afaik.
>> The code they mentionned is in a branch, but the trunk has full support for
>> async http requests.
>> They have released a new alpha version quite recently and it has just been
>> promoted as a TLP this week.
>>
>> Quoting http://www.apachenews.org/archives/001068.html
>> HttpCore NIO extensions can be used to build
>> asynchronous HTTP services based on non-blocking I/O model capable of
>> handling a great number of simultaneous connections with just a few I/O
>> threads.
>>
>> I really don't know what the web page you found refers too, but I suppose it
>> is outdated or refers to a dead branch without any relationship with the
>> current trunk.
>>
>> I've used HttpCore to implement a component in camel and it works well. The
>> only thing is that the api are not locked yet, which means it may require
>> work when we upgrade to the next version.
>>
>> An option to consider would be to use camel to implement the
>> HttpProviderEndpoint.
>>
>
> That's exactly what I'm thinking as I read your whole reply.
>
>
>>> ACTION 2: Refactor the HttpProviderEndpoint to use JHC
>>>
>>> ServiceMix 4.x:
>>> In ServiceMix 4.x, the overall plan involves refactoring the entire
>>> container from the ground up. Much work has already taken place toward
>>> this effort, mostly by Guillaume Nodet (see
>>>
>>> https://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0
>>> ).
>>> So far the idea for HTTP support in SMX 4 is to use the Apache Camel
>>> HTTP component (this still needs to be discussed further in order to
>>> figure out how the Apache CXF SE will work with both HTTP and JMS
>>> endpoints, but this is a separate topic for another discussion).
>>>
>> The idea is to avoid code duplication between camel / servicemix and provide
>> a single way to configure transports (thereby removing the need for this
>> thread in smx 4.x).
>> In my opinion, we will have the JBI 1.0 compatibility layer in smx 4, so
>> that we have backward compatibility with smx 3.x (to the extent of the JBI
>> specification).
>> For new applications, we should focus on using camel transports (this
>> includes the camel-jhc component i talked about), and for soap support
>> provided by cxf, we should use
>> the soap: protocol provided by camel-cxf which can be backed by any other
>> camel transport.
>> So currently, if you write
>> from("soap:jhc:http://localhost:8080/myservice").to(...)
>> in camel, it will create an http server side socket using HttpCore, and add
>> soap processing using CXF.
>> That way, we should not have to deal with CXF transport at all and only use
>> the camel HTTP transport provided by HttpCore (hopefully we can switch it to
>> be the default transport for http in camel at some point, so that the need
>> for the jhc: prefix will disapear).
>>
>> This is my view on how to solve the transport problem in Smx 4, but there I
>> still don't see how we can get rid of all the other http transport
>> duplication in smx 3 (especially the CXF one).
>>
>
> Then why don't we just make use of the Camel HTTP transport now for
> SMX 3 for the HttpProviderEndpoint? Is there anything preventing us
> from doing this now?
>
> We still need to create a document on the wiki explaining the HTTP mess.
>
> Bruce
>
Re: HTTP support in ServiceMix
Posted by Bruce Snyder <br...@gmail.com>.
On Nov 16, 2007 8:11 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> The work on the 4.x http components is not stalled afaik.
> The code they mentionned is in a branch, but the trunk has full support for
> async http requests.
> They have released a new alpha version quite recently and it has just been
> promoted as a TLP this week.
>
> Quoting http://www.apachenews.org/archives/001068.html
> HttpCore NIO extensions can be used to build
> asynchronous HTTP services based on non-blocking I/O model capable of
> handling a great number of simultaneous connections with just a few I/O
> threads.
>
> I really don't know what the web page you found refers too, but I suppose it
> is outdated or refers to a dead branch without any relationship with the
> current trunk.
>
> I've used HttpCore to implement a component in camel and it works well. The
> only thing is that the api are not locked yet, which means it may require
> work when we upgrade to the next version.
>
> An option to consider would be to use camel to implement the
> HttpProviderEndpoint.
That's exactly what I'm thinking as I read your whole reply.
> > ACTION 2: Refactor the HttpProviderEndpoint to use JHC
> >
> > ServiceMix 4.x:
> > In ServiceMix 4.x, the overall plan involves refactoring the entire
> > container from the ground up. Much work has already taken place toward
> > this effort, mostly by Guillaume Nodet (see
> >
> > https://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0
> > ).
> > So far the idea for HTTP support in SMX 4 is to use the Apache Camel
> > HTTP component (this still needs to be discussed further in order to
> > figure out how the Apache CXF SE will work with both HTTP and JMS
> > endpoints, but this is a separate topic for another discussion).
>
>
> The idea is to avoid code duplication between camel / servicemix and provide
> a single way to configure transports (thereby removing the need for this
> thread in smx 4.x).
> In my opinion, we will have the JBI 1.0 compatibility layer in smx 4, so
> that we have backward compatibility with smx 3.x (to the extent of the JBI
> specification).
> For new applications, we should focus on using camel transports (this
> includes the camel-jhc component i talked about), and for soap support
> provided by cxf, we should use
> the soap: protocol provided by camel-cxf which can be backed by any other
> camel transport.
> So currently, if you write
> from("soap:jhc:http://localhost:8080/myservice").to(...)
> in camel, it will create an http server side socket using HttpCore, and add
> soap processing using CXF.
> That way, we should not have to deal with CXF transport at all and only use
> the camel HTTP transport provided by HttpCore (hopefully we can switch it to
> be the default transport for http in camel at some point, so that the need
> for the jhc: prefix will disapear).
>
> This is my view on how to solve the transport problem in Smx 4, but there I
> still don't see how we can get rid of all the other http transport
> duplication in smx 3 (especially the CXF one).
Then why don't we just make use of the Camel HTTP transport now for
SMX 3 for the HttpProviderEndpoint? Is there anything preventing us
from doing this now?
We still need to create a document on the wiki explaining the HTTP mess.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: HTTP support in ServiceMix
Posted by Guillaume Nodet <gn...@gmail.com>.
On Nov 16, 2007 3:14 PM, Bruce Snyder <br...@gmail.com> wrote:
> Currently the HTTP support in ServiceMix is a bit disjointed. So far there
> is:
>
> * lw HTTP components
> * old smx-http endpoints
> * new smx-http endpoints
> * cxf-bc http endpoint
>
> And now in ServiceMix 4 we are probably going to use Apache Camel's
> HTTP component. So let's address this in two sections:
>
> ServiceMix 3.x:
> Currently in ServiceMix 3.x, as noted above there are simply too many
> ways to skin the HTTP cat. The first thing we need to do is create a
> document that addresses and explains this. Beyond there being multiple
> classes providing support for both HTTP consumption and HTTP
> production, there are some shortcomings in the newest servicemix-http
> provider endpoint.
>
> ACTION 1: Create a document explaining each HTTP component/endpoint
>
> The HttpProviderEndpoint currently uses the Jetty client to provide
> messages to HTTP endpoints. While this works well, the Jetty client
> does not support SSL and there is no immediate plan to make it do so.
> Not only does the HttpProviderEndpoint need SSL support, but it also
> needs to support asynchronous HTTP requests. The Jakarta Commons
> HttpClient 3.x supports SSL but only 4.0-alpha2 provides support for
> async HTTP and it seems that this work is now stalled (see
> http://wiki.apache.org/jakarta-httpclient/HttpAsyncThreadingDesign).
>
> IMO, the HttpProviderEndpoint implementation needs to be refactored
> now to use the Jakarta Commons HttpClient (JHC)
> (http://jakarta.apache.org/httpcomponents/httpclient-3.x/index.html)
> instead of the Jetty client. The HttpProviderEndpoint API should not
> be changed at all, just the underlying implementation. But I'd also
> like to be able to slide in the 4.x line of JHC into the
> HttpProviderEndpoint for testing purposes. I'm wondering about
> something Adrian Co suggested, but I have no idea if the 3.x and 4.x
> APIs of JHC match or not. Adrian's suggestion was to create an API to
> decouple any HTTP client from the endpoint so that it isn't tightly
> coupled at all. I prefer to do exactly this, but I need to look into
> it a bit more.
>
The work on the 4.x http components is not stalled afaik.
The code they mentionned is in a branch, but the trunk has full support for
async http requests.
They have released a new alpha version quite recently and it has just been
promoted as a TLP this week.
Quoting http://www.apachenews.org/archives/001068.html
HttpCore NIO extensions can be used to build
asynchronous HTTP services based on non-blocking I/O model capable of
handling a great number of simultaneous connections with just a few I/O
threads.
I really don't know what the web page you found refers too, but I suppose it
is outdated or refers to a dead branch without any relationship with the
current trunk.
I've used HttpCore to implement a component in camel and it works well. The
only thing is that the api are not locked yet, which means it may require
work when we upgrade to the next version.
An option to consider would be to use camel to implement the
HttpProviderEndpoint.
> ACTION 2: Refactor the HttpProviderEndpoint to use JHC
>
> ServiceMix 4.x:
> In ServiceMix 4.x, the overall plan involves refactoring the entire
> container from the ground up. Much work has already taken place toward
> this effort, mostly by Guillaume Nodet (see
>
> https://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0
> ).
> So far the idea for HTTP support in SMX 4 is to use the Apache Camel
> HTTP component (this still needs to be discussed further in order to
> figure out how the Apache CXF SE will work with both HTTP and JMS
> endpoints, but this is a separate topic for another discussion).
The idea is to avoid code duplication between camel / servicemix and provide
a single way to configure transports (thereby removing the need for this
thread in smx 4.x).
In my opinion, we will have the JBI 1.0 compatibility layer in smx 4, so
that we have backward compatibility with smx 3.x (to the extent of the JBI
specification).
For new applications, we should focus on using camel transports (this
includes the camel-jhc component i talked about), and for soap support
provided by cxf, we should use
the soap: protocol provided by camel-cxf which can be backed by any other
camel transport.
So currently, if you write
from("soap:jhc:http://localhost:8080/myservice").to(...)
in camel, it will create an http server side socket using HttpCore, and add
soap processing using CXF.
That way, we should not have to deal with CXF transport at all and only use
the camel HTTP transport provided by HttpCore (hopefully we can switch it to
be the default transport for http in camel at some point, so that the need
for the jhc: prefix will disapear).
This is my view on how to solve the transport problem in Smx 4, but there I
still don't see how we can get rid of all the other http transport
duplication in smx 3 (especially the CXF one).
>
>
> Thoughts? Comments?
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/