Functional Architecture

Functional Architecture

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

The Issue Tracking application uses a three-tier architecture typical of the Microsoft® ASP.NET application style. The application was created using Microsoft Visual Studio® .NET, and runs within the Microsoft .NET Framework and common language runtime.

In the client tier, Microsoft Internet Explorer displays the application user interface. It receives HTML, Microsoft JScript®, XML, and XSL data from the Issue Tracking application via HTTP.

The application tier comprises a Microsoft Windows® server operating systems Server running Microsoft Internet Information Services (IIS) and the .NET Framework. The Issue Tracking application runs as an ASP.NET application inside the common language runtime. The application tier handles client requests, and communicates via WebDAV with Microsoft Exchange in the server tier.

The server tier comprises IIS, an Exchange Server 2003, and the Exchange store, running on Windows server Server.

The rest of this topic provides additional details about each tier.

The Client Tier

The client tier consists of a typical Web-enabled personal computer running Microsoft Windows® and Internet Explorer version 5.5 or later. The client sends requests to the Issue Tracking application using HTTP GET and POST. The pages displayed on the client are a mix of several technologies:

• HTML and Dynamic HTML (DHTML) supply the skeleton, layout, and interaction implementation in the user interface.

• JScript implements client-side interaction and validation code, and constructs the data structures sent to the application in HTTP POST requests.

• XML and XSL provide data and formatting for the data-bound Web Form controls. For example, the data tables that appear on many pages arrive at the client as XML data, and are formatted on the client by applying an XSL stylesheet.

For more information about client software requirements, see System Requirements.

The Application Tier

The application tier runs on a Windows server Server running both IIS and the Issue Tracking application. This section describes how the Issue Tracking application works inside ASP.NET. The next section describes how the Issue Tracking application is structured.

When the user accesses the Issue Tracking application using a client Web browser, the initial page request is sent as an HTTP GET request. Subsequent requests generated in response to the user clicking links or buttons in the Issue Tracking application user interface are transmitted as HTTP POST commands.

In the application tier, IIS listens for HTTP requests on the Issue Tracking application virtual directory port. IIS passes the requests through the Internet Server Application Programming Interface (ISAPI) extension interface to the ASP.NET ISAPI dynamic-link library (DLL). When the call is made to the ASP.NET ISAPI DLL, execution moves from the standard Microsoft Win32® operating environment, into the managed code environment of the .NET Framework and the common language runtime.

In response to the client request, ASP.NET retrieves the proper page, performs the necessary processing, and returns the response back through the ASP.NET ISAPI DLL. The response information passes through the IIS ISAPI interface and the Issue Tracking application IIS virtual directory, and then to the client browser. The response sent back to the client can include HTML, DHTML, JScript, XML, and XSL.

It is important here to mention two powerful .NET Framework and ASP.NET features. When you have the Issue Tracking application installed and running, view the source of a page displayed on the client browser, and compare it with the .aspx and .aspx.cs. source files. Notice that much of the code running on the browser is not written by the developer, but is automatically generated by ASP.NET. This can save significant development time that might be spent programming client-side user interaction, data validation, and request formulation. In addition, ASP.NET automatically handles differences between client browsers and devices.

There are three distinct lifetime phases of an ASP.NET page. The first time the page is loaded, ASP.NET initializes the page through the OnInit event, which calls the Page_Init function. Events coded for the page respond to user actions, and may be called many times during the lifetime of the page. User-interaction events that trigger actions on the same page are called "postbacks." When the page is no longer needed, ASP.NET unloads the page by calling the Page_Unload function. During each of these stages, ASP.NET uses the design and code created by the page developer.

There are two general styles you can use to write ASP.NET applications. The pages of an ASP.NET application are called "Web Forms." In previous versions of ASP, scripting code was inserted inline with the HTML page design. This method is still available. ASP.NET also offers a second design method, in which the HTML layout and markup are stored in one file, and the code controlling the behavior of the Web Form stored in a different file. The Web Form layout, created using the Visual Studio .NET Web Forms designer, is stored in a file with the .aspx extension. The code-behind file, which contains page initialization, event handlers, functional logic, and page cleanup code, has the same name with an additional suffix depending on the programming language used. For example, the code-behind files of the Issue Tracking application are written in Microsoft C#, and have the extensions .aspx.cs. ASP.NET binds events written in the code-behind files to the applicable Web Form controls.

