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

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

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.

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

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

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(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

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

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(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

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(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 > <mailto:jboss-development@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/jboss-development ---- Mark Little mlittle(a)redhat.com <mailto:mlittle@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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. >

Sure. In the 4.2 version of ESB we're using a version that is based on the original WS-Addressing implementation we developed in Arjuna for the Web Services transactions product back in 2004 and used for interoperability testing with Microsoft, IBM etc. It's based on the 2004 version of WS-A (http://www.ibm.com/developerworks/library/specification/ws-add/) We have a new version for the next major release of ESB based on the 2006 release of WS-A (tested here http://www.w3.org/2002/ws/addr/testsuite/), but the concepts are pretty much the same (basically you lose ReferenceProperties). This class is the one people are expected to develop endpoint references (EPRs) against: http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/core/rosetta/sr... But this one is the one that does the real work: http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/core/rosetta/sr... BTW, URI would be fine too. EPRs are a superset. Mark. On 20 Jun 2007, at 19:08, Scott M Stark wrote: > We use both URLs and URIs in the vfs, but still rely on the URL > handler > mechanism for content. There needs to be some mechanism to obtain > content streams and properties/attributes for the endpoint. We > should > have a common lib for either URIs or EPRs. Give a pointer to the EPR > code in the ESB codebase. > > > Mark Little wrote: > > 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. > > > > > > > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development > > > > ---- Mark Little mlittle(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Maybe we should externalize it into a jbossws-addressing.jar. Currently ESB and JBossWS are using different implementations of the same specs. With remoting it would be already three parties. IMHO it should become a subproject of either JBossWS or ESB and publish jars to the repository for others to refer to. /Heiko On Thu, 2007-06-21 at 08:20 +0100, Mark Little wrote: > Sure. In the 4.2 version of ESB we're using a version that is > based on > the original WS-Addressing implementation we developed in Arjuna for > the Web Services transactions product back in 2004 and used for > interoperability testing with Microsoft, IBM etc. It's based on the > 2004 version of WS-A > (http://www.ibm.com/developerworks/library/specification/ws-add/) > > > We have a new version for the next major release of ESB based on the > 2006 release of WS-A (tested here > http://www.w3.org/2002/ws/addr/testsuite/), but the concepts are > pretty much the same (basically you lose ReferenceProperties). > > > This class is the one people are expected to develop endpoint > references (EPRs) against: > > > http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/core/ > rosetta/src/org/jboss/soa/esb/addressing/EPR.java > > > But this one is the one that does the real work: > > http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/core/ > rosetta/src/org/jboss/soa/esb/addressing/PortReference.java > > > BTW, URI would be fine too. EPRs are a superset. > > > Mark. > > > > On 20 Jun 2007, at 19:08, Scott M Stark wrote: > >> We use both URLs and URIs in the vfs, but still rely on the URL >> handler >> mechanism for content. There needs to be some mechanism to obtain >> content streams and properties/attributes for the endpoint. We >> should >> have a common lib for either URIs or EPRs. Give a pointer to the EPR >> code in the ESB codebase. >> >> >> Mark Little wrote: >>> 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. >>>> >>>> >> >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> >> >> > > ---- > > > Mark Little > mlittle(a)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(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

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(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 > > ---- > > Mark Little > mlittle(a)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(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

I would like to see the client endpoint (InetAddress most of the time) of an invocation. Maybe it's already in the InvocationRequest, but I can't find it. Carlo On Thu, 2007-05-17 at 15:51 -0400, 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

No I mean the remote socket address: http://java.sun.com/j2se/1.5.0/docs/api/java/net/Socket.html#getRemoteSoc... Somewhere deep down if a remote invocation comes in over a socket the remote address is known. If it can be associated with the invocation it can be used to set up auditing and filtering. Carlo On Sun, 2007-06-17 at 03:46 -0400, Ron Sigal wrote: > Hi Carlo, > > I'm not sure I understand what you're asking for. An > org.jboss.remoting.Client has an identity, the sessionId, which is > included in the InvocationRequest. But Client doesn't really map to > an InetAddress. The socket transport, for example, maintains a pool > of TCP connections, each with a different port. Remoting could supply > the InetAddress of the connection used for a particular invocation, if > that's what you mean. But note that that same connection could be > used by a different Client for a different invocation at any time. > > -Ron > > Carlo de Wolf wrote: > >> I would like to see the client endpoint (InetAddress most of the time) >> of an invocation. Maybe it's already in the InvocationRequest, but I >> can't find it. >> >> Carlo >> >> On Thu, 2007-05-17 at 15:51 -0400, 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

I don't think we can get access to the remote address in the rmi transport.