Training
Certifications
Books
Special Offers
Community




 
Microsoft® Windows® 2000 Server Resource Kit
Author Microsoft Corporation
Pages 7296
Disk 1 Companion CD(s)
Level Advanced
Published 01/19/2000
ISBN 9781572318052
Price $299.99
To see this book's discounted price, select a reseller below.
 

More Information

About the Book
Sample Chapter
Related Series
Related Books
About the Author

Support: Book & CD

Rate this book
Barnes Noble Amazon Quantum Books

 


Chapter 6: Developing Web Applications from the Internet Information Services Resource Guide



The adoption of Internet standards coupled with the immense popularity of the Web have changed the architecture of distributed computing. The multilayered nature of the Web is an ideal environment for the development of component-based applications. They can be developed and customized quickly, with advanced system services such as database access and transaction processing. System resources can be managed and administered remotely. Moreover, new applications are available immediately, without requiring anything more than a browser on the user's system.

This section examines the opportunities that the Web provides for distributed application development, and demonstrates how to use Internet Information Services (IIS) 5.0 to develop the n-tier (also called multitier) Web applications of the future. In the process, the section will introduce client-based and server-based technologies that Microsoft has developed to implement this new breed of Web applications. The section assumes the reader is familiar with software development concepts.

Building on Client/Server

Market analysts have noticed a trend toward developing multitier applications that are distributed over Internet-standard networks, and predict rapid growth in these distributed systems in the coming years. Some predict that, by 2005, the familiar architecture of client/server applications will be replaced by "super-suites" of interconnected components, operating in frameworks of widely-available distributed systems. In other words, applications will be assembled from reusable building blocks, by using a variety of cooperating subsystems.

Before delving into the implementation details of building Web applications, it might be helpful to take a brief look at the architecture of the Web from a historical perspective, beginning with the traditional client/server architecture.

Client/Server Revisited

Cooperating and communicating applications have typically been categorized as either client or server applications. While the client application requests services using Microsoft® Distributed Component Object Model (DCOM) or remote procedure calls (RPCs), the server application responds to client requests. Traditional client/server interactions, shown in the figure below, are often data-centric and combine most (if not all) of the processing (or business) logic and user interface within the client application. The server's task is simply to process requests for data storage and retrieval.

Functional Diagram of a Client/Server (Two-Tier) Application

Client/server (two-tier) applications have usually performed many of the functions of stand-alone systems; that is, they present a user interface, gather and process user input, perform the requested processing, and report the status of the request. Because servers only provide access to the data, the client uses its local resources to process it. Out of necessity, the client application can tell where the data resides and how it is laid out in the database. Once the server transmits the data, the client is responsible for formatting and displaying it to the user.

The primary advantage of two-tier applications over monolithic, single-tier applications is that they give multiple users access to the same data simultaneously, thereby creating a kind of interprocess communication. Updates from one computer are instantly available to all computers that have access to the server.

However, the server must trust clients to modify data appropriately-unless data integrity rules are used, there is no protection against errors in client logic. Furthermore, client/server connections are hard to manage-the server is forced to open one connection per client. Finally, because much of the business logic is spread throughout a suite of client applications, changes in business processes usually lead to expensive and time-consuming alterations to source code.

Although two-tier design still continues to drive many small-scale business applications, an increasing need for faster and more reliable data access, coupled with decreasing development time lines, has persuaded system developers to seek out a new distributed application design.

Multi-Tier Design

The new system design logically divides computing tasks across the application. Viewed from a purely functional standpoint, most applications perform the following three main tasks: gathering user input, storing the input as data, and manipulating the data as dictated by established operational procedures. These tasks can be grouped into three or more tiers, which is why the new system design provides for three-tier, or multitier applications. The application tiers, shown in the figure below, are:

  • Client Tier   The user interface or presentation layer. Through this topmost layer, the user can input data, view the results of requests, and interact with the underlying system. On the Web, the browser performs these user interface functions. In non­Web­based applications, the client tier is a stand-alone, compiled front-end application.
  • Middle Tier   Components that encapsulate an organization's business logic. These processing rules closely mimic everyday business tasks, and can be single-task-oriented, or part of a more elaborate series of tasks in a business workflow. In a Web application, the middle tier might consist of Microsoft® Component Object Model (COM) components registered as part of a transactional application or instantiated by a script in Active Server Pages (ASP).
  • Third Tier   A database management system (DBMS) such as a Microsoft® SQL ServerT database, an unstructured data store such as Microsoft® Exchange, or a transaction-processing mechanism such as Transaction Services or Message Queuing. A single application can enlist the services of one or more of these data providers.

