Transport Use Cases

[dmlloyd]

Right now there are a set of socket-based transports (including bisocket, multiplex, and socket, and encrypted variants), RMI, and a few HTTP-based transports.

There are a few other transports that are on the table - JGroups, SSH. Also, I've seen some informal requests go by for much more esoteric transport mechanisms - like FTP, email, and that sort of thing.

Is there a use case for these transports? Honestly I can't see why someone would use RMI (or the other socket transports) if there was a single socket transport that provided authentication, (possibly keyless) encryption, bidirectional communication, asynch request/replies, and multiplexing multiple requests or sessions on the same connection.

HTTP seems useful in the case where a firewall prevents regular socket communication. Apart from that, it would probably be inferior (performancewise) to a single socket as described above.

I'm not sure of the utility of a JGroups transport - certainly it could be done, but would this add any value over what JGroups does today?

As for the other transports - FTP, email, etc. - are these truly appropriate to Remoting? Perhaps those types of transports are more suited towards a SOAP-like approach? If they really are wanted, then JIRA issues should be opened for each transport, along with a sketch of requirements and a use case.

[trustin]

I agree with you that it's of dubious value to provide additional transports considering the current set of implemented transports.

BTW, it sounds like Remoting is not for interoperability between various parties but for efficient and full-featured communication between only Remoting clients and servers. Did I understand correctly? and out of curiosity, is it what users want?

[dmlloyd]

"trustin" wrote:
I agree with you that it's of dubious value to provide additional transports considering the current set of implemented transports.

BTW, it sounds like Remoting is not for interoperability between various parties but for efficient and full-featured communication between only Remoting clients and servers. Did I understand correctly?

You are correct.

"trustin" wrote:
and out of curiosity, is it what users want?

Well, we've had a tough time getting user input thus far. Hopefully next week will shed some light. The current state of Remoting 3 is based on all the feedback I've been able to locate about earlier versions thus far.

[ron_sigal]

"trustin" wrote:
and out of curiosity, is it what users want?

Currently, I'd say that the biggest users of Remoting are EJB2/3 and JBossMessaging. Eventually, JBoss Naming (JNDI) will be converted as well. In all of these cases, Remoting clients and servers are created in matching pairs by higher level code. The use of Remoting by JBossWS is a counterexample, since they use a Remoting client without a Remoting server, but I can't say much more than that, not being very familiar with their code. There are other JBoss projects that use Remoting, but none have asked for sweeping changes, to date.

So, on the whole, if you refer to current users, I'd say the answer is "yes".

This is not to say that we couldn't court other users. And, in fact, there is an existing community of Remoting users outside of JBoss. But I think we should always listen for the thundering footsteps in our ecosystem.

[trustin]

I see. See you there then! :)

[jason.greene]

The use of Remoting by JBossWS is a counterexample, since they use a Remoting client without a Remoting server, but I can't say much more than that, not being very familiar with their code.

JBossWS uses Remoting solely for basic client side http transport functionality. SOAP marshalling is implemented in JBossWS using a custom remoting marshaller.

The server side component of JBossWS is currently just a servlet, which is needed for container integration, however, it was also desired for remoting to provide a lightweight standalone http server API. Tom did a prototype awhile back using an embedded slimed down version of tomcat, but it would also be a good idea to reuse any VM provided http server, the sun vm includes one, for example. This is obviously less important than the main and more prevalent use cases of remoting, but I thought I would mention it nonetheless.