• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RMI, business logic

 
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 )
     
    author and jackaroo
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 225
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 12200
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic