[jboss-dev] Remoting 3.0
Mark Little
mlittle at redhat.com
Tue Jun 19 09:08:16 EDT 2007
How about moving away from URLs to URIs or EPRs (WS-Addressing
Endpoint References)? We use EPRs, which are basically URIs with some
additional meta-data (which can be null if you want). URLs are ok and
my JBossESB 5.0 prototype runs on current Remoting and does a mapping
from EPR down to URL when it needs to, but they are pretty limiting.
Plus URL doesn't support SFTP or FTPS.
Mark.
On 19 Jun 2007, at 14:00, Bill Burke wrote:
> The URL for JMS would look real ugly too. New URL protocols are
> dangerous too as you may not be able to override the JDK's URL
> Handler (because it can only be set once!). I ran into this
> problem with Tomcat 5.
>
> 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 <mailto:jboss-
>>> development at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> ----
>> Mark Little
>> mlittle at redhat.com <mailto: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
>
> --
> Bill Burke
> JBoss, a division of Red Hat Inc.
> _______________________________________________
> 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/3aebe804/attachment.html
More information about the jboss-development
mailing list