an EAR (Java EE) application which listen to a socket request

I want to build a Java EE application (EAR) which not only provi开发者_JAVA技巧des web service(WAR) or direct JMS request (EJB), but I would like to also accept the socket request (e.g. UDP packet).

I have tried writing a listener with java.net.DatagramSocket, letting it run as separate process, and redirecting the request to my EAR application.

the question is.. how can I build such socket listener into my Java EE (EAR) applcation seamlessly?

thanks.

---

The right approach would be to create a JCA adapter for that. JCA adapter can be used for outbound or inbound connectivity. You're allowed to start thread or schedule work in a JCA adpater. The inbound connectivity from the JCA adapter to the EJB is done using custom message-driven bean.

• The adapter start a socket listener and manage the connection from remote clients
• When a packet is received, a message is delivered to a custom MDB
• The MDB can then delegate the processing to other EJBs

You can even start transaction from the JCA connector so that the delivery of the message/packet to the EJB is transacted. JCA is part of the Java EE specifications and is supported by all application servers.

Another approach (but not compliant with the spec), is to start the thread that listens to the socket from a ServletContextListener. The thread will run in the web layer and you can call the EJB as usual. Dependency injection will not work, but JNDI lookup should still be ok.

---

Everything should be controlled by the container, because it's the only way to have a scaling application using Java EE.

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 external 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. But if you need transactions later or additional nodes, this part has to be redesigned.

---

As far as I know it doesn't conform to the spec.