RMI, business logic

[Seb Mathe]

First point
There's a lot of posts about "putting the business logic server side" or "just exposing database on the server".

I agree with most of arguments for both cases, even if I already had a little preference for the first one.

But with my assignement (B&S 2.3.3), I think I've found one major argument for the first solution (putting business logic server-side).
Because my DB methods does'nt use a cookie for locking purposes, the only way I've found for remembering which client holds a lock on a record is to store the caller Thread.
(Considering that I don't want a Data instance for each client for some reasons.)
Considering also that I will use RMI for networking, putting only the database on the server will cause problems.

Am I wrong or do I have forgotten something ?


Second point
It concerns the non-networked mode : in this mode, I think the client has not to deal with RemoteExceptions...
So in my interface which defines business methods (we'll name it "Service"), the methods does'nt throw RemoteException but something like ServiceException.
But exposing such methods server sides using RMI implies that methods declaration throws RemoteException.
(This thread discusses this point in detail.)
So today, my design looks like that :

 
                                           (Remote)
                                              |
                                              |
 Service                                RemoteService
    |                                         |
    +----------------+                        |
    |                |                        |
    |                |                        |
ServiceImpl  RemoteServiceWrapper      RemoteServiceImpl

Where :

Service interface defines business methods.

ServiceImpl is the major implementation (deals with database)

RemoteService extends Remote, redefine Service methods with throws RemoteException clauses

RemoteServiceImpl is the object bounded in RMIRegistry, and delegates calls to a Service instance

RemoteServiceWrapper delegates calls to a RemoteService instance.

I've also a Factory for creating Service instances : ServiceImpl in case of non-networked mode, RemoteServiceWrapper otherwise.

My problem is that I introduce 5 classes/interfaces with the same methods signatures and some complexity for the junior programmer...

I know we have to keep the solution simple, but I don't like the idea to put only "I have do this like that because it's the most easy/simple and requires less efforts" in my choice.txt !!

Hope I've bean clear...

(I'll keep my other questions for next time )

[Andrew Monkhouse]

Hi Seb,

Because my DB methods does'nt use a cookie for locking purposes, the only way I've found for remembering which client holds a lock on a record is to store the caller Thread.
(Considering that I don't want a Data instance for each client for some reasons.)

If you had not made your decision not to have a Data class instance for each client then you wouldn't be reliant on the thread . Sort of catch-22 there.

Another alternative is for you to add your own cookies to the remote methods, and map them to the thread numbers used internally by the Data class.

Regarding your second issue - making a solution "simple" is not just about reducing number of classes - in fact it can be just the opposite. Adding classes may make the overall solution easier to work with / understand / enhance / debug. So I would not worry about adding classes.

Regards, Andrew

[Seb Mathe]

Thanks Andrew,

But I've read my instructions again, and the term "Database server" is used several times...
Mmmmm... Putting business logic server side looks like an "application server", not a database one...

Just for my knowledge : Where does "Sort of catch-22" come from ?

[Andrew Monkhouse]

Hi Seb,

Catch-22 is a term coined by Joseph Heller in his book of the same name, often used to refer to a situation where circular logic is being employed (especially if it forces a situation that is undesirable (from a certain perspective)).

From the wikipedia entry for catch 22:

Within the book, "catch-22" is a military rule, the circular logic of which most notably prevents anyone from avoiding combat missions:

One may only be excused from flying bombing missions on the grounds of insanity;

One must assert one's insanity to be excused on this basis;

One who requests to be excused is presumably in fear for his life. This is taken to be proof of his sanity, and he is therefore obliged to continue flying missions;

One who is truly insane presumably would not make the request. He therefore would continue flying missions, even though as an insane person he could of course be excused from them simply by asking.

I was using catch-22 to refer to my reversal of your logic for using threads - I completed the circular logic .

Regards, Andrew