[jboss-dev] Remoting 3.0

[Ron Sigal]

I'm just trying to collect architectural requirements for now.  I assume 
that MINA will play a big role in Remoting 3.0.

Tim Fox wrote:
> Tim Fox wrote:
>> Ron Sigal wrote:
>>>
>>>
>>> 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.
>> Does Connection.receive() block until it receives a message()?
>>
>> Remoting 3.0 needs to support non-blocking semantics too to cope with 
>> very large numbers of connection (We can't have a thread per 
>> connection blocking on receive()).
>>
>> What you probably need is some kind of select() functionality (see 
>> the Java NIO API or unix select() and poll()) where you can register 
>> for events - in this case a single (or small group of) thread(s) 
>> would register for events on multiple "channels" and are woken up 
>> when an evens matches the selector.
>>
>> You probably also want to build in support for aynchronous IO via 
>> callbacks - in this case, you don't even have thread(s) waiting on 
>> select() but register some kind of callback handler and the OS calls 
>> your handler directly - this can occur with less context switching 
>> than select().
>
> Instead of trying to write your own, have you looked at other 
> frameworks, which have already done the hard work? (MINA is the 
> obvious one, there is also Grizzly but I don't know much about that).
>
>>
>>> 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
>>>>   
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
JBoss, a Division of Red Hat
"My company's smarter than your company."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20070618/9e1f2481/attachment.html