Overall Architecture

[Jim Bedenbaugh]

From the Instructions:
There are three key parts: the server-side database with network server functionality, the client-side graphical user interface, and a client-side database client part that handles the networking on behalf of the user interface.
I'm reading these instructions again and I'm confused. What exactly does client-side database client mean?

[Michael Morris]

Hi Jim,
Actually, the client-side graphical user interface, and a client-side database client part that handles the networking on behalf of the user interface is generally what you would consider the "client" in whole. The GUI part of the client displays the table data and facilitates booking and searching and the network part gets the remote (or local) connection to the database and actually makes the calls on the public Data interface. So don't fret on it too much and design your client in such a way that the two parts are clearly separated in your client.
Hope this helps,
Michael Morris

[Jim Bedenbaugh]

Michael,
Thanks for the reply. I think I may have a real design problem here.
I have a Model-View-Controller. The Model maintains data state, the View just has the methods to build the screen and the Controller directs all activities between the other two. Any requests for a connection, searches, etc, are passed to a DataClient from the Controller.
Here's where I think I have the problem:
DataClient extends UnicastRemoteObject and implements DataInterface. DataInterface extends Remote and contains all the Data methods (as well as lock(), unlock(), criteriaFind() and a few more I added). As needed, DataClient will pass requests on to Data, etc.
The server creates the RMI registry and then creates and instance of DataClient. DataClient and DataInterface (along with the LockManager) sit on the server side.
When the Controller handles the connection request, it uses a Connection factory that either just returns a local reference to the DataClient or it makes the RMI connection, which returns a stub (DataClient_Stub) to DataClient.
It looks like I've got the DataClient on the wrong side of the connection if I understand the instructions.
I think I'm gonna be sick. . .

[Sai Prasad]

Jim,
In addition to DataClient, you need a Factory object in the server side which is instantiated by the RMI server during startup. You don't want to instantiate the DataClient by the RMI Server standalone java application. Instead, the server Factory object has a method to return the remote object DataClient to the client. You do have the DataClient at the right side of the connection.

[Jim Bedenbaugh]

Originally posted by Sai Prasad:
Jim,
In addition to DataClient, you need a Factory object in the server side which is instantiated by the RMI server during startup. You don't want to instantiate the DataClient by the RMI Server standalone java application. Instead, the server Factory object has a method to return the remote object DataClient to the client. You do have the DataClient at the right side of the connection.

Sai,
Thanks for the reply. After further contemplation, I think I have the "DataClient" on the right side of the the connection, too. I think I should just rename my "DataClient" to DataServer, because that is what it actually is.
I'm not sure I understand why I need a Factory object. Could you explain? Thanks.

[Michael Morris]

Hi Jim,
The reason you need a factory is that you don't want all clients connecting to the database through the same stub. If you do it that way, you'll have to control all threading issues, etc. Why not let the RMI server do it for you? Each client should have a unique connection into the database that way there is less danger of them clobbering each other.
Hope this helps,
Michael Morris

[Jim Bedenbaugh]

Originally posted by Michael Morris:
Hi Jim,
Each client should have a unique connection into the database that way there is less danger of them clobbering each other.

Ummm. . .I'm really unsure now of my design.
See if this sounds right:
On the server side, I have a class that creates the rmiregistry. The class rebinds my DataServer to the registry. dataServer provides access to the database.
On the client side, I have a Connection Factory. If the request is to go through the network to get to the database, I do a Naming.lookup and return a stub reference.
Does this mean that when each client does a lookup, it gets it's own thread or am I returning the same thread each time?

[Samual Harvey]

Originally posted by Sai Prasad:
Jim,
In addition to DataClient, you need a Factory object in the server side which is instantiated by the RMI server during startup. You don't want to instantiate the DataClient by the RMI Server standalone java application. Instead, the server Factory object has a method to return the remote object DataClient to the client. You do have the DataClient at the right side of the connection.

This means when the server starts it instantiates the factory, but the server itself is a RMI server and the starting of it means RMI reference should be instantiated so why do you have to consider instantiating the local reference thru factory. Thus in your case when the factory is instantiated by server it will always return the remote reference when the method inside factory is called from the client. Does that means that the client will never call the factory class method directly (which I assume it should call it directly in the local mode).
I guess my question would be does your client calls factory object directly in local mode, as it is not doing any server connection in local mode. If yes then we can have DataClient object directly inside the Server class as mentioned by Jim.
Thanks.

[Michael Morris]

Hi Jim,
Umh.. well, think about it: three clients connect to the registry and receive a diffent stub into the same DataServer object. Sounds a little chaotic, doesn't it? Not that you can't figure out a way to control the chaos, it's just so much simpler to bind a connection factory to the registry and have that factory issue unique connection objects (which also extend UnicastRemoteObject) but that are not bound to the registry. That also solves the client ID problem: the client is uniquely identified by his connection object.
Hope this helps,
Michael Morris

[Nate Johnson]

I did mine exactly as Michael is describing it... so I would agree with his solution

[Jim Bedenbaugh]

Originally posted by Michael Morris:
Hi Jim,
. . .it's just so much simpler to bind a connection factory to the registry and have that factory issue unique connection objects (which also extend UnicastRemoteObject) but that are not bound to the registry. That also solves the client ID problem: the client is uniquely identified by his connection object.

Okay, so I would have a ConnectionFactory extending UnicastRemoteObject on the server. It returns a reference to my DataServer, which also extends UnicastRemoteObject
and and a DataInterface?
Further, the ConnectionFactory implements an interface that extends Remote also so I can get the DataServer references?

[Nate Johnson]

Here is what I did...

DataInterface has all public methods of Data
RemoteDataInterface implements Remote and DataInterface (some people will argue that this is an unneeded interface, but I just liked having it )
RemoteData extends UnicastRemoteObject and implements RemoteDataInterface -- it is the remote connection to Data
RemoteDataFactory extends UnicastRemoteObject and is bound into the registry -- its only purpose is a getConnection method that creates a new RemoteData and returns it to the client. This RemoteData can be used as the client id for locking because it is going to be unique.

Hopefully that helps some and didnt give away too much...

[Jim Bedenbaugh]

Originally posted by Nate Johnson:
Here is what I did...

DataInterface has all public methods of Data
RemoteDataInterface implements Remote and DataInterface (some people will argue that this is an unneeded interface, but I just liked having it )
RemoteData extends UnicastRemoteObject and implements RemoteDataInterface -- it is the remote connection to Data
RemoteDataFactory extends UnicastRemoteObject and is bound into the registry -- its only purpose is a getConnection method that creates a new RemoteData and returns it to the client. This RemoteData can be used as the client id for locking because it is going to be unique.

Hopefully that helps some and didnt give away too much...

Nate,
Thanks very much. This pretty much confirms what I asked about. I can refactor my code without too much trouble to implement.
I'm also beginning to realize I took some very bad advice early on from someone when I started this certification. I should have not just jumped in and just started doing the project as suggested.
Oh well, a tough lesson learned and probably cost me a couple of months in time.

[Anonymous]

There is a very handy paper entitled something like "Implementing Factories Using RMI". I've seen links to it in other discussion threads. It explains this factory approach perfectly.

[John Smith]

There is a very handy paper entitled something like "Implementing Factories Using RMI". I've seen links to it in other discussion threads. It explains this factory approach perfectly.

You probably meant this article: Applying the Factory Pattern to RMI. And yes, the factory concept is nicely explained in that article.
Eugene.
[ August 12, 2002: Message edited by: Eugene Kononov ]

[Anonymous]

Thanks, Eugene... that's the one. Could not recall the title. Just got back from vacation in Seattle. Brain is still on Orcas "island time"

[Samual Harvey]

Guys can you explain why Factory class has to extend UnicastRemoteObject and what is the difference between RemoteDataInterface and RemoteData class and why we need both of them?
Thanks.

[Nate Johnson]

I can tell you why I used a RemoteDataInterface and a RemoteData, but this was just my approach...
RemoteDataInterface implements my DataInterface and Remote.... I could have had RemoteData just implement my DataInterface and have DataInterface implement Remote, but I also use DataInterface for the local implementation.... I dont want any local stuff to be a "Remote" object.
RemoteData is my remote object that makes calls to the Data object. It also handles the database locking/unlocking.
I use a RemoteFactory because I wanted unique objects for locking/unlocking and didnt want to handle threads myself (let the RMI do it for me). Both files needed to be Unicast because they are both being used by my client... the client gets a ref to the factory and then the factory gives the client a RemoteData.
It is up to you how you want to do it and if you can defend it, you will probably do just fine.

[John Smith]

Guys can you explain why Factory class has to extend UnicastRemoteObject ?

UnicastRemoteObject is a convenience class to export the remote object, i.e. make it available for remote clients. Your client presumably resolves the factory by looking up the registry and invokes a method on that factory to get another remote object that represents your connection. You don't have to extend UnicastRemoteObject class, but if you don't, you need to manually code the "exportability" of your remote object.

and what is the difference between RemoteDataInterface and RemoteData class and why we need both of them

The remote object must have an interface and an implementation, that's all. Think of these as the standard "plumbing" behind the RMI concept.
Eugene.
[ August 12, 2002: Message edited by: Eugene Kononov ]

[Samual Harvey]

Originally posted by Nate Johnson:
RemoteDataInterface implements my DataInterface and Remote.... I could have had RemoteData just implement my DataInterface and have DataInterface implement Remote, but I also use DataInterface for the local implementation.... I dont want any local stuff to be a "Remote" object.

