Ive written a j2se app, (invoked via commandline) and communicates w/ network systems via a standard tcp/ip -based protocol (this app is the tcp client). it runs as daemon and waits for external communication, so it has to run all the the time.
this approach is good enough for few instances but as the need to run multiple instances (30+) invoking different configurations (ip, port, protocol requirement, etc), approach is obviously not ideal anymore. (invoking 30+ instances of jvm, not to mention, monitoring, and maintenance). So im looking at moving the application inside a jee app server. i have no prior experience w/ jee and having difficulty redesigning the application to comply w/ jee apis.
ejb can be a candidate but based from my readings, it will need a client to be invoked. i can have a servlet/jsp do the initialization, what type of ejb will i need. session beans i think is obvious but an instance of session bean doesn't survive past the servlet/jsp session (am i correct?). i need to have the ejb run like a daemon. so w/in the jee app, at any given time, 30+ instances of the same ejb should be running and i can check the status/control of each ejb through its interfaces. is this possible? i cant have sets of ejb clients running outside the jee server as this violates my purpose of running everything inside jee.
First off, EJB is an API for handling data that's stored in a database; since you don't mention that at all, I doubt that EJBs are going to be helpful. Also, Servlets/JSPs provide a web interface for an application; if this is a daemon then they won't be of much use.
Unless any JEE APIs are actually needed, it sounds like the right thing to do would be to refactor the code to be able to run multiple clients (each with different configurations) from within the same application. Java has excellent threading support that makes this easy.
This is unfortunately a lengthy discussion. EJB was indeed originally designed for distributed, scalable server processing. However, EJB is limited to triggering via a synchronous call via RMI or CORBA from a remote client or via an asynchronous JMS message. EJB 3 also adds SOAP as a transport protocol.
EJB has no direct support for raw TCP/IP communication or long running processes. However, what you can do is use a bridging solution (such as an ESB) to convert incoming TCP/IP packets to JMS messages and vice-versa. I've done something very similar to process messages from a legacy system.
Could that work for you?
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
If you settle for what they are giving you, you deserve what you get. Fight for this tiny ad!
Devious Experiments for a Truly Passive Greenhouse!