Google RMI

no not RMI, since it is in the same machine.
Really not an option, anything else

So? RMI can still be used, you simply run both the client and the server on the same machine, but that does not preclude you from using RMI.

Of course, you can always simply open a socket connection between them over localhost and use ObjectInput/OutputStreams.

..or use EJB's to simplify your task. For each of the two applications, create an equivalent local Home and Remote interfaces and you are good to go. Incase you don't know EJB's, try out the alternative suggested to you by Masijade.

EJBs would require a full appserver (or 2, if you want 2 JVMs to talk) and would still involve RMI (albeit under the hood).

Interprocess communication between JVMs is no different whether the JVMs are running on the same machine or if one machine is in your bedroom and the other on Mars.
You're going to use RMI or some other networking protocol, only thing you'll notice is that it's going to be faster and probably more reliable if the virtual machines are closer to each other (and it don't get much closer than when they run side by side on the same hardware).

Local interfaces were introduced for the same reason -- to avoid RMI invocations for methods which reside on the same App server. Since App server runs as a process, the method invocation on objects which reside in the same process space is handled in a different way than the normal RMI ones. You just need the local JNDI name and you are good to go. Oh and btw, the same app server can support deployement of multiple EJB applications.

There is always network latency to be taken into consideration. If what you say is true, well known sites wouldn't have used the concept of local mirrors. Infact, network latency is one of the biggest issues which designing applicaitons. There is always a finite amout of time requried which is directly proportional to the distance between the two machines.

Local interfaces work only inside a single appserver instance, thus a single JVM.
OP wants to use IPC between JVMs...
I know full well that a single appserver can run multiple applications side by side, it's my job after all... But those don't run in separate JVMs which is what the question was all about. And they have a marshaller service to take care of the communication between them, they don't do it directly.


Network latency has no influence on the application programming model.
The application doesn't care whether you have 2 instances running on a network with tons of latency or on the same machine (given that you've programmed it to account for the first rule of distributed computing: the network is unreliable).
So for the application it indeed doesn't matter whether you're talking across thousands of miles or to someone in the same OS instance, it'll just be faster. The protocols will be identical, certainly using Java (C might use named pipes between application instances in the same OS instance, Java doesn't have those).

Ok, ok
here is the actual problem spec.

I have a client application that has a print button. The client is running from the server in the SJSAS 9.
I have a modified Jasper Application for print jobs running in the client itself. How can I call the Jasper application from the client?
So it is not just a remote and local invocation or is it?

alternatively
I have SJSAS 9 and Jasper Server running in one or more JVMs. How can my app server EJB rich Client call the Jasper Server for reporting needs ?

Again has any one tried running JasperServer through JMS or any other mechanism from SJSAS 9 ?


I am working out a project specification and I am short of time.

Thanks for all the participation.

Look at this site

https://cajo.dev.java.net/