This content has been marked as final.
Show 5 replies
-
1. Re: Transport Use Cases
trustin Sep 19, 2007 12:48 AM (in response to dmlloyd)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? -
2. Re: Transport Use Cases
dmlloyd Sep 19, 2007 8:00 PM (in response to 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. -
3. Re: Transport Use Cases
ron_sigal Sep 20, 2007 3:26 AM (in response to dmlloyd)"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. -
4. Re: Transport Use Cases
trustin Sep 20, 2007 3:42 AM (in response to dmlloyd)I see. See you there then! :)
-
5. Re: Transport Use Cases
jason.greene Sep 21, 2007 11:26 AM (in response to dmlloyd)"ron.sigal@jboss.com" wrote:
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.