This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Perogi asks about RMI vs. Sockets Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Perogi asks about RMI vs. Sockets" Watch "Perogi asks about RMI vs. Sockets" New topic
Author

Perogi asks about RMI vs. Sockets

S Perreault
Ranch Hand

Joined: Oct 29, 2003
Posts: 37
I was asked to move my Q about RMI and Sockets and reasons for using one or the other to a new thread. The old thread is here: http://www.coderanch.com/t/184451/java-developer-SCJD/certification/NX-Bodgitt-Scarper-design-synchronization
My main idea is that Sockets are easier and a junior programmer would more than likely use them was squished earlier today at my job. One of my co-workers (who has passed the SCJD) seemed to believe that creating a socket connection and then a class/method to transmitt each type of 'request' would be more work than just creating a RMI server and letting that server do the hard work for you.
The first thing that dissuaded me to use RMI were the restrictions put on my application.
"Restrictions on RMI
To avoid unnecessary complexity in the marking environment certain restrictions are placed on solutions that use RMI. Specifically:

You must not require the use of an HTTP server.
You must not require the installation of a security manager.
You must provide all classes pre-installed so that no dynamic class downloading occurs.
You must use RMI over JRMP (do not use IIOP)"
I don't understand the 2-4 ones whatsoever.
Can anyone help with why to use a RMI setup and what 2-4 mean?
Thank you all!
Perogi.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Perogi,
Points 1 to 3 are all intertwined.
One of the features of RMI is that you can dynamically (on demand) download the stubs and executable classes.
If you aren't already familiar with stubs, what happens is you create your class(es) containing the methods which will be remotely executed, the run the "rmic" compiler against these classes, which provides stubs: little bits of code that the client can use to connect to your class without having to have a copy of your class. The stubs provide the glue to all the networking code. The stubs are compiled from the server class files, so every time you recompile the server code, you should recompile the stubs. Allowing them to reside on the server and be dynamically downloaded means that you would not have to send new stub files to your clients every time you make a change to the server.
Downloading executable classes is definately not required for this assignment, but you could use it for instance to download some security algorithm which will encrypt all the data between clients and server - since the code is downloaded dynamically, the programmer for the client side never gets to see how you implemented it (indeed, you could even hide the fact that it is being used at all) - reduces the chances of someone trying to hack your encryption algorithms if they never get to see them.
In order to download the stubs (or the complete classes), you need to put them on an HTTP or FTP server. Sun do not want you to force examiners to install a server of any kind.
Also Java 2 does not like your code downloading code from elsewhere (or even making unnecessary connections to other systems), so to download the stubs you would need to install a security manager. But the examiner's probably do not want you installing your own security manager on their system (and granting yourself who knows what security rights), and they should not have to do the work of setting up their own security policies. So that is also out.
Just in case you found a loophole somewhere in the previous two rules which might still allow you to dynamically download the stubs, Sun finally just rule it out altogether: no dynamic downloading!
As for the last bit (the RMI-JRMP vs RMI-IIOP) - RMI is the high level communications infrastructure. JRMP or IIOP is the low level communications protocol. (Similar to FTP is the high level infrastructure, but it can work over either TCP/IP or UDP/IP). JRMP is the native Java Remote Method Protocol - very specific to Java. IIOP is Internet Inter ORB Protocol is the standard protocol for communicating with CORBA systems. It is a way of achieving interoperability between Java and CORBA systems.
All Sun are saying here is that you must use the native format. Don't go using the Corba format. To use IIOP you have to specify it as a command line option to rmic. So by default you will be safe without it.
Clear as mud?
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Perogi,
Originally posted by S Perreault:
My main idea is that Sockets are easier and a junior programmer would more than likely use them was squished earlier today at my job. One of my co-workers (who has passed the SCJD) seemed to believe that creating a socket connection and then a class/method to transmitt each type of 'request' would be more work than just creating a RMI server and letting that server do the hard work for you.

