Should I be using RMI

Question

Hi,
Two questions really:
1) Should I be using RMI
2) If so how much of the program should use RMI
I am about to start building a database driven application. However, I am unsure whether to make it 2-tier not using RMI or 3-tier using RMI.
The various different clients all need to add,update and delete things in the database which will be done over JDBC. However, all the clients also need to be notified of certain activities taking place on any of the other clients, for instance if one client adds a record the other clients need to be informed of this.
I assume that the broadcasting of the these messages to the listening clients would need to be done using RMI or some other distributed systems technology. Is this a correct assumption?
However, when one of the clients does a query on the database should this be done directly, bypassing the servers. I was thinking this as passing record sets from the database server to the application server and then onto the client applicaiton would result in significant network traffic. Therefore, I assume, that for the other parts of the applicaiton which don't involve the broadcasting of information to all the clients I should just make the database connections within the client programs and connect directly to the database. Is this also a correct assumption?
Any comments on this would be much appreciated.
Thanks in advance
Robert Miles

Answer 1

Here's the approach that my company took for a database-centered set of applications.
We wanted multi-user access, and we wanted an object interface, because there is substantial application logic that we preferred to put on the server.
The design we created uses
o apiobjects, which are held by clients, and which in turn simply hold references to
o apiserver objects, which belong to a client session, and which in turn simply hold references to
o dbobjects, which belong to the system, and represent the database data being used by one or more active clients.
Note that in this design, RMI is hidden in the apiobjects. It is important, but not to the client, whether or not the apiobject holds real data, or accesses the server and returns the data.
One other note about this architecture: The data is organized into an object tree. The top of the tree is an "entry" object which the client instantiates and uses to log in; the login returns a "server" object, which is the root for accessing all other objects.
For event notification we ask the client to define an event manager, and tell the "server" about it. (There are also some fairly extensive filter definition capabilities.) On the server side, and event manager, when told about an event, searches the sessions for managers to be notified, and notifies them by calling a method on the event manager.
What about other applications accessing the DB? Well we are still discussing this.
o One consideration I can think of is locking. If all your locking can be convincingly consigned to the DBMS, then maybe you can implement a completely-separate access path.
o Another consideration - one not necessarily shared by my colleagues - is that the boundaries around applications are not always rigid, and the first time a new application crosses the RMI-vs_other boundary, well you'll have some work to redo.