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

Fri Apr 4 22:07:39 UTC 2008

async fire and forget

http://activemq.apache.org/nms/ndoc/ActiveMQ.Connection.OneWay.html

synchronous

http://activemq.apache.org/nms/ndoc/ActiveMQ.Connection.SyncRequest.html

response set async as new message is just a Queue with a correlation
id perhaps in the message header

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

Jon


On 04/04/2008, Michael Wright <michaelwri22 at yahoo.co.uk> wrote:
> yup, I was thinking that there would be various call types. Some would want
> a response, some wouldn't of course, and some would want a response but it
> to be sent back as new message (so the calling service could continue on
> with whatever, and would just need to be registered to accept the return
> message types from the router service. )
>
> Brian Wolfe <brianw at terrabox.com> wrote:
>  It's a good way of cleanly seperating logic from location. The only
> thing that you have to beware though is latecy of the calls. Some may
> need to have a callback in order to return the calling thread control
> until an answer can come back. ;-P
>
>
>
> On Fri, 2008-04-04 at 18:09 +0100, 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
>
>
>
>  ________________________________
>  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
>
>