Three-Tier Architecture on the Web

Application tiers don't always correspond to physical locations on the network. For example, the middle and third tiers may coexist on the same server running both IIS 5.0 and SQL Server, or they could be separate. The middle tier alone may tie together several computers, and sometimes the server becomes a client itself.

Separating the application into layers isolates each major area of functionality. The presentation is independent of the business logic, which is separate from the data. Designing applications in this way has its tradeoffs; it requires a little more analysis and design at the start, but greatly reduces maintenance costs and increases functional flexibility in the end.

The explosive growth of the Internet is a strong motivation for organizations to adopt n-tier architectures in their products. However, organizations still face challenges. How can they take advantage of new technologies while preserving existing investments in people, applications, and data? How can they build modern, scalable computing solutions that are dynamic and easy to change? How can they lower the overall cost of computing while making complex computing environments work? One solution is Microsoft® Windows® Distributed interNet Applications (DNA).

Windows DNA

Windows DNA architecture is Microsoft's framework for building a new generation of n­tier computing solutions. Windows DNA provides a framework for delivering solutions that meet the requirements of corporate computing, the Internet and intranets, and global electronic commerce, while reducing overall development costs.

The heart of Windows DNA is COM. Windows DNA architecture makes use of a common set of services, including Hypertext Markup Language (HTML) and Dynamic HTML (DHTML), Microsoft® ActiveX® controls, COM components, client-side and server-side scripting, transactions, security and directory services, database and data access, systems management and HTML, and component authoring environments. These services are exposed in a unified way through COM, which enables applications to interoperate and share components easily.

The Windows DNA Family of Technologies

Windows DNA builds on the client-side services of the Microsoft® Windows® operating system and Microsoft® Internet Explorer, on the distributed infrastructure of Microsoft® Windows® 2000 Server and the Microsoft® BackOffice® family, and on the company's integrated tools, such as the Microsoft® Visual Studio® development system. Because Windows DNA architecture uses open protocols and published interfaces, organizations can integrate third-party products and solutions. In addition, because Windows DNA architecture embraces an open approach to Web computing, it builds on the many important efforts at developing standards approved by bodies such as the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF).

For more information about Windows DNA, see /dna/.

The Future of Applications on the Internet

Customers are beginning to demand global access to the information they need, both public and personal. Users increasingly want to use a single client application for their information access needs, and they rely on the versatility of the network and servers to provide content and services. Users will come to depend on these applications and want them to be universally available; they might even want to replace local applications on their desktop systems.

Consequently, there is likely to be an explosion of HTML-based server applications to feed the ubiquitous availability of the powerful Internet client. Applications will be factored into user interface-only client components (with little software required beyond the standard Internet browser), and a middle tier of server components that have no user interface and that provide services to the local desktop or across the Internet.

The following sections describe the roles that the client and middle-tier play in distributed Internet and intranet applications. The third tier is discussed in Data Access and Transactions in this book.

Client-Side Technologies

This section presents a survey of the technologies that make up the client tier of today's Web applications. Each technology is considered from the perspective of what it is, how it works as part of a Web application, and what the issues are regarding its use. This section does not discuss how to develop applications using client-side technologies.

Text and HTML

HTML is the basic formatting language of Web pages. Just like a printed page, text on a Web page can include a variety of font faces, colors, font weights and attributes, spacing, and columns. In addition, Web pages can include tables, frames, and HTML forms. Web applications make heavy use of tables and forms to display data, organize application elements, and collect user input.

