开发者

How to serve a socket from a Java EE application?

开发者 https://www.devze.com 2022-12-17 10:35 出处:网络
We would like to serve some client r开发者_运维百科equests within our Java EE application server (JBoss 4.2.3). I read that the Java EE spec doesn\'t allow opening a socket from an enterprise bean. Bu

We would like to serve some client r开发者_运维百科equests within our Java EE application server (JBoss 4.2.3). I read that the Java EE 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?


You're right, since you can declare transactions for every thing in Java EE 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 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 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.


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...


Right now I implement a workaround:

alt text http://yuml.me/7f82bd5c

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


I have used somewhat similar solution as per my need in Spring MVC. Might be this can help someone here around.

Start a Socket Port on server start up. I used @scheduler annotation whereas you can use listener based solution as well. You can also implement ApplicationContextAware listener and can access other application beans from it.

@Scheduled(fixedDelay = 1000 * 60 * 60 * 24 * 365) 
public void startListenerPort() { 
    ServerSocket socket = new ServerSocket(9999); 
    // do some stuff here 
}

Just make sure that you have allowed TCP traffic on the port that you have assigned to the Socket (Firewall Settings).

In this way, you can have TCP traffic on port 9999, where as your app server will continue to run on different port as normal.


Although not strictly a purely TCP connection, but you may be able to achieve what you need with a @ServerEndpoint annotation to create a WebSocket from the Java EE7 spec.

Although this DOES use HTTP, it will function a little bit like a binary interface when your @OnMessage method and a ByteBuffer (or byte[]) as the argument.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号