Why Should You Use COM?

[Previous] [Next]

I'll assume that you are at least considering using COM+ to build distributed applications. Many companies are using COM+ and Microsoft Windows 2000 because they provide a robust development platform. This platform is made up of several core technologies that provide the basic building blocks for constructing multitier business applications. And after all, the more the underlying platform brings to the table, the less code you have to write and debug.

I probably don't need to convince you that multitier applications offer many advantages over the two-tier applications that were in vogue in the late 1980s and early 1990s. Your company has probably already decided to abandon the two-tier approach in favor of a multitier strategy. However, I'd like to take a little time at the beginning of this chapter to review the most significant problems with two-tier applications and explain how multitier applications provide solutions to many of these problems. I'll also discuss why multitier development introduces some new problems and additional complexities.

One of Microsoft's goals in developing COM+ has been to offer companies the benefits of multitier applications while hiding as much of the inherent complexity as possible. Over the last decade, Microsoft has made many advances in creating this infrastructure for distributed applications.

The first version of COM shipped in 1993. Since that time, COM has grown from a young and complicated technology to become the core of Microsoft's multitier strategy. This chapter examines COM's most important milestones. Along the way, I'll also do my best to define all the acronyms that marketing folks have generated over the years. You've probably heard of OLE, DCOM, ActiveX, and MTS. COM+ and DNA are the two most recent additions to the list. But have you ever tried to explain the difference between these terms to someone at a cocktail party? It's not easy, is it? They all mean different things to different people.

The chapter concludes with a high-level overview of the distributed services that have been integrated into the COM+ platform. Any nontrivial multitier application requires such things as transaction support, integrated security, a Web server, messaging, and delivery of event notifications. This chapter will identify where each of these COM+ services fits in. Before drilling down into the low-level details in the chapters that follow, I'll show you how all these pieces fit together. This should give you an appreciation for COM+ as a whole and show you the light at the end of the tunnel.

From Two-Tier to Multitier Systems

One of the best reasons to use COM+ is to move a company's information systems from a two-tier architecture to a multitier architecture. This transition requires the design and creation of a middle-tier layer of business objects. Business objects usually sit between client applications and database servers. COM+ serves as the platform for these types of systems.

Two-tier applications have been widely deployed in the industry, so the problems associated with them are well known. Let's review the key shortcomings of a traditional two-tier architecture, such as the one shown in Figure 1-1.

Figure 1-1 Typical two-tier applications require a separate connection to a database server for each user, and the user's computer must have the appropriate driver for a specific database management system (DBMS).

• User interface code is intermingled with business logic and data access code, which makes it difficult to reuse business logic and data access code across multiple client applications. Furthermore, changes to business logic or the database often require rebuilding and redistributing client applications.
• Each client application, complete with business logic and data access code, runs in a separate process, so you can't share resources that are process-specific, such as threads and memory. You also can't share a database connection in a two-tier application because each user requires a separate connection to the database server. The same is true for client applications that connect to a mainframe computer. This inability to effectively share resources across a set of users limits a system's overall throughput and scalability.
• Every client computer requires one or more proprietary drivers so that it can talk to a database server or a mainframe application, which makes desktop computers more expensive to maintain and configure. The system administrator must install and maintain a set of drivers on each computer to provide access to such things as open database connectivity (ODBC) databases. If you need to swap out your back-end database—for example, if you're moving from Sybase to Oracle—the administrator must visit every single desktop. That gets expensive.
• Client applications have a hard time accessing data from multiple data sources. In a corporate environment, it's not uncommon for critical business data to be spread across many different systems, as shown in Figure 1-2. Things get pretty tricky when an application needs to run business transactions using data that's spread across multiple computers. Things get exceptionally difficult when the data is also stored in a variety of formats.
• Client applications are often required to run on the same local area network (LAN) as the database server or mainframe application, which makes it impossible to build distributed applications that span geographic locations. Many companies have employees all over the planet, and many of them need to create applications for customers and suppliers that could never be integrated into such a controlled environment as a corporate LAN.
• Users are restricted to specific platforms. For example, a two-tier system often requires everybody to run the same operating system, such as a 32-bit version of Windows. In a world where any computer can potentially be connected with any other, this limitation is becoming more and more unacceptable.
• Two-tier systems cease to be operational when computers become disconnected, such as when the database server is taken off line for maintenance or laptop users disconnect from the network while they're working in airplanes or at customer sites. A system's availability is severely limited if it experiences downtime whenever various computers can't directly connect to one another.

