<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
Remoting has oneway "invocations" and callbacks, which don't wait for a
response. I think that corresponds to unreliable delivery.<br>
<br>
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?<br>
<br>
-Ron <br>
<br>
Mark Little wrote:
<blockquote cite="mid43799331-5FED-461F-8DCC-14D548323A11@redhat.com"
type="cite">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 ;-)
<div><br class="khtml-block-placeholder">
</div>
<div>Oh and reliable delivery is something that should be optional
IMO.
<div><br class="khtml-block-placeholder">
</div>
<div>Mark.</div>
<div><br class="khtml-block-placeholder">
</div>
<div><br>
<div>
<div>On 19 Jun 2007, at 00:25, Ron Sigal wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"> Hi Tim,<br>
<br>
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. :-)<br>
<br>
-Ron<br>
<br>
Tim Fox wrote:
<blockquote cite="mid46768194.5010307@jboss.com" type="cite">Ron
Sigal wrote: <br>
<blockquote type="cite"><br>
<br>
Scott M Stark wrote: <br>
<blockquote type="cite">The main problem for me with the
TowardsGreaterSymmetryInRemoting page <br>
is that its not talking about a base asynch message oriented <br>
architecture. Much of the current asymmetry's is due to the rpc
oriented <br>
api. If you flip this around to have a base asynch message view, all <br>
communication is handling of these messages. RPC with callbacks is <br>
setting up blocking message handlers. Symmetry from a higher level <br>
Client api is also not a requirement in my view. By definition a <br>
callback is an unpredictable event/out of band msg with respect to some
<br>
rpc call returning a value. The use of client and server are also by <br>
definition asymmetric and map to msg senders/receivers. We need to
start <br>
from the bottom and move back up to the rpc api in order to be able to <br>
talk about what the 3.0 version of Client should look like. </blockquote>
<br>
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. <br>
</blockquote>
Does Connection.receive() block until it receives a message()? <br>
<br>
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()). <br>
<br>
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. <br>
<br>
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(). <br>
<br>
<blockquote type="cite">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. <br>
<br>
<blockquote type="cite">The architecture also needs to be
layered such that you can plug into <br>
low level message creation for the case of needing to control the on
the <br>
wire format of these messages. <br>
<br>
We are brining on the MINA lead, Trustin Lee, so we will need to look
at <br>
how <br>
<br>
</blockquote>
<br>
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. <br>
<br>
<blockquote type="cite">Anil Saldhana wrote: <br>
<blockquote type="cite">Ron, <br>
Most of it may already be present. <br>
<br>
Here is what I am thinking: <br>
a) Pluggable mechanism to do authentication at either ends of the pipes
<br>
(SASL) <br>
b) Pluggable ways to secure the payload that passes through the pipes. <br>
<br>
Regards, <br>
Anil <br>
<br>
Ron Sigal wrote: <br>
<blockquote type="cite">There have been various attempts to
get some discussion going about <br>
the features desired for the next generation of Remoting, and so far I <br>
think the buzz has broken the -80 db level. I'm trying again with the <br>
wiki page at <br>
<a class="moz-txt-link-freetext"
href="http://wiki.jboss.org/wiki/Wiki.jsp?page=TowardsGreaterSymmetryInRemoting">http://wiki.jboss.org/wiki/Wiki.jsp?page=TowardsGreaterSymmetryInRemoting</a>.
We in the Remoting group (i.e., me in the Remoting group) would like <br>
to hear from the Remoting stakeholders about what features would make <br>
Remoting more usable for you. Of course, I could just go ahead and <br>
write fun stuff. :-) <br>
<br>
-Ron <br>
</blockquote>
_______________________________________________ <br>
jboss-development mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<br>
<a class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
<br>
</blockquote>
<br>
_______________________________________________ <br>
jboss-development mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<br>
<a class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
<br>
</blockquote>
------------------------------------------------------------------------
<br>
<br>
_______________________________________________ <br>
jboss-development mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<br>
<a class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
<br>
</blockquote>
<br>
_______________________________________________ <br>
jboss-development mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<br>
<a class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
<br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font color="#000000">JBoss, a Division of Red Hat<br>
"My company's smarter than your company." </font></div>
<div style="margin: 0px;">_______________________________________________</div>
<div style="margin: 0px;">jboss-development mailing list</div>
<div style="margin: 0px;"><a
href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a></div>
<div style="margin: 0px;"><a
href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a></div>
</blockquote>
</div>
<br>
<div> <span class="Apple-style-span"
style="border-collapse: separate; border-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px;"><span
class="Apple-style-span"
style="border-collapse: separate; border-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px;">
<div>----</div>
<div><br class="khtml-block-placeholder">
</div>
<div>Mark Little</div>
<div><a href="mailto:mlittle@redhat.com">mlittle@redhat.com</a></div>
<div><br class="khtml-block-placeholder">
</div>
<div>JBoss, a Division of Red Hat</div>
<div style="margin: 0px;">Registered Address: Red Hat UK Ltd,
Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, </div>
<div style="margin: 0px;">SI4 1TE, United Kingdom. </div>
<div style="margin: 0px;">Registered in UK and Wales under Company
Registration No. 3798903 </div>
<div style="margin: 0px;">Directors: Michael Cunningham (USA),
Charlie Peters (USA) and David Owens (Ireland)</div>
<div><br class="khtml-block-placeholder">
</div>
<div><br class="khtml-block-placeholder">
</div>
<br class="Apple-interchange-newline">
</span></span> </div>
<br>
</div>
</div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
jboss-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font color="#000000">JBoss, a Division of Red Hat<br>
"My company's smarter than your company."
</font></div>
</body>
</html>