Client Application Overview

This application overview discusses the specifics of how our client application interacts with available Web Services. We discuss working with user requirements, obtaining information about XML Web services, and designing a client application—Golf Reservation System Client—based on the controller design pattern and the procedure flow it enforces.

The Golf Reservation System is a tee time registration application through which registered users can search for golf courses, view details on specific courses (tee descriptions, slope ratings, individual hole distances, pars and handicaps), view available tee times at those courses, make reservations, and view a list of previously registered times. Specifically, the Golf Reservation System client application discussed in this chapter is a Web client built to interact with the Golf Reservation System Server XML Web services.

A production application of the Golf Reservation System variety would provide much more functionality, but for the purposes of this book the Golf Reservation System allows us an under-the-hood view of .NET in action while it ties together course and user data, makes that data available through XML Web services, and displays it using the controller design pattern introduced in Chapter 5.

User Requirements

The ideal division of labor between developer and designer—in which the developer writes code and the designer creates interfaces—is rarely achieved when rich UIs are required for sophisticated applications. The more business logic an application developer can mask from the UI developer, the better. Combining the .NET Framework with the controller design pattern, though, results in further separating the duties of developers and designers, not only because the controller XSLT skin is completely responsible for formatting controller-result XML, but because developer duties can be divided between server and client. This separation creates truly distributed applications in that one developer or business provides the XML Web services, perhaps in conjunction with a UI, while another developer or business interested only in manipulating those XML Web services builds an entirely separate client application.

The handoff between server and client responsibilities occurs at the time of publishing of the XML Web services. As long as all requests are presented in the agreed-upon format, as defined by the XML Web services, the server application does not care what the client application does with the results. Likewise, as long as the server application accepts client requests in the agreed-upon format, the client application does not care how the server implements functionality.

Although the Golf Reservation System server application is in many ways tailored specifically to the Golf Reservation System Client we will build, it is entirely feasible that the Web methods could be designed to model only the data behind them and provide an XML Web service interface for retrieving the data. The result would be a service published on the Internet that is not tailored to a specific client application design, but instead provides abstractions on a complex data store. In this situation the clients would not necessarily be user-focused Web applications.

Imagine the Golf Reservation System server application as a stand-alone service provided by a conglomeration of golf courses. Multiple Internet applications could call into provided services and format and manipulate data as they saw fit. One client application might use the GolfCourseService to retrieve only golf course data (with or without displaying it), while another might retrieve golfer information from the GolfCourseService. A client could be developed by a partner business interested in collecting and manipulating the service result data, but not necessarily interested in displaying that data without further manipulation to a client—a server-to-server business interaction facilitated through XML Web Services.

Web Services

The Golf Reservation System contains only one Web Service, conveniently named GolfCourseService. Numerous other Web methods, however, are available within this lone service. The Web methods necessary for the Golf Reservation System vary from search helpers to everyday findById methods.

The GolfCourseService is responsible for masking business object design complexities and particulars. The developer calling and retrieving data from Web methods need not know whether a table of addresses is in the Golf Reservation System database. Instead, the .NET Framework allows back-end developers to create facades for complex business logic and publish the API for those facades (Web Services) to the network or Internet.

The Golf Reservation System client application calls into the GolfCourseService Web Service via SOAP requests and receives SOAP responses. The .NET Framework, though, handles the complexities of creating, sending, receiving, and parsing the SOAP documents. A developer seeking to manipulate a Web Service outside the scope of the .NET Framework would not only need an understanding of the business functionality available through the methods but an understanding of and an ability to generate SOAP calls to the methods, as well as an ability to parse the response SOAP documents.

Obtaining Information About a Service

Browsing to a Web Service results in the display of a description of what Web methods it provides and how to call into those methods using the supported protocols. Figure 10-1 is a screenshot of the GolfCourseService called in this manner, at http://localhost/TeeTimes/GolfCourseService.asmx.

