wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Should lock methods be callable by the client 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 "Should lock methods be callable by the client" Watch "Should lock methods be callable by the client" New topic
Author

Should lock methods be callable by the client

Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11503
    
  95

Hi everyone,
I know a lot of people have only been exposing "business methods" to the client (so "bookContractor()" or "bookRoom()") rather than allowing the client to call the lock(), update(), and unlock() methods directly.
But I wonder if this meets the requirements?
With the Fly By Night Services assignment, it was fairly explicit that the client had to be able to call equivelant methods to all the public methods in the Data class. Therefore they had to be able to call lock() directly.
Looking at the new assignments, I see some people have requirements similar to:
  • You must implement "Network server functionality for the database system"
  • "Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the [provided] interface"


  • My reading on those two requirements is that the server must be providing the same methods to the client as used by the Data class itself.
    ---
    Some of the assignments have a lock method that returns a cookie which must be used in the database modification methods and in the unlock method. I see that as further evidence that the lock method should be called from the client side.
    Consider the normal "booking" method: if it is on the server side, the cookie provides no benefit whatsoever. If you did not have the cookie requirement, the code would still work in an identical manner.
    The cookie only makes sense if the client has to receive it and work with it.
    ---
    Now I know people have passed the assignment when they only exposed business methods to the clients. This may have been because they gave good reasons for doing so in their design decisions document. Or it may have been pure luck. I don't know.
    So what do y'all think?
    Regards, Andrew


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

    Joined: Jul 07, 2003
    Posts: 555
    Hi Andrew,
    this problem bothers me two.
    I am sure it better to have 3-Tier architecture, but I have send an e-mail to Sun for 1,5 month ago and I've got no answer. So I decided to avoid it.
    I have published my mail in the thread:
    Mail to Sun
    I will repeat it here, since it is more suitable to this topic:


    Hello,
    I have decided to apply 3-tier architecture in my assignment (URLyBird 1.1.1).
    I have provided new local and remote interfaces to allow high level access to the database:
    public interface DBServer {
    public void book(RecordModel record)
    throws RecordNotFoundException,
    DBConcurrentModificationException,
    IOException;
    public RecordModel[] find(RecordModel criteria) throws IOException;
    public MetaData getMetaData() throws IOException;
    }
    public interface DBServerRemote extends DBServer, Remote {
    }
    The interface for database access defined by Sun, which will be available only for local use, because it will be used by implementation of DBServer interface, not the client application:
    package suncertify.db;
    public interface DB
    {
    public String[] read(int recNo) throws RecordNotFoundException;
    public void update(int recNo, String[] data, long lockCookie)
    throws RecordNotFoundException, SecurityException;
    public void delete(int recNo, long lockCookie)
    throws RecordNotFoundException, SecurityException;
    public int[] find(String[] criteria);
    public int create(String[] data) throws DuplicateKeyException;
    public long lock(int recNo) throws RecordNotFoundException;
    public void unlock(int recNo, long cookie)
    throws RecordNotFoundException, SecurityException;
    }
    The only access point to work in network mode will be then DBServerRemote interface, which provides only 3 methods required by the my client application.
    There is a following requirement in the assignment:
    The following are the "top level" features that must be implemented:
    A client program with a graphical user interface that connects to the database
    A data access system that provides record locking and a flexible search mechanism
    Network server functionality for the database system
    My question is:
    -if my design satisfies requirement,
    -Do I have to provide additionally a Remote interface, whose methods would have the same signatures and functionality as local DB interface, except throwing RemoteException,
    since I don't understand what interface do you mean by saying "Network server functionality for the database system ".

    ... no answer....

    Best,
    Vlad
    Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    My instructions match those cited by Andrew, and I agree that they seem to require that the server have the same lock() and unlock() methods which use cookies. Except that if we use RMI there's the additional fact that from the client's perspective, the server throws additional RemoteExceptions from all its methods, which means that it can't implement the interface specified; it can only implement a nearly identical interface which allows additional exceptions. We can get around this by providing a client-side wrapper which converts the RemoteDB interface back to a DB interface. A really strict interpretation of the spec migt forbid this, but since they've explicitly said RMI is acceptable, we have to assume that they didn't intend the spec to be quite this strict. Still, it seems safest for the server's interface to be as close as possible to the given "data access" interface, and for extra effect use a wrapper which makes it match the required interface exactly.
    Apparently Sun's interpretation is actually looser than this, since people have passed without exporting lock() and unlock() to the client at all. But to be safe I'd avoid this type of design. In the real world we'd usually be able to get better feedback on this sort of question, and we might even have an opportunity to get them to revise their silly API. But that's not the case here, and I prefer to err on the side of caution when interpreting Sun's specs.
    The cookie only makes sense if the client has to receive it and work with it.
    Well I don't really think the cookie makes much sense at all. But I agree that, given that the specifications went to the trouble of putting it in there, it seems that someone, somewhere thinks that cookies are useful and important, and though I don't agree I figure it's best to make them happy by requiring cookie usage on the client as well.
    Vlad: I think that your mail is probably too long for Sun to want to answer. Most importantly, after you describe your design at length, you as "is this acceptable"? As a general question, this is something that Sun is not going to answer - they're not going to review people's designs before submission. They probably get a lot of questions like this, and it sounds like you want general reassurace your design is OK. They don't want to get into that. I know that your question is really more specific than that - you're not looking for general reassurance, you want to understand this requirement in particular:
    Your server [...] must provide locking functionality as specified in the [provided] interface

    I'd suggest starting out with this and saying you don't understand that requirement, because for RMI it's not possible for a Remote object to have that interface. The question (the only question you expect them to answer) is whether it's acceptable to have a server whic implements nearly the same interface as the one provided, except that it also throws RemoteException?
    I think the answer really has to be "yes", or no one would be able to pass with an RMI solution, and we'd have heard about it. So I'm not realy worried about this. But if you want Sun to answer, you probalby need to focus the question as specifically as possible. Makesure it's clear the question is "what do your requirements mean?" rather than "is my design OK?".
    Hope that helps...


    "I'm not back." - Bill Harding, Twister
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Jim,
    Vlad: I think that your mail is probably too long for Sun

    You are absolutely right, but I will not annoy Sun with questions.
    As Phil said: The boss is in the vacation in Australia (Andrew, just a joke ), and his cell phone is off.
    The only thing which I have change is :
    added two new adapter interfaces local/remote for the client which change slichtly a signature of methods: String[] read (int recNo)-> RecordModel read(int recNo), int[] find(String[] criteria) -> RecordModel[] find (Hashtable criteria) and so on to make info and changes on the database transparent to the client. I am sure it is going to work.
    Andrew, I haven't actually seen anybody hiding lock/unlock passing the test.
    Strange, but if you have seen anybody the one must be a challenger.
    Best,
    Vlad
    [ September 25, 2003: Message edited by: Vlad Rabkin ]
    Ulrich Heeger
    Ranch Hand

    Joined: Jun 06, 2003
    Posts: 266
    Hi Andrew,
    you wrote:
    The cookie only makes sense if the client has to receive it and work with it.

    Do you mean that the business logic should be displaced from the server to the client? That for example for booking all the procedures:
    lock
    update
    unlock
    should be made from the client side?
    Regards
    Ulrich
    Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    Do you mean that the business logic should be displaced from the server to the client?
    That's what Andrew and I are saying, yes - based on the stated requirements. (Even though there's a good chance Sun is not so strict here, we believe in not taking unnecessary chances.) However when I said " The cookie only makes sense if the client has to receive it and work with it", what I really meant was that the cookie requirement is a silly design, and I resent Sun for imposing it on us. But as long as the server is being forced to use it, the client might as well suffer too.
    Tony Collins
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    Well I'm going to hide lock, I'll tell you if I fail. I just think it's silly not to hide the database layer from the gui.
    It's only another fee if I fail.
    Anyway in my instructions it only says the server must implement the locking functionality nothing about providing a interface, though I may be wrong, probably am.
    Anyway my instructions say
    Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.

    Doesn't say that the server must make provide this interface. Not as I understand American anyway.
    Tony
    [ September 25, 2003: Message edited by: Tony Collins ]
    Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    Well I'm going to hide lock, I'll tell you if I fail.
    Excellent, we need guinea pigs for this sort of thing.
    I just think it's silly not to hide the database layer from the gui.
    I agree. It's just when the silliness is imposed by the client, and they make a bunch of noise about "must" requirements and automatic failure, I don't feel too guilty if the result is silly-looking.
    Sudhansu Pati
    Ranch Hand

    Joined: Sep 23, 2003
    Posts: 77
    Hi guys,

    ===========================================
    Here is my opinion about hiding lock
    ===========================================
    You can create another layer called DBAdapter as follows.
    DBAdapter{
    private Data d;
    public bookHotel(){
    d.lock();
    d.update();
    d.unlock();
    }
    }

    From the client GUI, just call (new DBAdapter).bookHotel(). Then you are not worried about hiding the locking mechanism from the client GUI. It is already hidden by another layer.
    ======================================
    Why there is a lockCookie
    ======================================
    What I understood so far (please corret me if I am wrong) is when you lock, you get a cookie. Now when you want to delete or update a record, you must provide the same cookie. I am not sure about your assignment, but my assignment requires to pass the lockCookie as a parameter to update and delete method.
    That means before update or delete, you must acquire a lock first. Inside the update and delete method, you must check if the lockCookie is same as the cookie value of the locked record.
    Having said all that - I think sun wants us to do lock-update-unlock and lock-detele-unlock sequence instead of just update and delete.
    Disagree ??


    Sudhansu<br />SCJP, SCWCD, SCBCD, SCJD, SCEA, SCDJWS
    Arun Kumar
    Ranch Hand

    Joined: Aug 29, 2003
    Posts: 67
    Ok after much thinking about this last night, Andrew and Jim are right. Its not worth (atleast to me) to take so much effort to do this assignment, learn so many new things and better ways, and fail just because i implemented a better way.. i dont want to be a guniea pig...
    I will get back to the model where i send the cookie all the way to the client, that is the GUIController.
    Arun
    [ September 25, 2003: Message edited by: Arun Kumar ]

    SCJP (1.4), SCWCD, SCJD
    Bharat Ruparel
    Ranch Hand

    Joined: Jul 30, 2003
    Posts: 493
    I think I am with Tony here. I have URLy Bird 1.3.1 and I can't find anything in its problem statement that conveys anything about the client MUST provide the locking functionality. In my opinion, the server-side locking is much more elegant and realistic. As a matter of fact, my lock and unlock methods do not mention cookies at all! Is that not a sufficient indication that SUN has decided to allow us to CHOOSE either the client side or the server side locking?
    Bharat


    SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
    Arun Kumar
    Ranch Hand

    Joined: Aug 29, 2003
    Posts: 67
    Bharat,
    I think the decision depends on the signature of your lock method.
    The signature of the lock method given to me returns a long value. But i think in your case (if i can remember right) it is void. Thats why you are using the Data.this for unique lock.
    So for those whose signature doesnt require to return a long value, can hide the lock/unlock from the client. But others IMO it is safer to call the lock,update,unlock all from the client side....
    Arun
    Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    [Bharat]: I think I am with Tony here. I have URLy Bird 1.3.1 and I can't find anything in its problem statement that conveys anything about the client MUST provide the locking functionality.
    Hmmm, OK. I have B & S (Contractors) 2.1.1, and have the following under "Locking":
    Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.

    Same thing Andrew quoted originally. If indeed you don't have this or somethign equivalent in your assignment, then you do have more flexibility allowed. Cool. Wanna trade assignments? Naah, I'm just about done with mine, no need to switch now.
    Tony: does your assignment have a section like the one I just quoted above? Which assignment do you have? Please include version number. Often these differences don't break down along URLyBird/B&S lines; instead some versions of URLyBird and B&S do things one way, and other versions of URLyBird and B&S do them another way. Which is further reason to be carefully evaluating what anyone else says here, and decide what works best for you.
    [Arun]: I think the decision depends on the signature of your lock method.
    Yes, this is another important variable, one known to be independent of whether you have B&S or URLyBird.
    Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    Suds - yes, I think most of us have something like your DBAdapter class somewhere in our design. The question (well, one of them anyway) is: should the DBAdapter be on the client, or on the server? There are two basic possibilities:
  • Client GUI calls DBAdapter which calls through network to Server which calls DBAccess class
  • Client GUI calls through network to Server which calls DBAdapter which calls DBAccess class

  • Those of us with instructions which require the server to have a lock() methodprobably should do #1, because the DBAdapeter won't have a lock method. Those of you without this instruction have more flexibility to improve your design.
    Regarding your bookHotel() method - how do you know that some other client hasn't just booked the hotel room, perhaps just before your own request? What happens if you book the room again to someone else? Is ther eany way to prevent this?
    Other than this issue, I thouk your understanding of the lock and cookie requirements is good. (Oh, and you probably also need to check if the cookie is valid when you unlock.)
    Tony Collins
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    Well my version 2.2.2 and it says
    Server
    Required Interface
    Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:
    package suncertify.db;
    public interface DBAccess
    {
    // Reads a record from the file. Returns an array where each
    // element is a record value.
    public String [] readRecord(long recNo)
    throws RecordNotFoundException;
    // Modifies the fields of a record. The new value for field n
    // appears in data[n]. Throws SecurityException
    // if the record is locked with a cookie other than lockCookie.
    public void updateRecord(long recNo, String[] data, long lockCookie)
    throws RecordNotFoundException, SecurityException;
    // Deletes a record, making the record number and associated disk
    // storage available for reuse.
    // Throws SecurityException if the record is locked with a cookie
    // other than lockCookie.
    public void deleteRecord(long recNo, long lockCookie)
    throws RecordNotFoundException, SecurityException;
    // Returns an array of record numbers that match the specified
    // criteria. Field n in the database file is described by
    // criteria[n]. A null value in criteria[n] matches any field
    // value. A non-null value in criteria[n] matches any field
    // value that begins with criteria[n]. (For example, "Fred"
    // matches "Fred" or "Freddy".)
    public long[] findByCriteria(String[] criteria);
    // Creates a new record in the database (possibly reusing a
    // deleted entry). Inserts the given data, and returns the record
    // number of the new record.
    public long createRecord(String [] data)
    throws DuplicateKeyException;
    // Locks a record so that it can only be updated or deleted by this client.
    // Returned value is a cookie that must be used when the record is unlocked,
    // updated, or deleted. If the specified record is already locked by a different
    // client, the current thread gives up the CPU and consumes no CPU cycles until
    // the record is unlocked.
    public long lockRecord(long recNo)
    throws RecordNotFoundException;
    // Releases the lock on a record. Cookie must be the cookie
    // returned when the record was locked; otherwise throws SecurityException.
    public void unlock(long recNo, long cookie)
    throws SecurityException;
    }
    Any unimplemented exceptions in this interface must all be created as member classes of the suncertify.db package. Each must have a zero argument constructor and a second constructor that takes a String that serves as the exception's description.
    Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.
    Network Approaches
    Your choice of RMI or serialized objects will not affect your grade, but no other approach is acceptable. In either case, the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely. No authentication is required for database access.
    Locking
    Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
    Return to top

    I think the word Server is confusing as it seems to be used as a generic term for database layer & networking layer and I'm guessing this is where the confusion is arising.
    Also note this line
    There are three key parts: the server-side data management system, the client-side GUI, and the network connection between the two.

    Tony
    [ September 26, 2003: Message edited by: Tony Collins ]
    Tony Collins
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    When I book my ticket to see Wayne Rooney and the ten no marks that play around him, the Server locks my seat while I pay, which part of the server I don't know( though I can bet its at the back end) but its still the server. The networking provides a connection to the server.
    That's just my understanding someone else could see it differently, though I think a common failure of (us) Software Enginners is to think in terms of implementation not overall design.
    It's a tough call I must admit but I going for the sound design.
    Tony
    Tony Collins
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.

    Also note the bold
    Tony
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Jim,
    Regarding your bookHotel() method - how do you know that some other client hasn't just booked the hotel room, perhaps just before your own request?

    I agree with you on issues. I use lock/unlock on the client, but this argumente above is not a problem:
    public book(Record record) throw RecordAlreadyModifiedException;

    The biggest argument to follow Jim and Andrew is following requirement from Sun:
    What you must do
    The following are the "top level" features that must be implemented:
    A client program with a graphical user interface that connects to the database
    A data access system that provides record locking and a flexible search mechanism
    Network server functionality for the database system

    Network server functionality for the database system !!!
    Tony, Ulrich, Phil, Bharat everybody who decided to make a 3-tier , you ignore this statement whole the time!!!
    Do you know the difference betwenn database functionality and business functionality? Database is back-end, and business is middleware!
    book is not database functionality - it is business-tier (middlewhere) functionality!!!
    You AdapterRemoteInterface will have business methods available on the network, not a database functionality!!!
    Before going too deep in theory, can anyone from "guinea pigs" resist this argument!?

    Best,
    Vlad
    Tony Collins
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    Hi Vlad,
    We define Server differently. I see Server as the whole Server side application. I access a server through a network connection.
    Also look over the sentance I have posted and particully the bold part of it. To me it sugests that buissness methods use the locking functionality on the Server( As a whole).
    Tony
    [ September 26, 2003: Message edited by: Tony Collins ]
    Tony Collins
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    Vlad this is the definition of Server from my instructions, this is defined in the introduction and index section.
    Server - The data server and its network connection

    And this is a quote from my Server Section
    Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above


    Check your instructions, we may solve this at some point.
    Tony
    [ September 26, 2003: Message edited by: Tony Collins ]
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11503
        
      95

    Hi Tony,
    I think you inadvertantly just provided me with more amunition
    You quoted the following previously, however I am changing which parts are bolded:
    Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.

    Taken in conjunction with your later quote defining what is a "server":
    Server - The data server and its network connection

    I think that the locking functionality must be provided over the network connection.
    When I book my ticket to see Wayne Rooney and the ten no marks that play around him, the Server locks my seat while I pay, which part of the server I don't know( though I can bet its at the back end) but its still the server. The networking provides a connection to the server.

    I don't know that a database server does the locking in that circumstance.
    In that circumstance, the remote view that you get on your web page is not doing any locking. However if you are designing your client application using MVC architecture, then your View in the client application you are writing will not be doing any locking either.
    In booking the ticket to see the show, it could be the Model at the ticketing agency that is doing the locking of records as it communicates to a database server somewhere else within the ticketing agency network.
    Your comment about booking the ticket, or booking through Amazon, is confusing two important issues:
  • the web page that you are seeing when booking over the web is not the entire "client application" it is only the remote view for the client application.
  • the client to the back end database is not a human, but a program that we are writting. So it is not the case that you can say that you as a human are not locking a record. It is a question of whether the "client application" which sits on the web application server is locking the record - and I submit that we don't know whether the client application is locking the record or not.


  • Regards, Andrew
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Tony,
    Tony:
    We define Server differently
    Server - The data server and its network connection
    Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.

    Andrew:
    I think you inadvertantly just provided me with more amunition

    Exactly!!!
    Look, what is data server? Data server is a server to access data.
    What should be methods to access data? To my opinion set/get/lock/unlock
    books() method is NOT a data accessing method, it is a method containing additional logic.
    You all argue all the time about lock/unlock. Let's look at this differenetly:
    Hiding lock/unlock means that update() method has no any sense. We need book method, which is NOT data accessing method. It is business method.
    You cann't say that a server containing method book() is a Data Server, it is a Business Server!!!
    We are assigned to provide Data Server, not a business one!!!
    Best,
    Vlad
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi all,
    Andrew, the question "Should lock methods be callable by the client ?" could be rephrased as "Should the client be able to call DBAccess methods directly ?" == "Should the server expose its DBAcess interface to the clients ?", or "Are we allowed to build a 3-tiers client-server system or is the 2-tiers design required ?".
    You and Jim think that the 2-tiers design is a "must" and you base your choice essentially upon two points :
  • An excerpt of the instructions : "Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided

  • above."
  • The fact that - for assignements which make use of lock cookies - the latter don't make sense if locking is managed server-side.


  • I read the instructions once more, extracting all parts which relate - closely or not - to the 2-tiers / 3-tiers design choice (I list them in the order they appear in the instructions) :
    Instructions:
    The IT director does not anticipate much reuse of the first Java technology system, but intends to use that system as a learning exercise before going on to a web based system.

    3-tiers is a better design with the web in mind : if the business methods are implemented server-side, they can be reused by a JSP application. If they are coded client-side, they have to be rewritten for the web.
    Instructions:
    The following are the "top level" features that must be implemented:
    * A client program with a graphical user interface that connects to the database
    * A data access system that provides record locking and a flexible search mechanism
    * Network server functionality for the database system
    The work involves a number of design choices that have to be made.

    As a 3-tiers supporter, I don't like the sentence "A client program ... that connects to the database", but I think it's compensated by "Network server functionality for the database system".
    And I love the last one : "The work involves a number of design choices that have to be made."
    Instructions:
    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.

    A 3-tiers design is simpler client-side and hardly less simple server-side. But it's far (not a little) more efficient (see discussion at the end of this post).
    Instructions:
    The main architecture of the application must be a traditional client-server system. There are three key parts: the server-side data management system, the client-side GUI, and the network connection between the two.

    As a 3-tiers supporter, I don't like the words "must be a traditional client-server system". But as the 3-tiers design is well-known for years now, is it less "traditional" than the 2-tiers design ?
    Instructions:
    The program must be able to work in a non-networked mode. In this mode, the database and GUI must run in the same VM and must perform no networking, must not use loopback networking, and must not involve the
    serialization of any objects when communicating between the GUI and database elements.

    You may guess that I don't like the words "when communicating between the GUI and database elements".
    Instructions: (about the client-side GUI)
    The user interface for this assignment must satisfy the following criteria:
    * ...
    * It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.
    * ...
    * It must allow the user to book a selected record, updating the database file accordingly.

    In that only section dedicated to the client, as a 3-tiers supporter, I love that section because they describe the job to be performed in business terms : search and book. Better, the search functionality (exact match) is not directly compatible with the findByCriteria database functionality (wild-card match).
    OTOH, I don't like that much the words "updating the database file accordingly".
    But after all, isn't it what the client does in a 3-tiers system anyway ? "Accordingly" does not mean "directly", right ?
    Instructions:
    Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.

    This is probably one of the best parts of the instructions for the 3-tiers advocates : if we decouple the client job from the low-level database job, it's possible to change the db system (to a commercial one like Oracle - quite probable when they'll move to the web) "with minimal disruption to the users when this occurs.". Client code doesn't need to change, and users just need to reconnect to a new server. (BTW, with my sockets implementation which supports call-backs, it can even be done without any disruption to the users at all (by broadcasting a call to a callback method like please_reconnect_to_new_server(newIPAddress, newPort) ).
    Instructions:
    Server
    Required Interface
    Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:

    DBAccess is clearly presented under the "Server" section. Good point IMO for the 3-tiers supporters.
    Instructions:
    Locking
    Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any
    moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.

    IMO, reference to the "interface provided above" is just a way to explain what they mean with the "locking" word. Nothing more than that. The next sentence is in in favour of this interpretation, because they just go
    on with the same explanation. Notice also the context in which the only "client" word is used in the whole paragraph. Locking is clearly server stuff, which must offer the capability to handle multiple clients
    safely. Period.
    Instructions:
    This document deliberately leaves some issues unspecified, and some problems unraised. Your ability to think through these issues, in the face of realistically imperfect specifications, and come to a tenable solution
    is something upon which you are being graded.

    This paragraph explain why our instructions are so vague, but also encourage us to dare to be a little bit creative to solve unspecified issues. I do think here that they cannot be so vague about the desired main architecture (2-tiers / 3-tiers), and in the same time penalize the guys who would choose the 3-tiers one (and justify it).
    I don't think that Andrew is right when he writes "Now I know people have passed the assignment when they only exposed business methods to the clients. (...) Or it may have been pure luck. I don't know.".
    Pure luck in that area is impossible IMO : we are talking about the main (biggest) design choice you can make in the assignment. Do you really think a grader could be absent-minded enough to not notice that you built
    a 3-tiers system when he expects (and only accepts) a 2-tiers one ?!
    ----
    Now about the lock cookies as an argument in favour of the 2-tiers design :
    Andrew:
    Some of the assignments have a lock method that returns a cookie which must be used in the database modification methods and in the unlock method. I see that as further evidence that the lock method should be
    called from the client side.
    Consider the normal "booking" method: if it is on the server side, the cookie provides no benefit whatsoever. If you did not have the cookie requirement, the code would still work in an identical manner.
    The cookie only makes sense if the client has to receive it and work with it.

    Jim:
    Well I don't really think the cookie makes much sense at all. But I agree that, given that the specifications went to the trouble of putting it in there, it seems that someone, somewhere thinks that cookies are useful and important, and though I don't agree I figure it's best to make them happy by requiring cookie usage on the client as well.

    Well, till Suds's post, I thought like Jim (and like Andrew) : lock cookies don't make sense. But after reading Sud's post, I thought that they bring at least this benefit : they help the programmer to never forget to lock() a record before updating or deleting it. As both updateRecord() and deleteRecord() have a lock cookie as parameter in their signature, locking will be enforced at compile time. In comparison, in
    assignments with no lock cookies, locking is only enforced at run time.
    Now Andrew, if your assertion "on the server side, the cookie provides no benefit whatsever" is false, your deduction "The cookie only makes sense if the client has to receive it and work with it" is false too. Right ?
    Now I thought of a big argument in favour of the 3-tiers design, using a similar way of Andrew's arguing (using the method signatures as a way to find out SUN expectations). Look at these methods signatures :
    public long[] findByCriteria(String[] criteria);
    public String [] readRecord(long recNo);
    Andrew, don't you think that any SUN's engineer, whith a 2-tiers design in mind - wouldn't have written the readRecord() signature as the following ?
    public String [][] readRecords(long[] recNos);
    Here is what would happen in a 2-tiers system with the provided interface, searching for criteria giving a (quite small) 500 records result-set :
    long[] recNos = Client.findByCriteria() .....wire.....Server.findByCriteria()
    String[] records = new String[recNos.length];
    records[0] = Client.readRecord(recNos[0]).....wire....Server.readRecord()
    records[1] = Client.readRecord(recNos[1]).....wire....Server.readRecord()
    records[2] = Client.readRecord(recNos[2]).....wire....Server.readRecord()
    ...
    ...
    ... (repeated 500 times (!))
    ...
    ...
    records[499] = Client.readRecord(recNos[499]).....wire....Server.readRecord()
    In comparison, using the second signature (the one which would justify a 2-tiers system), it gives :
    long[] recNos = Client.findByCriteria() .....wire.....Server.findByCriteria()
    String[] records = Client.readRecord(recNos).....wire....Server.readRecords() // done !
    Of course, it's not a demonstration, because - as so many people here claim it (Max, Mark) - : "Performance is not an issue in this assignment".
    In fact, I don't agree with that assertion. To me, it's just a rumour. You may read the instructions 1000 times, the only statement which refers to performance is this one :
    Instructions:
    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.

    It's just common sense, and it could have been replaced by something like "A good design, such as one created by a good developer, will be preferred to a bad one, even if the bad one is simpler."
    Mmh, not sure Mark will agree, but. BTW, welcome back to the the forum, Mark !
    Just a few more words to Vlad :
    Vlad:
    The only thing which I have change is : added two new adapter interfaces local/remote for the client which change slichtly a signature of methods:
    String[] read (int recNo)-> RecordModel read(int recNo), int[] find(String[] criteria) -> RecordModel[] find (Hashtable criteria) and so on to make info and changes on the database transparent to the client. I am sure it is going to work.

    Just be aware of the fact that your solution is a 2.5-tiers system. I mean that it seems that you don't implement the db interface client-side as provided (the solution Andrew and Jim defend), neither you hide db access completely to the client as I suggest. Your solution seems to be just in the middle of those two extremes, and I am afraid that it's not the most comfortable position to defend (but I told that to you already).
    This post is typically such a one I hope to get replied to and argued against. Andrew, Jim, Mark, Vlad, Suds, Tony ... and the others, thank you in advance for your reply.
    Best,
    Phil.
    PS: Andrew, we were well inspired to initiate a new thread !
    [ September 26, 2003: Message edited by: Philippe Maquet ]
    [ September 26, 2003: Message edited by: Philippe Maquet ]
    Michael Fitzmaurice
    Ranch Hand

    Joined: Aug 22, 2001
    Posts: 168
    Hi all
    This is an interesting discussion. Clearly, if we want to get tied up in the semantics, your own personal definition of terms like 'providing functionality' (e.g. is this the same as *exposing* functionality?) and 'server' become increasingly important.
    For what its worth, I do not intend to expose the lower level locking mechanism to clients at all, and I will explain why I have interpreted the instructions this way in my choices.txt.
    Andrew wrote:
    and I submit that we don't know whether the client application is locking the record or not

    I agree with this statement - as a user, I don't know whether the client application is locking the record or not. However, neither do I care, so long as the record gets locked and the behaviour I expect is guaranteed. Hence, my own interpretation of Sun's instructions leads me to believe that they won't fail you for not exposing the lock method to clients (in my case the return type is void, there is no 'cookie', so maybe its a bit safer for me to assume this).
    So long as the data access layer is using a locking mechanism appropriately to ensure thread safety for the application, I am hoping they don't care if the nitty-gritty of how this is being done is visible client-side or not. I think it is important to show that you have considered both roads here though, and chosen one over the other based on a well reasoned interpretation of your own particular instructions. My own general strategy is to explain how my interpretations influenced my design, and what the alternatives were for other interpretations I can see.
    I feel it would be a cruel Sun examiner indeed who fails you in such circumstances...


    "One good thing about music - when it hits, you feel no pain" <P>Bob Marley
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Phil,
    As a 3-tiers supporter, I don't like the sentence "A client program ... that connects to the database", but I think it's compensated by "Network server functionality for the database system".

    Why do you permanently ignore the sentense "Network server functionality for the database system".
    Is book/find to your opinion is network server functionily to the database system.
    The GUI client is required to provide book/find finctionality, but the server is required to provide all functionality including create/read/update.
    You can change signature using Adapterpattern, but you MUST make available database functionality over the newtwork, which you YOU FAILED to do!
    Best,
    Vlad
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Vlad,
    Vlad:
    Why do you permanently ignore the sentense "Network server functionality for the database system".

    Because any server which connects to a database offers "network server functionality for the database system". Amazon.com offers network server functionality for its database system, right ? And it's quite reasonable to think that within its database system, there is some locking functionality. Still right ? But your browser has not to care about it ! When you order a book on Amazon, from your client application's point of view (the browser), you just "order and pay" for a book, you don't send to Amazon all the detail operations to be performed to get your book ordered.
    The client is ... just a client. As a client of a restaurant, you order some food without detailing how the "Chef" has to do his job ! And as a user of MS-Word willing to save his document, you execute the menu command :


    instead of all of these ones :


    Vlad:
    You can change signature using Adapterpattern, but you MUST make available database functionality over the newtwork, which you YOU FAILED to do!

    Well I don't know where you read in the instructions that you could change the methods signatures, even through some Adapter. And if you do, you are quite alone here to defend your position, because Andrew and Jim suggest to expose DBAccess as it is (remember what Jim wrote above about the slight change to be made to the signatures (related to the fact that access is remote), and the way to justify it). Your changes in method signatures are all but slight in comparison !
    "which you YOU FAILED to do!" : I hate that word ("fail") I invested too much time and energy these last 5 months in the Java technology, full time and at own cost, to accept to fail just because I'd choose a 3-tiers design over a 2-tiers one, I mean given the instructions I received which are dumb reguarding that choice.
    I love what Michael wrote above :
    My own general strategy is to explain how my interpretations influenced my design, and what the alternatives were for other interpretations I can see.
    I feel it would be a cruel Sun examiner indeed who fails you in such circumstances...

    You'll understand that I am a volunteer too to play the "guinea pig" role.
    Given the instructions I received, if I fail because of that choice :
  • I'll try to appeal
  • And if I fail anyway, I'll probably move to another technology (after all .NET and C# are also marketable technologies, right ?)


  • Best,
    Phil.
    [ September 26, 2003: Message edited by: Philippe Maquet ]
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Phil,
    1) What all "guinea pigs" are trying to say is that 3 tier architecrure is better. Yes it is, but that is not the question we are arguing.
    2) As Andrew said, and how I understand him, your client has not to be a GUI client. Your sample with amazon: I agree that is not a HTTP client who lock/unlock, but it could be jsp which are doing it. I doubt it, but that is what Sun wants.
    I think all of us know the point and understand each other. The only issue is the risk.
    So, I have a question: who is from the team of "guinea pigs" first to take
    the test?
    Don't forget to put your results in Results forum...
    Best,
    Vlad
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Vald,
    So, I have a question: who is from the team of "guinea pigs" first to take the test?

    Well, till now, here are the teams (members listed in alphabetically order ) :
    Not actually concerned because passed :
  • Andrew


  • In favour of the 2-tiers solution :
  • Jim
  • Vlad


  • Ready to play the "guinea pig" role in favour of the 3-tiers :
  • Bharat
  • Michael
  • Myself (Mmh ... notice how replacing "Myself" by "Phil" wouldn't disrupt the alphabetic order : it's magic ! )
  • Suds
  • Tony


  • Don't know yet
  • Arun


  • And here are their relative weight :
  • Not concerned : 11%
  • 2-tiers :22%
  • 3-tiers :56%
  • Don't know : 11%


  • Mmh, it seems that I am a democrate !
    Best,
    Phil.
    [ September 26, 2003: Message edited by: Philippe Maquet ]
    Tony Collins
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    I think you're taking a risk exposing the locking methods. We're discussing the semantics of language. So if the spec isn't clear, which it appears not to be, then you have to go with the common practice which I believe is a tiered server.
    Tony
    [ September 26, 2003: Message edited by: Tony Collins ]
    Michael Fitzmaurice
    Ranch Hand

    Joined: Aug 22, 2001
    Posts: 168
    So who will be submitting any time soon? By the sounds of posts on JR, Tony, Phil and Vlad must be nearly there. I don't expect to be ready to submit until the end of the year or so - by this time I don't think I will qualify for 'guinea pig' status any longer...
    P.S. Tony - are you an Everton supporter?
    Tony Collins
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    Well I sat my exam today and am submitting tomorrow. I need to find work so I have to submit.
    Concerning football, I'm an exiled Arsenal supporter and a adopted Evertonian. I've lived in Liverpool for the last ten years and I can't bring myself to watch the dreadful team that bears the cities name, so DULL. Though work is not common in Liverpool so hopefully I shall be returning to London to watch Arsenal again.
    Rooney is fantastic though, could be the new world superstar me thinks.
    Tony
    Arun Kumar
    Ranch Hand

    Joined: Aug 29, 2003
    Posts: 67
    Hey ppl,
    I am in for the 2 tier model
    I read the for and against arguments regarding 2 tier. Personally i prefer 3 tier model. But for the sake of certification, i will stick with the 2 tier model.
    Arun
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hey Phil,
    could you please update your ratings!

    Best,
    Vlad
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Vlad,

    could you please update your ratings!

    Hmh... No need. Just change the section title "Don't know yet" by "Traitors"...
    Best,
    Phil.
    Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    A question: is there anyone here who has an NX assignment (URLyBird or B&S/Contractors) and does not have a sentences like the following in their requirements?
  • "Network server functionality for the database system"
  • "Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the [provided] interface"

  • [PM]: Not actually concerned because passed :
    1. Andrew

    You might want to take another look at the first post in this thread, Philippe. Andrew did FBN, which didn't have the requirements under discussion. But he's made his position clear for those who do have such requirements.
    In favour of the 2-tiers solution :
    Note that we don't actualy like the two-tiers solution; we just believe it's what the client has required.
    [TC]: I think you're taking a risk exposing the locking methods. We're discussing the semantics of language. So if the spec isn't clear, which it appears not to be, then you have to go with the common practice which I believe is a tiered server.
    If the spec genuinely isnt' clear, you may go with common practice. It's hardly must. And really, common practice can easily lead to a substantially more elaborate design, with validation at several differnt levels, change logging, rollback procedures. Maybe even use a real database instead of this crude text file. We're not expected to include everything in our solution that might be desireable in the real world. It's possible IMO that Sun put in this spec to try to keep designs somewhat simple, and thus easier for them to grade.
    More importantly though, that's if the spec isn't clear. I really think "Your server ... must provide locking functionality as specified in the [provided] interface" is clear enough. I concede it's not 100% unambiguously clear, but I believe it's clear enough that I see a much bigger risk in ignoring the spec than I do in going against common design patterns. You (TC) did make a good observation earlier about possible confusion in what is meant by the "server". I suppose some people might indeed think that as long as some component on the server implements the specified interface, that satisfies the requirement. But note the word "provide". Provide to who? Other components on the server? I think not - if a server is required to provide something, it's required to provide it to clients. That's what servers do, they serve clients. If your server implementation has a lock method somewhere internally but the client can't call it, you haven't "provided" that functionality as specified in the interface.
    Now I think there's actually a good chance that the "guinea pigs" will pass without problems, because Sun may not choose to enforce this requirement as strictly as they might. I believe this mostly because I think that if everone who didn't provide a lock() method to clients were to fail (for the NX assignments), we'd probably have heard something about it by now. E.g. Max has had a lot of private students who have taken the exam; he'd proably have noted if everyone with a thin-client 3-tiered design were failing. So great, 3 tiers is probably OK. But that's dependent on Sun's good will. If a grader chose to mark off points or fail you for failing to adhere to the requirements, you don't really have a very good case to argue against them, IMO.
    Part of the test is, can you adhere to customer requirements? Customers sometimes ask for strange things. Just because we don't see a good reason for those requirements doesn't necessarily mean there isn't one; they may just not be telling us everything. Why did they specify a particular interface? Maybe there are other classes already written, or being written by others, which expect to use that interface. And maybe those classes need to be able to run on different machines, not just on the server. If our server provides the full DB interface in its interface to clients, it's going to be easy to connect our new DB server to these other programs. Maybe that's what their reasoning, maybe not, we dont' know. We just have the requirements they gave us. We may not like them, but we can still implement them.
    Michael Fitzmaurice
    Ranch Hand

    Joined: Aug 22, 2001
    Posts: 168
    Quote from my spec (which I suspect to be the same in everyone's instructions):
    Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.

    Jim, I can certainly understand your point - I see how you are interpreting this the way you are (especially since you have a lock method with a 'cookie' returned, if I remember correctly).
    My point is not that this instruction is unclear to me (ambiguous yes, but not *problematically* unclear). My own interpretation of this can be summed up as:
    Your server must be capable of handling multiple concurrent requests without nausing up the data file and making you look like a complete spanner. It must be doing this at the lowest level via a locking mechanism using the above interface. Not something you come up with yourself that might make you look like a complete spanner. Or that our examiner won't be able to understand (which would make you look like a spanner).

    As you can see, I am not interpreting the word 'provide' in this context to mean 'expose to clients'. I am interpreting it as 'handle for clients'. I therefore see the first part of the sentence (up until the comma) as functional specification and the second half as implementation detail.
    I am not arguing that I am right and you are wrong, just that I would be shocked if my own interpretation and subsequent design led to me failing for not implementing the spec. Especially if I explain in choices.txt that my design is a direct result of my interpretation, and that if I had chosen to interpret it differently, I would have designed x, y, and z differently.
    My gut feeling is that this is not a risk - if I thought it was I would choose the *safe* option.
    Arun Kumar
    Ranch Hand

    Joined: Aug 29, 2003
    Posts: 67
    Originally posted by Philippe Maquet:
    Hi Vlad,


    Hmh... No need. Just change the section title "Don't know yet" by "Traitors"...
    Best,
    Phil.

    Awwww... Phil dont be mad at me
    Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    That's OK Arun, we're happy to have you.
    [Michael]: I am not arguing that I am right and you are wrong
    Likewise - there's enough ambiguity in the spec here to respectfully disagree regarding which interpretation we view as more probable, and what risks we're willing to take. And it would be pretty harsh of Sun to actually fail people for this, especially since many of the people taking the exam don't have English as a first language. "Must" requirements should be a little more clearly expressed if they're really going to be enforced. But I can't control what Sun actually will do, so I'm erring on the side of caution, as I interpret it. YMMV of course.
    Have a good weekend, all...
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Jim,

    1. Andrew
    You might want to take another look at the first post in this thread, Philippe. Andrew did FBN, which didn't have the requirements under discussion. But he's made his position clear for those who do have such requirements.

    I knew it. I confess that I put Andrew aside just to boost a bit the 3-tiers rating !
    BTW, here are the new ones (incuding Andrew and Arun) :
  • 2-tiers : 44%
  • 3-tiers : 56%


  • It seems that all our discussion turns around the meaning of only one word ("provide"), and I agree with Michael telling that "provide" does not mean "expose to clients".
    Your wrote :
    But note the word "provide". Provide to who? Other components on the server? I think not - if a server is required to provide something, it's required to provide it to clients. That's what servers do, they serve clients. If your server implementation has a lock method somewhere internally but the client can't call it, you haven't "provided" that functionality as specified in the interface.

    If 80% of a server job is to serve clients requests through an exposed interface, my server also provides a GUI to let an administrator manage application, network and database settings. It provides functionalities which are not under clients control : database caching, "live" backup, lock timeouts, broadcasting of messages, database opening and shutdown, etc.
    The instrutions are so unclear in that area (2-tiers/3-tiers), that, with Michael, I think there is no risk at all to choose one solution or the other. Or, at least, there is not more risk to choose 3-tiers while the grader would expect a 2-tiers system, than to choose 2-tiers while the grader would expect a 3-tiers one. But we should pass in both cases anyway (or fail for other reasons).
    Best,
    Phil.
    [ September 27, 2003: Message edited by: Philippe Maquet ]
    Bharat Ruparel
    Ranch Hand

    Joined: Jul 30, 2003
    Posts: 493
    Hello Phil,
    You wrote:

    The instrutions are so unclear in that area (2-tiers/3-tiers), that, with Michael, I think there is no risk at all to choose one solution or the other. Or, at least, there is not more risk to choose 3-tiers while the grader would expect a 2-tiers system, than to choose 2-tiers while the grader would expect a 3-tiers one. But we should pass in both cases anyway (or fail for other reasons).

    I couldn't agree with you more. I think Sun has given us the freedom to choose either a 2-tier or a 3-tier implementation. It seems to me that certain versions are deliberately slanted towards one solution or the other. In my version, URLy Bird 1.3.1, it would make litle sense to expose lock-unlock-islocked methods to the client.
    Regards.
    Bharat
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Should lock methods be callable by the client