On Nov 16, 2007 3:14 PM, Bruce Snyder <[EMAIL PROTECTED]> 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)[EMAIL PROTECTED]&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/