Let me ask you further based on the following,
If I dont have RemoteDataInterface then DataInterface extends Remote. All the methods in the interface also throw RemoteException. Now you can implement in both ways I mean both in local and remote way. The difference can be that the local implementor class (DataAccessLocal) just implements the DataInterface and its methods does not throw any RemoteException and creates a Data object for local data access. Whereas, the DataInterface can be implemented by the Remote Class (DataAccessRemote) which extends UnicatRemoteObject and implement the DataInterface. Its methods throws the RemoteException. The Factory class not can return a reference of either DataAccessLocal or DataAccessRemote, based on the type of connection.
Do you think this is correct?

[Michael Morris]

Hi Samual,
That's essentially what I did except that only remote objects were returned by a factory. All of my connection objects, whether remote or local, were created by a ConnectionDirector so for a local connection, the client simply requested that a LocalConnection be built. My conection factory, whenever getConnection was called, requested that a remote connection be built by the ConnectionDirector and that object was returned. Like you, I only had one interface which extended Remote but local connections obviously never threw a RemoteException.
Hope this helps,
Michael Morris

[Samual Harvey]

Nate,
Based on ur inputs, I further assume that on the client side, ur client when in local mode uses the DataInterface object directly which provides a direct access to the data object, and when in remote mode calls RemoteFactory which returns a RemoteData.
As per the factory design the factory class hides the object type from the user and it should return the different type of object based on the data provided to it, but your factory will always return you a RemoteData object, so is this just the name or the concept that your factory class is using.
[ August 12, 2002: Message edited by: Samual Harvey ]
Michael, I have same question for you, about the name of factory class. If the factory class always returns you Remote object why you call it factory class. I was thinking if using Factory pattern then the factory should return either local or remote, but then the question is where does the factory class resides, on server side or on client side.
[ August 12, 2002: Message edited by: Samual Harvey ]

[Michael Morris]

Hi Samual,
On the server. There is really no point in having a factory on the client since the client either connects to a single local object or is issued a connection to a single remote object via the remote connection factory. So you are correct in saying that in my design only remote objects were returned by the connection factory. That's not completely true, I had a third connection type called ServerControlConnection which was used by the server to lock and close the database. That type of connection was not available remotely though.
Hope this helps,
Michael Morris

[Nate Johnson]

Originally posted by Samual Harvey:
Nate,
Based on ur inputs, I further assume that on the client side, ur client when in local mode uses the DataInterface object directly which provides a direct access to the data object, and when in remote mode calls RemoteFactory which returns a RemoteData.
As per the factory design the factory class hides the object type from the user and it should return the different type of object based on the data provided to it, but your factory will always return you a RemoteData object, so is this just the name or the concept that your factory class is using.

Well, I have two kinds of factories in my project... the client has a ConnectionFactory that has a getConnection method. Based on command line parameters give at startup, the ConnectionFactory will return a DataAccess (interface) that is really a LocalData object or a RemoteData object. The client couldn't care less which it was since all of the methods are that same for both.
Then I have a factory on the server that right now just creates RemoteObjects... I guess right now it is just a "single product factory" and could be extended in the future to return different types of objects.
It is really up to you how you want to implement your project
Did I answer your questions?
[ August 12, 2002: Message edited by: Nate Johnson ]

[Samual Harvey]

Originally posted by Michael Morris:
That's not completely true, I had a third connection type called ServerControlConnection which was used by the server to lock and close the database. That type of connection was not available remotely though.

Can you elaborate more on ServerControlConnection . You said it is used by server to lock and close the dataabse. Does ServerControlConnection has a data object reference to it. Does it uses the client id to lock the database. I have not thought anything about lock/unlock. Can you explain more on this.

Thanks.

[Michael Morris]

Hi Samual,
I diverged from the instuctions by neither modifying (except to fix the depracated methods and to make some cosmetic changes) Data nor subclassing it. I used a Builder Pattern to create composites, hence the ConnectionDirector class. My ServerControlConnection could only lock the database (no matter what value was passed into the lock method, it just called lockManager.lock(-1, this)) and close it. All the rest of the public Data methods were no-ops, just empty methods. My RemoteConnection was not allowed to close the database and lock and unlock were no-ops for the LocalConnection. This design was easy to implement and made more sense to me than anything else, but I'm not suggesting that anyone else go this route. The most important thing is to make your design clear enough for yourself especially and anyone who is stuck with maintaining your code later.
Hope this helps,
Michael Morris

[Jim Bedenbaugh]

Originally posted by Michael Morris:
Hi Samual,
I diverged from the instuctions by neither modifying (except to fix the depracated methods and to make some cosmetic changes) Data nor subclassing it. I used a Builder Pattern to create composites. . .

Michael,
I did the same thing, including a reference to Data in my DataServer (which subclassed UnicastRemoteObject), only if I tried using the reference to Data as an instance variable, I get a Serialization error. How do you overcome this?