Figure 10-1 Detailed information about the Web methods provided.

Clicking a specific method (shown in Figure 10-2) offers a detailed description of that method and a form to invoke it. Note that submitting the form on this page does invoke the method and will perform the actions of that method as if it were called from an application. If the method results in a new database insert, submitting this form will do the same. Also detailed on the method description page is the protocol syntax request and response for SOAP calls, HTTP POST, and HTTP GET.

Figure 10-2 A brief description and protocol syntax for invoking a Web method.

Understanding Web Service Method Signatures

The client application we will build requires little information to interact with the Golf Reservation System Server. We need only the method signatures of the Web methods provided by GolfCourseService and a brief description of method functionality if the intended method functionality is not immediately obvious by name.

These Web methods and the classes behind them make up the Golf Reservation System server application and represent the proxy necessary for other applications to interact with and manipulate the Golf Reservation System business logic. For more specific information about when and how to create Web Services from a server perspective, please see Chapter 9.

Golf Reservation System Client

Golf Reservation System Client consists of the following: a Web reference for connecting to the Golf Reservation System Server Web Services, C# Web forms (.aspx.cs classes and associated .aspx files), and all items necessary for implementing the controller design pattern.

To connect to the GolfCourseService Web Service provided by the Golf Reservation System server application, which can reside anywhere on the Internet or local network, you need to create a Web reference. A Web reference provides class and Web method definitions available from the services it contains and makes those business objects and methods available to the project. In Microsoft Visual Studio.NET, this is as simple as providing a URL to the Web Service, which in turn iterates over the resulting WSDL data and creates all the necessary stubs for use in your Visual Studio. NET project. Outside the application, any number of tools for querying WSDL documents published on the Internet or network can be used. Visual Studio .NET just makes it easy and virtually seamless for the developer.

In developing a C# client application, accessing the Web Services available within an existing Web reference requires creating Web forms. Adding a Web form to your application creates both a WebFormName.aspx.cs file and a WebFormName.aspx file. The .aspx page is an instance of its associated .aspx.cs class, referred to in many cases as the "Class-behind" file. Visual Studio .NET provides skeleton templates for creating C# Web forms, and adding a Web form to a project creates these templates for you, including all the required methods and formatting. We will use the template for the .aspx.cs file, but because we are employing the controller design pattern for our UI, we will not be using the skeleton template for the .aspx files.

Note that a Web form, as used by the client in a Web application, is simply an instance of that Web form's associated Class-behind file, the .aspx.cs file. Any public variables and methods defined in the Class-behind file will be available to any instances of the class, and any private methods and variables will be hidden from the instance.

To reference Web methods within the aspx.cs file, you must instantiate the Web Service to make it available to your class. You are then provided all available Web methods and object types defined in the Web Service. For example, the CourseDetail.aspx.cs file instantiates the GolfCourseService and calls the getCourseDetail method passing in the required courseID string. This example is as follows:

 // localhost is the name of the computer hosting the Golf Reservation 
//System Server // First, create a protected reference to a GolfCourse object // making it available to instances of this class, and assign // the url variable `id' to a local variable, `_id' protected localhost.GolfCourse gc; string _id = Request.QueryString.Get("id"); // Next, instantiate the GolfCourseService localhost.GolfCourseService gs = new localhost.GolfCourseService(); // Pass the local _id variable to the GetCourseDetail Web method and assign  // the result local GolfCourse gc. gc = gs.GetCourseDetail(_id); 

The result of the getCourseDetail method is a GolfCourse object as defined in the Golf Reservation System server application, and this object is made available for manipulation by the CourseDetail.aspx.cs class.

Any objects needed for reference in the .aspx file instance must be declared in the constructor of the .aspx.cs class, usually as protected. Therefore, in keeping with the CourseDetail.aspx.cs example, any instance (.aspx) of the CourseDetail.aspx.cs class will have a GolfCourse object named gc associated with the given id parameter available for manipulation. Any public or protected objects declared in the constructor are likewise available to each instance of the Web form.

