Comp150CPA: Clouds and Power-Aware Computing
Classroom Exercise 4
Stubbing and binding
Spring 2011

group member 1: ____________________________ login: ______________

group member 2: ____________________________ login: ______________

group member 3: ____________________________ login: ______________

group member 4: ____________________________ login: ______________

group member 5: ____________________________ login: ______________

In class we have studied the concepts of binding, stubbing, and deferred development. Let's explore a bit more about these concepts.

  1. Although we have only studied the case in which one servlet service is defined in a project, there is no problem with creating multiple servlet services for one project. Why might you want to do this?
    Answer: There are two reasons for creating multiple services: cohesion and multiple programmers. One programmer can work on one service without communicating with a programmer working on another. A second issue is that it is easier to write a service when it is responsible for one and only one thing. The extent to which a service accomplishes one kind of task is called cohesion. One might not want, e.g., to write one service that interacts with both Google Mail and Google Calendar. A better design would be to write one service for interacting with each one.
  2. Based upon the discussion of the User service, how would you store the preferences of a specific user, e.g., background color of the site?
    Answer: One cannot store these in the User object, but could, e.g., store them in the main datastore. To do this one creates a persistent class instance that describes preferences, where the key of the persistent class is the user's ID.
  3. Suppose you are developing the SimplePersistence example and (justifiably) want to defer development of the PersistentThingServiceImpl class until later. Recall that the structure of this class is:
     
    public class PersistentThingServiceImpl 
      extends RemoteServiceServlet 
      implements PersistentThingService {
        
        static final long serialVersionUID=1;
    
        @Override
        public String getThing(); 
    
        @Override
        public String setThing(String s); 
        
        @Override
        public String clearThing(); 
    }
    
    Give a reasonable set of stubs for this class, and explain why using these stubs as temporary definitions of the methods allows debugging other classes before writing this one.
    Answer:
     
    public class PersistentThingServiceImpl 
      extends RemoteServiceServlet 
      implements PersistentThingService {
        
        static final long serialVersionUID=1;
    
        @Override
        public String getThing() { 
    	// TODO: write getThing()
    	return "gotten"; 
        } 
    
        @Override
        public String setThing(String s) { 
    	// TODO: write setThing(String)
    	return s; 
        } 
        
        @Override
        public String clearThing() { 
    	// TODO: write clearThing()
    	return "cleared"; 
        } 
    }
    
  4. Under what conditions is stubbing a class to defer development a bad idea?
    Answer: One cannot tell if a dynamic change that should be made has been made, e.g., deleting objects matching a pattern. You cannot conclude that your user interface works until the stub has been implemented.
  5. (Advanced) Why is it possible to define a servlet with a different relative web address than the address that the web server knows about?
    Answer: The reason that the mapping between services and URLs is so flexible is that it must be able to represent one-many relationships in which one service is known by several names. This need makes the configuration too flexible, in the sense that the service can also be known by no names at all.

    The reason for wanting to represent a service by multiple names has several uses. First, one can write a service that in one module implements two kinds of service, by reacting to the name. This is done sometimes when the two kinds of service are interrelated.

    A more subtle reason for wanting to be able to have a service by two names comes from wanting to change a name of a service while the service is running. If one makes it available by two names, and then replaces the references to the older name, one can then safely make it known only by the new name without even stopping the service!