• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Comment on the point �Overall Architecture�

 
Amund Frislie
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
�The remote client code that you write must provide all the public methods of the suncertify.db.Data class�. Why do you think Sun has made this requirement? Does this imply that any "larger" methods containing multiple Data methods (e.g. booking) should be on the client side only? Would lead to a lot of network chatting...
Amund
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That was my conclusion, yes. This requirement only makes sense if the Data interface represents the split between client and server. Together with the code-for-reuse requirements, it nudges you into building a classic fat-client/database-server application.
- Peter
 
dave wav
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter,
Could you elaborate more on this topic?
any "larger" methods containing multiple Data methods (e.g. booking) should be on the client side only?
The methods such as booking should be included in the Data Interface provided remotely to the client or just reside in the client side, I am not very clear about this.
last thing, in this project, Do we favor to build a classic fat-client/database-server application or thin client? what's the pros and cons?
Thanks in advance,
dave
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by dave wav:
any "larger" methods containing multiple Data methods (e.g. booking) should be on the client side only?
Yes.
Now where did I have my boilerplate architecture diagram again... (rummage) ah, here.
GUI <==> Business Layer <==> Persistence
Adding bookFlights() and what have you to your server interface is mixing up the business layer API, which is
  • Abstract
  • Completely application specific
  • Coarse grained
  • with the persistence layer (database) API, which is
  • Low level
  • Completely generic
  • Fine grained
  • Can you see why this would be bad OO design? It would inhibit reuse as well, because the server code you write would no longer be reusable beyond the cut-and-paste sense
    By requiring that you have a client-side object that implements "all the public methods in Data" (you should immediately think: "Interface!"), they are effectively saying "the persistence API should be exposed to the client application". That only makes sense if the business layer is part of the client application itself.
    Consider the alternative -- the business layer on the server. Then all you would and should expose on the server is a high-level, abstract API with methods such as bookFlights and searchFlights. The client would not know or care about find(), criteriaFind(), lock(), unlock(), etc, or even that the backing store is a database at all. In an enterprise-type J2EE application this would be the way you'd probably do things, the business API would be implemented by a stateless session EJB. Behind the scenes, invisibly, it would use entity beans, JDO-based Java code, or something similar to interface with a relational database. You would never let the client talk to the database directly.
    last thing, in this project, Do we favor to build a classic fat-client/database-server application or thin client? what's the pros and cons?
    They correspond broadly to the two architectures I contrasted above. I don't think the pros and cons matter much, the decision has effectively already been made for you.
    - Peter
    [ April 20, 2002: Message edited by: Peter den Haan ]
     
    Debra Bellmaine
    Ranch Hand
    Posts: 40
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Peter,
    I'm really glad you explained the two architectural approaches so succinctly...the second (thin client) approach seems so much more correct to me that I would have just blundered along without really getting that it is not what is called for.
    I'm still not sure about what is actually involved in a "client program that implements the same public methods as the Data class." Obviously an interface that is implemented by both Data and ClientData... as I am writing this I'm thinking the following:
    1. GUI listeners are notified of user action.
    2. Controller methods are invoked by listeners to determine how to handle gesture (assume gesture is OK action on book flight dialog).
    3. Controller invokes dataClient method to:
  • handle any necessary business rules
  • invoke same method on remote Data

  • 4. If we implemented Observer pattern, remote Data would fire change notificaton to the view(s), etc. (I know this part is not required - what is your 2cents on doing this anyway?)
    If this is the correct approach, then yes, the client would be fat with the business logic residing there.
    Another question. You wrote
    it is mentioned that the database should be designed for re-use in different projects

    I've seen this stated elsewhere in this forum, and I have read and re-read the Application Submission doc, but I've not found where this is stated. Can you point me to the actual verbage? I don't dispute that this is probably desirable, but I'm going nuts thinking I'm overlooking something major.
    Thanks,
    Debra
    SCJP
    [ May 04, 2002: Message edited by: Debra Bellmaine ]
     
    Peter den Haan
    author
    Ranch Hand
    Posts: 3252
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Debra Bellmaine:
    I'm still not sure about what is actually involved in a "client program that implements the same public methods as the Data class." Obviously an interface that is implemented by both Data and ClientData...
    Not necessarily. For example, the client-side object in question could simply be the RMI stub for a DataInterface implementation that actually lives on the server (for specifics, search this forum for the "Connection" approach).
    4. If we implemented Observer pattern, remote Data would fire change notificaton to the view(s), etc. (I know this part is not required - what is your 2cents on doing this anyway?)
    Personally I wouldn't touch it -- it adds too much complexity for a feature that is out of scope. The client application has to export remote objects, the notification mechanism would be asynchronous with the threading issues that come with it... I assume the instructions still state that your design should be comprehensible to a junior programmer.
    The rest looks good.
    Another question [...]
    Unfortunately, I can't access my instructions at the moment. I did my assignment two-and-a-half years ago and I know for a fact that things have changed (for example, I had to provide a data import utility). My instructions stated that Fly By Night expected to use the database code in other projects and that I should code for such reuse. Yours may not -- don't doubt your sanity, do a string search for "reuse" or "re-use"
    - Peter
     
    Debra Bellmaine
    Ranch Hand
    Posts: 40
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Peter,
    Thanks for the swift reply. I initially was thinking that the stub would suffice for the client-side data implementation, but this would then not come into play when running locally. What say you about that?
    I am relieved to hear that you did the assignment a while back...that explains the discrepancy. The current instructions do not tell us that re-use is a requirement at all. The fact that the Data class and its helpers are so generic is the only suggestion that this may be the case, but it is apparently not now a requirement.
    With regard to Observer, yes, the instructions do still state that the design should be comprehensible to a junior programmer. Too bad, I did Observer implemented within an MVC architecture in a Sun instructor-led class, and it really was not too complex, but I've gotten enough negative feedback within the forum to think it could work against me.
    muchos gracias,
    Debra
    [ May 04, 2002: Message edited by: Debra Bellmaine ]
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic