We had a systems architect design our system and after he left, we found numerous design flaws and are now re-visting the design. First let me describe a little about our application. We are using or planning to use Apache, JRun, Oracle, and SonicMQ.
Our client application is a Java app. We receive orders from the client, do some business processing/write to db and need to send the order message to an external client to get filled and receive the report back. We need to open a persistent TCP/IP socket connection to the external client. They only allocate 1 IP and 1 port for us to connect with. I beleive we can't use connection pooling because they only allocate 1 port for us to use.
We need to establish the socket connection to the external Server at startup and have the same connection available to us when sending any and all orders. We don't want to shutdown and startup the connection everytime we have to send a message. Any moment of time we can have up to 1000 messages/orders generated per second.
This whole system was designed using Servlets and Servlets chaining. Now we are finding that was the wrong approach and the architect might not have understood our business requirements.
Am I understanding this correctly and going in the right direction when I think that we should be using an EJB instead of a Servlet. Is the only way to have a persistent TCP/IP socket connection is through an EJB and not Servlets ?
I just wanted to get some opinions from people because I don't want to make another mistake and choose the wrong technology. Any input in the design would be greatly appreciated.
Thanks in advance for your help.
EJB specs prohibit you from using SOcket Connecitons in EJB
First of all, are you sure you can only make one connection at a time? Every HTTP server allocates a single port for it's clients to use (80), but it can handle thousands of concurrent connections.
Regarding your question, it is hard to say which technology is better for you. EJB can be an overkill in many cases. Only you can estimate how big this system will get. If it'll allways remain small-to-medium, EJB is probably an overkill.
If you do choose to use EJB, there is a small problem. EJB does not prohibit the use of Sockets as stated in a post above (it only prohibits listening to/accepting connections and using multicast sockets). However, if you really want to have only one open connection at all times, you will have portabillity problems if you try to use the obvious approach of holding it in a static variable. Your application's scallability will be limited because you will only be able to use one App server instance (no fault tolerance, no load balancing). This, for me, is allmost reason enogth not to use EJB at all. Even if you only use one App server instance, your code will still have portabillity issues, because some App servers may choose to load several VMs (and each will have it's own static variable, and it's own connection). Some App servers may also choose to load the same class several times (in different protection domains), again leading to multiple connctions.
One portable solution would be to write a small TCP/IP server program that can accept multiple connections and serialize them to a single connection. This kind of solution is very weak in terms of scallability.
All these problems can be solved if you can make multiple socket conections...
Good luck anyway
My understanding is that EJBs are prohibited to be Socket Server but EJBs can be Socket Clients. Can EJBs open a socket and send come commands to devices?
Yes, EJBs can act as socket clients. As I mentioned above, only listening to ports, accepting socket connections, and using multicast are prohibited. Every RMI call you make makes use of a TCP connection, so it wouldn't make much sense to prohibit it.
I stand corrected
You can certainly keep a socket connection open from a servlet engine.
What is your actual problem?