Beyond all the features and advantages already mentioned, possibly the biggest advantage that MTS provides is the capability to update a component without stopping the server. When IIS uses a DLL, it "locks" the DLL into memory. To replace the DLL, you must stop IIS. During development that's no problem at all, but in a production environment it may be impossible to stop the server simply to update one component for your application. Other users may be in the middle of critical operations in other applications running on that server. If you stop the server, you destroy all the sessions.
Using the Internet Service Manager, you can mark your applications so that they run in a separate process space than the root Web application. If you do that, you can release DLL locks on components used exclusively by your application by unloading the application. That helps, but not enough. If any other application is using the DLL, unloading your application won't release all the locks, and you'll still be unable to replace the component. If you run the component under MTS, you can release all references and replace the component without having to stop the applications. Of course, depending on the application's needs, you may still affect the application if you update components while the applications are running.
The second largest advantage is that MTS maintains objects in memory. Throughout this book, I've tried to hammer home the first rule of Web programming: Get in, get the data, get out. Almost anything that can help you do that is worth doing, and you'll see immediate benefits, either in application responsiveness or in application scalability. Unfortunately, few things that you can do will improve both responsiveness and scalability. MTS does slow down application initialization, so the first people to reach your application will have to wait longer for the application to load. After it's loaded, though, you'll be able to scale much better with MTS than without it.
Finally, MTS lets you group functionality and control access to functionality through role-based security. In many Web applications, where users access the site anonymously, this kind of security won't do you any good. On intranet sites, where all the people accessing the application can be authenticated through the network, MTS security is a blessing. Instead of having to set individual properties or write code, you can break your application into interfaces and assign permissions to the interfaces.
When Should we Use MTS?
At first, I thought that MTS should be limited to large sites. After creating several IIS applications (with both ASP and VB WebClasses), I've come to realize that you should always use MTS. MTS is much like SQL Server. You think it's overkill—more power than you need—until you deliver your application. When 20 people hit your site at the same time and the server reaches 100 percent usage, you begin to realize that you should have done things differently. I now believe that you should plan for and use MTS in almost all Web applications, whether you think you'll need it or not.
Writing and coding an MTS component is more work than writing a standard ActiveX DLL. Because MTS wants (and for efficiency, requires) stateless components, you need to maintain state elsewhere. It seems as though in the last few years we've moved from an individual client, where you maintained state because that's where your program was running, to a two-tier, then a three-tier, and finally a three-tier-with-MTS application. Each time programming practice adds a layer, you have to write more code. Also, it seems like each added layer wants to shirk the responsibility for maintaining state. For example, you don't want to maintain state on the client—the space available is limited, it's inherently insecure, and it causes too much network traffic. You don't want to maintain state on the Web server—it uses up server resources and slows response time. You don't want to maintain state in the data services components—they need to be stateless so that multiple clients can use them. That puts the burden of state maintenance squarely on the business components. But wait—isn't it more efficient to put the business components in MTS and make them stateless, too? That's right! The answer is, it's just not efficient to maintain state.
State maintenance in Web applications, as you've seen, requires a change in your approach to application programming. Planning an application that uses MTS requires a similar change in mindset. The point is, you need to start approaching all Web applications as though you were unable to maintain state at all. Only grudgingly, when it's absolutely necessary, should you maintain any state information for a client. And when you do, you'll have to decide which will hurt your application's performance the least—to store it on the client, the Web server, or the business component layer. Welcome to the modern world of Web applications, where performance and reusability, but not responsibility, are the watchwords of the hour.
So now that you understand the benefits of using MTS and you know when to use it in your applications, the next section will show you how can you use MTS components with WebClasses
