[jboss-dev] Remoting 3.0

[Ron Sigal]

Scott M Stark wrote:
> The main problem for me with the TowardsGreaterSymmetryInRemoting page
> is that its not talking about a base asynch message oriented
> architecture. Much of the current asymmetry's is due to the rpc oriented
> api. If you flip this around to have a base asynch message view, all
> communication is handling of these messages. RPC with callbacks is
> setting up blocking message handlers. Symmetry from a higher level
> Client api is also not a requirement in my view. By definition a
> callback is an unpredictable event/out of band msg with respect to some
> rpc call returning a value. The use of client and server are also by
> definition asymmetric and map to msg senders/receivers. We need to start
> from the bottom and move back up to the rpc api in order to be able to
> talk about what the 3.0 version of Client should look like. 
>   

Actually, a "base asynch message oriented architecture" was just what I 
was trying to get at.  While Remoting should continue to support the rpc 
model, the Connection.receive() and Connection.send() methods that I 
mentioned are intended to support asynchronous message sending and 
receiving.  Also, while it's true that client and server roles are 
inherently asymmetric, actors can play multiple roles (like Peter 
Sellers).  In Remoting, for example, callbacks (in push mode) are 
handled by clients on the server side talking to servers on the client 
side.  I think the same thing would be conceptually simpler with a 
"connection" abstraction that mirrors a real TCP connection: it's true 
that there are client and server sockets, but once the connection has 
been created, there can be senders and receivers on both sides.

> The architecture also needs to be layered such that you can plug into
> low level message creation for the case of needing to control the on the
> wire format of these messages.
>
> We are brining on the MINA lead, Trustin Lee, so we will need to look at
> how
>
>   

The idea of stacks of marshallers and unmarshallers in Remoting has been 
floating around for a while, and Tom did some initial work in that 
direction.  I'm thinking that's where the layered message handling will 
live.  I've been meaning to write a second document on the subject, but, 
in fact, MINA has a pretty flexible and sophisticated framework for 
chains of message handlers, which looks like a good match for what we 
want.  As you say, we need to understand how MINA and Remoting will work 
together.

> Anil Saldhana wrote:
>   
>> Ron,
>>  Most of it may already be present.
>>
>> Here is what I am thinking:
>> a) Pluggable mechanism to do authentication at either ends of the pipes
>> (SASL)
>> b) Pluggable ways to secure the payload that passes through the pipes.
>>
>> Regards,
>> Anil
>>
>> Ron Sigal wrote:
>>     
>>> There have been various attempts to get some discussion going about
>>> the features desired for the next generation of Remoting, and so far I
>>> think the buzz has broken the -80 db level.  I'm trying again with the
>>> wiki page at
>>> http://wiki.jboss.org/wiki/Wiki.jsp?page=TowardsGreaterSymmetryInRemoting. 
>>> We in the Remoting group (i.e., me in the Remoting group) would like
>>> to hear from the Remoting stakeholders about what features would make
>>> Remoting more usable for you.  Of course, I could just go ahead and
>>> write fun stuff.  :-)
>>>
>>> -Ron
>>>       
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>     
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20070617/441ad756/attachment.html