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. <br><br><b><i>Brian Wolfe <brianw@terrabox.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> 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 <DrScofield@xyzzyxyzzy.net> 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>> > Yahoo! for Good helps
you make a difference <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>> 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></DrScofield@xyzzyxyzzy.net></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>