Java-RMI is tightly coupled with the Java language. Hence there are no separate IDL mappings that are required to invoke remote object methods. This is different from DCOM or CORBA where IDL mappings have to be created to invoke remote methods.
If you use a J2EE server (with EJBs, Web Services) you can talk to disparate systems. J2EE servers provide clustering for scalability. So I would go for a J2EE solution unless you have a compelling reason for writing your own Java only solution server. J2EE server also supports variety of protocols like Http(s), RMI/IIOP eyc.
Thanks, I understand your point regards scalability.
So say I have a trivial program that I've deployed to the app server. Say it only has one Remote method that when called adds 2 numbers together and returns the result. (lets ignore all those other services like EJB and web services for now)
My understanding in writing and running a stand alone Remote Service (from the Head First Java 1st Edition book pg 543) is that you must:
1) Write a remote interface 2) Make a remote implementation 3) Generate the stubs and skeletons using rmic 4) Start the RMI registry 5) Start the remote service
If instead I was to deploy this app to a J2EE app server, I assume prior to the deployment I must still do steps 1, 2 and 3. Is it correct to assume the app server does step 4 and 5 once deployed?
Joined: Feb 11, 2006
It may work, but the security restrictions of the specification indicate that a Web component (servlet) and EJB component can only have access permission to connect to a socket, not to listen on one. This means a web or EJB thread shouldn't be allowed to start up an RMI server which would need to listen on sockets for RMI connections.
There is nothing in the spec that I'm aware of to allow regiteriing of arbitraryRMI components with the containers own RMI server, other than via SessionBean.
Joined: Mar 23, 2006
Hmmm, by the technical nature of your answers it shows I've the wrong end of the stick on the RMI band wagon. Back to reading the documentation I think.