socket vs RMI

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.

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).

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.

Hi,
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.

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.

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).

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.

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.