The Windows 2000 cornerstone for developers is COM+ and its integration with Microsoft IIS and other core OS features. COM+ includes a new feature—queued components—that makes it a great fit for browser-based applications that use SQL Server.
Using COM+ has a significant impact on SQL Server in application manageability and application and database performance. When you design a Web application, you need to accommodate demands on the application that strain the system's resources. For example, you need to design e-commerce Web sites to handle seasonal surges in use. When the user load is greater than the system's resources can comfortably handle, the system slows, turns away users, or dies. None of these situations is good for business, and companies spend tremendous amounts of money each year trying to prevent them.
COM+ queued components can help with system resource management. Developers generally use COM objects in an Active Server Pages (ASP) application by calling a method of the object as follows:
Set oCustomer = server.createobject (business.Customer) x = oCustomer.UpdateOrder(OrderID)
These two lines of code first instantiate the Customer object, then execute the UpdateOrder method in the Customer object. This method is a synchronous call because when the code executes the UpdateOrder method, the calling ASP code can't execute until the UpdateOrder code is complete. If UpdateOrder calls another method that updates the database, the method might take a long time to complete if the database is busy or if any contentions occur. This type of problem can hamper order handling or bring down the system.
Queued components in COM+ come to the rescue by letting you perform work as in the sample code, but COM+ now intervenes for you. Instead of executing the UpdateOrder method and waiting on it, COM+ records the UpdateOrder method and immediately returns to the calling application. Then, COM+ sends the recorded method call for UpdateOrder to the queued components service and queues it for execution. Eventually, the system that is listening on this queue picks up the queued request and executes it.
Underlying queued components are Microsoft Message Queue Server (MSMQ) and the COM+ architecture. Queued components require MSMQ, which is the pipeline that provides the queue. As a developer, you don't need to work directly with MSMQ. COM+ does that work for you.
COM+ uses a recorder that it implements as a client-side proxy, similar to the way in which you call an object with Microsoft Transaction Server (MTS) and COM+ or Distributed COM (DCOM). Your code works with a proxy that behaves like the object but is simply an interface through which the method calls the object. The recorder proxy records the method calls, then routes them to the queue service. The destination server hosting the queue can be on the same system as the calling application or a different system.
You need to configure COM+ on the system hosting the queue to work with the queued component. A listener service on the system listens for messages on this queue as they come in. When the system receives a queued component activation call, COM+ instantiates the object and feeds the recorded method calls to the object that executes them.
To make this procedure work, you need to write the components to be queued. A queued components method can't return any values or use method parameters that can be changed by reference (byref). You also need to configure COM+ to queue your component on both ends of the queue by using Component Services Manager. For example, the systems that you need to configure include the system running the application that is calling the components methods (the ASP application in the example I use in this article) and the system that is hosting the queued component on the other end of the queue.
Let's consider the ramifications of using queued components in a Web application. The technology doesn't dictate where a queued component will do its work; you can easily create a layered application in which transactional components do the work. You can configure these components to run in many places. For example, you can create a master queued component that is responsible for updating orders, as in the previous example. Then, you can create another component that handles the database interface for updating orders. You can run the database component on the same system as the queued component. Or, you can set up several application servers that host the queued component and feed requests to each server according to its load. You can also use DCOM from the original queued component (Customer) and dynamically instantiate the worker component on various servers. By using this approach, you employ a dynamic application-loading feature in your application. Plus, you can build an application with components that work today and that you can later adapt to work with Win2K's Application Center Server (AppCenter) or any other new technologies that Microsoft introduces.
Another consideration when you use queued components is how you'll manage transactions and error handling. Be careful when you design the logic in any asynchronous application. Your application will need to handle many scenarios that are different from those in traditional synchronous applications. For example, if a user executes UpdateOrder on the Web server, and the queued component executes UpdateOrder on another system at a later time, then your application needs to handle the resulting error gracefully by taking the correct action in the database and notifying the user of the problem.
More to COM+
In addition to queued components, COM+ offers other significant benefits to developers who build applications on the SQL Server and Win2K platforms. In upcoming articles, I'll discuss other COM+ features that are useful with Web applications, such as loosely coupled events.