• Illustration: Windows as an Application Server
• Sidebar: Windows .NET Server Component Concepts

Large-scale server applications such as e-commerce sites could benefit from enhancements to COM+ and Microsoft Message Queuing (MSMQ) coming in Windows .NET Server 2003. Companies already running such applications on Windows NT 4.0 and 2000 should evaluate these services when deciding whether to upgrade to Windows .NET Server, as should companies doing new development with the .NET Framework and Visual Studio .NET. Windows .NET Server also delivers new COM+ and MSMQ features for creating and using Web services, but these features don't yet support the primary mission for Web services: cross-platform, cross-organization application integration.

(For a quick review of concepts for components and the COM+ and MSMQ services, see the sidebar "Windows .NET Server Component Concepts".)

Shoring Up Server Applications

All the new COM+ and MSMQ features of Windows .NET Server are designed to enhance its role as an "application server," that is, a software platform for running large-scale business applications. (See the illustration "Windows as an Application Server".) Selling Windows as an application server is strategically important to Microsoft and its partners, because once a company has a critical application running on Windows, it will likely continue to invest in Windows servers and other Microsoft products, such as the SQL Server database software or the BizTalk Server or Host Integration Services application integration offerings.

For companies that already use Windows NT 4.0 or Windows 2000 as application servers (e.g., BarnesAndNoble.com and Dell Computer), COM+ and MSMQ enhancements will weigh heavily in any decision to upgrade to Windows .NET Server. Applications that use these services on Windows 2000 should run on Windows .NET Server with little or no new code, and even NT 4.0 applications should require no more migration work for Windows .NET Server than they would for Windows 2000. However, for both types of applications, Windows .NET Server offers many small improvements to reduce downtime, simplify management, and boost scalability, for example:

• Administrators can shut down and restart components without interrupting work in progress, reducing downtime.
• Companies can run multiple versions of a set of components on the same server, simplifying management by enabling server consolidation.
• Components originally created for single users on workstations can take advantage of multiple processors on servers, enhancing scalability.

Companies building new server applications with the .NET Framework and Visual Studio .NET should also evaluate Windows .NET Server's COM+ and MSMQ improvements. While COM+ and MSMQ are still traditional "unmanaged" code and do not use the .NET Framework, "managed" code that does use the Framework can access both services through a set of APIs called the .NET Enterprise Services. Consequently, those applications will benefit from improvements to these services, and thus could run faster and more reliably on Windows .NET Server than on Windows 2000 retrofitted with the .NET Framework.

(For more information on how the .NET Framework, COM, COM+, and MSMQ interact, see ".NET Brings Changes to COM Architecture" on page 14 of the June 2002 Update.)

Finally, a company could find it easier to build Web services that use COM+ and MSMQ services on Windows .NET Server rather than on Windows 2000. However, COM+ and MSMQ do not enable features like transactions or reliable messaging across multiple Web services running on different platforms or owned by different organizations, even though such integration is the strongest reason for adopting Web services in the first place. The fault lies not in Windows .NET Server but in the state of Web services standards, which don't yet guarantee interoperability of Web services across platforms and do not include the security and reliability features required for cross-organization integration. (For a discussion of gaps in Web services standards, see "GXA Defines Framework for Web Services".)

COM+ Run-time and Design Improvements

The most important new features in COM+ 1.5 (the version that ships in Windows .NET Server, as well as Windows XP) are small changes to its run-time behavior that enhance performance and availability. COM+ 1.5 also has new deployment features that will help organizations consolidate components onto fewer servers, and some new design options that enhance scalability and simplify deployment. What follows is a description of the most notable features.

Pause, Recycle Enhance Availability

New "pause" and "disable" features enable administrators to shut down a running set of components in an orderly fashion. COM+ will block new requests to the components, wait for any in-process requests to complete, and then shut down the components. This is important for upgrading components on production servers. Previously, administrators had no way to shut down components without losing requests that had not yet been completed. Application Center, a separate product, supports this feature for Windows 2000 and COM+ 1.0, but it's built in to COM+ 1.5.

Administrators can also configure COM+ 1.5 to automatically "recycle" (shut down and restart) components periodically without interrupting requests currently being processed. This is a useful way to deal with buggy components that gradually accumulate resources such as memory while they run. Administrators can set components to recycle on a number of criteria (for example, when memory usage has reached a particular limit).

