On EJB Restrictions - Can You Open a Socket?
During job interviews, one of the frequent questions is
“What restrictions are imposed on EJBs?”.
I had a chat recently with someone about it, and we still don’t agree on the answer.
He believes we can’t open sockets, while I believe it is perfectly allowed, if you don’t retain the socket connection between method calls. His arguments are based on an analogy with files. After all in Linux, files are sockets. Here are his interpretations on a document about EJB restrictions on java.sun.com:
- Passivation affects server sockets. Why client sockets are not affected by passivation is not mentioned. I suspect that given that the socket mechanism is the same in both cases (IP packets), there should be no difference.
- EJBs are not allowed to access files because files are not transactional. Well, it is my understanding that sockets are neither.
- Deployability. The file open in one JVM will not necessarily be open in another JVM. It is my understanding that the same will happen on sockets.
Now here is my reply:
The reference I mentioned says you can not open server sockets, because to use them, you would have to let them open between methods calls, otherwise you can’t do anything with your server socket. Passivation will only happen after or before a method call, not in the middle. Good point, rollback seems hard with sockets. The real problem with files and deployability is about clustering. I quote the same source:
“if an enterprise bean running in a JVM on a particular machine is using or holding an open file descriptor to a file in the filesystem, that enterprise bean cannot easily be moved from one JVM or machine to another, without losing its reference to the file.” Basically it says what’s bad with files is if you use them to store some kind of state, because then this state will be different on different servers. This issue does not exist with sockets. What you mention is simply a configuration issue. Your datasources will vary as well from one JVM to another (on different servers)
I have the advantage that my interpretation is more common. But his arguments are still clever and EJBs specs could have been a bit more explicit about the use of java.io.Socket. Here is the line about it in the specs:
“The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean– to serve the EJB clients”
Our disagreement shows how such a simple subject, what you can and can’t do in EJBs, is most of the time badly understood.