Chapter 9: Building a Server Application
9 Building a Server ApplicationThe best way to assimilate all that we have covered so far is to stop talking about it and start writing code. This is precisely the goal of Chapters 9 and 10. We will pull together a number of concepts in doing so, including XML content, XSLT skins, XML UI elements, SOAP, and XML Web services. Whether your goal is to understand the entire application or just specific pieces of it, we hope you get something useful from the code in these chapters. We will begin our programming endeavor by providing an overview of the application we will build. We will then focus on the server-side component of the application.
In this chapter we will design and implement the database logic, the data sets, and data adapters that provide access to the underlying datastore, the business logic that comprises the "guts" of the application, and, finally, a variety of Web Services that expose our business logic to clients.
A production application of the the Golf Reservation System variety would normally provide much more functionality, but for the purposes of this book, the project allows us an under-the-hood view of .NET in action. It ties together course and user data, makes that data available through XML Web services, and displays it using the controller design pattern discussed in previous chapters.
The XML Web services logic of the Golf Reservation System will not query the Access database directly. Instead, all data access will flow through a more abstract CourseDataSet class. The CourseDataSet will mimic the structure of the underlying DBMS and will provide quick and easy access to data from the application layer.
Using a DataSet to mask the underlying database has a number of advantages. First and foremost, it breaks the traditional ties that bind business logic to specific DBMS's. The Golf Reservation System's server-side component could be rewritten with a minimum amount of effort to support new database requirements. Second, direct in-memory DataSet access eliminates expensive boundary crossings to call into the database. Data can be retrieved quickly from the DataSet without the need for repetitive SQL queries. Finally reducing the load on the database engine frees it to operate more efficiently, enhancing the scalability of the application.
"Finder" XML Web services used for searching will create DataView objects to query the data contained in the CourseDataSet. Web Services can filter data by means of the DataView class's RowFilter property. Row filters use Expression objects to provide rich, SQL-like selection capability.
The server will implement a series of DataAdapter classes to handle all marshaling of data to and from the database. There will be a single DataAdapter class for each database table. These adapters will work together to load the table data into a consolidated data set. Data updates will require the following three separate steps:
Business Object C# Class Definitions
The application provides C# classes for each object represented by a database row as well as classes for commonly used containable business objects that have no single table relationship, such as an address. Each class contains traditional methods in getters and setters and in most cases multiple constructor methods.
Not every class in the application mirrors a database table as does the GolfCourse class. The same will likely hold true with any application you build inside the .NET Framework. For example, the fact that the application contains an address class as an address object can be useful because, at least within our application, it relates to and holds requirements for the same properties and methods across multiple business entities (both a golfer and a golf course have addresses). Obviously, one goal of a .NET application is code reuse, and although this is a simple example, it's a good example nonetheless.
Table 9-1 contains the business objects in the Golf Reservation System application.
Table 9-1 Business Entities in the Golf Reservation System Server Application
The application contains only one XML Web service, conveniently named GolfCourseService. Numerous XML Web methods, however, are available within this lone service. The methods necessary for the TeeTimes application vary from search helpers to everyday findById methods.
GolfCourseService, like all XML Web services, is responsible for masking business object design complexities and particulars. The developer that needs to call into and retrieve data from Web methods need not know whether a table of addresses is in the database. The application calls into the GolfCourseService XML 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.
Browsing to an XML Web service with a Web browser results in a detailed description of the XML Web service, what methods it provides, and how to call into those methods using the supported protocols. Figure 9-1 shows the GolfCourseService called in this manner.
Figure 9-1 Browsing to an XML Web service provides detailed information about the methods provided.
Clicking a specific method (see Figure 9-2) offers a detailed description of that method and a form to invoke it, given your inputs. Note that submitting the form invokes 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 9-2 Clicking a Web method offers a method description and protocol syntax for invoking the method.
As detailed in Figure 9-1 , the GolfCourseService offers the following Web methods, listed here by method signature:
public GolfCourse FindAll()
These Web methods and the classes behind them make up the server-side component of our application and represent the proxy necessary for other applications to interact with and manipulate the Golf Reservation System business logic. We will break down these Web methods and the Golf Reservation System server business logic behind them in more detail later in the chapter.
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 those services and format and manipulate data as they saw fit: one client application might use the GolfCourseService only to retrieve data, while another might retrieve golfer information from the GolfCourseService, caring nothing about the course data also available.
Although the application is tailored to a specific clientone that allows validated users to register for tee timesthe Web methods could be designed modeling only the data behind them. This approach would provide an XML Web service interface for retrieving the data published on the Internet that was not tailored to a specific client application design, but instead provided abstractions on a complex data store.