Java RMI and binding

[JTan]

As I am not very familiar in RMI itself, I need some advice on how to bind the server and the client (GUIs) together.

I was thinking of implementing one remote interface for all the GUIs in the client program but I am not very sure whether is it feasible. Can anyone advise?

I am also thinking if the binding is successful, could the remote methods invoke any methods in the server so that the transactions can be carried out.

 

[sedj]

http://java.sun.com/docs/books/tutorial/rmi/

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[Diancecht]

http://www.oop-reserch.com/archives.html

http://www.javaworld.com/javaworld/javaqa/1999-04/05-rmicallback.html

 

[JTan]

I managed to figure out the previous queries.

Now I am encountering another question.

How should I pass the request from my GUIs to the server? Should I create a client program comprising for all of the GUIs and use that particular client program to bind to the server? Or can I invoke the remote methods directly from each of the GUIs?

Anyone who has some knowledge of RMI can help me in this?

 

[sedj]

In RMI there are two concepts - client and server.

There is usually only one server.
There are usually many clients.

For each client, you should bind to the server, and execute the required method.

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[JTan]

Yah...correct

I am talking about the client side. I created the GUI interfaces for users to execute the tasks, so I am wondering if I need to create a client program for the interfaces so to talk to the server? Or can I invoke the methods directly from the GUIs itself?

Thanks!

 

[timw]

I'd advise using the Business Delegate pattern. You create delegate classes which expose your business functionality to your clients, but make calls over the wire to the server to satisfy that functionality. Any remoting exceptions coming from the RMI layer are handled inside your delegates, only business exceptions are propagated. This will keep your clients decoupled from the underlying connection architecture, be it distributed or local.

Tim

 

[JTan]

Hi Tim,

could you elaborate further on the Business Delegate pattern?

So during a GUI program start-up, the delegate classes would be spawned automatically and then invoke remote methods on the server when required?

If it is supposed to work like that, I should create an object references to that class whenever there is an task request?

 

[timw]

To fully benefit from the Business Delegate pattern, you'd want a set of interfaces for the delegates, and have a class factory to instansiate the relevant implementation classes. The factory could cache the instances so they are only created once.

It may be that your 'client-facing' classes on the server already implement some business interfaces, in which case have your delegates implement these. Then, if you ever want a version which runs standalone on one machine, you can completely remove the remoting layer by having your delegate factory return instances of those 'client-facing' classes. The GUI will never know the difference.

Tim

 

[Diancecht]

Argh, patterns.

What tim is trying to say is that you should define the interaction with the server in some kind of "functional classes" with some interfaces.

Then, the GUI will call those methods with those classes.

In case that those objects are reusable, you can store them in a factory. Another approach is, if possible the use of static methods so the factory is not needed.

Cheers,

Dian

 

[sedj]

I call them "Helper" classes eg :

public class RmiHelper {
  MyRMIInterface server = null;

  public void callSomeRemoteMethod(String param) throws IOException {

  }

  public String getSomeRemoteData() throws IOException{

  }

  private void connectToServer() {

  }

Or something like that - then your GUIs can call this helper class to call methods, get data, set data etc.

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[timw]

... what Tim is saying is that this 'problem' has been solved before by using the Business Delegate and Service Locator Patterns. Naming these gives JTan something to Google on and learn the issues involved. He can then decide to follow the patterns, or go his own way armed with a deeper understanding of the challenges.

Tim