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)[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/
