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.<br><br><b><i>jon cundill <jcundill@gmail.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> http://activemq.apache.org/nms/ndoc/NMS.html<br><br>This seems relevant to the discussions here<br><br>Jonc<br><br><br><br>On 04/04/2008, Michael Wright <michaelwri22@yahoo.co.uk> wrote:<br>> yup you got it. I guess I did a really bad job of explaining what I meant.<br>> So I guess sometime I'll just commit some sample code. I'm not really<br>> thinking of anything complex (at least for now), just a way to separate all<br>> the network code from the rest of the code. So the "channel" is tasked with<br>>
getting a message from one point to another, and as you said the calling<br>> code doesn't care how it does it.<br>><br>> Brian Wolfe <brianw@terrabox.com> wrote:<br>> AH, I think I get it now. :)<br>> Self defining transport interfaces.<br>><br>> a service makes a call into the interface class, which then reads the<br>> configuration from the "channel" and the channel deals with creating<br>> whatever link level connection, encoding, and talking over that<br>> "channel". The supplier/consumer that is talking to the interface<br>> doesn't care if it goes over avian, udp, tcp, or http, or postal<br>> service. All it cares is that it posts and get's an answer back.<br>><br>> Am I even close here?<br>><br>> On Fri, 2008-04-04 at 13:19 +0100, Michael Wright wrote:<br>> > I guess in some ways it could be thought as a network bus, but I<br>> > wasn't thinking of the messages being broadcast on the channel,
where<br>> > all endpoints had to listen to all messages and pick out the ones for<br>> > them. I was thinking, if anything, of more like a cut down web<br>> > services protocol stack.<br>> ><br>> > My prototype channel is just a basic HTTP based one. That just finds<br>> > where the url of the channel receiver, that the required servlet is<br>> > currently registered at, is. Then does a HTTP POST of the serialised<br>> > message to that url.<br>> ><br>> > But the implementation should be up to the channels. All the rest of<br>> > the system should care is that a channel can pass messages from one<br>> > end point to another, and can map some standard addressing scheme to<br>> > those endpoints. Allowing for a dynamic system, where the addressable<br>> > message receivers (the servlets) can move around the endpoints on a<br>> > channel as needed. And new endpoints can be
added.<br>> ><br>> ><br>> > Dr Scofield wrote:<br>> > interesting thoughts. question: would a channel be something<br>> > like a<br>> > network bus?<br>> ><br>> > cheers<br>> > dr scofield<br>> ><br>> > Michael Wright wrote:<br>> > > I'm been thinking and prototyping about some improvements on<br>> > the grid<br>> > > servers/protocols.<br>> > ><br>> > > One of my aims is to try to separate the network code more<br>> > from the<br>> > > logic code. So am thinking of what I'm calling a Channel and<br>> > servlet<br>> > > system.<br>> > ><br>> > > A servlet is just a class that performs some service. I'm<br>> > thinking<br>> > > more in terms of breaking up the current servers into<br>> > smaller<br>> > > services/servlets.<br>> > ><br>> > > So then we have a collection of
servlets that do the various<br>> > functions<br>> > > that the current servers do (except I'm not including the<br>> > asset server<br>> > > in this as think that is best kept to a proper REST resource<br>> > based<br>> > > system).<br>> > ><br>> > > Then we come to the channel, maybe this is a bad term for<br>> > what I'm<br>> > > thinking, but anyway. The channel has two (or three) parts,<br>> > the<br>> > > sender/receivers, which are responsible for the<br>> > > serialising/deserialising of the messages/datagrams, and<br>> > also of<br>> > > sending it to the correct url. To find the url that a<br>> > message should<br>> > > be sent to, the other part of the channel is responsible.<br>> > I'm<br>> > > currently thinking of this as a basic central hash table<br>> > service, that<br>> > > just keeps track of
the servlets that are registered on that<br>> > channel<br>> > > and the url of the endpoint that they are one. Of course the<br>> > idea with<br>> > > the channel is to keep the code separate from the service<br>> > logic, so<br>> > > how the servlet tracking is done is up to the<br>> > implementation.<br>> > ><br>> > > While each servlet could actually have its own<br>> > endpoint/channel<br>> > > receiver, I'm thinking more of a collection of them sharing<br>> > a<br>> > > endpoint. So normally maybe only one endpoint per server<br>> > instance.<br>> > ><br>> > > So all a channel really is: Is a managed collection of known<br>> > services<br>> > > and the url they can be reached at. Plus the code for<br>> > de/serialising<br>> > > the messages in the format that channel uses.<br>> > ><br>> > > The
third component is the Router service. Each server<br>> > instance would<br>> > > have one of these, that is tasked with routing the messages<br>> > to and<br>> > > from the channel endpoint to the correct servlet. A router<br>> > could be<br>> > > connected to more than one channel.<br>> > ><br>> > > Again a basic concept. The task is just to keep track of<br>> > servlets in<br>> > > that instance, to know what channels they should be<br>> > receiving messages<br>> > > from. To be able to route a message from a servlet to a<br>> > channel;<br>> > > either a particular channel, or the servlet might just say<br>> > any channel<br>> > > that has a particular type of service registered on it. Also<br>> > the<br>> > > router should be able to do internal routing...from one<br>> > servlet to<br>> > > another that is in the same
instance.<br>> > ><br>> > ><br>> > > I'm also thinking that the region servers will have such a<br>> > router and<br>> > > be registered on a channel(s). And then region modules could<br>> > send and<br>> > > receive messages the same way.<br>> > ><br>> > > My thoughts and actually my requirements for some other<br>> > ideas. Is to<br>> > > have a dynamic modular system. That keeps the network code<br>> > completely<br>> > > separate from the services logic. I really think that the<br>> > current<br>> > > servers are too err monolithic and really group together a<br>> > bunch of<br>> > > services that are separate. I don't mean they should always<br>> > be on<br>> > > separate servers, just the code should be separated more and<br>> > more<br>> > > modular.<br>> > ><br>> > > So my thoughts are
lots of smaller services/servlets. And<br>> > once we do<br>> > > that, it could lead to lots of url having to be kept track<br>> > of by each<br>> > > other servlet if we used the current approach. So thats why<br>> > I think<br>> > > the network code , including url management/tracking should<br>> > be<br>> > > completely separate.<br>> > > This also I think/hope could help with scaling things. In<br>> > that as the<br>> > > servlets can be grouped together as needed (and even moved<br>> > around the<br>> > > server instances). Then a very small grid might only want to<br>> > run one<br>> > > backend server instance that had all the servlets that it<br>> > needs<br>> > > running. While a much larger grid might have a server<br>> > instance for<br>> > > each servlet, and maybe more than one servlet of each type<br>> >
running.<br>> > ><br>> > > Also its possible that we could use the same servlets in<br>> > standalone<br>> > > mode, as they would just use the internal routing function<br>> > of the<br>> > > routing service.<br>> > ><br>> > > Another benefit is it helps to make the whole thing more<br>> > customizable.<br>> > > In a number of different ways. One of those ways is<br>> > something that<br>> > > I've done some prototyping of. Which is as the servlets and<br>> > router<br>> > > classes have no network code in at all. Its a simple task to<br>> > write<br>> > > different versions of the channel receivers/senders for say<br>> > a ASP.net<br>> > > implementation.<br>> > ><br>> > > There are still a number of things that need more thought.<br>> > But thats a<br>> > > general overview of my ideas<br>> >
><br>> > ><br>> > ><br>> ><br>> ------------------------------------------------------------------------<br>> > > Yahoo! for Good helps you make a difference<br>> > ><br>> > ><br>> > ><br>> ><br>> ------------------------------------------------------------------------<br>> > ><br>> > > _______________________________________________<br>> > > Opensim-dev mailing list<br>> > > Opensim-dev@lists.berlios.de<br>> > > https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> > ><br>> ><br>> ><br>> > --<br>> > dr dirk husemann, mathmatics and computer science, ibm zurich<br>> > research lab<br>> > SL: dr scofield ---- drscofield@xyzzyxyzzy.net ----<br>> > http://xyzzyxyzzy.net/<br>> > RL: hud@zurich.ibm.com - +41 44 724 8573 -<br>> > http://www.zurich.ibm.com/~hud/<br>> ><br>> >
_______________________________________________<br>> > Opensim-dev mailing list<br>> > Opensim-dev@lists.berlios.de<br>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> ><br>> ><br>> ><br>> ><br>> ><br>> ______________________________________________________________________<br>> > Yahoo! for Good helps you make a difference<br>> > _______________________________________________<br>> > Opensim-dev mailing list<br>> > Opensim-dev@lists.berlios.de<br>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<br>><br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>><br>><br>><br>> ________________________________<br>> Yahoo! for Good helps you make a difference<br>><br>><br>>
_______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>><br>><br>_______________________________________________<br>Opensim-dev mailing list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></brianw@terrabox.com></michaelwri22@yahoo.co.uk></blockquote><br><p>
<hr size=1>
Yahoo! for Good helps you <a href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=51947/*http://uk.promotions.yahoo.com/forgood/">make a difference</a>