----- Original Message ----- > From: Tim Judd <tjud...@yahoo.com> > To: Tomcat Users List <users@tomcat.apache.org> > Cc: > Sent: Friday, July 1, 2011 7:52 AM > Subject: Re: webapps and TCP/UDP listening sockets > > Hi Pid, all > > I'm disappointed the responses I've gotten seemingly to be scolding > messages. I > am reading up on documentation, I am reading the APIs, I am reading > everything I > > can. Think of Citrix (in Windows environments) - code is executed on the > server > > and displayed on your desktop; X11 forwarding does the same thing. I don't > know > which machine is executing the code > > I understand you guys are trying to help, but I am disappointed all I'm > hearing > is "you're doing it wrong" basically. I was hoping a quick answer > to know which > machine is executing the code which would be the same side that has it bound. > > > Does anyone know which machine will bind?
I don't think anyone is trying to scold you as such. Some people may be wondering why Tomcat is involved with this is all. That being said, I've written a rather lengthy response to your question. OK, I hope it's a proper response. The first part covers (briefly) running a network server under Tomcat. The second part covers an idea (alternative approach) that would actually leverage Tomcat's capabilities. I hope this is useful. Hopefully this is not off the mark. Here's my understanding of the problem and your solution. 1. Deploy a client-server CRM software package 2. CRM has both point to point and broadcast requirements 3. Centrally deployed server 4. Potentially load-balanced farm of servers You have tentatively decided on approaching requirement 2 with a custom UDP and multicast protocol. You are asking if you can leverage Tomcat (or maybe another servlet container) to help with communications, deployment, and resiliency of your solution. The short answer is probably not, not without a lot of work. I think the best that you're going to achieve with Tomcat is something like what Derby does with its derby.war implementation. Apache Derby comes with a war file that allows you to run a networked derby database from within Tomcat. This war file provides a command / control / monitoring interface for the Derby database. This interface is accessible through Tomcat. However, Tomcat does not provide the network connection for the actual database and its clients. This is provided by the network Derby server, which listens on TCP port 1527 (by default). The database communication is under complete control of the Derby network server, and does not use Tomcat resources. You can accomplish this for your system. You should look at the source code for the derby.war file to see how the command / control / monitoring interface is built. However, I don't think this is all that you want to accomplish. Now we get to the architecture of your system. If you wish to leverage Tomcat's resources, then there are several ways of going about it. Talking off the top of my head, here are some ideas. 1. Use Tomcat 7.0.x This will allow you to use asynchronous servlets. Coupled with AJAX, you can then broadcast messages to all waiting clients. With Tomcat 6.0.x, there was a container-specific way of accomplishing this (with Comet). 2. Use AJAX or AJAX / JSON for normal data communications This is independent of what server you use (could be Tomcat, Apache HTTPD, IIS, etc.) or language (Java, Perl, PHP, C#, etc.). This will make your application more "lively". There are security considerations when doing this, so please research carefully. 3. Desktop application There's no reason why a platform communicating via HTTP has to be a web browser. You could write a client in JavaFX (for example) to interact with the server portion of your application. In order to go this route (Tomcat, HTTP, asynchronous servlets, AJAX, JSON), you will have to do some research. Before diving into the servlet 3.0 specifications and asynchronous servlets, I recommend getting your feet wet with some basic concepts. A good book for doing that is: Head First Servlets and JSP There's also an AJAX book in the same vein. Head Rush Ajax Neither of these books serve as complete references, but they do introduce you to the concepts necessary for building what I think you're trying to accomplish. Once you've wrapped your head around the concepts in these books, then you would benefit from reading the servlet specification (sounds like 3.0 will fit your requirements as I understand them). You'll probably want to have your application interact with a database as well. In that case, Hibernate may be a good fit. There are several books on that, as well as a Tomcat Wiki article on how to get Hibernate to work with Tomcat's database pooling mechanism. Hopefully, this has been useful. I apologize if I'm completely off base here. . . . . just my two cents. /mde/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
