Graham W Lowe

Axl,
This guide rocks!!! It looks to be very comprehensive and well organized. Thanks for all of your hard work.
Graham

Hi Mike,
I uploaded my assignment May 30th. I took my written exam on June 3rd. I received my results on June 19th. Sun claims that the marking process should take about 4 weeks from the time you take your written exam (that's assuming that Prometric sends Sun your exam promptly). The grading of your assignment will not begin until you've uploaded your assignment and Sun has received your written examination from Prometric. In my case, the process only took a little over 2 weeks. If you are worried about a mix-up you may want to write Sun and ask them if they've received your written examination yet.
Best of luck Mike!
[ June 20, 2002: Message edited by: Graham W Lowe ]

Thanks for the congrats Clement.
It took me about 2 hours to prepare for the follow-up examination. I reviewed my source code at a high-level and drew up some UML diagrams to review how the classes fit together (the diagramming was probably overkill but I am a very visual person). I then re-read my design document to review my design decisions (this was probably the most helpful).
The follow-up exam is dead easy once you've done the assignment and necessary documentation. It's more or less an exercise in proving that you actually did the work.
Regards,
Graham

I just received my results for the SCJD and I would like to thank everyone in the Developer Certification forum for their help. I received a score of 145/155. The break down was General Considerations(maximum = 58): 55 Documentation(maximum = 20): 20 GUI(maximum = 24): 21 Server(maximum = 53): 49
I chose to use RMI over serialized objects. I modified the Data class instead of extending. I implemented client-tracking for locking within a DataProxy class and implemented the actual database locking within the Data class. I used the Unreferenced interface to handle the release of locks for crashed clients. Design patterns I used included Factory, Proxy, MVC, and Data Access Objects and Value Objects for the persistence layer.
Thanks again to everyone for their help. On to SCWCD!
Regards,
Graham

Dean,
In your design, is your flight object utilizing your flight services facade controller for actions on the database (i.e., all calls to the Data class are made from your services facade controller)? From your description, it sounds like you have some layering going on--services layer, business layer and presentation layer.
I just wanted some clarification on this because I'm doing something similar in my assignment.
Thanks

After finishing the database and client networking portion of the assignment, I am beginning to have concerns about the overall complexity of the architecture I've designed. I worried that I might be docked marks for going to far.
Basically along with the low level database I have created a Data Abstraction Layer composed of a FlightDAO (Data Access Object) which handles all persistence related operations. I'm using RMI as the underlying network protocol and the DAO is simply passed a reference to either a DataProxy or Data object depending upon whether local or remote database access is required.
On top of this layer, I have a Business Layer, which handles all the business logic related to searching and booking flight. In this layer I have 2 classes a ReservationSystemController which delegates it's actions to a TravelAgentDelegate class which encapsulates any business logic for searching and booking a flight (e.g., don't book more seats than are available for a flight). It accomplishes this through interacting with FlightDAO passing it Flight value objects for either searching or for booking. When searching, the FlightDAO dynamically constructs queries in the String format acceptable by the Data.criteriaFind method using reflection on the Flight value object to call the appropriate accessor methods.

My justification for this extensive layering approach is that Fly By Night is a growing travel agency whose persistence needs may soon outgrow their home grown database. In fact, they may even in future move to a web based UI. By decoupling the 3 layers--the persistence access, the business logic and finally the presentation--they should be able to swap to a vendor database or xml persistence engine or Servlet/JSP presentation layer without affecting too much code.
Has anyone who passed gone to this level of abstraction? I'm worried about the statement, "A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient than the simple one."