Figure 1-2 A two-tier strategy doesn't work well when a company has multiple client applications or multiple database servers.

Splitting out the presentation tier

The problems of a two-tier architecture can be solved as many other problems in computer science are solved—by adding a layer of indirection. You can decouple client applications from business logic and data access code by introducing a set of business objects, as shown in Figure 1-3. The client application containing the user interface code is often referred to as the presentation tier. Unless I indicate otherwise, the term client application in this book means a presentation-tier application that contains the elements and code for the user interface.

Business objects allow you to centralize your logic and reuse it across several client applications. In networks based on Windows 2000 and Windows NT, these business objects can be deployed using COM as the foundation. COM can also provide the basis for remote communication between client applications and middle-tier objects.

One of COM's biggest selling points is that it allows middle-tier programmers to update the code in their business objects without requiring recompilation or redistribution of client applications. It's pretty straightforward and painless to change your business logic or data access code after your components have already been put into production because client applications are shielded from your business objects' implementation details.

Figure 1-3 Introducing a set of business objects in the middle tier eliminates costly dependencies between client applications and database servers.

An application's data can change storage formats and new database servers can be brought on line without undue pain and frustration. You can often make the necessary modifications to a single Microsoft Visual Basic dynamic-link library (DLL). It's easy to recompile a DLL and replace it on a production server in the middle tier. The client applications remain in production unaltered.

In a typical multitier application like the one shown in Figure 1-3, a set of middle-tier objects runs on behalf of many users. However, all these objects often run inside a single process on a Windows 2000 server. This makes it possible to share process-specific resources such as threads, memory, and database connections across multiple users. Also, the computers running client applications don't require database drivers, as they do in the two-tier model.

Logical tiers vs. physical deployment

One of the first questions that arises in multitier development is where each of the tiers should be deployed. Figure 1-4 shows two possible scenarios. The number of tiers doesn't necessarily indicate how many computers are involved. In a small deployment, the business code and the database server might run on the same computer. In a larger system, the data can be kept on one or more dedicated computers while the business objects run on a separate host.

Figure 1-4 The mapping between business objects and the data access layer can be simple at first and then become more complex without affecting client applications.

Some physical deployment schemes are easier to set up and less expensive. Others offer higher levels of scalability, reliability, and fault tolerance. When people speak of multitier systems, they're speaking of several distinct logical tiers. The physical deployment can vary and can easily be changed after a system is put into production. One of COM's greatest strengths is that it allows you to make changes to the physical deployment without modifying or recompiling any application code.

Some people use the terms three-tier or N-tier instead of multitier. For the most part, these terms all mean the same thing—that a system has three or more tiers. Figure 1-5 shows a more complex set of physical layers. In the multitier model, the business and data access tiers can be arbitrarily complex. The best thing about this model is that client applications know only about a visible layer of business objects. All the additional complexity behind the business objects doesn't concern them. The primary design goal in a multitier system, therefore, is to hide as much of this complexity as possible from the client applications that make up the presentation layer.

Another powerful feature of COM is that it allows client applications to create and use objects from across the network. Behind the scenes, COM uses a protocol called Remote Procedure Call (RPC) to execute method calls across process and host boundaries. RPC is the first of several important protocols that you should understand before you design a distributed application with COM+.

If you have a set of users that all run COM-aware operating systems such as Windows 2000, Windows NT, and Windows 98, you can create multitier applications like the one shown in Figure 1-5. The computers running the client applications rely on COM to establish connections with business objects across the LAN. Once a client application creates business objects from across the network, it can use them to run transactions and retrieve information.

Figure 1-5 One of the greatest strengths of a multitier architecture is that it hides the complexity of a company's evolving IT infrastructure from client applications.

