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
I probably don't need to convince you that multitier applications offer many advantages over the two-tier applications that were in
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
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
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
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.
Typical two-tier applications require a separate connection to a database server for each user, and the
Figure 1-2 A two-tier strategy doesn't work well when a company has multiple client applications or multiple database servers.
The problems of a two-tier architecture can be solved as many other problems in computer science are
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
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
In a typical multitier application like the one shown in Figure 1-3, a set of middle-tier objects runs on
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
The mapping between business objects and the data access layer can be simple at first and then become more complex without
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
. 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
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.
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
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
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
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
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
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.
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
An application built on top of a messaging protocol can continue to
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.