<!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">
Michael Wright wrote:
<blockquote cite="mid:123445.44612.qm@web23011.mail.ird.yahoo.com"
type="cite">I guess in some ways it could be thought as a network bus,
but I wasn't thinking of the messages being broadcast on the channel,
where all endpoints had to listen to all messages and pick out the ones
for them. I was thinking, if anything, of more like a cut down web
services protocol stack.<br>
<br>
My prototype channel is just a basic HTTP based one. That just finds
where the url of the channel receiver, that the required servlet is
currently registered at, is. Then does a HTTP POST of the serialised
message to that url. <br>
<br>
But the implementation should be up to the channels. All the rest of
the system should care is that a channel can pass messages from one end
point to another, and can map some standard addressing scheme to those
endpoints. Allowing for a dynamic system, where the addressable message
receivers (the servlets) can move around the endpoints on a channel as
needed. And new endpoints can be added.<br>
</blockquote>
ah. ok. so it's not a network bus, but rather a dual-ended funnel ---
like >--< ? with servlets attaching themselves to the respective
funnels on each end?<br>
<br>
cheers,<br>
dr scofield?<br>
<br>
<blockquote cite="mid:123445.44612.qm@web23011.mail.ird.yahoo.com"
type="cite"><br>
<br>
<b><i>Dr Scofield <a class="moz-txt-link-rfc2396E" href="mailto:DrScofield@xyzzyxyzzy.net"><DrScofield@xyzzyxyzzy.net></a></i></b> wrote:
<blockquote class="replbq"
style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">
interesting thoughts. question: would a channel be something like a <br>
network bus?<br>
<br>
cheers<br>
dr scofield<br>
<br>
Michael Wright wrote:<br>
> I'm been thinking and prototyping about some improvements on the
grid <br>
> servers/protocols.<br>
><br>
> One of my aims is to try to separate the network code more from
the <br>
> logic code. So am thinking of what I'm calling a Channel and
servlet <br>
> system.<br>
><br>
> A servlet is just a class that performs some service. I'm thinking
<br>
> more in terms of breaking up the current servers into smaller <br>
> services/servlets.<br>
><br>
> So then we have a collection of servlets that do the various
functions <br>
> that the current servers do (except I'm not including the asset
server <br>
> in this as think that is best kept to a proper REST resource based
<br>
> system).<br>
><br>
> Then we come to the channel, maybe this is a bad term for what I'm
<br>
> thinking, but anyway. The channel has two (or three) parts, the <br>
> sender/receivers, which are responsible for the <br>
> serialising/deserialising of the messages/datagrams, and also of <br>
> sending it to the correct url. To find the url that a message
should <br>
> be sent to, the other part of the channel is responsible. I'm <br>
> currently thinking of this as a basic central hash table service,
that <br>
> just keeps track of the servlets that are registered on that
channel <br>
> and the url of the endpoint that they are one. Of course the idea
with <br>
> the channel is to keep the code separate from the service logic,
so <br>
> how the servlet tracking is done is up to the implementation.<br>
><br>
> While each servlet could actually have its own endpoint/channel <br>
> receiver, I'm thinking more of a collection of them sharing a <br>
> endpoint. So normally maybe only one endpoint per server instance.<br>
><br>
> So all a channel really is: Is a managed collection of known
services <br>
> and the url they can be reached at. Plus the code for
de/serialising <br>
> the messages in the format that channel uses.<br>
><br>
> The third component is the Router service. Each server instance
would <br>
> have one of these, that is tasked with routing the messages to and
<br>
> from the channel endpoint to the correct servlet. A router could
be <br>
> connected to more than one channel.<br>
><br>
> Again a basic concept. The task is just to keep track of servlets
in <br>
> that instance, to know what channels they should be receiving
messages <br>
> from. To be able to route a message from a servlet to a channel; <br>
> either a particular channel, or the servlet might just say any
channel <br>
> that has a particular type of service registered on it. Also the <br>
> router should be able to do internal routing...from one servlet to
<br>
> another that is in the same instance.<br>
><br>
><br>
> I'm also thinking that the region servers will have such a router
and <br>
> be registered on a channel(s). And then region modules could send
and <br>
> receive messages the same way.<br>
><br>
> My thoughts and actually my requirements for some other ideas. Is
to <br>
> have a dynamic modular system. That keeps the network code
completely <br>
> separate from the services logic. I really think that the current <br>
> servers are too err monolithic and really group together a bunch
of <br>
> services that are separate. I don't mean they should always be on <br>
> separate servers, just the code should be separated more and more <br>
> modular.<br>
><br>
> So my thoughts are lots of smaller services/servlets. And once we
do <br>
> that, it could lead to lots of url having to be kept track of by
each <br>
> other servlet if we used the current approach. So thats why I
think <br>
> the network code , including url management/tracking should be <br>
> completely separate.<br>
> This also I think/hope could help with scaling things. In that as
the <br>
> servlets can be grouped together as needed (and even moved around
the <br>
> server instances). Then a very small grid might only want to run
one <br>
> backend server instance that had all the servlets that it needs <br>
> running. While a much larger grid might have a server instance for
<br>
> each servlet, and maybe more than one servlet of each type running.<br>
><br>
> Also its possible that we could use the same servlets in
standalone <br>
> mode, as they would just use the internal routing function of the <br>
> routing service.<br>
><br>
> Another benefit is it helps to make the whole thing more
customizable. <br>
> In a number of different ways. One of those ways is something that
<br>
> I've done some prototyping of. Which is as the servlets and router
<br>
> classes have no network code in at all. Its a simple task to write
<br>
> different versions of the channel receivers/senders for say a
ASP.net <br>
> implementation.<br>
><br>
> There are still a number of things that need more thought. But
thats a <br>
> general overview of my ideas<br>
><br>
><br>
>
------------------------------------------------------------------------<br>
> Yahoo! for Good helps you make a difference <br>
> <http: mailuk="" taglines="" isp="" control="" *http:=""
us.rd.yahoo.com="" evt="51947/*http://uk.promotions.yahoo.com/forgood/">
<br>
><br>
>
------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
> <br>
<br>
<br>
-- <br>
dr dirk husemann, mathmatics and computer science, ibm zurich research
lab<br>
SL: dr scofield ---- <a class="moz-txt-link-abbreviated" href="mailto:drscofield@xyzzyxyzzy.net">drscofield@xyzzyxyzzy.net</a> ----
<a class="moz-txt-link-freetext" href="http://xyzzyxyzzy.net/">http://xyzzyxyzzy.net/</a><br>
RL: <a class="moz-txt-link-abbreviated" href="mailto:hud@zurich.ibm.com">hud@zurich.ibm.com</a> - +41 44 724 8573 -
<a class="moz-txt-link-freetext" href="http://www.zurich.ibm.com/~hud/">http://www.zurich.ibm.com/~hud/</a><br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</http:></blockquote>
<br>
<p> </p>
<hr size="1"> Yahoo! for Good helps you <a moz-do-not-send="true"
href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=51947/*http://uk.promotions.yahoo.com/forgood/">make
a difference</a>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="80">--
dr dirk husemann, mathmatics and computer science, ibm zurich research lab
SL: dr scofield ---- <a class="moz-txt-link-abbreviated" href="mailto:drscofield@xyzzyxyzzy.net">drscofield@xyzzyxyzzy.net</a> ---- <a class="moz-txt-link-freetext" href="http://xyzzyxyzzy.net/">http://xyzzyxyzzy.net/</a>
RL: <a class="moz-txt-link-abbreviated" href="mailto:hud@zurich.ibm.com">hud@zurich.ibm.com</a> - +41 44 724 8573 - <a class="moz-txt-link-freetext" href="http://www.zurich.ibm.com/~hud/">http://www.zurich.ibm.com/~hud/</a>
</pre>
</body>
</html>