File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes RMI, business logic Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "RMI, business logic" Watch "RMI, business logic" New topic
Author

RMI, business logic

Seb Mathe
Ranch Hand

Joined: Sep 28, 2005
Posts: 225
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 :


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 )


    Regards,<br />Seb<br /> <br />SCJP 1.4
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11460
        
      94

    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


    The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
    Seb Mathe
    Ranch Hand

    Joined: Sep 28, 2005
    Posts: 225
    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
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11460
        
      94

    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
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: RMI, business logic