[jboss-dev] Remoting 3.0
Mark Little
mlittle at redhat.com
Tue Jun 19 05:06:01 EDT 2007
One thing I was discussing with Tom at the start of the year was ESB
using Remoting for its transport layer. Unfortunately there isn't a
complete solution as it currently stands, because we have
asynchronous (one-way) messaging transport requirements that cover
more transports than Tom thought Remoting could deal with (then),
including: FTP, database, email, JMS (that one is critical for us but
causes a circularity with the current implementation if we plug in
JBoss Messaging, which is built on Remoting ;-)
Oh and reliable delivery is something that should be optional IMO.
Mark.
On 19 Jun 2007, at 00:25, Ron Sigal wrote:
> Hi Tim,
>
> Excellent. This is just the kind of feedback I was hoping for. We
> definitely want Remoting 3.0 to satisfy the needs of JBM. You're
> our best critics. :-)
>
> -Ron
>
> 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().
>>
>>> 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, a Division of Red Hat
> "My company's smarter than your company."
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
----
Mark Little
mlittle at redhat.com
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire,
SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20070619/af0d025d/attachment.html
More information about the jboss-development
mailing list