Remoting 3 and HTTP client

[asoldano]

This is related to https://jira.jboss.org/jira/browse/JBWS-2554 .
In few words, JBossWS will soon need to use other means for http client invocations, as Remoting is not going to provide this anymore.
Perhaps this might be the chance for making the http client pluggable.
Right now I'm thinking about using HTTPClient (http://hc.apache.org), any opinion?

[trustin]

Hi Alessio,

Remoting 3.1 will have HTTP transport, although it's not going to be backward-compatible in wire-level. Release date is not sure yet unfortunately.

As an alternative, I'd like to suggest you to try Netty HTTP codec - http://www.jboss.org/netty/

Check the HTTP client / server example in the documentation section - http://tinyurl.com/5w3fpb (HttpClient, HttpClientPipelineFactory, and HttpResponseHandler are all you need to see.)

It's supposed to be very efficient in dealing with large number of concurrent HTTP connections thanks to the effectiveness and robustness of its core.

[ropalka]

It's not clear to me what's going to happen with remoting?
Is it going to remove client side abstraction or is it going to change binary protocol in incompatible way so using it cross different AS versions is not an option anymore?
Do we need to remove remoting dependency from our client side?

If we need to remove dependency on remoting and provide pluggible client transport layer then note that we have nontrivial dependencies on JBoss Remoting:
* FastInfosetConnectionHTTP
* JsonConnectionHTTP
* SOAPProtocolConnectionHTTP
* SOAPProtocolConnectionJMS
i.e. new transport should allow us to do http(s) & jms messages exchange at least.
We should also consider socket reuse (this is issue of our current implementation - many customers are complaining about it)

[asoldano]

"trustin" wrote:
Hi Alessio,

Remoting 3.1 will have HTTP transport, although it's not going to be backward-compatible in wire-level. Release date is not sure yet unfortunately.

As an alternative, I'd like to suggest you to try Netty HTTP codec - http://www.jboss.org/netty/

Check the HTTP client / server example in the documentation section - http://tinyurl.com/5w3fpb (HttpClient, HttpClientPipelineFactory, and HttpResponseHandler are all you need to see.)

It's supposed to be very efficient in dealing with large number of concurrent HTTP connections thanks to the effectiveness and robustness of its core.

Thanks Trustin, this is exactly the kind of suggestion I expected from you guys ;-)
I'll try Netty first for sure.

[timfox]

JBoss Messaging 2.0 also uses Netty, including the HTTP servlet transport, which allows JMS traffic to be tunnelled over port 80 in any servlet container.

[dmlloyd]

It's not clear to me what's going to happen with remoting?
Is it going to remove client side abstraction or is it going to change binary protocol in incompatible way so using it cross different AS versions is not an option anymore?
Do we need to remove remoting dependency from our client side?

This is what's happening. Remoting 3 introduces a new API which is not compatible with Remoting 2. It also is introducing new protocols which are incompatible with the old ones, though a translation layer is possible and is in the works in order to allow some level of interoperability.

As of right now, I'm targeting AS 5.1 to have both Remoting 2 and 3 in it, with Remoting 3 existing as a sort of tech preview. At some unspecified point in the future, all services (such as EJB3, invokers, etc) will have been migrated to 3 and Remoting 2 will disappear (API and all). At this stage, all clients should be using R3 (though it will still be possible to support R2 clients without having R2 exist on the server).

The HTTP abstractions (client and server) which appeared in Remoting 2 are more of an abstraction leak than an API feature, which came about from the fact that all of Remoting was basically stuck into a single JAR with no distinction between API, SPI, and implementation. A similar abstraction is not going to appear in the Remoting 3 API because the interfaces therein pertain only to remote invocation.

[ropalka]

JBWS-2674 depends on this issue as well.

[ropalka]

"trustin" wrote:

As an alternative, I'd like to suggest you to try Netty HTTP codec - http://www.jboss.org/netty/

Hi Trustin,

I just spent few hours with studying your Netty project/samples/code base.
I think Netty is the best thing we could use for our next generation webservices
client transport ;)

Richard