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

Fri Apr 4 21:50:36 UTC 2008

http://activemq.apache.org/nms/ndoc/NMS.html

This seems relevant to the discussions here

Jonc


On 04/04/2008, Michael Wright <michaelwri22 at yahoo.co.uk> wrote:
> yup you got it. I guess I did a really bad job of explaining what I meant.
> So I guess sometime I'll just commit some sample code. I'm not really
> thinking of anything complex (at least for now), just a way to separate all
> the network code from the rest of the code. So the "channel" is tasked with
> getting a message from one point to another, and as you said the calling
> code doesn't care how it does it.
>
> Brian Wolfe <brianw at terrabox.com> wrote:
>  AH, I think I get it now. :)
> Self defining transport interfaces.
>
>  a service makes a call into the interface class, which then reads the
> configuration from the "channel" and the channel deals with creating
> whatever link level connection, encoding, and talking over that
> "channel". The supplier/consumer that is talking to the interface
> doesn't care if it goes over avian, udp, tcp, or http, or postal
> service. All it cares is that it posts and get's an answer back.
>
> Am I even close here?
>
> On Fri, 2008-04-04 at 13:19 +0100, 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.
> >
> >
> > Dr Scofield 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
>
> _______________________________________________
> 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
>
>