[Opensim-dev] OGS 2 (or maybe 1.5) thoughts
Brian Wolfe
brianw at terrabox.com
Fri Apr 4 16:32:46 UTC 2008
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 <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
More information about the Opensim-dev
mailing list