Administrators dealing with buggy components will also appreciate a new "process dump" feature, which enables them to capture memory images of components as they run. Developers can feed these images into a debugger to catch and diagnose hard-to-reproduce bugs "in the act."

Windows Services Speed Startup, Simplify Security

On COM+ 1.5, sets of components can run as a standalone Windows service, rather than being hosted by the generic COM+ service as on Windows 2000. This can reduce downtime by speeding and simplifying startup: the components can start automatically when a server boots, restart automatically on another server when a server fails (triggered by the Microsoft Cluster Service), and automatically start any other Windows services upon which they depend (e.g., a local database engine).

Running components as Windows services also makes them simpler to secure because they can use one of Windows .NET Server's new, low-privilege service accounts (LocalService or NetworkService). On Windows 2000, in contrast, components either run with high privileges (local system) or the administrator must manually create a low-privileged user account for them on each server where they are deployed.

However, components running as Windows services cannot use the new pause, disable, and recycle features.

Application Pooling Balances Load

COM+ 1.5 enables an administrator to set up a pool of Windows processes that run copies of a set of components and share their request load, a feature called "application pooling." (Note that this feature has nothing to do with COM+ object and connection pooling.) Application pooling can improve availability: components remain available as long as at least one process in the pool is running.

Application pooling can also extend the useful life of "single-threaded" components, components that work on a single request at a time. Such components often stem from desktop or client/server applications that originally served a single user. On Windows 2000, a single-threaded component must run in a single Windows process, where it cannot take advantage of multiple processors and must wait along with the process for network and disk operations to complete. On Windows .NET Server, in contrast, a single-threaded component can have several copies running in separate processes, which in turn enables it to exploit multiple processors.

Partitions Enable Consolidation

