expert's advise: RMI vs HTTP


General J2EE: expert's advise: RMI vs HTTP

  1. expert's advise: RMI vs HTTP (3 messages)

    I'm working in a distributed application and I found two solutions to my problem, but I don't know what's the better.

    I've a swing client that needs connect to a server for to get business data, and I thinking in this solutions:

    note: the data is sended as XML.

    No 1. Using Http
    Swing client ==========> Servlet ====> Business Objects

    No 2. Using RMI
    Swing client ====rmi====> Business Objects

    I don't know the advantages or disadvantages for each option.

    what you think that is the best for send and receive xml data. ?


    Threaded Messages (3)

  2. expert's advise: RMI vs HTTP[ Go to top ]

    My suggestion will be to use HTTP rather than RMI.

    RMI is generally used between two server components to communicate, the reason being, they will be tightly coupled to finally form a blotware application. Something on the note of inter bean communication will be done on RMI, reason being that whole application has a single entity with integration of these beans and hence RMI which is more tightly coupled scenario with performance and marshaling advantages is a best option.

    In your case you just want xml data to be retrieved from server, I guess if you go for HTTP then over all architecture is kind of loosely bind and hence your server component can be changed pretty quickly and easily. with HTTP your client has more freedom for connectivity, something on the line that down the line if you want to browse some other information then you can just add a servlet and make a call to it.

    HTTP use for client side will be always a preffered thing over RMI. imagine scenario that as the number of clients increase or may be you want your swing client to be ported to web based interface then you just need to develop view part for browser and the backend part will remain the same.

    final opinion is
    HTTP is much much better over RMI for your kind of case.

  3. expert's advise: RMI vs HTTP[ Go to top ]

    Hi David,

    There is no clear winner of these two options. The better approach depends on several factors. I'm not going to list all of them and repeat part of the previous poster's reply rather I'll try to complement his thoughts with two more issues.
    1. Usually Swing clients communicate with business logic over RMI. This way you get rid of the additional overhead HTTP introduces. I don't know if this is a must but you might not be required to transfer the data using XML and if that's true you should consider RMI as a valid approach.
    2. If your clients are located at places where you do not have control over the firewall policy it could turn out that the only way to implement it is over HTTP. RMI supports HTTP tunneling but if your client has remote objects invoked by the server (often you don't have such and most likely you don't have too) RMI won't do the job.

  4. expert's advise: RMI vs HTTP[ Go to top ]

    Just two comments to previous responses

    1. If your client is not "read-only" and your update functionality has a transaction semantics, I would suggest using EJB (rmi) backend because it's transactable (via JTA). There's no way to propagate a transaction context via HTTP.

    2. If your client needs to show data changes asynchronously (read-only or not), HTTP again looses it's advantages because it's one-way protocol and your client will need to send poll requests each n seconds. That would increase the server throughput and will require to maintain the client state on the server to determine what changes must be sent. JMS backend seems to be more straightforward solution in that case.