Dave, Yes, you are right! Mixing in the network layer and the app layer may not be a good idea since it is several layers on top of it. I might take a look again at Squid but the concept is to be able to have more control of the request/response cycle albeit at a cost (perhaps minimal) to performance. I tend to look at the load balancer for high availability though.
-- rick ----- Original Message ----- From: "David Leangen" <[EMAIL PROTECTED]> To: "General OPS4J" <general@lists.ops4j.org> Sent: Tuesday, September 25, 2007 12:32 AM Subject: Re: Need to deploy a gateway > > Rick, > > Cool... must be nice to have that kind of hardware. ;-) > > Won't you lose the positive effects of the load balancer though (i.e. > speed) if you talk to it with an OSGi gateway? > > I guess I don't see the benefit of mixing in OSGi with that kind of > network function, which I see as a layer beneath OSGi. Unless, of > course, you're just talking about configuration of the device. > > > Cheers, > Dave > > > > On Tue, 2007-09-25 at 00:34 -0400, Rick Litton wrote: >> Hi Dave, >> >> My plan is to have the OSGi gateway talk to a hardware load balancer >> (thank >> goodness we have it in inventory) and so there is no need to use Squid >> and >> the like. So in a sense, the gateway will function as a proxy server and >> at >> the same time act as an interceptor to a certain extent. By doing so, it >> will just complement the load balancer in addition to performing some >> specialized functions. I'm not aware of restlet so I will certainly look >> into it. And yes, pax logging is certainly a candidate. Thanks for the >> suggestions! >> >> -- rick >> >> ----- Original Message ----- >> From: "David Leangen" <[EMAIL PROTECTED]> >> To: "General OPS4J" <general@lists.ops4j.org> >> Sent: Monday, September 24, 2007 11:49 PM >> Subject: Re: Need to deploy a gateway >> >> >> > >> > Rick, >> > >> > If it were me, if you are talking about load balancing or some other >> > kind of replication, I'd use some existing clustering framework rather >> > than building my own with OSGi. >> > >> > If you are just talking about routing based on the application, then >> > I'd >> > use a proxy (such as apache/mod_proxy or Squid) rather than trying to >> > do >> > this in OSGi. If you really want to do this in OSGi, then maybe take a >> > look at restlet, which can allow you to route requests. >> > >> > This of course would sit on your proxy server. >> > >> > >> > As for authentication, you could have one backend service that services >> > all your machines, that is if you want to avoid replication of that >> > service. >> > >> > Logging and such... well, I'd just add an instance of the pax-logging, >> > for bundle example, on each server, rather than trying to centralize >> > it. >> > >> > >> > Just my 2 cents. >> > >> > >> > >> > Good luck! >> > Dave >> > >> > >> > On Mon, 2007-09-24 at 23:49 -0400, Rick Litton wrote: >> >> Hi everyone, >> >> >> >> I apologize for the long absence from this ML since moving to a new >> >> role (job). But now I'm planning to set up an OSGi gateway as an >> >> entry point to a web portal project. The gateway will accept requests >> >> (via http) and route each request to the appropriate service handler >> >> (a clustered web server). In addition, it should also be able to >> >> handle common services such as authentication, logging, etc. and other >> >> usual OSGi service stuff. The solution must be robust enough to >> >> handle and service requests that number in the several thousands per >> >> day. My first concern is to ensure reliability by avoiding an SPF >> >> (single point of failure). Also, I'm not so sure that a single >> >> HttpService service bundle can do the job, i.e. it doesn't become a >> >> bottleneck. Since I'm in the company of great minds here at OPS4J, I >> >> would like to gather some suggestions as to how I may be able to >> >> implement an ideal solution. So please feel free to comment. Your >> >> ideas will be highly appreciated. Thanks. >> >> >> >> -- rick >> >> _______________________________________________ >> >> general mailing list >> >> general@lists.ops4j.org >> >> http://lists.ops4j.org/mailman/listinfo/general >> > >> > >> > _______________________________________________ >> > general mailing list >> > general@lists.ops4j.org >> > http://lists.ops4j.org/mailman/listinfo/general >> >> >> _______________________________________________ >> general mailing list >> general@lists.ops4j.org >> http://lists.ops4j.org/mailman/listinfo/general > > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
