How to serve a socket from a J2EE application?

Question

We would like to serve some client requests within our J2EE application server (JBoss 4.2.3). I read that the J2EE spec doesn't allow opening a socket from an enterprise bean. But the spec suggests no alternatives.

Specifically, enterprise beans should not:

• listen on, accept connections on, or multicast from a network socket

So the question is: What can I do to serve some binary tcp based protocols (not http) from within an application server?

Here someone suggests to implement a resource adapter. Is this the way you have to go or are there other (easier) solutions?

Answer 1

Neither should you access files :(

This is in the spec because EJBs have to be:

• distributable (you don't know beforehand on what server/instance your EJB will be deployed
• the container is to be able to manage "everything" so you must not spawn your own threads

That in mind nothing will halt you from starting a server socket in your app (the best place would probably be in a servlet) but you should take care about how the serversocket is closed when your app goes down...

Answer 2

You're right, since you can declare transactions for every thing in J2EE they must be supported from all components you want to connect. Files if any should be stored in a database. Everything should be controlled by the container, because it the only way to have a scaling application using J2EE.

A few options:

• Implement a Connector (JCA) a example is here: http://www.theserverside.com/tt/articles/article.tss?l=J2EE1_4 probably the best way if you have existing clients.

• Use Java Message Queues

• The relationship between this techniques is discussed here http://java.sun.com/products/jms/faq.html#relship_ejbs

• Write server who stores requests in the database.(No Tx support)

• If you have only one server and it seems too much overhead, you could ignore these aspects and follow Vinegars suggestion. But if you need Tx later or additional nodes this part has to be redesigned.

Answer 3

Right now I implement a workaround:

I use a standalone java application that accepts tcp calls from the client and forwards them as JNDI calls to the application server.