Java RMI

What is the advantage/disadvantage of using Java RMI for communication b/w multiple server/clients over socket communication.

Also, how does Java Beans come into play for communication.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Beans do not have anything to do with communication specifically. the beans specs were designed to allow the user to  develop components which would be generic enough for re-use. typically front-end components can usually be generic for use and so you will find that a majority of the beans available are UI beans, but you may create network beans as well.

As for RMI vs sockets, RMI is a specific protocol that allows you to invoke functions on remote objects just like you would invoke them in local object space. The stub and skeleton objects are responsiible for doing the transfer of objects across the network etc. When you do socket communication, communication is not always Object based unless you develop your own protocol, but then why not use some one else's already done work. Well one reason for developing your own object method invocation protocol might be if you think that you can improve on RMI !!

But then you have CORBA. So although RMI may be a bit slow when the VM is first loaded in the server, it works fine after that, so go ahead by all means and use RMI.

see ya
We have legacy systems that uses TCP/IP. Our java clients could run TCP/IP but
we chose RMI due to the fact that the legacy systems are behind a firewall and
our clients can be anywhere. Therefore I have put together a second tier
server that talks to the clients in RMI and to our legacy servers in TCP. I am
still relatively new to RMI, but from what I understand TCP/IP communications
from our clients would not get through the firewall without serious security
concerns, whereas with RMI this would not be a problem. Now how do I know
that? I have taken that as truth when one of our network guys said it. Since I
have had to come up to speed fast on Java and RMI for other reasons, I haven't
had enough time to fully investigate this matter. If what the network guy says
is true, I would think if you had a firewall in your architecture, this would
be a compelling reason to use RMI over TCP.


                       Experts : Java : Client & Server

                       RMI vs. a socket solution


                       I wonder which solution is the most efficient: I have an
                       applet that is supposed to communicate with an
                       application (server), and I'm not sure about the
                       advantages and disadvantages of RMI and a socket

                       Please help me out. Which one will work best?

                       -- F.S.

              expert Greg Travis's answer:

                       Since you haven't mentioned what your applet does, it's
                       not really possible to answer this question completely.
                       However, there are a few rules of thumb that can be kept
                       in mind.

                          1.RMI is, of course, a socket solution itself. That is,
                            RMI is built on top of lower-level networking
                            layers. This said, RMI can't really be any faster
                            than Sockets in general. What you really want to
                            do is consider what structure you might use in a
                            custom socket solution and compare that to what
                            RMI does.

                          2.RMI is very general: It lets you call any remote
                            method of any suitably prepared object. You can
                            make the calls any way you like, and you can make
                            the calls in any order. Because the structure used is
                            quite general, you can probably write a custom
                            socket solution that's faster. This is not to denigrate
                            the authors of the RMI library, but merely to state
                            that less general solutions are usually more open to
                            optimization than more general ones.

                          3.RMI is built on top of Object Serialization (OS).
                            OS is simply one way of passing data around, and,
                            like RMI, it too is quite general: You can pass any
                            suitable prepared object over a network
                            connection and it will show up on the other side,
                            intact and ready to have its methods called. The
                            same arguments about generality and efficiency that
                            applied to RMI applies here as well.

                          4.On the other hand, Object Serialization does
                            supply some optimizations of its own. For example
                            in certain circumstances, when user code sends an
                            object twice, the underlying OS layer will send the
                            full object the first time and will only send an
                            abbreviation the second time: "Hey, object #45345
                            sent again." This technique can save a lot of
                            bandwidth, but remember: You can use the same
                            technique in your code as well.

                       Now let's consider some of the possibilities for
                       optimization. Let's say your applet is a game, and one of
                       the messages sent to the client is "the player has moved to
                       location x, y."

                       If you implement this in RMI, you will be writing code to
                       make a remote call to an object. Without actually using
                       some kind of Socket Sniffer, we aren't going to be able to
                       tell what bytes are being sent, but it's a good bet that the
                       underlying RMI library will have to send at least the
                       following things across the network:

                            remote object id
                            remote object method id
                            types and contents of the arguments.

                       Now, if you write your own system, you can probably get
                       away with sending between four and eight bytes. It's not
                       likely that anything general like RMI is going to be more
                       efficient than that (but you never know).

                       Of course it all depends on what your program does.
                       Some network protocols are rather like function calls: A
                       Chat server, for example, might have a set of messages,
                       each of which has a set of arguments:

                          1.command=say, userid=100, text="hey there
                          2.command=change_channel, userid=100,
                          3.command=quit, userid=100

                       These messages are so much like function calls, RMI can
                       be a very convenient way to implement them.
                       Optimization issues aside, if you write a system like this
                       you are likely to be doing by hand what RMI can do for
                       you automatically.

                       In conclusion, there are two issues involved: efficiency and
                       ease of programming. RMI can be very convenient if your
                       protocol resembles function calls; on the other hand, being
                       very general, RMI will probably not get you optimal
                       performance, as compared with a finely-tuned custom
                       solution. However, it's important to remember the
                       Grandmother of all programming rules of thumb:

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.


Java beans are for reusabl code componenets.

Minaly they will play the ROLE in GUI intesive projects.

Ravindra76Commented: is a good site to know about beans
ramchandAuthor Commented:
Hi ravindra76 and thockit, Thanks for your response. I would like to give equal points to both of you.

ramchandAuthor Commented:
Would like to give half points to thockit too.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.