Certification Objective 6.02: Defining the Technical Architecture of a Solution | MCSD Analyzing Requirements and Defining .NET Solutions Architectures Study Guide (Exam 70-300 (Certification Press)

Since we created the concept of our solution in Chapter 2, we already have a good idea of what the technical architecture of our solution will look like. For instance, we have probably already decided whether we will create a web-based solution, a wireless personal digital assistant (PDA) solution, or a regular Windows application. Technical architecture is the overall structure and technical design of an application. As many of you know, .NET applications can be designed for many target architectures, such as the following:

Single-tier, or standalone
Two-tier, or client/server
Three-tier, or n-tier

XML web services

Author's Note

A tier is a distinct layer of an application installed on its own computer across a network. The key word is “distinct”—different computers that have identical components of a single application installed on them are considered part of the same tier.

The best technical architecture to choose for a particular solution is usually based on many factors. In general, application designers should choose the architecture that contains the fewest number of “tiers” that will meet the clients business and technical requirements. That is, there is no point making a word processing application an n-tier application unless there are requirements that can only be fulfilled by introducing networks and servers into the equation. Likewise, you will probably want to investigate an n-tier solution for a high-performance, high-availability online transaction processing (OLTP) system because that architecture will help fulfill some of the business requirements that other architectures will have a hard time fulfilling.

Exam Watch

The MCSD 70-300 exam will test your ability to determine the best technical architecture for a particular solution.

In this section, we will take a brief look at each of the architectures and look at the situations and scenarios where each would be used in a production environment.

Scenario & Solution
To create an application that does not require access to a network or a server,…	Create a single-tier, or standalone, application
To create an application that requires access to a database or an application server somewhere on the network,…	Create a two-tier, or client/server, application
To create an application that distributes work between a client machine and more than one server,…	Create an n-tier, or distributed, application

Single-Tier Solutions

A single-tier architecture is the simplest form of application architecture. Single-tier applications, sometime called standalone applications, have everything they need to run installed locally on the client computer (also called a client workstation). Typically, these applications consist of a single binary executable (EXE) file, although you will find some applications that ship with their own binary libraries (DLLs), local data stores, or both. There are many examples of single-tier applications, such as word processors, spreadsheets, accounting programs, and video games.

Other than the typical productivity applications, custom-developed single-tier applications are a bit unusual in the corporate world because applications typically have to share data with other applications or a central data server. That is the nature of large corporations and governments—data is only useful if it is available in a central location. However, there are plenty of reasons you might want to develop a single-tier application:

The application is just a tool (such as a calculator) or a game and is not required to save any information permanently.
The application produces paper printouts, data files, or e-mail that can be sent on to other applications for processing.
The application does save information permanently, but no other computers or people need access to that information.
The application is easier to develop than two-tier and n-tier applications.
The application is less complex than two-tier and n-tier applications.

There are also several reasons why you would not want to choose a single-tier application for a particular solution:

There may be scalability concerns as the application grows in size and scope.
It is often more difficult to back up files on a user’s individual desktop than on a server.
There may be performance issues because one computer does all the processing work in a single-tier application.

Application developers will need to analyze the business needs of their individual situation carefully in order to determine if a single-tier architecture is the proper solution.

Two-Tier Solutions

A two-tier architecture is only moderately more complicated than a single-tier one. Typically, a two-tier application involves an application that runs on one computer (called the client) connecting to a database running on another computer (called the server). This setup is called a client/server architecture.

In addition to a client/server setup, there are other ways to split the processing between the two machines in a two-tier arrangement. An application can run on a server that sits in between the client and the database to handle certain types of business processing. Because the server application and the database reside on the same computer in this case, many developers still regard this as a two-tier architecture.

Some web-based applications can be described as having a two-tier architecture. (Web applications are sometimes described as n-tier as well, as you’ll read in the next section.) Web applications typically force the web server to do most of the processing work and require only that a web browser be installed on the client machine. That is why they are sometimes called “thin clients.”

There are many good reasons why a developer may choose to split an application into two tiers:

The server provides a way to share information between multiple clients.
Intensive processing can be handed off to the server to perform.
Server applications are sometimes easier to update than client applications.
Two-tier applications can be fairly easy to develop.
There are many ways to distribute the workload across client and server machines.

There are also a few reasons why you would not want to create a two-tier application for a particular solution:

Two-tier applications are more complex and require more maintenance compared to single-tier solutions.
Performance issues may arise if the client computers are relying on the server to do too much work.
A faulty or slow network could cause application problems.
Availability issues may arise if the server needs to be rebooted for routine tasks such as installation of operating system service packs.

Despite these considerations, the two-tier application is one of the most popular types of applications in the corporate environment. It is extremely flexible in the ways in which it can be configured, and all of the Visual Studio .NET languages (such as VB .NET and C#) easily support interacting with a database server using the ADO .NET classes.

Three-Tier and n-Tier Solutions

Three-tier and n-tier architectures are the most complex types of applications to develop. Creating systems that distribute the workload over several servers can be a complex task because it usually involves creating Component Object Model (COM) components that can run in a Microsoft Transaction Server (MTS, for Windows NT) or Component Services (for Windows 2000) transaction server environment.

The simplest type of architecture that fits this description would be an ASP.NET web application that has a database residing on another server. This three-tier architecture provides a clear distinction between the three application layers—the presentation layer, the business layer, and the data layer. The most complex application architecture would be an n-tier application that is divided into dozens of individual COM components installed across a dozen or more servers. These components would need to be running inside a COM+ or Distributed COM (DCOM) environment in order for all the pieces of the application to communicate with each other effectively.

In some respects, the n-tier architecture is the least efficient form of application configuration. Just think about the amount of effort it takes by several machines just to pass messages around in order to get something done. In fact, if you were to place a simple client/server application in a head-to-head race against a complex n-tier setup to process a single database transaction, the client/server application would probably win.

But the real strength of the n-tier setup is its scalability. If you placed the client/server and n-tier applications in a head-to-head race to process 10,000,000 records, the n-tier application would probably win. This is because in the n-tier configuration you have the power of several servers to process the transactions, as opposed to just one measly server in the two-tier configuration. Our n-tier application can even have several database servers at its disposal if the database becomes the bottleneck because there are established methods for splitting a database over many machines.

As you’d expect, there are several reasons why you would want to develop a three-tier or n-tier application for a particular solution:

It is extremely scalable, which allows more transactions to be processed per hour.
It is highly available in that servers can usually be rebooted without bringing the application down (because multiple servers perform the same task).

There are also several reasons why you would not want to choose this application type:

It is difficult and more expensive to develop.
It is difficult and more expensive to maintain.
Its complex architecture means the sources of problems are not easily found.
The costs for hardware and software licensing costs are higher than for other application types.

The n-tier architecture is popular for enterprise-level systems, which are designed to serve thousands of users simultaneously. This could be an e-mail system, an e-commerce web site, or some other mission-critical application that the company cannot afford to have go down for maintenance. It could also be an application that must have servers distributed geographically (around the country or around the world) to provide decent performance and reduce network risk but still needs a centralized server to consolidate the regional data. The one thing to realize about these types of systems is that they are expensive to develop and maintain.

Using Microsoft Transaction Server or Component Services

Many of the advantages of developing three-tier and n-tier applications are only realized when the COM objects are managed inside a transaction server environment. In Windows NT, this environment is called Microsoft Transaction Server (MTS), and in Windows 2000 it is called Component Services or COM+.

Transaction servers provide the following benefits:

Object brokering Helps applications use components, making code reuse easier
Transaction monitoring Manages transactions across multiple components
Object caching and pooling Allows an application client to use preloaded copies of a component for improved application performance
State maintenance Allows applications to treat a component as if it had exclusive access to it, even though it doesn’t
Data sharing between components Uses the Shared Property Manager to allow related components to share data with one another
Process isolation Protects the server from misbehaving components, so they cannot crash the server
Security Manages the security settings for components
In-memory databases Allows you to store frequently accessed databases in memory for performance purposes
Application packages Makes it easier to place components of an application across multiple servers, called distributed processing

Developers who plan to use COM components in their web applications should investigate the use of MTS. You might think that this would be overkill for small applications, but MTS can have benefits even for small sites.

XML Web Services

Microsoft is positioning XML web services as one of the building blocks for applications that are distributed over the Internet. What makes a web service different from one-, two-, and three-tier applications is its interface with the outside world. Specifically, web services are accessed using XML-formatted messages instead of graphical buttons and text boxes.

The users of web services (or consumers, as they are called) are other applications, not humans. You and I are not going to sit down and format an XML message just to purchase an airline ticket over the Web—another application is needed in order to help us do that. There are two main advantages of creating web service applications:

They work using standard protocols over the Internet.
If the application developer allows it, anyone can write an application to interface with that service.

One analogy I use to describe why web services are important is that, in the future, you will be able to tell your mobile phone that you need to book a trip to Chicago. Your mobile phone will be smart enough to contact the airline to purchase your tickets according to your preferences, contact your favorite hotel to book a room, and contact the car rental agency to reserve an automobile. It will be able to do this by interfacing with the web services provided by these companies. It will even remind you on the morning of your trip to pack an umbrella, since the forecast is calling for rain in Chicago.

When designing a web service application, there are a few issues that will need special consideration during the physical design step of the design process. Even though this application uses standard Internet protocols such as HTTP to communicate, this does not necessarily mean it is exposed to the public at large over the Internet. For example, a company can deploy an internal document repository as a web service and ensure that the application is available only to certain employees.

Choosing a Data Storage Architecture

Another issue that must be addressed when designing applications is the data storage architecture. Almost since companies have relied on computers (since the big room-sized mainframe days of the 1960s), companies have relied on the data that computers have produced. In the old days, mainframes used to store their data to tape—big reels of magnetic tape that were stored in canisters and manually filed away for later retrieval. These days, servers are connected to massive arrays of hard drives, often arranged in striped sets such as in a Redundant Array of Independent Disks (RAID) configuration.

On The Job

I’m sure there are people who still rely on tapes, because mainframes really haven’t gone away, but it’s been at least ten years since I have seen one.

The most common type of data storage architecture is the relational database. A few well-established and reliable relational database management systems (RDBMS) exist, such as SQL Server 2000 and Oracle 9i. These are scalable and robust applications that can support applications requiring several terabytes of data storage. These servers can typically be clustered—allowing multiple database servers to serve a single application for the most robust and reliable solution.

There is an emerging type of database called an object-oriented database management system (OODBMS). An OODBMS includes support for the modeling and creating of database objects, including complex object-oriented concepts such as classes, inheritance, and methods. Object-oriented databases are still relatively rare, and few standards exist for developers to rely on.

Another emerging type of database is the native Extensible Markup Language (XML) database. XML is a hot Internet standard for formatting data for storage and transmission. XML is a text-based format that is self-describing—elements and attributes demark the columns of data and also provide a basic definition for what each field contains. For those of you unfamiliar with XML format, the following code listing is an example of an XML document.

<?xml version="1.0"?> <employees>   <employee >   <name>Bob Jones</name>   <number>123456789</number>   <dob>07/01/1940</dob>   <doh>01/01/2000</doh>   <salary>52000</salary>   <img src="/books/2/310/1/html/2/BobJones.gif" />   </employee> </employees>

As you can see from the preceding code, XML can be read easily by both humans and machines. For instance, it is easy to infer that the XML element <name> gives the full name of the employee with the ID 9091773. Many of you may think that XML looks surprisingly similar to Hypertext Markup Language (HTML). That is because HTML and XML have an ancestral language in common—Standard Generalized Markup Language (SGML).

Exam Watch

For the MCSD 70-300 exam, you should understand what XML is, and you should know some of the benefits of using it as a data storage format.

There are some significant differences between HTML and XML, however, so the similarities are only superficial. XML has rules that make its format a lot stricter (and thus less flexible) than HTML. There is an XML-compatible version of HTML available called XHTML.

When a computer reads an XML document, it is said to parse it. One of the limitations of XML as a data storage format is that, because it is text based, XML data takes up more disk space and memory than its binary data counterparts. XML is also more difficult to sort and search on because the columns are embedded inside the XML document, and that means that all of the XML code has to be parsed in order to extract a single column of data.

Author's Note

For more information on XML, HTML, or XHTML, check out the World Wide Web Consortium’s web site at http://www.w3.org/.

This does not necessarily mean XML is a bad choice as a data storage format. One of XML’s greatest strengths is that, as a text-based format, it can be easily shared between any set of hardware and operating system platforms in the world. An Apple Mac can easily read XML files generated by an IBM mainframe, and a PC can easily read files generated by a Palm Pilot personal digital assistant (PDA). As long as they can talk, they can share XML.