-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank,
印华 wrote: | In my design, I | [have divided] the server side into several separate logic parts, and each | part is deployed on a separate Tomcat server. e.g. the first tomcat | server is to process login request, second tomcat server is to | calculate user data, the third tomcat server is to store all the user | information. It is a [distributed] architecture, and I hope in this way, | this system can be extended by adding tomcat server when the | application load on one Tomcat server is big enough. I'm not sure you need all that complexity... most people just run the whole application on a single server. When the load gets too high for one server, you duplicate the web app onto a second server (and so on) and then load balance between them. There's no reason to have physically separated login, calculation, and data storage mechanisms. | So currently, I meet a problem of how to | communicate between the tomcat servers, I think http or webservice | can do this work simply, but the efficiency is not good, and I don't | know whether JMS is a good choice for this. JSM isn't really any better or worse than SOAP, REST, or other "standard" forms of communication. | I wonder if there is any | other way to communicate between the tomcat server? Servers can communicate in lots of ways: 1. Records through a database 2. Binary or text data through a socket 3. Binary or text data through a named pipe (on a shared filesystem) 4. Objects through JNDI 5. Objects through RMI | Any help and suggestion will be welcome. Honestly, the best thing to do would be to put everything into a single web app and just load balance between (identical) Tomcat servers. I don't see any advantage of the separation you have created. If you need sessions to be replicated in a cluster, you can simply turn on "distributable" sessions and configure the Tomcat instances to participate in the cluster. If you can tolerate the loss of information resulting from a Tomcat instance going down while a user is logged-in, then you don't even have to do that. Less complexity results in easier maintenance. Hardware is cheap. Manpower is expensive. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkePj6kACgkQ9CaO5/Lv0PCp8QCgirMzuuO3iuUgh0Ql3tZZ7qUZ tEYAmgMFDz227mn6yf/wYQsITodDJIVU =93Cr -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
