<!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">
<br>
<br>
Scott M Stark wrote:
<blockquote cite="mid4655AA2B.1020607@redhat.com" type="cite">
<pre wrap="">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.
</pre>
</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. 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 cite="mid4655AA2B.1020607@redhat.com" type="cite">
<pre wrap="">
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
</pre>
</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 cite="mid4655AA2B.1020607@redhat.com" type="cite">
<pre wrap="">Anil Saldhana wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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
<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
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
</pre>
</blockquote>
<pre wrap="">_______________________________________________
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>
<pre wrap=""><!---->
_______________________________________________
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>
</body>
</html>