No subject
Sat Apr 19 02:14:48 UTC 2014
I think a number of people were thinking I meant something a lot more complex than I do (at least to start with)
So as soon as I get time I'm going to try to write a more clear in depth email. Just that won't be for a few days or more.
But yeah basically as you said end to end funnels with servlets attaching to the ends.
Dr Scofield <DrScofield at xyzzyxyzzy.net> wrote: Michael Wright wrote: 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.
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.
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.
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?
cheers,
dr scofield?
Dr Scofield <DrScofield at xyzzyxyzzy.net> wrote: interesting thoughts. question: would a channel be something like a
network bus?
cheers
dr scofield
Michael Wright wrote:
> I'm been thinking and prototyping about some improvements on the grid
> servers/protocols.
>
> One of my aims is to try to separate the network code more from the
> logic code. So am thinking of what I'm calling a Channel and servlet
> system.
>
> A servlet is just a class that performs some service. I'm thinking
> more in terms of breaking up the current servers into smaller
> services/servlets.
>
> So then we have a collection of servlets that do the various functions
> that the current servers do (except I'm not including the asset server
> in this as think that is best kept to a proper REST resource based
> system).
>
> Then we come to the channel, maybe this is a bad term for what I'm
> thinking, but anyway. The channel has two (or three) parts, the
> sender/receivers, which are responsible for the
> serialising/deserialising of the messages/datagrams, and also of
> sending it to the correct url. To find the url that a message should
> be sent to, the other part of the channel is responsible. I'm
> currently thinking of this as a basic central hash table service, that
> just keeps track of the servlets that are registered on that channel
> and the url of the endpoint that they are one. Of course the idea with
> the channel is to keep the code separate from the service logic, so
> how the servlet tracking is done is up to the implementation.
>
> While each servlet could actually have its own endpoint/channel
> receiver, I'm thinking more of a collection of them sharing a
> endpoint. So normally maybe only one endpoint per server instance.
>
> So all a channel really is: Is a managed collection of known services
> and the url they can be reached at. Plus the code for de/serialising
> the messages in the format that channel uses.
>
> The third component is the Router service. Each server instance would
> have one of these, that is tasked with routing the messages to and
> from the channel endpoint to the correct servlet. A router could be
> connected to more than one channel.
>
> Again a basic concept. The task is just to keep track of servlets in
> that instance, to know what channels they should be receiving messages
> from. To be able to route a message from a servlet to a channel;
> either a particular channel, or the servlet might just say any channel
> that has a particular type of service registered on it. Also the
> router should be able to do internal routing...from one servlet to
> another that is in the same instance.
>
>
> I'm also thinking that the region servers will have such a router and
> be registered on a channel(s). And then region modules could send and
> receive messages the same way.
>
> My thoughts and actually my requirements for some other ideas. Is to
> have a dynamic modular system. That keeps the network code completely
> separate from the services logic. I really think that the current
> servers are too err monolithic and really group together a bunch of
> services that are separate. I don't mean they should always be on
> separate servers, just the code should be separated more and more
> modular.
>
> So my thoughts are lots of smaller services/servlets. And once we do
> that, it could lead to lots of url having to be kept track of by each
> other servlet if we used the current approach. So thats why I think
> the network code , including url management/tracking should be
> completely separate.
> This also I think/hope could help with scaling things. In that as the
> servlets can be grouped together as needed (and even moved around the
> server instances). Then a very small grid might only want to run one
> backend server instance that had all the servlets that it needs
> running. While a much larger grid might have a server instance for
> each servlet, and maybe more than one servlet of each type running.
>
> Also its possible that we could use the same servlets in standalone
> mode, as they would just use the internal routing function of the
> routing service.
>
> Another benefit is it helps to make the whole thing more customizable.
> In a number of different ways. One of those ways is something that
> I've done some prototyping of. Which is as the servlets and router
> classes have no network code in at all. Its a simple task to write
> different versions of the channel receivers/senders for say a ASP.net
> implementation.
>
> There are still a number of things that need more thought. But thats a
> general overview of my ideas
>
>
> ------------------------------------------------------------------------
> Yahoo! for Good helps you make a difference
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
--
dr dirk husemann, mathmatics and computer science, ibm zurich research lab
SL: dr scofield ---- drscofield at xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/
RL: hud at zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
---------------------------------
Yahoo! for Good helps you make a difference
---------------------------------
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
dr dirk husemann, mathmatics and computer science, ibm zurich research lab
SL: dr scofield ---- drscofield at xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/
RL: hud at zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
---------------------------------
Yahoo! for Good helps you make a difference
--0-1037203-1207604039=:17696
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
More information about the Opensim-dev
mailing list