HTML adheres to a set of standards that makes it usable over the entire Internet, as well as on intranets. For more information about HTML standards, either see the W3C home page at http://www.w3.org or consult your HTML reference materials. For information about the newest extensions to HTML, see Dynamic HTML.

Graphics and Multimedia

Graphics and multimedia, if used effectively, can greatly enhance the look and feel of an application. They can instruct, as well as draw the eye to important areas of the screen.

Multimedia is an especially powerful tool on an intranet. For example, by using streaming audio/video, like that available through Microsoft® NetShowT, you can broadcast special events as they happen, or use prerecorded video to train employees in complex technical operations.

Because of the speed limitations of modems used for most Internet connections, heavy use of graphics and multimedia over the Internet should be restricted. Low-resolution graphics, if designed correctly, not only download more quickly but may actually look better than high-resolution graphics on most computer monitors.

Hyperlinks

Hyperlinks connect the parts of your application together, act as the application's "menu," and can perform both client-side and server-side actions. For example, clicking a hyperlink can cause a page to load in another frame, or can run a client-side script to change the layout of the page.

Hyperlinks are normally embedded directly on the page as text or graphics (such as an image map) where the user can view and click them. They can also be activated when a form is submitted, or client-side script can dynamically create and trigger them.

There are lots of ways to present links to the user. You can simplify the layout of a large number of hyperlinks by grouping similar choices together, by using a similar style of presentation, or by hiding and displaying links as appropriate. For instance, you can choose to display links dynamically, based on the privilege level of your users. Only visitors with high-level access would be able to view links that perform advanced or administrative actions.

Client-Side Script

Client-side scripts run within the user's browser, using the processing power of the user's (client) computer. They can be written in any language supported by the browser; the most common is JavaScript, which is supported by most browsers. Some browsers, such as Internet Explorer, also support Microsoft® Visual Basic® Scripting Edition (VBScript). Client-side scripting enhances Web pages with a variety of custom capabilities. For example, you can use scripts to perform field edits and calculations, manipulate the client window, or validate form input. Scripts normally appear directly on the page they affect, but they can be used to manipulate the content of pages in another frame or browser window as well. For more information about browser support for client-side technologies, see Table 6.1 in the topic Browser Support.

ActiveX Controls

ActiveX controls can be used either to customize the user interface, or as "plug-in" applications (such as the Macromedia Shockwave animation control and the RealNetworks streaming audio/video player). ActiveX controls can perform a variety of tasks, from navigation to real-time interaction with stock quotes. They can be written in any language that supports COM Automation, including Microsoft® Visual Basic®, C++, Java, or even COmmon Business Oriented Language (COBOL).

ActiveX controls can be embedded into the HTML page by using the HTML <OBJECT> tag. If the control does not exist on the user's system, it can be downloaded using the URL specified in the CODEBASE attribute (see the following example). The <OBJECT> tag also supports component versioning. Once the control is downloaded and installed, the browser continues to use the cached control until an updated version is available on the server. The following example demonstrates the CODEBASE attribute:

<OBJECT ID="BoomButton" WIDTH=225 HEIGHT=35
   CLASSID="clsid:56F1BF40-B2D0-11d0-A6D6-00AA00A70FC2"
   CODEBASE="http://domain.microsoft.com/AControl.cab#Version=1,0,0,1">
</OBJECT>

A malicious ActiveX control could perform potentially destructive actions on the user's computer, such as erasing data from the hard drive. To help users determine whether a control is safe to use, Microsoft has developed security guidelines for vendors to follow when releasing a control. A control should identify its creator with a "signature" issued by a well-known security authority, such as VeriSign. Microsoft® AuthenticodeT, the company's code-signing technology, assures accountability and authenticity for software components distributed on the Internet. Only the original owner can modify a signed control, which prevents tampering by third parties. (For more information about Authenticode and code-signing, see /security/default.asp.)

As of this writing, only Microsoft® Internet Explorer 3.0 or later includes native support for ActiveX controls. Because of this, ActiveX controls are probably most useful for intranet sites or sites created especially for Internet Explorer users.

Case Study of a Web Application

Microsoft recently introduced a new means of filing employee expense reports. The old system required employees to prepare expense report forms, attach receipts, and submit them to their managers, who would review the forms and submit them to the accounting department. Mistakes were common, and forms often had to be resubmitted. Once the paperwork was finished, the reports were painstakingly entered into a database.

To eliminate some of the problems with the existing system, the accounting department introduced a Web application to control and streamline the employee reimbursement process. The new application allows the employee to report expenses using a Microsoft® Excel worksheet modeled after the paper version of the old form. The worksheet, after it has been downloaded to the user's browser, validates the data as it is submitted, catching most user errors up front. When the documents are ready, the electronic form can be routed to the employee's manager by e-mail. After the manager approves the form, a copy is returned to the accounts department and an approval notification is sent to the employee. The accounting department then performs all of its final work online, saving considerable time and effort.

The new expense-reporting system effectively:

  • Improved Control   Control was a recurring theme throughout the design of the application. The worksheet and associated Web site were carefully designed to ensure that both employees and managers understood their responsibilities. Using an electronic form meant that reports could be tracked on their way through the system, making expense auditing on the back-end faster and more verifiable.
  • Reduced Labor   Because there was less paperwork to be processed, the company was able to improve control while reducing the labor required to process and audit expense reports.
  • Decreased Resource   Part of the goal was to reduce paper waste. The online system requires fewer forms, and hence fewer resources.
  • Decreased Payment Cycle Time   The old process took 8 to 10 days from time of approval to employee reimbursement. Approval sometimes required weeks. The online solution enables a much faster turnaround time. In most cases, payment can be made within one or two days of approval.

Payoffs such as these are a common theme in most Web applications. A well­designed application can improve the way you work by being available wherever there's a browser.


Cascading Style Sheets

The Cascading Style Sheet (CSS) standard gives authors more control over fonts, sizes, two-dimensional overlapping, and exact glyph positioning (for rendering scripts and fonts of various languages, such as the diacritical marks used in Vietnamese or the calligraphic script of Urdu). CSS also separates formatting information from the Web page content, making it much easier to design and revise pages.

Style sheets control the appearance of HTML tags; they do not replace them. Style sheets give you the ability to attach style information to one or more HTML documents and to any of the tags within them, which greatly expands your control over the appearance and structure of each page. Formatting information can be applied to custom tags for a given browser, as well as to standard HTML tags.

CSS information can be specified by linking, embedding, or as an inline style modifier. An HTML document can use any combination of these three methods. However, the most common method is linking, because it establishes a basis for embedded and inline style modifications. An example of a link to a style sheet is shown here:

<LINK REL=STYLESHEET TYPE="text/css" HREF="./myCustom.css">

Note   Because of changes to the CSS standards recently adopted by the W3C, the CSS support in Internet Explorer 3.0 is not fully compatible with that found in Microsoft® Internet Explorer 4.0, which supports the new standard. A detailed description of the latest CSS 2.0 standard is available at http://www.w3.org/Style/.

Dynamic HTML

Dynamic HTML (DHTML), which is supported by Microsoft® Internet Explorer 5, is an emerging standard that is more than just an extension of standard HTML. With DHTML, you can easily add advanced functionality that was previously difficult to achieve without client-side controls. For example, you can:

  • Hide text and images in your document and keep this content hidden until a given time elapses or until the user wants to view it.
  • Animate text and images in your document, independently moving each element from any point to another in the document, following a path that you choose, or that you let the user choose.
  • Create a ticker that automatically refreshes its content with the latest news, stock quotes, or other data.
  • Create a form; then instantly read, process, and respond to the data the user enters in the form.

Internet Explorer 5 does not require additional support from Java applets or embedded controls to achieve these effects. It automatically reformats and redisplays the DHTML page to reflect dynamic changes in content styles. It does not need to reload the document, load a new document, or depend on the server to generate new content. Instead, it uses the power of the user's computer to calculate and carry out changes.

DHTML documents make heavy use of styles and script to process user input and directly manipulate the HTML tags, attributes, and text in the document. Through the Internet Explorer 5 object model, you can control every property of every HTML tag to precisely control the layout, appearance and function of your page.

Note   Not all the features of DHTML are compatible with all browsers. Web pages intended for viewing by browsers other than Internet Explorer 5 should be tested for compatibility with other browsers.

For more information about DHTML, see http://msdn.microsoft.com.

Data Binding

Using DHTML, the results of database queries can be "bound" to HTML elements, such as the rows of a table. (You can also use data-binding ActiveX controls, such as the Advanced Data Connector (ADC), included in earlier versions of Internet Explorer.) Data Binding allows you to remotely view and modify the results of database queries within the browser. It is a function of Remote Data Services (RDS), which is part of the Microsoft® ActiveX® Data Objects (ADO) family of data access components.

Note   Data binding is supported if you are using Microsoft® Internet Explorer 4.0 or later.

For more information about RDS and ADO, see Data Access and Transactions in this book or see the IIS 5.0 online product documentation. For more information about data binding, see http://msdn.microsoft.com.

Browser Support

In intranet scenarios where a single browser type can safely be assumed, you can design your sites around browser-specific technologies with impunity. (Just in case someone is an errant browser user, you should alert your users with a "Best viewed with" graphic on the site's home page.)

On the Internet, however, you can't assume that everyone has an up-to-date browser. And, even among newer browsers, several different types are available; Microsoft, Netscape, and Sun Microsystems have all released browsers with varying degrees of support for ActiveX, Java, scripting, and HTML. The question of what functionality to perform on the client depends on the variety and capabilities of browsers you want to support.

Using the lowest-common-denominator approach, pages contain no more functionality than the least capable browsers can process successfully. Content is guaranteed to be viewable in its entirety on any browser. Unfortunately, users might notice, and be disappointed by, the limited functionality this approach requires.

Some sites provide text-only versions of their pages, or frames-free areas for less capable browsers. This duplication ensures that all users get the same information, but it requires that you develop, test, and maintain multiple versions of your site. Often the less functional version remains underdeveloped, as the focus of development tends toward "bells and whistles."

The best approach may be to develop pages using basic technology, such as HTML and JavaScript, and to add specific features once you have determined the browser type. This is often a good middle ground, because all pages can be developed using one set of design elements and content. The advanced features of the Web site, such as data binding, are made available only to browsers that support them.

The Browser Capabilities component included in the scripting environment of ASP provides a way to detect the browser type and to tailor the returned document in order to exploit browser-specific capabilities. For more information about this component, see the IIS 5.0 online product documentation.

Table 6.1 summarizes browser support for different client technologies.

Table 6.1   Support for Client Technologies by Browser


Technology
Widely
Supported

Internet Explorer 3.0x
Internet Explorer 4.0
and 5
HTML X X X
Graphics and multimedia X X X
Hyperlinks X X X
JavaScript X X X
VBScript   X X
ActiveX controls X X
Cascading Style Sheets X X
Dynamic HTML   X

Limitations of Client Technologies

Although it's possible to create applications that rely exclusively on client-side technologies, they are somewhat limited in their capabilities, just as client/server architecture is. There are several reasons why client/server architecture isn't suitable for full-scale enterprise applications on the Internet:

  • A client application using client-side ActiveX controls or client-side scripting is not supported by all browsers. A line-of-business application for the Internet must work with as many browsers as possible, including those that do not support HTML tables, frames, Java applets, client-side scripting, or ActiveX controls.
  • Coding business logic as client-side script fails to protect your programming investment (because the source code is available to all). Java applets and ActiveX controls are more secure, but whenever you combine business logic with the user interface, your application becomes harder to support and to debug. In addition, the resulting components are less likely to be reusable in other applications.
  • Client-centric applications do not take full advantage of the three-tier programming model. Designs in which the client plays more than a supporting role typically take on tasks that are better suited for the server, such as resource management and data manipulation.


Next


Visit Microsoft Press for more information on
Microsoft® Windows® 2000 Server Resource Kit



Top of Page


Last Updated: Friday, July 6, 2001