This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes socket vs RMI Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "socket vs RMI" Watch "socket vs RMI" New topic

socket vs RMI

Ethem Yuksel

Joined: Feb 06, 2009
Posts: 6
Hi to all,
I've completed my assignment by picking sockets for the network layer. But i need a good reason for sockets against RMI. I am thinking because it was easier and easy for a junior to understand. But i am not sure if it is a good reason.

Any advices?
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Ethem Yuksel wrote:Hi to all,
I've completed my assignment by picking sockets for the network layer. But i need a good reason for sockets against RMI. I am thinking because it was easier and easy for a junior to understand. But i am not sure if it is a good reason.

Any advices?

I think it is valid! No new *stuff* to learn, plain old java object with sockets. I actually wrote that as a downside for my RMI solution, even though it is quite easy, it would be easier to "read the code" (and understand) with sockets than with RMI (for a super junior programmer).

Olu Shiyan
Ranch Hand

Joined: Jun 10, 2010
Posts: 57

Hi guys,

I want to use RMI for my network layer but justifying my choice is proving tricky. Personally, I want to use RMI because I havent used it before but I have used sockets before. However I believe I need to give a better reason. How did you guys justify your decision? Did you list the advantages and disadvantages of both and then choose one based on the requirements? Simplicity is obviously not a good reason for choosing RMI as far as I can see- the sockets solution (in Andrew's book for example) is as easy to understand as the RMI solution.

Robert Benson
Ranch Hand

Joined: Apr 04, 2010
Posts: 56
I wrote an RMI solution for my application, thought about it for a while, then wrote a socket solution.

From looking at the ranch and other searches, RMI is the way to go. However, on balance, I think the socket solution is preferable (for me) for my application.

The one big hang up I had with using RMI for my application was with RemoteException and its use in the networking context. However there is a requirement to run the application in alone mode without any networking references.

My understanding is that this would require different layers: a layer to work in networking mode with reference to RemoteException and a layer to run in alone mode without reference to RemoteException.

My thoughts are that a junior programmer would find these layers harder to conceptualise so I went with sockets. I have documented this in my choices.


SCJP 6 , OCMJD 6 ,
Roberto Perillo

Joined: Dec 28, 2007
Posts: 2258

Howdy, Robert!

Well champ, I'd say that it depends on the way you are designing your application. Please take a look here. This is one of the ways the business layer can be built. In this proposal, we have one interface that defines the business methods the application will have. Each method also throws RemoteException. There is a default implementation of it (which is used when running the application locally), and there's also another implementation that extends it and uses RMI. This is the most clear design I could think of. In your class that corresponds to the window, there will be a reference to the business interface, and when the application starts, you can refer to the proper implementation, according to the way the application was started.

In conclusion, I'd say that RMI is the most straightforward way. I'd say that it is also easier for a junior programmer to understand. In the scenario I described above, the RemoteException will only occur when using the implementation that uses RMI.

Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Robert Benson
Ranch Hand

Joined: Apr 04, 2010
Posts: 56
Hi Roberto,
Thanks for the reply.

From what I've read (and used) RMI is better than sockets. If RemoteException was not in the ring. This would have been a no brainer. I would have coded RMI without doubt.

I took a look at the post that you highlighted. With your years of experience.You will look at the interfaces and understand very quickly whats going on.

I'm at the other end of the scale (junior java programmer) and I'll have to sit and scratch my head for a while to figure out the interfaces. For that reason sockets win for me on this occassion.

Roel De Nijs

Joined: Jul 19, 2004
Posts: 5123

To be honest I can't think of a reason why you should not make use of RMI.

1/ RMI requires less code than using sockets. And less code means (or should mean):
  • less bugs
  • less code to maintain

  • 2/ RMI is a proven technology with an extensive amount of examples and tutorials. So no need to reinvent an existing technology. It will also be very easy (for a junior programmer) to find any resources if he has trouble (and a lot easier to find help regarding a custom designed protocol).

    3/ ... (more reasons in my choices.txt )

    SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
    David Byron

    Joined: Jan 20, 2009
    Posts: 171

    In general, I looked at the issue this way:

    RMI offers a high-level, Java-specific abstraction that solves problems of complexity that this assignment does not raise in an important way. The socket metaphor offers a lower-level, universal approach to marshaling objects on the wire.

    Sometimes there's value in not assuming that Java (or known interopped technologies) will be on the far side of a connection. In particular, the assignment mentions that other undefined systems may or may not be in play thanks to a customer whose tolerance for hybrid systems is rather high.

    Yes, RMI is easy in its way and the overhead isn't too onerous. But in a very simple domain with only a couple of business services, perhaps RMI offers too much solution/abstraction for not enough problem.

    The choice could go either way, but the case for sockets, I think, has something to do with directness, simplicity, universality, and flexibility in relation to the terms of the assignment.

    SCJD 6, OCPJP7, Baroque Potion, G+
    Mike Peters
    Ranch Hand

    Joined: Oct 10, 2009
    Posts: 67

    In my opinion both RMI and sockets are easy to implement. A socket implementation where you send command objects over the wire is not much harder than an RMI implementation. I think both solutions have their advantages and disadvantages. If you are comfortable with RMI use that, if you know your way with sockets use that. You can pass the assignment with both solutions if you are able to justify your choice.

    Mike Peters
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    subject: socket vs RMI
    Similar Threads
    Adapter pattern and general exception.
    Use of sockets through RMI
    Specifying local and network "mode"
    RMI vs. Sockets
    passed 148/155 :-))))