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:
polling a remote EJB every second from the client
polling a servlet (Is it preferable to use json/ xml instead of java object serialization? Any other serialization?)
websockets (Is it possible to send Java objects here? Or must the result be serialized to Json for for example?)
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?)
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.
Related
I have a small Java SE application, it´s practically a fat client sitting on top of a database. To further my Java skills, I decided to make a client-server application out of it. The server application communicates with the database and handles all kinds of lengthy operations, while the client application only receives the results, mostly ArrayLists of moderate length and primitives.
To this end, I started reading on RMI and did the Oracle tutorial, which I found surprisingly difficult to understand and even get to work.
Is there anything else I can use instead of RMI, without having to dive into JavaEE?
One way I would suggest would be to use JSON as the format for data exchange. You can use GSON to convert the data from Java objects to JSON and back. The transport could be done directly on the HTTP protocol using REST. You can use Jersey as a REST server/client or roll your own (since you don't want to use JEE, which Jersey is part of).
SIMON is as simple to use as RMI, but with fewer traps in the initial setup. It also has some advantages over RMI. Here is a simple hello-world example:
http://dev.root1.de/projects/simon/wiki/Sample_helloworld110
I take it RMI = Remote Method Invocation ...
You can have a look at XMLRPC, JSONRPC, JMS, or if you want to roll your own, use JSON to POST messages and convert the JSON back to a java object on the other side using GSON (from Google) or setup RabbitMQ and use AMQP to submit and receive messages if you don't want to handle the POSTing yourself, Spring AMQP makes it fairly easy to do this.
I have requirement something like this:
once the request is received by my service, i need to send it 2-3 third party servers at a time and get the response from all server and return the response.
How can I achieve that?.
My thought : I can create separate threads for different servers and send the request to all servers parallely, but here the issue is, how I will come to know the threads are finished and consolidate the response from all servers and return to caller.
Is there any other way to do in spring boot(micro service)?.
You can leverage asyn feature supported by Spring Framework. Let's see the folllowing example which issue multiple calls in Async style from Spring's official guides:Async Method
Another possible solution for internal communications between Microserives is to use the message queue.
You didn't specify what type of services are you consuming. If they are HTTP, you may want to use some Enterprise Integrations abstractions (most popular are Spring Integration and Apache Camel).
If you don't want to introduce message bus solution into your microservice, you may want to take a look at AsyncRestTemplate
We're using spring-messaging websocket with STOMP. Now we've defined multiple #SubscribeMapping methods, but is there also some sort of callback that gets fired when a client application disconnects from the socket?
We got a list of connect clients and some additional properties, like status. Status field needs to be updated when the client application disconnects.
Any suggestions on how to achieve this in Spring? I've tried implementing ApplicationListener however, there's no usefull information in the OnSessionDisconnect object.
I want to use apache CXF to build my client. Unfortunately, I do not see a way by which it allows me to dispatch a client dynamically based on the port and operation name. If there is a huge wsdl, JaxWsDynamicClientFactory would create classes for all services contained in it which is an overhead that I'd like to avoid.
I found a similar implementation in JAX-WS. Is there any api in CXF that would do the same?
CXF supports the JAX-WS Dispatch API, which is a low-level interface to SOAP.
That means you can create a Dispatch that represents a particular port-type on a service and then invoke the methods by building the message
// Set things up...
Service s = ...
Dispatch<DOMSource> dispatch =
s.createDispatch(portName, // << a QName!
DOMSource.class, Service.Mode.PAYLOAD);
// Construct the request message here
Node response = dispatch.invoke(new DOMSource(request)).getNode();
// Understand the response message here
Of course, that then means you've got to work with the DOM for the messages, which is highly annoying. I think that's the part of tooling that's really worthwhile.
we're developing standard Java SE application and it is necessary to implement some logic on remote server (using Java EE running on OpenShift PaaS). My question is, what is the best way to remote call classes/methods between the SE client and EE application?
My tips:
EJB remote call: however, is the communication encrypted (or possibility to do that)?
Expose EBJs through JAX-RS: looks line nice one, with possibility to use SSL encryption
Thanks for any suggestions.
Title of this question indicates that the Java SE client is in Spring. If the PaaS provided allows, you can even choose Spring. That will help you in long term as the skillset to maintain your application will be small. It'll also improve efficiency.
JAX-RS is features provided by Spring and EJB are almost same.
Assuming you are bound to use EJBs, I'd suggest to go with 'Expose EBJs through JAX-RS'.
Pros -
It avoids tight coupling of client and service. Remote calls will make client aware of EJBs.
In future, you can choose to change your technology from EJB to something else, then client will be minimally impacted.
If you think to write client in any other technology than Java, then it'll be smooth.
Saves time related to JNDI setup
Cons -
Additional time for marshalling and un-marshalling.
Request-response convertes on client and server sides