[Opensim-dev] OGS 2 (or maybe 1.5) thoughts

Fri Apr 4 12:19:07 UTC 2008

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080404/c02fbcf8/attachment-0001.html>