Re: [jboss-dev] Remoting 3.0

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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> >>>> >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development -- JBoss, a Division of Red Hat "My company's smarter than your company." ------------------------------------------------------------------------ _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development