Although this approach works well for some applications, it's inadequate for others. This style of development usually requires that every user run a 32-bit version of Windows. It also works much more reliably when all your client applications and business objects are running inside the same LAN. You might, however, want to reach users who haven't logged on to the local network or who are running other operating systems, such as Macintosh, OS/2, or UNIX. You can reach a much larger audience by using a Web-based development strategy.

Web-based applications

The popularity of the Internet and Web-based applications has spurred the industry's adoption of multitier architectures. In a Web-based system, client applications run inside a browser. Browsers submit requests to Web servers using a lightweight protocol called Hypertext Transfer Protocol (HTTP). The presentation tier in a Web-based application is constructed with Hypertext Markup Language (HTML).

The way things work in a typical Web application is actually pretty simple. A client submits a request to the Web server, and the Web server responds by processing the request and sending an HTML-based page back to the user. The great thing about working with HTTP and HTML is that every major platform supports them. Your applications can potentially reach any user on the Internet.

Note that the Web server is the client's entry point into the middle tier, as shown in Figure 1-6. When a client submits an HTTP request, the middle-tier application must load and run business objects in order to realize the benefits of multitier development. While the code and HTML pages that make up the presentation tier live on the server, you can still separate the user interface elements, the business logic, and the data access code. As you'll see in later chapters, you can create a single set of business objects and share them across LAN-based clients as well as Web-based clients.

Figure 1-6 Web-based development makes it possible to reach clients over the Internet who run a wide range of browsers and operating systems.

If you design a Web-based application correctly, you can realize all the benefits of multitier development that I've described so far. You can share process-specific resources such as threads, memory, and database connections across a large group of users. You can respond to a single HTTP request by retrieving data and running transactions against multiple data sources. Moreover, Web-based development significantly reduces or eliminates client-side configuration issues.

When you design a Web-based application, you must decide which browsers and platforms you plan to support. If your primary goal is to reach the broadest possible audience, you should opt for a pure HTML solution. If you want to build a more sophisticated user interface, you generally have to restrict users to one specific browser or a set of modern browsers.

For instance, features such as Dynamic HTML (DHTML) and client-side JavaScript are supported by recent versions of Microsoft Internet Explorer and Netscape Navigator. If you use these features, however, users with older browsers will have trouble using your application. Typically, you must decide whether it's more important to support a wider population of users or to create an application with a more polished user interface. It's a tough decision that you should make early in the design phase.

The need for messaging

You should address one final issue during the initial design phase of a multitier application. Many of the protocols used in distributed applications, such as RPC and HTTP, are synchronous. This means that the application running on the client's computer must wait patiently during each request while the server computer performs the requested task. Also, if the server has a large backlog of requests, a client might be forced to wait for an unacceptable period of time.

Also note that applications built using synchronous protocols depend on every computer involved in the processing of a request being on line at the same time. The server must be on line for the client to make requests, and clients must be on line and issuing requests to make use of the available processing cycles that the server has to offer. If the server goes off line, clients can't issue requests. When the clients are off line, the server sits around with nothing to do. In essence, everybody has to be on line at the same time for the system as a whole to be operational.

Frequently, multiple applications need to communicate in an asynchronous and disconnected manner. Messaging is a mechanism for establishing asynchronous communication between two or more applications. Client applications send asynchronous messages to queues across the network. Each message typically represents a client request or some type of notification. Server applications monitor these queues and process messages either as they arrive or at a later time. Messages and queues simply provide a layer of indirection between the applications that are making requests and the applications that are processing requests.

An application built on top of a messaging protocol can continue to operate when various computers are off line. However, creating a robust messaging infrastructure that can route each message to its destination queue with the required delivery guarantees is not a trivial undertaking. A messaging infrastructure must provide an extensive set of subsystems to transparently store messages when computers are off line and then forward them to their destination later when a connection can be established.

Most companies aren't willing to invest the time and money it takes to write and debug the code for a custom messaging infrastructure. Fortunately, several messaging products that offer the benefits of asynchronous and connectionless communication are commercially available, such as the IBM MQSeries family and Microsoft Message Queuing Services (MSMQ). This eliminates the need to hand-roll a custom messaging infrastructure.