Discussions

Performance and scalability: HTTP or RMI-IIOP

  1. HTTP or RMI-IIOP (2 messages)

    I have a Swing application that needs to get data from a database. Rather than directly access the database, I want the clients to hit a middle-tier component which will access the database and return the results. Transactions are not required as this is a read-only access and the middle-tier component can help cache some of the frequently required data.

     This intermediary can be either a set of servlets or stateless EJBs with other helper classes. I believe HTTP will be slow as compared to RMI-IIOP and slightly more cumbersome to access given that serialized Java objects will be returned. My immediate thought is to put up a set of stateful session EJBs that access the data and return Java objects to the Swing client.

     Can you share your ideas on this and suggest other alternatives?

    Threaded Messages (2)

  2. HTTP or RMI-IIOP[ Go to top ]

    I have a Swing application that needs to get data from a database. Rather than directly access the database, I want the clients to hit a middle-tier component which will access the database and return the results. Transactions are not required as this is a read-only access and the middle-tier component can help cache some of the frequently required data.This intermediary can be either a set of servlets or stateless EJBs with other helper classes. I believe HTTP will be slow as compared to RMI-IIOP and slightly more cumbersome to access given that serialized Java objects will be returned.

    If your are in a Java-only world and have no firewall issues I'd use simple plain RMI. Why even consider something else?
    My immediate thought is to put up a set of stateful session EJBs that access the data and return Java objects to the Swing client.

    BTW, if you expect more than a couple of clients simultaneously accessing your middleware component(s), I'd seriously strive for a *stateLESS* design.

    Good luck!
    Stefan
  3. HTTP or RMI-IIOP[ Go to top ]

    How about using Hessian? We have good experiences on using Hessian to communicate between a WebStarted thick client and application running in a J2EE application server.

    With Hessian, you can implement a binary webservice as a servlet extending HessianServlet class. Then you just map the servlet to some url in web.xml and use the service methods just like any other java object. All you need to know at the client side is the url to the web service and how to use HessianProxyFactory to fetch an instance of an object implementing your service interface.