Hopefully we will get Phil involved in this discussion - he is a Sockets fan.
First up - a sockets solution does not have to be harder for a junior programmer to understand. Yes, you will have at least one additional class on client side and on server side just to deal with sockets. But from experience, these are often set up early in development and then never touched again. Especially where we are using Object Serialization, the junior programmer should rarely have to touch the socket code. And the moment you get up to the level of the class that is calling your communications classes, there is often little (if any) difference between a sockets solution and an RMI solution.
Also RMI can add to the junior programmer's learning curve. They have to worry about the extra interfaces and using rmic - often not covered on an introductory course or book on Java. Plus if you have one of the assignments that does not use a lock cookie, you may have to use a connection factory on the server side to ensure you have a unique identifier for your locking (assuming you are exposing locking to the client). All of which can create extra confusion to the poor junior programmer.
If you had to worry about firewalls, or about having system administrators setting up your system, then a plain sockets solution is usually easier than an RMI solution.
Finally Sockets perform much much better than RMI. Last time I tested, I got several times more bytes transferred in a simple RMI test application than in the Sockets solution that did the same work, and my RMI application used 3 sockets compared to the 1 socket used by my Sockets application. (I wish I had bookmarked the thread where I talked about that - Phil, did you bookmark it?)
Having said all that, RMI means that you don't have to worry about those extra classes that I talked about for handling networking issues - simple things like accepting a connection, spawning a new thread for it, handling timeouts, that sort of thing are all taken care of for you.
And RMI really does make your code look like you are just calling another method. There is nothing to differentiate between the call to a local method and a call to a remote method (apart from catching the RemoteException), so this can make your code easier to read.
Regards, Andrew
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Perogi,
I found the thread where we were talking about Sockets last time. It is: Anybody interested in a sockets discussion ?.
You may find arguments to counter your work collegues recomendation for RMI
You still have to make your design decision on which one you are going to use. I strongly recommend that you build a small test application using both sockets and RMI so that you can get a feel for what is needed in both solutions. That may help you make up your mind as to which one you want to use.
Regards, Andrew
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Andrew,
Sorry not to have joined quicklier. I am ill and I am afraid I'll spend more time today in my bed than on JV
Perogi, this thread should be more interesting for its arguments about sockets vs RMI (that's what you are looking for), than for its technical contents (I had to stop the discussion in the middle because of a lack of arguers ).
Back to the subject. You'll see there that I chose to implement a quite complex sockets solution in order to be consistent with the arguments I used to favour sockets over RMI : better performance and scalality among others.
Then Andrew came in with an interesting post proving that (as you seem to guess yourself) sockets may be preferred for their greater simplicity, justifying a simple sockets solution.
In other words, if you claim that :
  • you chose sockets for performance and scalability, you'll probably have to build a sockets solution which will be much more complex to build (but not to use) than the simple use of RMI ;
  • you chose sockets for their simplicity, a simple sockets implementation is the right choice.


  • Best,
    Phil.
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11404
        
      81

    Hi Phil,
    Originally posted by Philippe Maquet:
    Sorry not to have joined quicklier. I am ill and I am afraid I'll spend more time today in my bed than on JV

    Sorry to hear that. Take it easy, and get well soon.
    I'll try not to convert too many people to fat client while you are sick
    Regards, Andrew
    S Perreault
    Ranch Hand

    Joined: Oct 29, 2003
    Posts: 37
    Philippe,
    I hope you feel better. Nothing stinks more than being sick on a weekend
    Andrew,
    Thank you for the extremely detailed post. I sort of understood the first 3 points but now I definitely understand them, thanks!
    Good to see that the RMI-JRMP is the default. It would stink to fail the project because you forgot to add a flag. Of course, I plan on getting an ANT script together (I am already using CVS) to compile the project. Do you know if it's okay to use ANT and CVS for the project? (Removing all of the CVS folders of course)
    Also, do you believe that one can learn most things needed to start with RMI and Sockets without having to purchase a book? I have some experience with sockets when I recently implmented UPS/FedEx tracking with my current client. I have used RMI about 5 years ago when I was a Comp Sci student for a very small project.
    I will definitely create two small projects testing each to see which one I believe is 'better' for this size project.
    Thanks again guys, someday I hope to be as much help with the newbies as you both are.
    Perogi.
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11404
        
      81

    Hi Perogi,
    Originally posted by S Perreault:
    Do you know if it's okay to use ANT and CVS for the project? (Removing all of the CVS folders of course)

    No problems. You can use whatever development tools you like, as long as there are no dependancies on those tools.
    Originally posted by S Perreault:
    Also, do you believe that one can learn most things needed to start with RMI and Sockets without having to purchase a book?

    It depends on the individual. There are some excellent tutorials on both RMI and Sockets on the Sun site (and others), it just depends on whether you as an individual can learn from online sources, or whether you prefer the book in front of you.
    Since you already have experience with both sockets and RMI, I don't think you should have problems picking them up again.
    Regards, Andrew
    [ November 01, 2003: Message edited by: Andrew Monkhouse ]
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Perogi,
    My main idea is that Sockets are easier

    Well, I would argue it.
    I used RMI. There are many adv. and disadv.
    My main point was that Sockets are neither elegant, nor reusable. The applications themselves must define protocol of bytes to pass back and forth. The developer must concentrate on protocol, rather then the business logic.
    RMI is an advanced technology for distributed programming. The remote interface must be defined between client and server. This interface looks almost the same as a local one. It hides network and serialization protocol.
    The developer can concentrate now on business logic. It suits more to the overall concept of Java.
    Trade-off: less control over threads and some deployment efforts. Both of these "problems" are not problems for me and shouldn't be for anyone else,
    except Phil .
    There are many more adv. of RMI (e.g. mentioned by Andrew, - dynamic stubs and so on).
    Sockets, for me, are just step in the past.
    Best,
    Vlad
    [ November 02, 2003: Message edited by: Vlad Rabkin ]
    Adrian Muscalu
    Ranch Hand

    Joined: May 08, 2000
    Posts: 73
    Vlad,
    I haven't given much thought of RMI vs Sockets yet since I'm still battling with the lock strategy. However, I don't think that "the sockets are just a step in past". It's about having control vs giving control and is about scalability. You write your own protocol but how often will that change? I'd think the sockets are more scalable. For those where is specified the application might be used in WEB later, I see easier to NOT have a different server (RMI server) working in the background.
    But I might be wrong...

    Adrian
    [ November 02, 2003: Message edited by: Adrian Muscalu ]

    SCJP2, SCWCD
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Vlad,
    Sockets, for me, are just step in the past

    It's nice that you didn't add ", better suited to very old developers."
    Best,
    Phil.
    [ November 02, 2003: Message edited by: Philippe Maquet ]
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Phil,
    It's nice that you didn't add ", better suited to very old developers."

    Hm... By the way, how old are you?
    Just a joke.
    Sockets and RMI are BOTH a good choice. The point is if you chose something you should be able to justify your decision. You must convince yourself first so strongly, not to have troubles to convince Sun...
    Best Wishes to Socket fans,
    Vlad
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Vlad,
    Phil:
    It's nice that you didn't add ", better suited to very old developers."
    Vlad:
    Hm... By the way, how old are you?

    43 ( ~ )
    It's young enough to keep in top shape, old enough to be experienced, but unfortunately too old to get a position as a junior in a (for me) new technology. This may explain why I choose on purpose the hard ways in all parts of this assignment. My main aim with this assignment is getting experienced, cert being - let's say - just a side effect.
    And you Vlad BTW ?
    Best,
    Phil.
    [ November 03, 2003: Message edited by: Philippe Maquet ]
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Phil,
    I am 28.
    Phil:
    ... This may explain why I choose on purpose the hard ways in all parts of this assignment.

    I don't think so
    Best,
    Vlad
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    That I chose the hard ways ?
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Phil,

    Nope.
    I don't think that:
  • you are old
  • it is the reason you choose not easy ways to develop


  • I din't want to say that you choose easy ways to develop.
    Best,
    Vlad
    P.S. I respect your way to develop, because it is your own way you chose and don't let anybody to make you give up.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Perogi asks about RMI vs. Sockets
     
    Similar Threads
    NX: Bodgitt and Scarper and design/synchronization questions
    NX: Bodgitt & Scarper: Documentation Format
    Bodgitt & Scarper contractors / FBN ???
    NX: Bodgitt and Scarper unbooking contractors
    Database Location - Bodgitt & Scarper