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. :-)-RonTim Fox wrote:Ron Sigal wrote:Scott M Stark wrote:The main problem for me with the TowardsGreaterSymmetryInRemoting pageis that its not talking about a base asynch message orientedarchitecture. Much of the current asymmetry's is due to the rpc orientedapi. If you flip this around to have a base asynch message view, allcommunication is handling of these messages. RPC with callbacks issetting up blocking message handlers. Symmetry from a higher levelClient api is also not a requirement in my view. By definition acallback is an unpredictable event/out of band msg with respect to somerpc call returning a value. The use of client and server are also bydefinition asymmetric and map to msg senders/receivers. We need to startfrom the bottom and move back up to the rpc api in order to be able totalk 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 intolow level message creation for the case of needing to control the on thewire format of these messages.We are brining on the MINA lead, Trustin Lee, so we will need to look athow
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,AnilRon Sigal wrote:
There have been various attempts to get some discussion going aboutthe features desired for the next generation of Remoting, and so far Ithink the buzz has broken the -80 db level. I'm trying again with thewiki page athttp://wiki.jboss.org/wiki/Wiki.jsp?page=TowardsGreaterSymmetryInRemoting. We in the Remoting group (i.e., me in the Remoting group) would liketo hear from the Remoting stakeholders about what features would makeRemoting more usable for you. Of course, I could just go ahead andwrite fun stuff. :-)-Ron
_______________________________________________jboss-development mailing list
_______________________________________________jboss-development mailing list
------------------------------------------------------------------------_______________________________________________jboss-development mailing list
_______________________________________________jboss-development mailing list--JBoss, a Division of Red Hat"My company's smarter than your company."_______________________________________________jboss-development mailing listjboss-development@lists.jboss.org <mailto:jboss-development@lists.jboss.org>----Mark Littlemlittle@redhat.com <mailto:mlittle@redhat.com>JBoss, a Division of Red HatRegistered 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--Bill BurkeJBoss, a division of Red Hat Inc._______________________________________________jboss-development mailing list