350 CHAPTER 11 (Web host music) REST-BASED MODEL VIEW CONTROLLER
350 CHAPTER 11 REST-BASED MODEL VIEW CONTROLLER PATTERN The Google search implementation is simpler than Amazon.com s because it uses the generated client stub. All of the classes that are prefixed with the Google identifier are the generated classes. The variables _endpoint and _key are values from a configuration file. The variable _endpoint is used to define the server called to execute a search. The variable _key is the Google access identifier that serves the exact same purpose of identification as the Amazon.com access identifier key. The variable queryIdentifier is the client-provided query identifier if an asynchronous request is made. If a synchronous request is made, the query identifier length is zero. In the implementation, though, the method addResult is always called with a query identifier. This is okay, because the servlet or handler that converts the results into XML (or HTML, or other content returned to the client) will know whether or not to process the query identifier. When the executed search responds, the found entries are added to a result set by converting the results to the type SearchResult. The found types are not converted into XML because that would couple the results to a specific data format. This would be problematic for the Permutations pattern, which generates the format that the client wants to see and thus prefers to manipulate objects and not have to parse an XML file again. Creating a Search Engine Client Infrastructure I have very quickly described the implementations that execute a search on Amazon.com and Google. My objective is not to explain how the Amazon.com and Google search engine APIs function. My objective is to illustrate the following requirements used to finish implementing a controller: The request information provided by the client will in most cases not be enough to perform a request to the remote servers. A client can provide the extra information, but that should be avoided whenever possible because a dependency to a specific implementation is created. Extra request information would be stored as configuration items that are loaded by the controller and passed to the local client. Hard-coding any of the parameters is not advised. The local clients should not couple themselves to specific data formats or types. This means the local clients should not assume XML, and should not assume being called from a specific controller technology such as a Java servlet or ASP.NET handler. These requirements dictate that the controller implementation should be kept as general as possible. Individual model details are managed by the local clients that convert the specifics into a general model used by the controller. However, the reality is that there are specifics. For example, the Amazon access identifier requires extra information stored in a configuration file or sent by the client to the controller that is then sent to the local client. Programmatically, being generic and specific at the same time is impossible or at least it can seem impossible. The solution to this dilemma is to use the Extension pattern. The purpose of the Extension pattern is to be both a general and a specific solution. The best way to understand this is to consider the following source code:
If you are looking for affordable and reliable webhost to host and run your business application visit our ftp web hosting services.