Because we are using the controller design pattern, the resulting .aspx file is not a completed client page; instead it is an XML document. The document schema is agreed upon between the UI developer and the back-end developer. Therefore, after creating the Web form class and an associated .aspx XML file, the system developer duties are completed. The UI developer is now responsible for deciding how to format the data provided in the .aspx file, which can be used for any number of XSLT skins.

At this point the controller methodology takes over and formats the given-view XML (the .aspx result) with the appropriate template matches in the appropriate skin. The result, at least after using the ie5.xsl skin, is a page formatted to designer preference.

The Controller Design Pattern

The Golf Reservation System client application implements the controller design pattern for creating and managing the UI. Similar to the application of Web Services, the controller design pattern is platform- and application-non-specific in its implementation. Using XML and XSLT, all the UI designer requires is an agreed-upon schema for how the data is to be presented and working knowledge of how to use XSLT and associated formatting tools for presenting that data.

The controller implementation in the Golf Reservation System client application expects object-descriptive XML. That is, the result of a call to getCourseDetail.asmx.cs is an XML document describing the course in question, the syntax of which can be found in the code listing under getCourseDetail.aspx. Another popular implementation of the controller design pattern is to create a DTD abstracting both the data involved and the suggested (not actual) presentation of that data. For example, a list of courses from courseSearchResult.aspx could be formatted as

 <courseList> <courseListItem> <name> Some Course Name </name> ... </courseListItem> <courseListItem> <name> Another Course Name </name> ... </courseListItem> . . .   </courseList> 

Optionally, courseSearchResult.asmx can format XML describing the contextual relationship of the data to a general layout, providing data in name/value pairs to the XSLT developer, such as

 <list type="courseList"> <listItem> <property> <name>Name</name> <value>Pebble Beach</value> </property> . . . </listItem> <listItem> <property> <name>Name</name> <value>Augusta National</value> </property> . . . </listItem> </list> 

Both models have advantages and disadvantages, and the application designer must decide which method best fits the application. At an initial view the object-descriptive model is the obvious choice, but keep in mind that it requires a new xsl:template block for nearly every type of request/response pair. However, the model describing the presentation lends itself to design consistency and an easier-to-maintain UI because it requires fewer templates.

The second approach involves contextual understanding of the data provided. Is a property significant? Which nodes can display on which Internet devices? These questions are significant in designing a client application, and a design team will probably come up with a hybrid of the two patterns instead of choosing one.

Procedure Flow

An application-perspective procedure flow from a Golf Reservation System Client page request is as follows:

1. User requests page (controller.asp?view=courseDetail&id=12) either by typing an address in the browser location bar or by clicking a link somewhere. In either case the call for our sample client, is an HTTP GET method. (HTTP POST methods are also possible, though they're not used in this application.) All required variables are passed through the URL or as form variables. The Golf Reservation System client application assumes these variables are both present and formatted correctly. A production application would contain extensive validation.
2. The controller locates the requested viewtype.aspx in the "content" folder and evaluates. Keeping with the CourseDetail example, the aspx file is located at /content/courseDetail.aspx.
3. Calling the .aspx file forces the compiled .aspx.cs file to create an instance in the form of the aspx document. The Page_Load( ) function in the aspx.cs file is called and initializes the class. All public variables defined in the constructor are made available to the .aspx instance. The Web Service is instantiated and various Web methods are called. Database reads and writes are executed as necessary. The controller loads the XML result in a variable named xmlurl.
4. The controller.asp retrieves the appropriate XSLT skin, ie5.xsl. (Golf Reservation System Client contains only one but can contain many skins.) The controller loads the XSLT in a variable named xslurl.
5. The controller uses xslurl to transform xmlurl and returns the transformed result, in this case, an HTML document.