Hi Tuncay, If I understand your task correctly, you need to develop a system that has no graphical user interface (The point of sale machines take care of that) but it needs to conduct transactions between those POS systems and the database.
That is more or less what J2EE and Enterprise Java Beans were designed for. You would need to write EJB's to communicate with your POS systems in whatever format they use. Those could convert the transactions to XML and pass it on from there to other EJB's to process the data. You can write and/or buy EJB's to perform your business logic and drop them in the app server for deployment. If you use one of the commercial app servers (Webgain from BEA and WebSphere from IBM are the two biggest sellers right now) and even some of the Open Source ones you get all the enterprise level stuff (load balancing, failover, etc., etc.) that you need. With J2EE a big advantage is that you are not locked into any particular hardware/OS. Most of the big commercial J2EE app servers run on Sun, HP, IBM, Linux, and others. The pure Java ones will theoretically run on anything with a Java VM. So if you change brands of server, you just put your app server on the new one and deploy your apps without changing them (theoretically). Rick ----- Original Message ----- From: "Tuncay Baskan (Ưnternet Grubu)" <[EMAIL PROTECTED]> To: "Tomcat Users List (E-mail)" <[EMAIL PROTECTED]> Sent: Wednesday, October 16, 2002 12:23 PM Subject: Is an application server suitable? > Hello all, > > Briefly, my question is not specific to Tomcat. I'm looking for answers > generally related with application servers, and tomcat user list is one > place really experienced and nice people exist. > > Here it goes... > > We are at the first steps of a big (well, for us it is big) project. On our > part, there will be a database server (probably Oracle or DB/2) which > probably will have to be capable of handling more than 1,500,000 > transactions per day coming from POS machines all around the country. > Current infrastructure is based on mainframes and they are expensive to > maintain as you know. > > We won't be dealing with X25 to TCP/IP or other low level POS related > networking things. Those are considered as "outside world" for us. Here is a > text diagram showing what we think for now: > > | > | +----------+ +----------+ > | | Server 1 | <----> | | > | +----------+ | | > | . | | > POS | +----------+ | Database | Report > machines | | Server 2 | <----> | Server | <-- stuff > (X.25) | +----------+ | | (internal) > | . | | > | . | | > | +----------+ | | > | | Server N | <----> | | > | +----------+ +----------+ > | > > 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. > > I hope I explained the case well. I'm waiting for advices. > > Best regards. > > /tb. > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
