Why does Java RMI exist? Who uses it and for what?
My most pressing questions;
Why would you want to make calls to methods that aren't defined on your machine? Wouldn't it take much longer to execute? I don't see how this makes the world a better place. Wouldn't it just be smarter to have many machines running the complete program rather than many machines each running parts?
Doesn't the fact that you have to manually provide interfaces to all the machines (clients and servers) kill whatever benefits having remote objects provides? In other words, if a benefit of having a remote object is that the client programmer doesn't have to interact with the server programmer, then doesn't it get annoying to have manually contact eachother to update the interfaces on both sides for each little change?
How is this similar or different to a typical web app set up where a client communicates with a server? In my mind, HTTP calls are much easier to understand. Can an RMI Server require some sort of password from RMI clients?
What kind of applications are typically made using Java RMI? Any hard examples?
Why does Java RMI exist?
Err, because Sun built it? The same Sun that provided Sun RPC.
Who uses it and for what?
RMI is the basis of Jakarta EE (formerly J2EE) just to name one small example. However the concept of remote method calls dates further back to at least CORBA, and the concept of remote procedure calls to at least the 1970s. Sun provided their implementation of RPC in about 1982 and it is the basis of NFS among other things.
Why would you want to make calls to methods that aren't defined on your machine?
Err, if you wanted them to run on another machine?
Wouldn't it take much longer to execute?
Of course.
I don't see how this makes the world a better place. Wouldn't it just be smarter to have many machines running the complete program rather than many machines each running parts?
So you've never heard of distributed computing, then?
Doesn't the fact that you have to manually provide interfaces to all the machines (clients and servers) kill whatever benefits having remote objects provides?
No.
In other words, if a benefit of having a remote object is that the client programmer doesn't have to interact with the server programmer
Did somebody say that was a benefit?
then doesn't it get annoying to have manually contact each other to update the interfaces on both sides for each little change?
There don't tend to be many 'little changes', if you actually design your system before implementing it. But that isn't the only development model anyway. You could have a third person developing the interface. Or the same person developing both sides. Or have the remote interface defined by a specification. Or ...
How is this similar or different to a typical web app set up where a client communicates with a server?
It uses RMI instead of HTTP.
In my mind, HTTP calls are much easier to understand.
You can't get much easier to understand than a remote interface, but obviously your mileage varies.
Can an RMI Server require some sort of password from RMI clients?
Yes, it can use mutually-authenticated TLS for example, or arbitrary authentication protocols implemented via custom socket factories.
Related
I have the following situation:
I have 2 JVM processes (really 2 java processes running separately, not 2 threads) running on a local machine. Let's call them ProcessA an ProcessB.
I want them to communicate (exchange data) with one another (e.g. ProcessA sends a message to ProcessB to do something).
Now, I work around this issue by writing a temporary file and these process periodically scan this file to get message. I think this solution is not so good.
What would be a better alternative to achieve what I want?
Multiple options for IPC:
Socket-Based (Bare-Bones) Networking
not necessarily hard, but:
might be verbose for not much,
might offer more surface for bugs, as you write more code.
you could rely on existing frameworks, like Netty
RMI
Technically, that's also network communication, but that's transparent for you.
Fully-fledged Message Passing Architectures
usually built on either RMI or network communications as well, but with support for complicated conversations and workflows
might be too heavy-weight for something simple
frameworks like ActiveMQ or JBoss Messaging
Java Management Extensions (JMX)
more meant for JVM management and monitoring, but could help to implement what you want if you mostly want to have one process query another for data, or send it some request for an action, if they aren't too complex
also works over RMI (amongst other possible protocols)
not so simple to wrap your head around at first, but actually rather simple to use
File-sharing / File-locking
that's what you're doing right now
it's doable, but comes with a lot of problems to handle
Signals
You can simply send signals to your other project
However, it's fairly limited and requires you to implement a translation layer (it is doable, though, but a rather crazy idea to toy with than anything serious.
Without more details, a bare-bone network-based IPC approach seems the best, as it's the:
most extensible (in terms of adding new features and workflows to your
most lightweight (in terms of memory footprint for your app)
most simple (in terms of design)
most educative (in terms of learning how to implement IPC). (as you mentioned "socket is hard" in a comment, and it really is not and should be something you work on)
That being said, based on your example (simply requesting the other process to do an action), JMX could also be good enough for you.
I've added a library on github called Mappedbus (http://github.com/caplogic/mappedbus) which enable two (or many more) Java processes/JVMs to communicate by exchanging messages. The library uses a memory mapped file and makes use of fetch-and-add and volatile read/writes to synchronize the different readers and writers. I've measured the throughput between two processes using this library to 40 million messages/s with an average latency of 25 ns for reading/writing a single message.
What you are looking for is inter-process communication. Java provides a simple IPC framework in the form of Java RMI API. There are several other mechanisms for inter-process communication such as pipes, sockets, message queues (these are all concepts, obviously, so there are frameworks that implement these).
I think in your case Java RMI or a simple custom socket implementation should suffice.
Sockets with DataInput(Output)Stream, to send java objects back and forth. This is easier than using disk file, and much easier than Netty.
I tend to use jGroup to form local clusters between processes. It works for nodes (aka processes) on the same machine, within the same JVM or even across different servers.
Once you understand the basics it is easy working with it and having the options to actually run two or more processes in the same JVM makes it easy to test those processes easily.
The overhead and latency is minimal if both are on the same machine (usually only a TCP rountrip of about >100ns per action).
socket may be a better choice, I think.
Back in 2004 I implement code which do the job with sockets. Until then, many times I search for a better solution, because socket approach triggers firewall and my clients worry. There is no better solution until now. Client must serialize your data, send and server must receive and unserialize.
It is easy.
I am working on an existing system written using .NET 2.0 remoting to integrate a number of embedded clients to a central server. Due to a number of issues, it has become desirable to rewrite the server in Java. Updating the clients is not really viable at this point; there are many of them and they are geographically scattered, so an update would be potentially expensive. To this end, I was wondering what solutions are available to implement a Java server that would be compatible with the existing over-the-wire protocol?
I am aware of JNBridgePro, but it is unfortunately too expensive for our current budget. I also have the CD from the book Microsoft® .NET and J2EE Interoperability Toolkit (Microsoft Press), which has a copy of a piece of software called "ja.net" from Intrinsyc Software that promises to fulfill this function, but in order to use it you need to obtain a licence from Intrinsyc and their web site is not responding (perhaps they have gone out of business since the book was published?).
Are there any others I'm not aware of?
No, no such thing (except custom commercial solutions).
However, if you are up to an in-house solution, you can:
Write your own .NET remoting adapter, which sits between the .NET clients and the Java server.
The .NET adapter translates the requests to something known by the Java server (maybe a web service interface, via SOAP) and the same for the responses.
So, the .NET adapter would be something like a pass-through and mapping component, with no actual logic. This way all logic can be in the Java server (which seems to be what you want).
It could take some time to do it, but it depends directly on the number of clients you have and on the number of types of requests and responses.
When implementing a client/server solutions, one of the questions you always need to answer is about protocol.
In simple cases, it's possible that packets are always of the same type, so the protocol could even have no logic at all: client connects to the server and sever just says some fact, the client disconnects and that's it.
In more complex cases, some packets are can only be sent in some specific cases. For instance, imagine an abstract server that requires authorization: clients have to authorized before sending or getting any useful data. In this case, the concept of session appears.
Session is an concept that describes the state of client/server dialog: both client and sever expect something from eachother, while there are also things that both of them don't expect.
Then, going even deeper, pretend that protocol is quite complicated and it's implementation should be easily extendable. I believe, that the theoretically right solution here is using a finite state machine. Are there any Java frameworks/libraries that allow this state machine to be easily implemented? Or probably, any more protocol-specific solutions?
What I'm expecting is a framework that allows me to define states and transitions between them.
Update: the question is not about easiest client/server solution implementation, the question is about implementing custom protocol. So, please, don't recommend using web services.
I remember using Unimod FSM for finite state machines a few years ago, although for serious work I always preferred to implement the finite state machines directly.
I want to implement encrypted communication between two JAVA servers, both are under my control. There are three architectures I have in mind and want to get your input on the pros and cons of them.
Architecture 1:
Whenever I invoke a remote method, I do not pass the parameters as plain text but as a serialized CipherText-Object. I will use the ESAPI-library for this, but the actual implementation does not matter. What's important is that the CipherText-Object contains arbitrary Data encrypted with a symmetric key including an MAC for authentication. The symmetric key is available as a pre-shared secret on both servers.
Architecture 2:
I don't care about the encryption on application level but delegate it to the transport layer. This could be a VPN-Tunnel or some sort of server-to-server encryption that is supported. I don't have too much information about what is available on modern application server at the moment. Input on this is welcome as well.
Architecture 3:
Using javax.rmi.ssl to use RMI over SSL.
It feels like architecture 1 is complicated and a pain to implement. Architecture 2 leaves the encryption to the application server. As an application developer I have no control over the configuration these features. That's bad because I want to ensure that the application cannot be used without proper encryption. Architecture 3 seems to be the best way but I have no experience with this technology.
How would you rate those three architectures? Did I miss an even better way to implement this? The main goal is to ensure secure encrypted communication, but the complexity of the resulting source code, performance issues and the like are of course a concern as well.
First of all, security solutions are not one-size-fits-all. You must evaluate threats(who would be interested in snoping/attacking), risks (what would you lose if an attacker succeeded) and cost of implementation and use.
Second, the security solutions usually are not exclusive. You could implement all 3 solutions at the same time (communication over VPN of RMI-SSL calls with encripted parameters). The issue would be cost of implementation and overhead.
Now to the question at hand:
1) I do not like it, because:
It allows someone snopping to know what metods are called, even if he does not know which data is passed.
As far as I know, MACs can be spoofed
You have to keep control of your servers now and in the future so the shared secret is not discovered. Maybe next month one of your servers is taken away to another location/branch/departament and more people starts having access to it. Or maybe they deploy your servers in another bussiness without changing the secret.
2 and 3) are more or less equivalent. With 2, though, you have to get sure that your servers only accept connections coming through the OpenVPN, and not from other NI. I do not know RMI over SSL well, but if it has not any hidden vulnerability it looks OK.
IMHO, I would go for 3 (standard, integrated in the server and more flexible). 2 is a good option too, easier to implement but requires you have a better control of the server. 1 is reinventing the wheel where there are already valid options, I would discard it.
Architecture 4: standard socket I/O over SSL.
i want to write a game that will utilize java applets as client programs and will run a server application to operate the game (control the game handle the chat etc) is there a way to host such an application on a free server, or does it require a specialized server?
also is there a way to use php for tcp connection so it will receive the data and send it using tcp to the users (using a db to store user information from request to request) (for instance will forward chat massages)
If you are planning to use Java, make it completely on Java based, it will provide you the security and the performance would be much better.
If you are looking for a Free Java Server, I can provide you the Java server to host your Java based application for free.
A little remark about PHP: If you looking at PHP as a possible replace for server-side Java, I think that's not a good idea, cause PHP may be much slower (up to 1000 times according to the benchmarks I've seen, but that might not be absolutely correct).
I've seen a free java hosting called 'MyJavaServer' and that's all that I've found at that moment (couple of years ago). So you'll have to figure out how much java hostings are available now. And of course, there still makes sense to buy/rent a dedicated java server.
Addition: You do not really have to use DB to store intermediate information, you could do that even with PHP through things like 'memcached'.