A significant advantage to the separate file storage in the code-behind development style is that Web designers are generally protected from unintentionally changing the page functioning, and programmers are generally protected from changing the layout. The separate code files can be compiled into an assembly DLL using Visual Studio .NET, which makes the code load much faster. The .NET Framework determines what type of browser the user is running, and renders the Web Forms into HTML and script, within the capabilities of the browser. The developer doesn't need to write specialized code to determine the browser capabilities, or write multiple versions of the same page to accommodate different browsers.

When the Issue Tracking application is built in the Visual Studio .NET environment, all the C# code modules, including the .aspx.cs code-behind files, are compiled into a single assembly DLL. The .aspx Web Form files are compiled as needed at runtime by the ASP.NET page compiler. The page compiler builds each page when it is first requested, and the compiled page assembly is retained in memory and on disk until it is no longer needed. While this increases the delay when first loading the page, subsequent requests are handled much more quickly.

For more information about creating applications using ASP.NET, see MSDN Online.

The Issue Tracking Application Structure

The Issue Tracking application consists of Web Forms for each page rendered in the user interface, and includes several C# code files that perform functions commonly used by the Web Forms. All user interface design was created in the Visual Studio .NET Web Forms designer; no hand-editing was needed in the .aspx files.

Each page the Issue Tracking application displays to the user is defined in a Web Form, which consists of an .aspx file and an .aspx.cs C# code-behind file.

Many of the Web Forms display lists of companies, contacts or issues using a DataGrid control. Data obtained from the Exchange store is organized into a DataView structure, and the DataViews are bound to the DataGrid control by code in code-behind portions of the individual Web Forms.

The code in E2KDav.cs formulates and handles the Distributed Authoring and Versioning (DAV) requests to the Exchange server, and returns the data that is then used to create the DataViews. The DAV requests use the HttpWebRequest object.

The code in Utility.cs performs a variety of miscellaneous utility functions, including filtering unsupported characters in folder and item names. Utility.cs provides functions to construct the XML used in the DAV requests, and to retrieve individual Exchange store item properties. Utility.cs uses E2KDav.cs to handle many DAV requests.

The code in Contacts.cs creates, updates, and retrieves information about contacts in the Exchange store. Contacts.cs uses E2KDav.cs to handle the DAV requests.

Similarly, the code in Companies.cs and Issues.cs creates, updates, and retrieves information about companies and issues in the Exchange store. They also use E2KDav.cs to handle the DAV requests.

To enable easier localization and customization, all strings that appear in the user interface, or that are presented in error messages, are stored in the Application.resx resource file. All of the Issue Tracking application Web Form code-behind files use the PageLocalization function to retrieve information from this file.

For more information about the individual Web Forms, see The Visual Studio .NET Project.

The Server Tier

The Issue Tracking application stores information about all of the companies, contacts, and issues inside the Exchange store on the server tier.

To access the Exchange store, the Issue Tracking application calls the functions in E2KDav.cs that create and handle the request. When building the application, Visual Studio .NET compiles E2KDav.cs into the application assembly DLL. Running as managed code within the .NET Framework and common language runtime, the application assembly uses the WebRequest class to make requests to the Exchange store, and to retrieve the resulting data.

Security credentials needed to access the Exchange store are passed in the DAV XML in addition to the request information. For more information about the Issue Tracking application security, see Security Architecture.

The information passes between the application and server tiers as XML via DAV, to the Exchange virtual directory of IIS.

The Exchange virtual directory passes the requests to the ExchangeDAV interface, which then processes the request via the Exchange store driver. The Exchange store driver places data into and retrieves data from the Exchange store.

Returning data to the Issue Tracking application occurs in the reverse order, starting at the Exchange store, and ending in the application tier. When the DAV data is returned, it is processed by the application and presented to the user as appropriate.

Send us your feedback about the Microsoft Exchange Server 2003 SDK.

Build: June 2007 (2007.618.1)

© 2003-2006 Microsoft Corporation. All rights reserved. Terms of use.