• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RMI or TCPIP Socketing

 
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can anyone briefly explain the pros and cons of RMI and TCPIP socketing? I am gonna to choose RMI to implement my network part, but in fact I do not know what are the pros and cons for those two approaches. I think this may be one of the questions coming out in the written examination.
 
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is oversimplification of the differences but I feel the main one is data marshalling. RMI takes care of that for you whereas you're on your own with sockets.
 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll try to expand a bit on the previous reply... But take this
with a grain of salt because I have not really begun the server-
side of the assignment.
Sockets+Serialization: On the client side, you send a Request
to the server to "do something." You open a socket, send the
Request through, and wait for a Response. The Request contains
some sort of command, and some data in Serialized form. The
server processes the request and sends back a Response on
that socket connection. The Reponse likely contains a
result code of some sort (eg. SUCCESS, FAILURE, NODATA, etc...)
as well as the data returned in serialized form if any exists.
The client deals appropriately with the Response. End of story.

RMI: You set up methods on your server to handle client requests
inside of a class. In RMI these methods are special in that they
are Remote methods. With the appropriate magical incantations
involving reviving the skeletons of the dead and stubbing your
toes while dancing inside a pentagram of upside-down nails, you
can call these methods from the client without really having to
know as a programmer that these methods are actually executed on
the server. The existence of the server is relatively invisible
to the programmer.
Comparing these two approaches seems a bit weird to me because
taken to its logical conclusion, the first approach may
involve writing your own version of RMI completely from scratch.
Obviously doing that would be well beyond the scope of this
assignment. The first approach does seem more "open" to me in
that you can (sort of) publish your protocol without any
particular implementation attached to it at all. The second
approach is more "closed" in that it would be difficult for
someone else to write a client for your server without your
cooperation. The second approach may involve more overhead
because it has a generic mechanism for "marshalling" which as I
understand it is the process of handling the request and sending
back a response. In terms of transparency, scalability, and
easy of programming (once the basic framework has been set up,
which I understand can be somewhat of a challenge with RMI),
I think RMI has the upper hand. For the application we have to
build, it seems to me that the only really meaningful reason
to use sockets+serialization would be if one could not use
RMI for some reason.
This is an issue I have found stimulating to think about, so
if anyone has any comments or feedback, I would love to see it.
Vlad

 
Rudy Yeung
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Vlad,
Thanks for your long reply. I will slowly absorb in it and do some studying myself based on what you have written. As I have said, this may be one of the exam questions.
 
vladimir levin
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just one more quick note. You know, I thought I was being a bit
clever in saying that with sockets+serialization you could
allow other people to write clients for your application without
giving them more than just a protocol spec, but since objects
are being serialized, that's not so true. If the data passed
back and forth were also defined in some standard way, then
you could do that -- the web protocol http is a good example
of that approach. Anyway, since we are serializing objects,
anyone implementing a client would need the object definitions
so it's not such an open architecture. Anyway, I ramble but
the open-architecture thing isn't really relevant. =)
Vlad
 
Rudy Yeung
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Though I am not familiar with both RMI and TCPIP socketing, I read a networking book talking about both the approaches. It stated that RMI makes use of the RMISecurityManager class to verify a user's identity and allows different users the different levels of access to a remote object. On the socketing side, it has the SSL layer doing the same kind of job. On the RMI side, however, you can extend the Activable class instead of UnicastRemoteObject to make your RMI server request on demand. On the other hand, the socketing approach does not have the request on demand feature though again I do not know the pros and cons of the UnicastRemoteObject and Activable class. I would like to hear some comments from others.
 
reply
    Bookmark Topic Watch Topic
  • New Topic