Distributed Development on Windows NT Server

The previous section of this chapter examined the costs and benefits of an N-tier design. One of the costs is in developing a sophisticated framework to handle the requirements of a distributed application. Industry reports have shown that most successful N-tier systems in production have required a large investment to put such a framework in place. These reports show companies typically spend around 40 percent of their programming efforts on the infrastructure for a distributed system. That leaves only 60 percent of their investment for writing domain-specific code, such as business logic and data access code.

Microsoft saw the disproportionate amount of money that was being spent on infrastructure in these distributed systems. It realized that companies wanted to spend more time writing business logic and less time writing complex code to take on issues such as connection management, thread pooling, and transaction monitoring. Microsoft's entire enterprise strategy is based on the assumption that companies would rather have someone else create the pieces of this essential distributed application framework.

Microsoft is building a COM-based infrastructure for creating distributed N-tier applications with Windows NT Server. Quite a few of its pieces are already in place, and many more are expected over the next few years. In the last part of 1998 and through 1999, you'll see the transition from COM to COM+. One of the biggest motives for the development of COM+ is to provide programmers all the necessary infrastructure components they need for building a distributed application.

COM+ infrastructure components will, of course, be accessible to programmers through COM. This plan builds on COM strengths, such as OOP, component-based development, and language independence. COM makes it practical to assemble systems composed of Microsoft's components and yours.

The release of the Windows NT 4 Option Pack in December 1997 was a big milestone for distributed development. In many ways it represented the first phase of COM+. The Windows NT 4 Option Pack contained the initial release of MSMQ as well as improved integration among MTS, IIS, and ASP. This has made it possible for developers to build applications that take advantage of the connection management, thread pooling, transaction monitoring, message passing, and Web integration that are built into the infrastructure of Windows NT Server.

Projected additions to COM+ are other features that would be valuable in distributed application design, such as an event service and the automatic clustering of servers for fail-over support. Microsoft is also working hard to define the roles and responsibilities of each of these components and services with greater clarity. Some components might move from one service to another, and other components and services as yet unannounced will be added. Microsoft is pioneering this idea of creating a multipurpose distributed infrastructure, so you must expect some areas of COM+ to be in a continual state of flux. A few existing components in COM will continue to be center stage in COM+.

What Is MTS?

MTS stands for Microsoft Transaction Server. As the name implies, MTS is the piece of software that allows applications to use a transaction monitor in the middle tier of a distributed application. However, MTS is much more than a transaction monitor; it provides Microsoft's newest run-time environment for COM objects. Distributed objects can run in the MTS environment whether or not they're involved in transactions. The name MTS confuses people when they learn it can be used to deploy nontransactional objects.

This naming confusion exists because MTS has been the vehicle that Microsoft has used to ship the first generation of its distributed application framework. MTS programmers benefit from automatic support for practices such as connection management, thread pooling, and security. In the future, many of the MTS elements will be considered part of the generic COM+ shell as opposed to being part of MTS. Fortunately, these changes won't affect the way you create and deploy MTS applications.

MTS provides a distributed run-time environment in which you can run your business objects by launching a surrogate process on the server and loading user-defined objects from DLLs. Figure 1-9 shows the relationship between the client applications and MTS objects running on NT Server. These middle-tier objects can be created using any COM-enabled language, such as Visual Basic, C++, or Java. As a Visual Basic programmer, you're required to create ActiveX DLLs and install them in the MTS environment to deploy your business objects.

MTS is a platform for building online transaction processing (OLTP) systems. Your business objects access data in various data sources such as a DBMS from across the network. The transaction monitor built into MTS makes it easy for you to define a transaction across multiple data sources. MTS uses declarative transactions, which hide proprietary transaction APIs from MTS programmers. As you'll see in later chapters, MTS makes writing transactions far easier than writing explicit transactions using ODBC, ActiveX Data Objects (ADO), or Transact SQL.

Figure 1-9. MTS allows you to run business objects in Microsoft's distributed run-time environment.

What Is MSMQ?

Another powerful component to assist in building distributed applications is Microsoft Message Queue (MSMQ). MSMQ is a middleware product that enables asynchronous communications between applications. This means that client applications can send messages to a server even when the server isn't running. It also means that the server can receive messages after the client application has gone away. In environments in which client applications and servers can become disconnected for any number of reasons, this capability allows the distributed application as a whole to stay up and running.

MSMQ is based on the asynchronous delivery of messages to named queues. It's a very sophisticated product that can be integrated into distributed applications, including those based on MTS. Messages model procedure calls between a client and a server except that either party can do its work in the absence of the other. For instance, in a sales order application a client could submit several orders to the queue even when the server application wasn't running. At some time later when the server was started, the server could open the queue and retrieve all the order requests that were submitted by any client. MSMQ also makes it possible to return a message receipt to the caller as if it were the response to a method call.

MSMQ also contributes to an application's scalability. As the traffic in a distributed application increases, the managers of the system need to add more computers to increase the throughput of the entire system. To make use of any additional hardware, the system must somehow distribute client requests across all the available servers. This act of using as many of the available processing cycles as possible is known as load balancing. A queue facilitates load balancing because a client doesn't send a request to a specific server. The queue is a single repository that holds all incoming requests. A group of servers monitors the queue and splits up the workload as it arrives.

MSMQ will continue to be a big part of COM+. Visual Basic programmers can access MSMQ services through a set of COM interfaces. MSMQ integration with MTS makes it possible for a business object to retrieve a message from a queue inside a declarative transaction. If something goes wrong during the transaction, the message is left in the queue. This means that MSMQ can ensure that all messages eventually reach their destination. MSMQ also provides advanced features that address routing efficiency, security, and priority-based messaging.

Web-Based Development

Web servers are becoming increasingly popular as a platform for building information systems. Several key benefits accrue to a company when it moves toward an HTML-based environment. First, HTML is currently the best way to create a cross-platform application. Second, applications built around a standard Web browser significantly reduce desktop configuration and deployment costs. Finally, Web-based systems can be used to reach a much larger audience than is possible with typical LAN/WAN-based architecture. In a Web-based application, all a user needs is a browser, an Internet connection, and a valid IP address.

Until recently most Web sites have only been able to participate in data publishing. Today companies are beginning to see the advantages of implementing true OLTP systems through standard Web browsers. Using IIS and ASP, you can create Web-based OLTP systems based on COM and MTS. Figure 1-10 shows how all the pieces fit together. Web applications built using this architecture can exploit the strengths of one particular browser, such as Microsoft Internet Explorer, in an intranet-style environment. Other applications can use a pure-HTML approach that can serve a larger, Internet-style, user base.

Visual Basic 6 has added a new enhancement to the IDE called the IIS Application Designer (IISAD). The IISAD makes it easy for programmers to write their server-side logic in Visual Basic code instead of using VBScript or JavaScript in an ASP application. When a Web client makes a request, an application built using the IISAD responds to the request just like any other Web application. The difference is that the request will execute code you have written in Visual Basic. When you use the IISAD, you'll still program against the same set of ASP objects. The IISAD has also provided an easy way for you to stream HTML back to the client. As with ASP applications, the IISAD makes it possible to build a pure-HTML solution that leverages the MTS business objects you have running in the middle tier.

Figure 1-10. The integration between MTS and IIS allows Web clients to run MTS objects through browser-independent HTML.