CODEWITHSUNDEEP
javanetwork-programmingprotocolsrmi
J. Stoever
J. Stoever

Reputation: 876

Network communication options in Java (Client/Server)

There is RMI, which I understand to be relatively fragile, direct Socket connections, which is rather low level, and Strings, which while about as solid as it gets seems to be the metaphorical PHP.

What less basic options do I have for internet based Client/Server communication ? What are the advantages/disadvantages ? What are some concerns I should take into consideration ? Third party library suggestions are fine, as long as they stay platform independent (i.e. no restrictive native code).

Looking for options, not a definite answer, so I'm leaving the details of my own requirements blank.

Upvotes: 1

Views: 739

Answers (2)

user207421
user207421

Reputation: 311048

What does 'relatively fragile' mean? The issues with RMI have to do with it being a large superstructure on a narrow foundation, and specifically that it has a large reliance on DNS and Object Serialization. The closer you are to the silicon, the less 'fragile' any program becomes, but the more code you have to write. It's a tradeoff. I'm not a one-eyed RMI supporter, despite having written a book about it, but 'fragility' is too strong a word. It does what it does, and it does that reasonably well. RMI/IIOP does it even better in many respects if you need large-scale scalability. If your view of the world is an at-most-once remote method call without too much security, RMI/JRMP will give it to you. The further you get from that model the harder it becomes to apply.

Upvotes: 0

millhouse
millhouse

Reputation: 10007

As you specified "internet based", there's a lot to be said for an HTTP-based, RESTful approach (I've highlighted some concerns you should consider):

Pros:

  • You can use/abuse one of the myriad web-tier frameworks for the server side (e.g. Spring MVC, Play!)
  • The low-level work has been done on client-side (Apache HTTPClient)
  • Plain-text protocol is easy to debug on the wire
  • Tons of tools available to help you debug the interactions (e.g. SoapUI) - you can pretend to be client OR server and so develop in isolation until the other end is ready
  • Using a well-known port (80/443) makes punching through corporate firewalls a whole lot easier

Cons:

  • There's a fairly major assumption that the server will be doing the lion's share of the work - if your model is "inverted" then it might not make much sense to be RESTful
  • Raw performance will be lower than a bits-on-the-wire socket-based approach
  • Plain-text protocol is easy to sniff on the wire (SSL can remedy this)

Upvotes: 2

Related Questions