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

Fri Apr 4 22:02:27 UTC 2008

http://activemq.apache.org/cross-language-clients.html

jonc

On 04/04/2008, Michael Wright <michaelwri22 at yahoo.co.uk> wrote:
> while I haven't closely looked at the .net message api, I was trying to
> avoid anything that could tie it to .net. I think we have seen that people
> will want to write implementations of the grid servers in other languages.
> So I was thinking just a very lightweight generic system.
>
> jon cundill <jcundill at gmail.com> wrote:
>  http://activemq.apache.org/nms/ndoc/NMS.html
>
> This seems relevant to the discussions here
>
> Jonc
>
>
>
> On 04/04/2008, Michael Wright 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 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
> >
> >
> _______________________________________________
> 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
>
>