• 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

message from server

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,
I am using RMI for the network mode.
A class called DataServer which extends UnicastRemoteObject and implements an Interface called IData (all public methods from Data.java).
within the class DataServer, I implements a method called bookFlight.
Method bookFlight does locking a record, read, modify and unlock.
when I read a record, got latest seat number from Data.java, then comparing with the request seat number from GUI, either insufficient or ok.
I want to provide a message to the client if the seats not enough for reservation. Because this is in the network mode, client is talking to server using RMI, so how do I implement this functionality talking back from server to client?
can someone give me some idea? appreciated in advance.
dave
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by dave wav:
within the class DataServer, I implements a method called bookFlight.

Thereby mixing general-purpose and application-specific code, mixing two completely different levels of abstraction, and inhibiting the reuse of a potentially completely reusable server.
Not a good idea. Consider moving bookFlight() to the front end. Remember this architecture:
UI <=> Business Logic <=> Persistence
Whether the UI is Swing, JSPs, or something else; whether the business logic is a conceptual layer in the front end (as, IMHO, in FBN) or an EJB container; whether the persistence is an enterprise-level SQL database or a flat file; whether it all runs inside one JVM or each layer is represented by a farm of heavyweight multi-CPU servers -- you will find these layers, at a minimum, in every well-designed non-trivial software system. Well, almost every
Mix the layers, and the abstraction represented by each layer, at your own peril.
- Peter
 
dave wav
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter,
Thank you for your response and I agree with you.
But how about the client(UI)? should I retrieve remote methods within Business Logic or at UI?
I mean the code like this:
Registry remoteRegistry = LocateRegistry.getRegistry(host,portNumber);
data =(IData)remoteRegistry.lookup(url);
I think that Business logic is acting like client,(between Bus. logic and data server)
so the above code should be in the Business logic class. am I right?
Thanks,
dave
 
dave wav
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Peter,
Now I have another question, if I retrieve the remote methods within Bus. logic class,
I need import Suncertify.db.* package and catch
database exception within Bus. logic class,
I am not sure if this is the right way to do?
could you give me your opionion?
Thanks,
dave
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by dave wav:
But how about the client(UI)? should I retrieve remote methods within Business Logic or at UI?

It's the business logic, not the UI, that talks to the database. This would still be the client application though; as argued in this thread, I think that you are nudged towards incorporating UI and business logic in a classic fat client.
As regards the code that actually acquires the database server connection -- I personally preferred to keep the business logic completely database-type-agnostic and set up the connection in a separate chunk of initialisation code.
Regarding exception handling, I generally tend to catch exceptions only at the level where I actually know what to do with them. In FBN, that would be the UI level -- the only thing you can reasonably do is pop up an error message box, and that's the UI's task. Others would perhaps argue that you should catch RemoteException and DatabaseException and wrap them inside some BusinessLogicException so as to isolate the UI from the underlying database technology. They would have a point, and in a larger system I'd probably have done it.
- Peter
[ April 19, 2002: Message edited by: Peter den Haan ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic