Frank E. Redmond III
Microsoft Corporation
June 1999
Introduction to Windows DNA
Windows DNA Design Objectives
Autonomy
Reliability
Availability
Scalability
Interoperability
Summary
To design and build three-tiered applications for the Microsoft® Windows® platform, developers must understand two things: the fundamentals of three-tiered application design in general and the specific Microsoft technologies that are relevant in developing three-tiered applications for the Windows platform. Windows DNA describes both. Windows Distributed interNet Application (DNA) is a general architecture that describes how to build three-tiered applications for the Windows platform. The purpose of this introduction is to provide developers with a general methodology for designing and building Windows DNA applications. This introduction will not attempt to describe every conceivable aspect of Windows DNA, but rather will focus on providing the reader with a firm understanding of the basic tenets of Windows DNA application design.
Figure 1. A three-tiered application is an application whose functionality can be segmented into three logical tiers of functionality: presentation services, business services, and data services.
The presentation services tier is responsible for:
The business services tier is responsible for:
The data services tier is responsible for the:
Data services come in a variety of shapes and sizes, including relational database management systems (RDBMSs) like Microsoft SQL Server™, e-mail servers like Microsoft Exchange Server, and file systems like the NTFS File System.
By contrast, a two-tiered application is an application whose functionality can only be segmented into two logical tiers, presentation services and data services, and while the responsibilities of the data services are the same for two-tiered and three-tiered systems, the responsibilities of the presentation services are not. In a three-tiered application, the presentation services are responsible for gathering information from the user, sending the user information to the business services for processing, receiving the results of the business services processing, and presenting those results to the user. However, the presentation services of a two-tiered application are slightly different. The presentation services of a two-tiered application are responsible for gathering information from the user, interacting with the data services to perform the application's business operations, and presenting the results of those operations to the user.
Figure 2. A two-tiered application is an application whose functionality can only be segmented into two logical tiers of functionality: presentation services and data services.
The differences in the responsibilities of the presentation services for two- and three-tiered applications greatly influence the developer's perspective of the application as a whole. For example, in a two-tiered design the logic that performs the tasks that the application is being designed to automate (for example, income tax preparation, order processing, and so on), which is commonly viewed as "the application," executes wherever the presentation services are located. However, in a three-tiered design "the application" executes wherever the business services are located. Such fundamental differences can lead to all sorts of confusion when discussing three-tiered application concepts with two-tiered application developers or vice versa, which is why it's crucial to understand the fundamental difference in developer perspective associated with two- and three-tiered application designs.
The Windows DNA architecture is designed to maximize overall application:
Application autonomy refers to an application's ability to govern its critical resources. Critical resources are the precious resources required by an application to function reliably as an independent entity. RDBMS connections, mainframe connections, and transactions are all examples of critical resources. Application autonomy is arguably one of the most important aspects of Windows DNA application design, and is also one of the most important differences between two-tiered and three-tiered client/server designs.
In a typical two-tiered client/server design, clients have direct access to the application's critical resources and are free to use those resources however they desire.
Figure 3. Two-tiered client/server applications are non-autonomous, which means that clients have direct access to the application's critical resources and are free to use those resources however they desire.
Because clients have direct access to the application's critical resources, there is little or nothing the application can do to protect itself from malicious or unexpected behavior, which ultimately compromises the application's overall stability. For example, a single rogue client could purposefully exhaust an application's precious critical resources in an attempt to prevent other clients from performing their work. An attack like this could render the defenseless application useless.
Windows DNA applications, on the other hand, never allow clients to have direct access to critical resources. Instead, clients issue requests to special trusted components called executants that perform the business operations the application was designed to automate (for example, income tax preparation, order processing, and so on). For instance, a PurchaseOrder executant might perform the operations necessary to add a line item to a purchase order: ensuring that the desired item is in stock, calculating any sales tax, shipping charges, and so on. By forcing clients to issue requests to executants that perform business operations using critical resources in trusted, well-defined ways, Windows DNA applications remain in complete control of their critical resources, which ultimately increases the application's overall stability. Because executants are trusted components they have direct access to the application's critical resources, which means they must pay close attention to the manner in which critical resources are used. Before an executant performs any business operation on behalf of a client, it should authenticate the identity of the requesting client, validate that the client has the proper authorization to perform the requested business operation, and inspect the client's request for proper syntax and valid data. Anything less than a perfectly formatted request should be denied immediately. With such a high standard of excellence, it's reasonable to expect numerous client requests to be denied, which is why Windows DNA applications should provide executant emissaries, or emissaries for short.
Emissaries are components that are designed to help clients issue perfectly formatted requests to executants to perform business operations on their behalf. One of the ways emissaries help clients is by providing them with any supplemental data the client may need in order to prepare requests. This information could be read-only snapshots of the shared data that is maintained by the executant (price lists, inventory identification numbers, and so on), or writeable per-user data that is maintained by the emissary on the client's behalf (user profile information, shopping cart contents, and so on). Another way emissaries help clients is by validating as much of the user-provided information as possible before transmitting the entire request to the executant, which helps keep network roundtrips to a minimum. To further reduce network traffic, emissaries, along with any supplemental data they may require, can be downloaded and executed directly on the client. When transmitting requests to the executant, emissaries are free to use any means at their disposal (for example, DCOM, MSMQ, Winsock, and so on).
Figure 4. An architectural diagram of the various components involved in building a DNA application using the "Executants and Emissaries" methodology
For a Windows DNA application to make its business operations available to the widest range of presentation services (dynamic HTML, Microsoft Win32®, and HTML 3.2), emissaries must be accessible from both interactive and non-interactive presentation services. Interactive presentation services are capable of providing feedback to the user on either a form-by-form or field-by-field basis. For example, an application that supports a Win32 user interface created in Microsoft Visual Basic® could immediately display error messages in response to invalid data entry in a field on a form.
Figure 5. Interactive presentation services like those created using Win32 or DHTML are capable of providing immediate feedback to the user on a field-by-field or form-by-form basis.
Non-interactive presentation services, on the other hand, are only capable of providing feedback to the user on a form-by-form basis. For example, an application that supports an HTML 3.2 user interface requires the user to submit the entire form to the server before processing of any kind can be performed.
Figure 6. Non-interactive presentation services like those created using HTML 3.2 are not capable of providing immediate feedback to the user, because they require a trip to the server to perform any and all data validation routines.
Figure 7. Because non-interactive presentation services require a trip to the server to perform their data validation routines, they are typically limited to providing feedback to the user on a form-by-form basis.
While the HTML 3.2 user interface may be extremely non-interactive, it is supported by a wide variety of non-Windows platforms, including Linux, UNIX, and Macintosh, which makes HTML 3.2 ideal for extending the reach of an application to a variety of different platforms. Windows DNA applications should be designed to accommodate both interactive presentation services such as dynamic HTML and Win32 for corporate intranet users that expect the rich presentation services of Windows as well as non-interactive presentation services such as HTML 3.2 for supporting Internet and corporate extranet users.
For an emissary to support interactive presentation services it must support both property-level and object-level validation. However, for an emissary to support non-interactive presentation services, it only needs to support object-level validation. Property-level validation is the process of ensuring that an individual property is within a predefined range of acceptable values. For example, an Account emissary that supports property-level validation would ensure that its Zip property contains a valid ZIP code as defined by the United States Postal Service. Supporting property-level validation allows emissaries to provide immediate feedback to interactive presentation services like those created using dynamic HTML or Win32. Object-level validation is the process of ensuring that all of an object's properties are within their respective predefined ranges of acceptable values. For example, an Account emissary that supports object-level validation would only be valid if it contained a valid ZIP code and a valid State. A valid ZIP code with a non-valid State would equal a non-valid Account emissary. Supporting object-level validation allows emissaries to provide feedback to non-interactive presentation services like those created using HTML 3.2.
Reliability refers to an application's ability to provide accurate results. An application isn't reliable if it returns inaccurate results. However, ensuring accurate results in a multiuser environment is very difficult. For example, suppose an application is designed to transfer money from one account to another by crediting one account and debiting the other. While this seems like a simple operation, imagine the results if any part of the system hardware or software fails after crediting money to one account, but before debiting money from the other. Or, imagine if two clients increment an account's balance by US$50.00 as the result of a recent purchase. Both clients read the current balance US$100.00 and then increment the current balance by US$50.00 (balance = balance + US$50.00) for an inaccurate final balance of US$150.00 (the final balance should really be US$200.00). To ensure accurate results, executants should perform their business operations as part of a Microsoft Transaction Server (MTS) managed transaction. Transactions ensure that state transformations are Atomic, Consistent, Isolated, and Durable (ACID).
Because transactions lock records to ensure ACID behavior, they should be considered critical resources, which means that clients should never be allowed to access them directly. Imagine what would happen if a user initiates a transaction, and then leaves the office to get a cup of coffee! Any records locked as a result of the outstanding transaction would be unavailable until the user returns to complete the transaction or the system-defined timeout expires; so to maintain application autonomy, Windows DNA applications should treat transactions as critical resources.
Availability refers to the amount of time an application is capable of reliably servicing client requests, and is important because an application is only useful when it's available to service client requests. Application availability is dependent on many things that are beyond developer control—things like hardware availability (disk drives, NIC cards, controllers, and so on), software availability (RDBMSs, Web servers, queuing systems, and so on), and network availability. To increase hardware and software availability, Windows DNA applications should eliminate any potential single point of failure by implementing redundant systems. Windows DNA applications should rely on hardware systems composed of RAID drives, multiple NICs, multiple controllers, and so on, and clustered using Microsoft Cluster Server (MSCS). MSCS works by configuring individual system resources like network names, IP addresses, applications, and so on, as cluster resources, such that if the resource or any of its subordinate resources fail for any reason the resource will automatically be made available on another node in the cluster. Windows DNA applications can also rely on MSCS to implement redundant software systems. However, because any node in the cluster can become the active node, software systems must be installed, configured, and ready to begin execution on any node in the cluster. Windows DNA applications designed to support MSCS must avoid any machine affinity, and must ensure that any data required by the application to perform its business operations is accessible from each node in the cluster. Simply put, Windows DNA application developers must be careful what they cache.
Windows DNA applications can simulate increased network availability by using Microsoft Message Queue Services (MSMQ). MSMQ provides store and forward functionality that allows messages to be stored on the local machine whenever the destination queue cannot be reached due to network unavailability. Once a message has been submitted to MSMQ for delivery, MSMQ will constantly and repeatedly try to forward each message to its destination queue until the message either reaches its destination or its delivery timeout expires. In this way, MSMQ can provide guaranteed delivery, which gives it a clear advantage over other session-based network communication services like distributed Component Object Model (DCOM) and Remote Procedure Call (RPC). In addition, MSMQ supports dynamic routing, which allows MSMQ to dynamically select which network to use for message delivery from a pool of user-defined networks. By increasing the number of networks available for message delivery, applications increase their chances for successful message delivery. Dynamic routing is another advantage that MSMQ has over its session-based network communication counterparts.
Scalability is the utopian goal of linear throughput growth for additional resources, and is what allows an application to support anywhere from ten users, to tens of thousands of users, by simply adding or subtracting resources as necessary to "scale" the application.
Throughput refers to the amount of work, measured in transactions (generated by users or machine), an application can perform in a given period of time (usually seconds), and is typically expressed in terms of transactions per second (tps).
throughput = transactions / second
For example, if an application can perform a transaction in 20 milliseconds (ms) on average, that application's throughput would be 50 transactions per second, or 50 tps.
1 transaction x transactions
--------------- = ---------------- x = 50 tps
20 ms 1000 ms
Scalability is a measure of the overall change in throughput resultant from an increase in resources, specifically the resources required to perform the transactions that were used to ascertain throughput. For example, application A that manages 50 tps throughput with x resources and 100 tps throughput with 2x resources has better scalability than application B that manages 50 tps throughput with y resources, but only 75 tps throughput with 2y resources. This is because the overall change in throughput for application A is 50 tps while the overall change in throughput for application B is only 25 tps.
Because scalability is increased as throughput growth is increased (the higher the throughput growth per resource, the higher the scalability), application developers must concentrate their efforts on increasing throughput growth in order to increase scalability. The key to increasing throughput growth is reducing overall transaction times, which is a product of the amount of time required to acquire the necessary resource(s) and the amount of time that the transaction actually uses the resource(s).
transaction time = resource acquisition time + resource usage time
If a transaction takes 5 ms to acquire a database connection and another 10 ms to actually update a record in the database, the entire transaction would take a total of 15 ms. Many things such as network latency, disk access speed, database locking scheme (optimistic versus pessimistic), and resource contention can affect resource acquisition time. Similarly, many things, such as network latency, user input, and sheer volume of work can affect resource usage time. Increases in resource acquisition or resource usage times increase overall transaction times, which ultimately decrease throughput and application scalability. This means that to increase scalability, Windows DNA application developers should concentrate on keeping resource acquisition and resource usage times as low as possible. Here are some things you can do to keep your resource acquisition and resource usage times down:
Another way Windows DNA applications can improve their scalability is by using MSMQ for emissary-to-executant and executant-to-executant communication. By using MSMQ, throughput can be increased by simply adding more servers to process queued requests. Having multiple servers processing work from the same queue is an efficient way to provide truly dynamic load balancing. Because each server simply keeps processing work from the queue as fast as it possibly can, there is never a time when one server is overloaded and another server is waiting for work.
For more information on performance and scalability, download the WinDNA Performance Kit from the Microsoft COM Web site at http://www.microsoft.com/com/resources/WinDNAperf.asp.
Interoperability refers to an application's ability to access applications, data, or resources on other platforms. Many enterprise environments support several different kinds of hardware and software systems that must all work together in order for the enterprise to be successful, which is why it is important for Windows DNA applications to be interoperable. In order to maximize application interoperability, Windows DNA applications should rely on:
Windows DNA is a general application architecture that describes how to build three-tiered applications for the Windows platform. There are a number of factors to consider when designing and building Windows DNA applications. However, generally speaking, developers should concentrate on maximizing overall application autonomy, reliability, availability, scalability, and interoperability.