I'm developing a system that requires fast communication between two multithreaded applications through the network. Semantically, one application is a client that continuously does RMI calls to another application (server). I suspect that a lightweight library like Netty is more suitable for this task than a heavyweight approach like Tomcat/HTTPClient because of performance reasons. However, Netty is inherently asynchronous and it seems that it's quite difficult to properly implement RMI or request-response invocations on top of it.
Is there way to do request-response calls and, at the same time, leverage high Netty performance without development of error-prone customizations? Are there alternatives to Netty that are more suitable for this task?
Not familiar with Netty I'm afraid, but I used JBoss Remoting for this task - it supports a variety of protocols . You can also look here about JBoss remoting and nio
You could use an embedded GlassFish server and EJBs, which hide a lot of the low-level RMI details.
Related
My app requires bidirectional continuous communication with a high volume of clients (which are java agents installed on user machines) in addition it includes a spring mvc webapp which provides a standard jsp UI to manage these agents.
I’ve only looked at the basics of java akka (no time to learn scala for this project). But it seems like a good choice to handle the high volume of client agents. I’ve looked at akka spring integration module and akka-spring-java examples and using akka on the spring side seems pretty straight forward.
I thought using akka remoting with the client agent side might also be a good idea, the agent which will likely be embedded in another app basically runs a thread needs watch various processes in the user’s jvm and communicates with services on server. Using location transparency would simplify the architecture conceptually and possibly be more efficient.
This article suggests this may not be the correct approach
Peer-to-Peer vs. Client-Server
The alternative to using remoting would to use camel websockets which seem to be associated with the akka spring integration module.
What would be the best direction to take in the context of my app given it's tech stack?
You probably don't want to use remoting for a server-clients situation. Remoting gives both sides the same rights and privileges. It was designed for clusters and peer-to-peer.
Take a look at Akka I/O. It gives you asynchronous actors on both sides, but fits the server-client use case better. You wouldn't have to worry about threads and processes.
Also remember, that even when using Akka with Java you need the Scala library as a dependency.
i need some idea/suggestion regarding the implementation of any simple/easy to use setup for such system:
I have two machines, where one will send commands (can be commands, configuration files, text, xml etc) (I have to decide in which way the commands should work) and the other will implement those command. However this is not a completely interactive terminal application, the sender just need to know if it was executed fine or not.
Also RPC is not an option, do i simply go by implementing client/server socket concept??
Is there any well known library to help realize such scenraio in Java? or may be some web server and http based communication??
Any suggestions for opensource libraries to realize such scenario?
If you use sockets or any other TCP messaging service, you will get guarantied message delivery, and then all you need is to write the response on the server end and send it back.
The Apache MINA project. MINA's API is lower level and a great deal complicated. Even the simplest client/server will require a lot more code to be written. MINA also is not integrated with a robust serialization framework and doesn't intrinsically support RMI.
The Priobit project is a minimal layer over NIO. It provides TCP networking, but without the higher level features. Priobit requires all network communication to occur on a single thread.
The Java Game Networking project is a higher level library. JGN does not have as simple of an API.
KryoNet is a Java library that provides a clean and simple API for efficient TCP and UDP client/server network communication using NIO.
I am planning to do a simple Remote Procedure Call (RPM) over the web and I am currently using WebSockets. I was wondering if Jini is better than WebSockets or if there is a newer API or framework for Java to do RPC.
WebSockets and Jini are the main ones of note, both have their pluses and minuses. I'd say WebSockets is great just for the sheer amount of examples and documentation lying about. Jini is a lot different than WebSockets - so if anything the overheard of learning how to use it may not be worth it; that is up to you to evaluate, I spose.
I wouldn't use WebSockets directly because older browsers and/or corporate firewalls may have issues with it. SocksJS
is a respected wrapper that will gracefully degrade to another transport mechanism if required while still allowing you to work with a WebSockets type of API.
The client side is generally written in JavaScript but they have a number of servers written including two in Java: Vert.x and Netty. It looks like the Vert.x implementation is a little more mature at this point in time.
We have a Swing application. Now I need to set up a Java EE server that provides some services to these Swing clients on a LAN.
What is the best practice to implement this, considering that client and server communicate in both ways?
If the clients are in the LAN and you are programming both sides I would take RMI. Because it is much more performant than Webservices. I think it is the native way for communication with a Java EE Server.
Perhaps you should create Facade classes on the server-side which are providing the services.
Using JAX-RS with implementations like Jersey or Apache CXF with XML or JSON data format is a decent option.
If you need flexibility, go with Spring remoting, as it abstracts the remoting layer, so an eventual change of implementation keeps your hands clean.
I use HTTP Invoker, beacuse it's lightweight and uses java serialization, so it's a good choice for Java client -> Java server communication.
The downside of HTTP Invoker, in contrast to RMI, is that you always get new instances of objects from the server, so if an object sent from the client is changed on the server, the change won't be reflected in the client instance.
Good info is here: Considerations when choosing a technology
I would advice using Webservices.
RMI - This is pretty fine for Java applications, but it's general interoperatibility is imho low. If i imagine that you would like to switch from Swing to other technology or add another client not written in Java, RMI would be nightmare then.
Web services - It does not cover both directions communication. It's fine for Swing - Java EE, but you would have to do also some WS (or any other exposing mechanism) on Swing side which would take care of Java EE - Swing communication. E.g. like REST on Java EE and XML-RPC on Swing.
You can also think of using ESB.
I would suggest Spring RPC or maybe EJB 3 if you have a Java EE server and prefer to stick to standards of Java EE specification
Web Services are not binary and therefor will suffer from performance issues.
Imagine a Java client/server ERP application serving up to 100 concurrent users, both web and swing clients. For persistence we can use Persistence API and Hibernate.
But when it comes to client/server communication, do we really have an alternative to using an AS with EJBs to keep down the programming costs of remote communication?
It seems a very heavyweight solution to throw in EJBs and an application server, just for remoting stuff. There is also the standard way using RMI, but who wants nowadays to code everything on his own...
I know that you'll get a lot of features for free with an AS in addition to the remoting part. And, maybe it's the way to go. But, are there really any other (low programming cost) alternatives to an AS for doing client/server communication for an enterprise application?
Personally I consider Seam to be the ultimate solution to the problem I don't have but that aside, there are lots of options and Spring is used for most of them:
RMI;
Hessian (binary HTTP based protocol);
HTTP Invokers (Java serialization over HTTP);
Web Services; or
Even JMS.
The advantage of the HTTP based remoting methods is that they easily plug into Spring's security models. Plus then you get access to things like interceptors.
You can use light weight remoting frameworks. Spring is having a number of options in this section.
If you ask me one word for both, I will suggest two. Seam or Spring. I myself like Seam, but for lightweight remoting Spring has more viable solutions and support. Again if your AS is JBoss, give a thought to Seam.
An application server is a pretty heavyweight solution. Depending on your requirements, I would try to make sure that you can run on a simple servlet container (like Tomcat). I find remoting much easier with Spring-remoting instead of full EJB. Spring-remoting provides an abstraction on the actual remoting technique used. Hessian has a good reputation as a lightweigth protocol.
Having some sort of a server framework (AS or servlet container) is a good thing as you wont need to think as much about all the low level problems (connection establishment, threading, ...).