9.5 Exposed tiers

Exposed tiers

Let's return to the scenario of three-tiered development using COM components. In this case, you would design your application in a similar fashion as described above. In some regards, it's even simpler to create COM components than an EXE. You aren't in danger of breaking the rules of three-tiered development, because you simply can't. Reusing components is much easier because you don't have to worry about dependencies. Creating clean class hierarchies is also easier because you're dealing with various projects, which reduces the risk of creating unwanted relationships. Creating good object interfaces comes quite naturally, because there is no way to talk to a COM component other than through its interface. You aren't in danger of cheating (which might happen unknowingly, but with the same complications nevertheless).

Unfortunately, a number of issues are quite a bit harder to resolve in the world of COM components than in a regular Visual FoxPro application. How do you display the data, for instance? Again, single records aren't a problem, because you can always create a data object, but there is no way to switch into some other component's data session. That's where ADO comes in. ADO handles all data as objects, which can be passed through COM channels from the back end through the middle tier into the interface.

The great advantage of COM-based three-tiered applications is language independence. You can create a data-specific component in Visual FoxPro, another one that does a lot of calculations in Visual C++, a third one in Visual J++ and yet another one in Visual Basic. Even though you might not want to do that right away, you always have the option to switch to different components later on. If you switch to Visual FoxPro from Visual Basic, for instance, and aren't quite familiar with the environment, you can create a performance-critical data-retrieval component in Visual FoxPro, and other components that aren't so critical in Visual Basic (the tool you're familiar with). Later, when the application grows and performance becomes critical in other parts, you can easily trade single components for faster ones.

COM-based, three-tier applications often run on servers, whether Web servers or just intranet servers. In these scenarios, one powerful computer does almost all the work. When you have a large number of users, a large number of hits, or both, you need to make sure your application scales well. This isn't a trivial task in monolithic Visual FoxPro applications. Visual FoxPro is fast, no doubt, but once a certain amount of traffic occurs, there isn't much you can do. There's no intrinsic multithreading, no load balancing, basically nothing you can do other than coding your own pool manager (good luck!). When your application is based on COM components, this becomes much easier. You can simply let Microsoft Transaction Server handle your components, and it will make sure enough resources are available. All you need to do is register your component, and MTS will manage all calls to it. This includes component instantiation, which is handled entirely by MTS to ensure there are enough resources and component instances. Essentially MTS is a very advanced pool manager.

However, there is more to MTS than just scalability. "Transaction" is its middle name, which indicates that MTS is a transaction manager system as well. In fact, it allows you to span transactions over multiple components, no matter what language they are written in. In this case, things don't happen automatically anymore, but you have to design your COM components specifically for MTS. This isn't rocket science, but it is beyond the scope of this book. If you are interested in MTS, visit my Web site (www.eps-software.com) where I keep a list of recommended reading and a number of MTS articles.