Page #84 (Chapter 12 - IIS Applications and Microsoft Transaction Server)

	Chapter 12 - IIS Applications and Microsoft Transaction Server
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	When Should You 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.