[jboss-dev] Remoting 3.0
Mark Little
mlittle at redhat.com
Wed Jun 20 08:58:51 EDT 2007
I'll try to find the rest of the conversation I had with Tom, but
here's something relevant to this bit that he had to say back in
February 2007:
"Using JMS as remoting transport is going to be difficult. We had
thought about it, but since JMS offers a lot more in regards to
features (i.e. mainly in terms of quality of service, such as
guaranteed delivery, and point-to-multipoint), we decided not not
worry about it thinking if a user needed those types of features,
could just use JMS directly.
Guess if stripped out the use case to being a more simplistic one
where just sending messages using some default configuration, it
might work. However, since remoting is currently more a RPC based
model, I am not sure how we'd handle it all.
As an aside, I did some prototyping a while back for converting
remoting to be more messaging based instead of RPC based using a NIO
framework. I got some simple things working (such as a very simple
amqp example). However, it has been sitting idle for many months
since have a lot of other remoting issues to take care of. This
conversion is planned for the remoting 3.0 release, but right now, it
looks like that might not be till later this year."
Mark.
On 20 Jun 2007, at 02:55, Ron Sigal wrote:
> I think a JMS transport would work. JBossMessaging currently uses
> the bisocket transport (a descendant of socket) and the http
> transport. A Remoting transport that just interfaced with
> JBossMessaging doesn't sound like a problem. I'm not sure what the
> InvokerLocator would look like, but that's a different discussion.
>
> Remoting has oneway "invocations" and callbacks, which don't wait
> for a response. I think that corresponds to unreliable delivery.
>
> Do you remember why Tom thought these were "more transports
> than ... Remoting could deal with"" Was it for technical reasons,
> or because of time constraints?
>
> -Ron
>
> Mark Little wrote:
>> 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)
>>
>>
>>
>>
>> _______________________________________________
>> 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/20070620/28189e38/attachment.html
More information about the jboss-development
mailing list