Re: HTTP support in ServiceMix

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