For multi-JVM calls, one of the most common techniques is RMI (Java's implementation of RPC). In RMI, a call to remote machine is blocked. So, your threads are now at the mercy of a different JVM. Enterprise level applications faced this problem long ago. So, they solved the problem by making the call asynchronous. The technical term is Message Queuing (MQ). BTW, enterprise-designers solved on more problem with MQ - connecting legacy applications in a disjointed manner.
For Java, it is called JMS (Java Messaging System), which is a common interface of all major implementation of MQ. The committee for JMS comprised of representatives all major MQ vendors; so JMS essentially covers the common denominator.
OpenJMS is one such implementation of JMS. It came after JMS spec was created. It is open-source. I am using OpenJMS to do my initial R&D on JMS.
My initial comments about OpenJMS are:
- It is very easy to install. Just unzip.
- Very easy to run/stop. Run the startup.bat, shutdown.bat.
- There is a even better way - run the admin.bat. It pops up a small swing-window. From there, you can start/stop OpenJMS instance.
- Using Admin tool, you can see which topics (a JMS terminology, explanation coming) and queues (another one) are being maintained.
- Very easy to try to hello-world type thing. Ready to run (you have to have Ant configured, which fortunately I had) sample application can give you scope to do immediate testing.
A: I didn't try this yet. OpenJMS prefers that you get a handle to it (running on same or remote machine) using JNDI (I am also doing some JNDI study; refer to those concepts, I am not going to explain them again here).
I am planning to do some more R&D using OpenJMS with the following setup:
- Try 2-machine testing using my personal laptop and office-laptop.
- Try multi-machine testing using VMWare, where I will host 2/3 OS running.
- Hand-code some JMS client stuff.
Links:
No comments:
Post a Comment