[Michael Morris]

Hi Samuel,
Well to be network transportable via RMI, a class must either implement Remote or Serializable and Data does neither. So, for a Data object to be directly accessible through an RMI server, you need to tag it with one of those interfaces.

I'm a little confused on your design. Will each of your clients have a different Data object or will there only be one with all clients referncing the one? I'm guessing the latter. This is an approach I haven't seen before but I can see how it could work. The only real problem I see with it is the probability of network congestion but that's a performance issue which we probably shouldn't concern ourselves with in this assignment.
Hope this helps,
Michael Morris

[Michael Morris]

Originally posted by Michael Morris:
...but I can see how it could work.

I had a "brain fart" on this one, getting old you know. If you serialize Data, then each client will get a copy of Data and not a reference to the Data object on the server. I don't think that's what you're shooting for.
One further point, Data contains a reference to a RandomAccessFile which is not serializable either. You may be "barking up the wrong tree" here. Without quite a bit of modification, RMI will not be able to marshall and unmarshall a Data object.

Michael Morris
[ August 12, 2002: Message edited by: Michael Morris ]

[Sumesh Aravindan]

Hi Nate,

DataInterface has all public methods of Data
RemoteDataInterface implements Remote and DataInterface (some people will argue that this is an unneeded interface, but I just liked having it )
RemoteData extends UnicastRemoteObject and implements RemoteDataInterface -- it is the remote connection to Data

Nate, I just wanted to clarify this - you said, RemoteDataInterface implements Remote and DataInterface. How is this done? If I implement, then i can't call it an interface, right?

[Sumesh Aravindan]

Hi Nate,
I am reposting my question..please reply

DataInterface has all public methods of Data
RemoteDataInterface implements Remote and DataInterface (some people will argue that this is an unneeded interface, but I just liked having it )
RemoteData extends UnicastRemoteObject and implements RemoteDataInterface -- it is the remote connection to Data

Nate, I just wanted to clarify this - you said, RemoteDataInterface implements Remote and DataInterface. How is this done? If I implement, then i can't call it an interface, right?

[Nate Johnson]

I should have said extends... sorry.
I used two interfaces, unlike a lot of the people on this site... I used a DataInterface that has all the methods in Data declared and then I have a RemoteDataInterface that extends DataInterface and Remote. Then my LocalData implements DataInterface and my RemoteData implements RemoteDataInterface. Then my client only has to deal with "DataInterface" obejcts. I added a RemoteDataInterface because I did not want my DataInterface to implement Remote (since it can be a local connection as well).

[Sumesh Aravindan]

Thanks Nate!
But I am still confused with this line you wrote

and then I have a RemoteDataInterface that extends DataInterface and Remote

How can I extend both?

[Nate Johnson]

Originally posted by sumesh_aravind:
Thanks Nate!
But I am still confused with this line you wrote

How can I extend both?

They are all interfaces. An interface can extend as many other interfaces as it wants. Then a class that extends the first interface (RemoteDataInterface) would have to implement all the methods in all of the interfaces (DataInterface and Remote) up the chain.
Make sense?

[Sumesh Aravindan]

Sorry Nate..please ignore my last question...I just got confused...
Looks like I need more coffee these days

[Sumesh Aravindan]

Thanks once again....i figured that out after I posted my question.

[CyJenny Wong]

Hi Nate,
I just wonder what Exceptions you throws in
DataInterface's methods as RemoteDataInterface will also extends DataInterface & Remote

[Nate Johnson]

Originally posted by CYJENNY WONG:
Hi Nate,
I just wonder what Exceptions you throws in
DataInterface's methods as RemoteDataInterface will also extends DataInterface & Remote

I threw both DatabaseException and RemoteException from my DataInterface class.

[CyJenny Wong]

Hi Nate,
Thanks for the reply!
One more thing I don't really understand is that
as you're have 2 separate interface why you still have your RemoteDataInterface extends DataInterface & Remote. What's the point of doing that this way having Remote interface extending local one.
My approach is just have 2 separate interface one for local & one for remote, will this make any difference??

(111) -- for local db access
public interface DatabaseService {
 declare all public methods of data class and throws only DatabaseException
}
(222) -- for remote db access
public interface RemoteDatabaseService extends Remote {
  declare all public methods of data class and throws both DatabaseException & RemoteException
}

[Michael Morris]

Hi CYJENNY,
That's OK but it's not very OO and you run into a problem on the client in that you have to deal with two different interfaces. If you extend the interface that declares all of Data's public members, then the client can make all calls on the parent. I just used one interface for both local and remote but most have chosen Nate's approach, using a parent and child interface. I would strongly suggest that you not have separate unrelated interfaces for local and remote as you propose.
Hope this helps,
Michael Morris