Integration of Java server application into Application Server like TomCat, GlassFish, etc_问答_开发者

I am working on a server application that does the following:

Read data from a measuring device that is being addressed via a serial interface (javax.comm, RXTX) or sockets.
Exchange data (read and write) with another server application using sockets.
Insert data from (1) and (2) into a database using JDBC.
Offer the data from steps (1) to (3) to a JavaScript-based web app.

My current prototype is a stand-alone Java application and implements task (4) by writing the data to an XML file that is being delivered to the client via a web server (Apache), but I consider this to be a hack, not a clean solution.

This server application needs to start up and work also without any web clients being present.

I would like to integrate this server application into a Java application server, but I do not have much experience with these technologies and don't know where to start. I have tried some simple examples for TomCat and GlassFish, but that did not bring me any further because they are all built around serving web requests synchronously and stop where it would be getting interesting for me.

Is this possible to run such an app within TomCat or GlassFish?
If yes, where would be a good point to start (examples, which base classes, ...)?
Would it make any sense to split the application and implement only task (4) in a servlet, the rest in an ordinary application, communication via sockets, etc.?
Would other servers, e.g JBoss, be a better choice and if yes, why?

Edit:

The reasons I want to use a Java EE container are:

I would like to have a clean extern开发者_StackOverflow中文版al interface for step (4).
On the long run, the application will need to scale to a huge number of simultaneous clients (at least several 10.000), so a want a standard way of scalability and application management.

In general, it's not a good idea to implement all of this in a servlet container such as Tomcat.

A servlet container is designed to service requests from a client. It sounds like you have a process which will be running all the time or at least periodically. You can do this in Tomcat, but it's probably easier to do it outside. Leave Tomcat to do what it's good at, servicing requests from browsers. It's happiest when the requests are short lived.

So I would do as you suggest, and only have step 4 in the container. You can easily interrogate the database populated in step 3, so there is no need to create web services to populate the servlet container.

For step 4, you will need to expose some services from Tomcat, either through rest, soap, whatever you like. The javascript clients can then interrogate these services. This is all completely doable with Tomcat.

For scalability, there shouldn't be a problem using Tomcat. If all it's doing is pumping data from the database to the client, there probably isn't a reason to choose a J2EE container. If you don't have need of complex transaction management or security, try using something open source. It sounds like you can get what you want from Tomcat (& hibernate & spring security if necessary). If you start to have performance problems, then the fix will probably be the same for JBoss & Tomcat: you need more servers.

My advice: stick to the simple open source solutions and move to an application server only if you find it to be necessary.

I would loosely couple the solution and not try to do everything on the Java EE/Servlet container as exchanging data using sockets (managed by the application itself) is not something you typically want to do from a Java EE/Servlet container.

Running this on a Java EE container might also be overkill as this doesn't sound like a typical enterprise application where stuff like security and transaction management is important and the app could benefit from services provided by the Java EE/Servlet container.