From: "Tuncay Baskan (�nternet Grubu)" <[EMAIL PROTECTED]> Sent: Wednesday, October 16, 2002 9:23 AM
[snip] 1,500,000 transactions per day is ~60 trans/sec for an 8 hour day, just FYI. It certainly sounds like a lot of transactions, but isn't necessarily a lot of transactions, though response time can be a factor. > Servers will operate the business logic; is message consistent, is it a > debit or credit, has owner enough credit, what type of smart card is used, > etc etc. At this point I was thinking an application server can do it well > enough (scaling for incoming connections, database connection pooling, > managibility, etc.) But, as far as i know incoming connections are not HTTP. > > So, is it logical to use an application server to implement those "business > logic units"? I think we need to implement, say POSServlet classes from > generic Servlet interface. Has anyone seen or developed something like this > before? Or is it better to implement servers with ServerSockets? I don't > like the latter because imo, we need to "reinvent" a lot of things. Well, the basic answer is "yes", you need an application server of SOMEKIND, but most certainly not an HTTP application server. However, you can certainly use Tomcat as a basic foundation for your server, though it will be parts fairly deep into the core. While the servlet spec makes passing mention about it being "protocol agnostic", it really is an HTTP specification. However, Tomcat was built more generically than that (at least Tomcat 4). Tomcat manages its Servers, Connectors, and Engines. What is not clear, is how much of HTTP is in those components, though ideally it's all in the Connectors. So, in essence to pull off your project, you'd need to "simply" write your own Connector, and, maybe, an Engine. If your custom Connector can make the abstractions properly, you might be able to use the stock Servlet engine, even though you're not really doing HTTP. By leveraging Tomcat, though, you should pick up "for free" the connection pooling, JNDI stuff, an infrastructure to handle the socket connections, any session information, etc. (Actually, looking at the code, it appears that the Connectors do all of the socket infrastructure individually...I find that odd, but whatever). I certainly think that it's worth spending a couple of days looking over your requirements and perhaps hacking up some prototype Connectors and/or Engines. The biggest issue is that, of course, 99% of the work on Tomcat has been focused on the HTTP parts, rather than, necessarily, the GenericServlet parts, so some of this may be relatively unexplored territory, or if not unexplored, at least lightly traveled. Regards, Will Hartung ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
