5

I have a Java EE application where the model is updated very frequently from various sources. In addition I have a rich client application which triggers some actions via remote EJBs but which should also display the model changes ate least every second.

What is the easiest/ best option for sending the changes from the Java EE application to Java client application? Till now I have the following options:

  1. polling a remote EJB every second from the client
  2. polling a servlet (Is it preferable to use json/ xml instead of java object serialization? Any other serialization?)
  3. websockets (Is it possible to send Java objects here? Or must the result be serialized to Json for for example?)
  4. tcp socket connection (The server would provide a port where the client connects to on startup. Model changes are send via standard object serialization. Is this "allowed" in a Java EE app?)
Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Leikingo
  • 890
  • 3
  • 10
  • 23
  • Ever thought about JMS? I guess this is what JMS was designed for. – Xie Jun 30 '13 at 21:44
  • Actually no, never thought to use this for server to client communication. Till now only server to server... maybe I should give it a try. How would this compare in regard to complexity/performance to the other options? I've always found JMS a bit complex and bloated... – Leikingo Jun 30 '13 at 22:01

1 Answers1

3

Option 1 is the easiest one, you can use there asynchronous EJB methods:

SERVER

@Asynchronous
public Future<String> getUpdatedModel() {
    //here create blocking process until something interesting happen
    return new AsyncResult<String>("model has changed!");
}

CLIENT

    Future<String> updatedModel = bean.getUpdatedModel();
        while(true){
            String response = updatedModel.get();
            //process response here
        }

Option 2 looks like option 1, but you have to take care of marshaling objects, so don't bother in using plain servlet.

Option 3 looks interesting, as websockets are going to be included in Java EE7 (now you can use opensource comet implementations for servlets). In my opinion it is not designed for communication in enterprise applications, but might be fine for your usecase. There is a plenty of JSON serializers available (e.g. gson), I use that kind of communication between JS and java, and works fine.

Option 4 breaks major Java EE principles (opening your own sockets is forbidden), and I would discourage you to use it.

Option 5 Listen to Xie and use JMS! If you will use JMS topic, you could just send the message when particular event occur, and all connected client will receive the message asynchronously. It is natural Java EE way of solving this kind of problems, with out of box transactions, message redelivery and persistence if nessesary.

iskramac
  • 868
  • 6
  • 14
  • Thanks for the extensive answer. I agree on most aspects but I have a minor problem... I just tried a "small" client prototype which resulted in a huge (MB) client application. I'm using Glassfish 3.1.2. on the the server side and the only way to get everything to work was to include a lot of glassfish jars ([link](http://stackoverflow.com/questions/4311157/glassfish-v3-x-and-remote-standalone-client/5745860#5745860) and [link](http://stackoverflow.com/questions/5675024/with-which-maven-dependencies-can-i-create-a-standalone-jms-client-for-glassfish/5745837#5745837)). Maybe I'll try 2) and 3)? – Leikingo Jul 01 '13 at 07:24
  • Just expose those EJB as a SOAP WebService, client will be thinner and you still won't have to deal with serialization. If you do so, remove '@Asynchronous' annotations from EJB, as they are no supported with '@WebService' annotation. – iskramac Jul 01 '13 at 09:08
  • You don't think the SOAP xml stuff is too much overhead for polling updates from multiple clients every second? I think I'll try at least the REST approach and maybe use protocol buffers for serialization. – Leikingo Jul 01 '13 at 15:26
  • I wouldn't bother SOAP WS overhead in your case, as effort in implementation is smaller than REST, and in case of problems easy to refactor. But if you are sure that you will hit performance problems, use REST, or JMS ;) – iskramac Jul 01 '13 at 21:40