On Windows .NET Server administrators can install multiple copies of a COM+ Application on the same server by installing them in separate "application partitions." ("COM+ Application" is Microsoft's term for a package of components that uses COM+; it does not mean any application that uses COM+.) Each application partition can have its own component versions and settings (e.g., database names). Windows 2000, in contrast, only allows a single copy of a COM+ Application on a particular server.

Application partitions will particularly benefit application service providers who host components for multiple customers on a single server. The provider can give each customer its own database, and then set up an application partition that points to that database.

However, application partitions also enable administrators to run multiple versions of components side-by-side on the same server, by placing each version in its own application partition. This in turn can help companies consolidate servers that are running different versions of the components or beta-test new components on the same servers as production components.

Windows .NET Server also enables administrators to include a component in multiple COM+ Applications on a server (a feature called "aliasing"). On Windows 2000, a component has to reside in only one COM+ Application. Aliasing simplifies maintenance: a component can be reused in multiple COM+ Applications without copying its source code into multiple locations where it might get out of synch.

Transactions More Scalable, Accessible

COM+ 1.5 also introduces several new design options of interest to application architects. Most notable is "configurable isolation levels": COM+ transactions can run with less than full isolation from one another. A transaction's isolation level determines the amount of data it locks to prevent use by other transactions. Only the highest isolation level (serializable) is available to COM+ programmers in Windows 2000, even though the Distributed Transaction Coordinator (DTC) service that handles COM+ transactions supports other levels.

Lowering a transaction's isolation level improves scalability by increasing the number of other transactions that can work on data at the same time, at a cost of less reliable results. For example, a transaction that calculates an hourly sales report might run at the "read committed" isolation level, which allows other transactions to insert and delete data while the report is running, although this will cause small errors in the report's totals.

Designers will also find COM+ services like transactions easier to incorporate into applications, because many can now be called from code that isn't in a component. For example, an ASP.NET dynamic Web page could participate in a COM+ transaction. This will make it simpler for developers to exploit COM+ services in an application, because they do not have to create components and package them into a COM+ Application just to use a particular COM+ service, as they do on Windows 2000.

MSMQ Gains One-to-Many Messaging

The most important new feature of MSMQ 3.0 (the version that ships in Windows .NET Server, as well as Windows XP) is one-to-many messaging, the ability to send a message to multiple receivers in a single operation. This in turn makes it easier to code applications that notify a changing set of partner applications of important events (a task sometimes called "publish-subscribe"). For example, a company's inventory application might use one-to-many messaging to notify applications running in its district offices and reseller sites of changes to the company's product catalog.

MSMQ 3.0 provides two distinct mechanisms for one-to-many messaging:

Multiple destination queues. A single message can be addressed to multiple destination queues (a feature called multiple-element format names). Messages can also be addressed to distribution lists (of queues, not e-mail addresses) stored in Active Directory, which enables companies to centrally maintain and distribute these lists. MSMQ can provide all of the same guarantees and services for multi-destination messages that it provides for point-to-point ones (e.g., transaction support and message timeouts). Consequently, this feature can be used for critical application messages.

Multicast queue addresses. A message can be sent to an Internet Protocol (IP) multicast address. Copies of the message will then travel to all servers associated with that address over the Pragmatic General Multicast (PGM) protocol. PGM provides ordered delivery without duplication of messages, and it makes efficient use of bandwidth. However, it does not support some MSMQ features such as transactions and message timeouts. It could thus prove most useful pushing noncritical data (e.g., stock prices or news) to large numbers of recipient applications. PGM is currently being standardized by the Internet Engineering Task Force (which manages the major Internet protocol standards), and Cisco supports it in some routers, but it is not yet a standard. Consequently, multicast messaging will be most useful inside a company that can ensure that the protocol works among all destinations.

Other Improvements, Migration Issues

Apart from one-to-many messaging, minor MSMQ improvements include the following:

• Increase of the maximum queue size from 2GB to 1 terabyte (TB)
• Support for installing dependent clients (computers that can send and receive messages but do not queue them locally) in organizations before any full MSMQ servers are brought up.

MSMQ 3.0 does not, however, support all features of its predecessors. Missing are the Exchange connector (which allowed applications to exchange messages with Exchange recipients over MSMQ) and support for Novell IPX as a message transport protocol. Note also that most of MSMQ 3.0's new features are not available from dependent clients.

Small Steps Toward Web Services

Both COM+ and MSMQ have acquired features for hosting and communicating with Web services, another form of software component supported in Windows .NET Server. However, Web services standards are still a work in progress, and the Web services features of COM+ 1.5 and MSMQ 3.0 show some of the gaps. (See "GXA Defines Framework for Web Services".)

COM+ Builds, Uses Web Services

In Windows .NET Server, an administrator can turn any COM+ Application into a Web service using the COM+ Component Services console, without any special effort on the part of the developer. Component Services can also create COM components that act as a front end to a Web service, translating between COM requests and Simple Object Access Protocol (SOAP) messages. A company can use these features to integrate existing components and Web services. For example, a company might create a Web service for accessing customer data by modifying its existing COM business logic for customer management.

However, the COM+ Web services features also have limitations that could prevent their use cross-platform or cross-organization.

For example, Web services created from existing COM components with Component Services might not be able to accept requests coming from other software platforms (e.g., from a Java Server Page running on the Apache Web server). The limitations stem from the way Component Services uses Microsoft's .NET Framework infrastructure. To create a Web service, Component Services first creates .NET wrapper components for the original COM components. It then configures the .NET wrapper components via .NET Remoting, a .NET Framework feature that enables components to communicate with SOAP messages over Hypertext Transfer Protocol (HTTP).

Interoperability problems can arise because .NET Remoting only supports a fixed style of SOAP message (called RPC/Encoded), rather than the more general Document/Literal type, which better accommodates application-specific data types. .NET Remoting also cannot handle application-specific SOAP extensions, even though such extensions are allowed by SOAP. So a Web service created with .NET Remoting might not be able to communicate with a Web service created with other tools that use Document/Literal messages or SOAP extensions. Web services created from COM components by Component Services inherit this limitation.

Web services created by Component Services also do not support most COM+ features. This will hamper their use for application integration. For example, a Web service for maintaining customer data could initiate a COM+ transaction against a company's customer database. However, it could not participate in a larger transaction started by another application or Web service (e.g., an order management Web service that wants to add new customers inside an order transaction).

Windows Web Services Get MSMQ Guarantees

MSMQ 3.0 enables developers to create Web services that provide reliable delivery services, such as recoverable messages, transactions, and message timeouts, by using SOAP messages rather than binary MSMQ messages or SOAP payloads inside binary MSMQ messages. These Web services also exchange messages using HTTP or HTTPS (HTTP + Secure Socket Layer security) rather than MSMQ's proprietary protocol. Microsoft calls the combination the SOAP Reliable Message Protocol (SRMP). To support HTTP, MSMQ 3.0 also adds the ability to address queues by standard URLs (e.g., http://org.com/msmq/orders). An Internet Information Server (IIS) extension running on a Web server implements SRMP, translating between it and the native MSMQ protocol.

SRMP could prove useful for Windows-to-Windows communication that must cross firewalls (e.g., messages sent from an outsourced IIS Web site to a Windows application inside an organization). It also simplifies using MSMQ messaging in Windows organizations that don't have Active Directory, because messages can be routed to queues by URLs rather than by queue names stored in the directory.

However, SRMP at present is Microsoft-only; a cross-platform reliable messaging protocol for Web services is at the top of the "to-do" list for standards organizations such as the Web Services Interoperability organization. (See "GXA Defines Framework for Web Services".) SRMP is also not supported by Web services created with COM+ Component Services, nor by queued components.

Practical Web Services Await .NET Updates

Companies that want to use Web services for cross-platform, cross-organization application integration will probably need more than COM+ and MSMQ, even on Windows .NET Server. The best option for many companies will be Microsoft's BizTalk Server, which provides graphical tools for defining Web services message formats and translating them to and from COM requests/responses and MSMQ messages. Another alternative is to create the Web service with ASP.NET and the .NET Enterprise Services classes, which requires more code than BizTalk Server but needs only Windows .NET Server on the servers. Unlike .NET Remoting, both BizTalk Server and ASP.NET can handle application-specific message formats and SOAP extensions. Consequently, developers can use these tools to create custom SOAP message formats that solve problems like reliable messaging not yet covered by Web services standards, and they can also deal with custom formats defined by partner organizations.

Eventually, COM+ and MSMQ themselves will support transaction, reliable messaging, and the security standards needed to make Web services practical on a large scale, assuming vendors can agree on such standards. However, support for these standards, and other future improvements to COM+ and MSMQ, will likely only be available to managed components. Microsoft will focus future COM+ and MSMQ development on supporting managed components and eventually will move the services themselves to managed code. (See ".NET Brings Changes to COM Architecture" on page 14 of the June 2002 Update.) So while companies need not rewrite existing unmanaged components on Windows, they should minimize the number of new unmanaged components they write and move to the .NET Framework for future Windows component development as quickly as possible.

Resources

A more complete survey of COM+ 1.5 features is at msdn.microsoft.com/msdnmag/issues/01/08/ComXP/ComXP.asp.

Preliminary Platform SDK documentation for new features in COM+ 1.5 is at msdn.microsoft.com/library/en-us/cossdk/htm/whatsnewcomplus_350z.asp.

Application migration from MTS to COM+ is summarized at msdn.microsoft.com/library/en-us/dncomser/html/complus_migration.asp

Preliminary Platform SDK documentation for new features in MSMQ 3.0 is at msdn.microsoft.com/library/en-us/msmq/msmq_about_newfeatures_4hdl.asp. Particularly important is the topic "Hardened MSMQ Mode," which covers security configurations for MSMQ use over the Internet.

An overview of creating Web services with COM+ Component Services is at msdn.microsoft.com/library/en-us/dndotnet/html/comwscheckb.asp.

A comparison of .NET Remoting and ASP.NET Web services is at msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch16.asp.

A discussion of design principles for multitier applications with particular relevance to Windows .NET Server is msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch001.asp.

For information on Microsoft's system management strategy, see "Management Roadmap Revealed" on page 3 of the June 2002 Update.

An overview of Application Center appeared in "Application Center Aims to Simplify Web Clusters" on page 3 of the Apr. 2001 Update. Companies building applications on the .NET Framework will also want to use Application Center 2000 Service Pack 1, described at www.microsoft.com/applicationcenter/downloads/sp1.asp.

PGM is specified in Request For Comments (RFC) 3208, at ftp://ftp.isi.edu/in-notes/rfc3208.txt.