A few years ago, the dominant programming
model and design pattern was the client/server model. COM and DCOM
were predominant component technologies, and all was well. Then came
the Internet revolution. Almost overnight, a new paradigm
emerged—the multitier
architecture
.
Scalability is
perhaps the single most important driving force behind the move from
classic two-tier client/server to multitier applications. Today,
being able to handle a very large number of clients is necessary for
survival. The classic two-tier model simply does not scale well from
a few dozen clients to tens of thousands of clients hammering on your
system at peak load. The two-tier model of dedicating one server
object per client quickly causes critical resources to dwindle under
such loads. Allocating resources such as a database connection, a
system handle, or a worker thread to each client is unrealistic. The
middle tier was introduced precisely because you could no longer map
client objects directly to your data processing objects. The middle
tier allows pooling of resources, such as database connections,
hardware objects, or communication ports. The middle tier also allows
you to activate your objects just when they are required and release
them as soon as possible.
COM+ provides you with two elegant and user-friendly instance management services that you can use to build scalability into your system design from day one: object pooling and Just-in-Time Activation (JITA).
This chapter first defines the problems you face when designing a modern distributed system; it then explains COM+ strategies for managing objects that compose it.
A distributed system, by its very nature, implies that its clients are not on the same machine as the objects providing the services. In every distributed system, there are typically two kinds of clients: rich clients and Internet clients . The rich client typically shares the same local area network, called the Intranet. (A rich client can also be called an intranet client .) In most cases, no firewalls between the rich client and the application exist, so the rich client can invoke binary calls on components in the application. The Internet client connects to your application typically by using a web browser, but more of the other options, such as hand-held PDAs and cellular phones, are possible as well. The Internet client is located outside of your local area network and can reside anywhere on the Internet. In most cases, a firewall exists between the Internet client and your application.
Most applications have a mixture of rich and Internet clients. Some systems had only rich clients until they were opened to the Internet. Other systems were designed primarily for the Internet, but had to support rich clients—perhaps for application management, back-office operations, or other specific needs. In any case, when you design an application, you should plan to support both kinds of clients. The two kinds differ not only in the way they connect to your application, but also in their pattern of interaction with it. Your design should be able to scale up to both kinds of clients and compensate for their differences. COM+ instance management services were developed to answer precisely that challenge.
A rich client’s interaction with the server objects of a distributed application resembles that of the classic client/server application. The client connects to the server machine using a network protocol such as TCP/IP. Because the Intranet is considered a secure environment, it usually contains no firewalls and the client can connect directly to your server objects in the middle tier using DCOM (see Figure 3-1). The calling pattern to your application is as follows: create an object, use it, and eventually release it. The rich client usually presents to the user a rich user interface . The word “rich” in this context means that the user interface contains and executes binary code, processing information and rendering it to the user. The user interface is typically built with tools such as Visual Basic or Visual C++ with MFC. The new .NET Framework provides a new library of Windows Forms classes for building rich clients. (See Chapter 10). Even if the user accesses your application with a web browser, that browser may contain binary ActiveX controls. Intranet clients use rich user interfaces because they must usually provide a rich user experience. This experience supports more privileges and features for employees than are available to customers connecting to the same system via an Internet browser.
Consider your bank, for example. Most banks today provide easy access over the Internet for their customers, allowing simple operations such as viewing account balances and transferring funds between accounts. However, only bank tellers can perform operations such as opening or closing accounts and selecting various saving and investment plans. The next time you are in your bank, peek over the teller’s screen. The teller probably uses a rich client user interface that does not look like the one you use when you log on to the Internet banking application offered by the bank.
In a typical system, there are significantly fewer rich clients than Internet clients (as there are fewer bank tellers than bank customers). The overhead of creating a few server-side objects, allocating resources, and doing the cleanup for each client is not a scalability limitation. What really impedes scalability is the potential that rich client applications have for holding onto objects for long periods of time, while actually using the object in only a fraction of that time.
It is possible that when an Intranet application is started, it instantiates all the objects it needs and releases them only at shutdown, in an attempt to achieve better performance and responsiveness to the user. If your design calls for allocating an object for each client, you will tie up crucial limited resources for long periods and eventually run out of resources.
When users
access your system over the Internet, they
actually use a web browser to connect to an Internet web server (such
as the Microsoft Internet Information Server, IIS). The browser
generates a service request as part of the HTTP stream. The web
server creates objects required for handling the client request, and
when it finishes processing the request, it releases the objects (see
Figure 3-2). It is important to emphasize that the
Internet client connection is stateless; no object references are
maintained outside the scope of individual requests. The client is
usually a thin user interface, another name for
an interface that consists of simple HTML rendered by a web browser.
The browser’s main job is to send the user’s requests to
the server and display the web server’s reply. Although some
scripts sent by the web server, such as Dynamic HTML (DHTML), may
execute on the client side, such client-side logic is used primarily
to format the information on the user’s screen and has nothing
to do with server-side objects.
Depending on how widely your system is used, you could have a huge number of clients asking for service at any given moment. The length of time the web server holds the objects for an individual client request is usually not a scalability limitation. However, because there are so many Internet clients, scalability is limited by the overhead for each client request: creating objects, initializing them, allocating expensive resources such as database connections, setting up proxies, doing cross-machine or process calls, and doing cleanup. This problem is the opposite of the scalability problem for rich clients. Systems that use an ineffective approach of allocating objects per client request simply cannot handle a large number of clients. At periods of peak demand, the service appears to be unavailable or has irritatingly slow response time.