Windows Server 2003 for .NET Developers

This chapter discusses new and enhanced features in Windows Server 2003 that affect application development and application support on the platform. The goal of this chapter is to point out features and services that have changed from previous versions, problems that have been resolved, and new features that developers can take advantage of when writing and deploying applications on Windows Server 2003.

Windows Server 2003 as an Application Server

Microsoft Windows Server 2003 is designed to be an industry-leading application server. As such, Windows Server 2003 supports a broad range of standards, protocols, and communication interfaces. What sets Windows Server 2003 apart from other server platforms are the features you get out-of-the-box that allow developers to both build and deploy robust, scalable, and reliable applications. This chapter will introduce you to those features.

NET Framework 1 1

The Microsoft .NET Framework is included with Windows Server 2003 source files and can be installed to allow either .NET development or hosting.

Internet Information Services (IIS) 6 0

Internet Information Services (IIS) is the Microsoft Web server. As connectivity to the Internet and between organizations and individuals increases, Web-based applications and services have become the preferred way of sharing data and interacting with customers and partners. Internet Information Services is, therefore, an important part of the application support services offered by Windows Server 2003. This section covers the new architecture and features of IIS 6.0 (which is included with Windows Server 2003) and discusses how developers can take advantage of them.

IIS Architecture

IIS 6.0 has been completely rearchitected to be faster, to be more reliable, and to provide administrators and application developers with more control over how Web applications run. This new architecture radically changes how HTTP requests are sent and received, how Web server processes are managed, and how Web server processes communicate with one another. The changes include three new IIS-related components: HTTP.SYS, a kernel-mode HTTP listener; worker processes that execute Web application code; and the WWW Service Administration and Monitoring component, which manages worker processes.

HTTP.SYS—Kernel-Mode HTTP Listener

The first of these components is a kernel-mode HTTP Listener/Responder, HTTP.SYS. This kernel-mode driver is part of the network subsystem, starts at boot time, and is always running. By default, HTTP.SYS is not configured to listen on any ports and does not expose a security risk. HTTP.SYS will begin listening for requests only when the Internet Information Services component is added and Web sites are configured. When Web sites are configured, inetinfo and other IIS 6.0 components communicate with HTTP.SYS to fulfill HTTP requests. This is different from previous versions, which used winsock for these services. HTTP.SYS sends and receives HTTP traffic, and it routes requests to the IIS worker process responsible for a given Web site or application. HTTP.SYS does not run any application code or perform processing steps required to generate responses to any HTTP requests; it only routes HTTP requests and responses. HTTP.SYS maintains a kernel-mode cache. Therefore, it will cache responses that are cacheable and will attempt to service new requests from cache if possible. HTTP.SYS has a namespace routing table that maps URLs to the worker processes in which the corresponding sites and applications are running. HTTP.SYS uses this namespace routing table to route incoming HTTP requests. HTTP.SYS is also responsible for performing logging functions and implementing Quality of Service (QoS) functions such as connection limits and timeouts, queue-length limits, and bandwidth throttling.

Worker Processes

Worker processes are user-mode processes that are responsible for processing Web requests. The name of each spawned worker process is W3WP.EXE. They replace the DLLHOST.EXE process from Windows 2000 and the MTX.EXE process from Windows NT 4.0. Worker processes are associated with application pools. An application pool has at least one worker process assigned to it. Web sites, virtual directories, and applications are assigned to application pools based on the desired level of application isolation, performance, monitoring, recycling, and so forth. The worker process associated with a given pool processes all Web requests for the applications that are members of that pool. When HTTP.SYS receives a request for a URL, it uses its namespace routing table to determine which application pool supports the application associated with the URL. HTTP.SYS then submits the request to the worker process (or processes) associated with the application pool. The worker process might perform any number of actions to fulfill the request, including returning static pages, invoking ISAPI extensions, running Common Gateway Interface (CGI) handlers, and running application code such as ASP.NET. Worker processes send responses to HTTP.SYS, which will send the response the originating address. (HTTP.SYS might also cache the response.)

WWW Service Administration and Monitoring Component

The WWW Service Administration and Monitoring component (W3SVC) is a user-mode component of the World Wide Web service and is responsible for managing worker processes throughout their lifecycle. When Inetinfo.exe starts the World Wide Web service, the W3SVC reads the Metabase and initializes the HTTP.SYS namespace routing table, which maps URLs to the correct worker process running the corresponding site or application. Once the namespace routing table is initialized, HTTP.SYS can forward requests to the worker processes. The W3SVC is responsible for starting worker processes and will do so when the first request for a namespace supported by a worker process is received.

The W3SVC also manages worker processes through their lifetime by monitoring, starting, stopping, and recycling worker processes as configured. You’ll learn more about worker processes when you read about application pools a little later in this chapter. Figure 16-1 shows how the components and processes of Internet Information Services work together.

Figure 16-1: This figure shows the components and processes used by IIS to listen for, process, and respond to Web requests and manage worker processes.

IIS 6 0 Application Isolation

Application isolation is critically important in a Web server environment. Both internal (intranet) and public (Internet) Web servers typically host multiple Web sites and a variety of applications that support those Web sites. Much of the code run by applications is run on the Web server itself. Application code that is poorly written or ill-behaved might be prone to crashing. Depending on how well an application is isolated, and the version of IIS, the crash of a single application might affect nothing else running on the Web server or it might take down the entire Web server, necessitating a reboot.

To understand application isolation, you have to understand how the operating system controls processes and how application processes are managed by IIS. A process is the smallest unit of control for the operating system. A process has a range of memory addresses assigned to it and can put threads on the processor for execution and so forth. The operating system can terminate a nonresponsive process; other processes are unaffected and continue to run.

Evolution of Application Isolation in IIS 4.0 and 5.0

The communications architecture of IIS 4.0 lent itself to running applications in-process. This meant that Web requests, and any application code run as the result of a Web request, were executed in the same process space as the Inetinfo.exe (IIS) process. Applications ran much faster in-process because no overhead was incurred by crossing process boundaries to communicate with Inetinfo or by contacting ISAPIs (which also ran in the Inetinfo process space). Unfortunately, if an in-process application crashed, it took down the entire Web server. In IIS 4.0, you could run applications out-of-process. This approach was used to isolate a single application to a single process. Applications that were mission critical or prone to crashing were isolated to protect themselves and the Web server. Unfortunately, out-of-process applications suffered from decreased performance due to the amount of communication required to cross process boundaries and talk to the Inetinfo process, and ISAPIs running in the Inetinfo process space. Moreover, running many applications out-of-process resulted in a performance penalty on the server as a whole because of the increased overhead related to managing additional processes.

IIS 5.0 was a huge improvement over IIS 4.0. First, the communications architecture was improved so that running applications out-of-process incurred a smaller performance penalty. Next, application pools were introduced. In IIS 5.0, you could run applications in-process or out-of-process, or you could run multiple applications in a single out-of-process pool. An IIS 5.0 Web server had one, and only one, application pool. This setup provided the best performance-to-reliability trade-off. Typically, administrators would put all their well-behaved applications in the pool to protect the Web server service (inetinfo.exe) in case one of those applications crashed. That ensured the Web server would continue to run and could restart the application pool and applications automatically after a crash. This minimized service interruption, but it still meant the applications running in the pool were vulnerable to each other’s malfunctions. If one application in the pool crashed, the pool process was terminated and restarted, which would interrupt other applications running in the pool. There were some additional issues with IIS 5.0. Specifically, ISAPIs still ran in-process, which meant a poorly written ISAPI could still crash the Web server service.

IIS 6.0 Isolation Modes

This brings us to the discussion of isolation modes in IIS 6.0. IIS 6.0 supports two isolation modes for application isolation. The first isolation mode is IIS 5.0 isolation mode. In this mode, IIS 6.0 emulates the architecture of IIS 5.0. IIS still uses the HTTP.SYS kernel- mode services for request queuing and caching, but each Web request must traverse Inetinfo.exe. Applications are configured to run in-process, out-of-process, or in a single out- of-process pool, and ISAPIs run in-process with Inetinfo.exe. IIS 5.0 isolation mode is for backward compatibility for Web applications only and can be used to ensure applications previously supported on IIS 5.0 continue to run.

The preferred IIS 6.0 isolation mode is Worker Process isolation mode. This isolation mode takes full advantage of the new IIS 6.0 architecture. In this mode, the Web server service (inetinfo.exe process) is completely isolated from application code and ISAPIs. Everything needed to fulfill Web requests, including ISAPIs, are loaded into the process space of the worker processes fulfilling the requests. All user code is handled by worker processes. Processing is fast because most request steps can be fulfilled from within the worker process, and applications can be completely isolated from each other and from the server. If a worker process fails or hangs, the W3SVC simply shuts down the failing worker process and starts a new one to replace it. In addition, in IIS 6.0 Worker Process isolation mode there is no concept of in-process or out-of-process—there are simply multiple application pools (as many as you want to create). In addition, you can assign as many or as few applications to a pool as you want.

IIS 6.0 cannot support both modes simultaneously, and the default isolation mode is different depending on whether IIS 6.0 is installed new or as an upgrade. If IIS 6.0 is upgraded from a previous version of IIS, the isolation mode is set to IIS 5.0 isolation mode. If IIS 6.0 is installed new, the initial isolation mode is set to Worker Process isolation mode. The isolation mode can be changed by selecting or deselecting the Run WWW Service In IIS 5.0 Isolation Mode check box on the service tab of the Web Sites object properties in the Internet Information Services (IIS) Manager MMC snap-in, or by configuring the IIS5isolationModeEnabled parameter in the metabase. HTTP.SYS operation is unaffected by isolation mode settings. Changing the isolation mode requires that Internet Information Services be restarted.

Table 16-1 lists the default modes for each installation type. Table 16-2 compares isolation modes.

Isolation-Mode Recommendations

Remember that IIS 6.0 defaults to IIS 5.0 isolation mode when a previous version of IIS is upgraded. If you simply upgrade your existing IIS servers, you won’t get many of the advantages of the new architecture until you change modes. The goal should be to run in Worker Process isolation mode. Before upgrading servers, you should create a test server running in IIS 6.0 in Worker Process isolation mode. Migrate the applications to the test server, and test them running in that mode. Once all applications have been tested and verified to work in Worker Process isolation mode, upgrade production servers and switch to Worker Process isolation mode.

IIS 6 0 Application Pools

At this point, you’ve heard a lot about application pools and even learned the history of application isolation from IIS 4.0 to the current generation Web server, IIS 6.0. In addition to the performance and reliability enhancements offered in Worker Process isolation mode, you also get more granular application management because you can configure multiple application pools.

You can create as many application pools as you like and configure as many or as few applications in each pool as you like. In Worker Process isolation mode by default, a single application pool is created (named DefaultAppPool) and all applications run in that application pool. If you want to isolate an application, simply create a new application pool and configure the application you want to isolate to run in the new pool. In Worker Process Isolation mode, application pool names appear in the Application Pool drop-down list box on the Home Directory tab of a Web site, or the Virtual Directory tab of a Virtual Directory, which allows you to select from among the configured pools. Application pools also have lots of configuration options, which allow administrators to configure how the applications running in the pool are managed, monitored, and optimized. You can group applications in pools based on these requirements.

Application-Pool Health Monitoring

Application pools can be monitored by the WWW Service Administration and Monitoring component (W3SVC). The W3SVC uses worker process pinging to send messages to the worker process through a named pipe. The worker process is supposed to respond to the ping. The W3SVC will consider an application to be unhealthy if the application has crashed or if all available threads are blocked. The W3SVC will terminate the unhealthy worker process or invoke Rapid Fail Protection, depending on the configuration.

Rapid Fail Protection protects your Web server from an application that is failing repeatedly. With Rapid Fail Protection, you specify a number of failures (such as 5) over a given interval (such as 5 minutes). If the application pool exceeds the specified number of failures in the time interval, it is taken out of service and will not be restarted. HTTP.SYS returns a 503 Service Unavailable out-of-service message to any requests to URLs serviced by that application pool. IIS will not restart the application. By not restarting, the application is prevented from consuming resources during restart and failure, which could lead to widespread disruptions.

Application-Pool Recycling

Application pools can also be configured to periodically recycle. Recycling is configured on the Recycling tab and works the same way as ASP.NET application recycling, except it’s configured on a per–application pool basis. You can configure application pools to be recycled after a specified number of seconds, after a specified number of requests, at specified times during the day, or when virtual or used memory exceeds thresholds you specify.

Recycling provides an automated way to periodically reset applications. Some poorly written applications can benefit from periodic restart, and recycling can provide added stability while problems are corrected. Application-pool recycling can replace periodic reset scripts that are run on some Web servers to accomplish the same task. The W3SVC is responsible for recycling application pools and uses overlapped recycling. The old worker process remains active long enough to finish servicing existing requests, or until the Shutdown Time Limit (configured on the Application Pool’s Performance tab) is reached. A new worker process is created and added to the namespace routing table in HTTP.SYS, and all new requests for the application pool are directed to the new worker process.

Application-Pool Performance

Application pools can also be configured to conserve system resources by using the Performance tab of the Application Pool properties. You can specify an idle time-out, which allows the application pool to shut down if no request has been made of the pool in the specified interval. This saves server resources by terminating unused worker processes. This allows you to better manage the resources when the processing load is heavy or when certain applications are consistently idle.

You can also specify to restrict the number of requests that are allowed to be queued for an application pool. If the number of requests exceed the allowed maximum, the server returns a 503 Service Unavailable error. This prevents large numbers of requests from queuing up and overloading your server. This would happen only if requests couldn’t be processed quickly enough. If this happened consistently, you should address the problem by scaling up the server (such as by adding processors), by off-loading tasks to other servers, or by moving the sites or applications being overloaded to separate, faster servers.

You can enable CPU monitoring and specify a maximum percentage of CPU utilization the application pool is allowed to consume over a given time interval. The W3SVC can log an event or terminate the worker processes associated with the pool.

You can also assign multiple worker processes to the application pool. By default, application pools have only one worker process assigned. If you configure multiple worker processes to support the pool, you create a Web Garden. Having multiple worker processes assigned to a pool can increase scalability for long-running applications that have many more simultaneous connections. They can also increase scalability on heavily used application pools. You can also use them to reduce the chance of service disruptions due to blocks on multiprocessor systems. If one of the worker processes experiences a block, the other worker processes can continue to function. Web Gardens are not recommended when the application pools are only lightly loaded, when normal health management provides adequate reliability, and when applications running in the pool cannot be multi- instanced.

Application-Pool Identities

Finally, you can configure the account the application pool runs under on the Identities tab of the application pool properties. You can choose one of three predefined accounts or specify an account you have created. The three predefined accounts are the Network Service account (the default), which has a low level of privilege; the Local Service account, which has a lower level of privilege because it has no outbound credentials and can’t act as a machine on the network (it accesses the network as ANONYMOUS); and the Local System account, which is a highly privileged account. You should use an account with the lowest level or privilege that is able to perform processing tasks for applications in the pool. If you decide to designate a user-defined account for the pool, you can browse to the account from this tab. Any accounts you create to be used as an application-pool account should be added to the IIS_WPG group on the local system.

Application-Pool Scenarios and Recommendations

There are several theories for how you can group applications into application pools on IIS 6.0. For example, you could put all sites and applications from a single branch or customer in the same pool. In a hosted environment, you could create an application pool for each department or customer. You could create a Problem Child application pool with aggressive recycling settings for all your ill-behaved applications. Remember that there is not a one-to-one mapping between IIS 4 and IIS 5 isolation modes and application-pool configuration, so review each application individually. In general, it’s best to put mission-critical applications in their own pool, put applications that share common requirements (for example, Health Monitoring, Recycling, and Performance or Identity settings) in the same pool, and put well-behaved, noncritical applications in the same pool.

XML Metabase

One of the most important changes in IIS 6.0 is the introduction of the XML Metabase. The Metabase stores all the configuration information for IIS. The Metabase was introduced in IIS 4.0 because it was more extensible than the Windows NT registry, and it has been with us ever since. The problem with the Metabase until now has been that it has been a black hole for administrators and developers alike. Prior to IIS 6.0, you had to use proprietary tools such as Metaedit.exe or complicated APIs to access and manipulate the Metabase directly. With IIS 6.0, Metabase information is stored in a plain text file. Information in the Metabase is stored in XML format, meaning the document starts with an XML declaration, logical units of information (such as IIS Web Service configuration and application pool configuration) are XML elements, and the actual configuration parameters are attributes of the corresponding elements. All information is surrounded by the appropriate start and end tags. Metabase files are located in the %SystemRoot%system32inetsrv folder. The MBSchema.xml file contains the Metabase Schema, and the Metabase.xml contains the Metabase.

The XML Metabase provides many advantages, the biggest of which is that you can edit the Metabase with simple text editors. You don’t need to learn ADSI or WMI APIs, although both ADSI and WMI scripting providers are supported and, in most cases, pre-IIS 6.0 administration scripts will still work fine. The change in format has not hurt performance. Metabase read and write performance is equivalent to IIS 5.0. If you enable Direct Metabase Edit on the properties page of the server object, or set the EnableEditWhileRunning metabase attribute, you can edit the Metabase.xml file while IIS is running, and most changes will take effect immediately. The Metabase configuration can also be easily exported using the IISCNFG.vbs script, which allows administrators to create server-independent configuration files. This allows you to easily configure duplicate IIS servers in scenarios where Network Load Balancing is used.

Metabase History

The new Metabase History feature significantly simplifies testing and implementation rollback. It’s very simple. IIS tracks changes to the Metabase, and each time the Metabase is written to disk, copies of the Metabase Schema and Metabase.XML files are saved to %SystemRoot%system32inetsrvhistory. Each version is marked with a unique number. By default, ten sets of history files (Metabase and Schema) are stored in the history folders; you can adjust this default setting with the MaxHistoryFiles setting in the Metabase. The history feature allows you to easily roll back any changes made to the Metabase. To restore the Metabase to its previous state, simply select Backup/Restore Configuration from the All Tasks context menu of the server object, or copy, paste, and rename one of the copies from the History folder. Now developers can easily make changes to test or tune applications, and then quickly, easily, and safely roll back to the original configuration.

Enterprise UDDI Services

Universal Description, Discovery, and Integration (UDDI) is a standard for listing and describing Web services and other applications. Support for UDDI is growing on a broad basis, and Microsoft has included Enterprise UDDI services with Windows Server 2003 to provide out-of-the-box support for UDDI services targeting intranet and extranet scenarios. This section will explain what UDDI is and how it is used to locate, describe, and connect Web services and applications.

What Is UDDI?

UDDI has been called a directory for applications that don’t have a user interface. Users and search engines will use UDDI to locate information about Web services and other applications on a network. UDDI components describe what services and applications do, and provide information about how to connect to the services. UDDI can be used to advertise public applications and services, as well as internal applications and services in intranet and extranet scenarios.

Developers and companies will register Web services and other applications along with metadata describing and categorizing the services and applications. Other developers, customers, partners, and search engines will locate the services and applications using UDDI. Companies deploying or planning to deploy Web services and applications they want to share internally with partners or customers should start looking into UDDI. Developers should know about UDDI because it helps them find, share, and reuse Web services and other applications and to build smart applications that can search UDDI to locate those services. UDDI might also be of interest to IT professionals because it will help them categorize network applications. End users don’t have to know UDDI and might not realize they’re using it when they use a Web-based interface or a search engine that connects to UDDI servers.

Enterprise UDDI Services

Microsoft offers Enterprise UDDI services on Windows Server 2003 (all versions except Web Server Edition). Enterprise UDDI Services is compliant with versions 1 and 2 of the UDDI standard and is designed to target intranet scenarios to facilitate Web services, application visibility, and sharing of code. Enterprise UDDI Services also targets extranet scenarios to support the discovery and description of services used between partner organizations, as well as to enable construction of smart (UDDI-aware) applications. Microsoft Enterprise UDDI Services is a Web application (not a Windows Server 2003 service) and requires IIS 6.0 and MSDE or Microsoft SQL Server.

The State of UDDI

Version 3.0 of UDDI was just released and is being reviewed. Information about the UDDI standard can be found at http://www.uddi.org. You can visit the Microsoft UDDI directory and listing of public applications at http://uddi.microsoft.com.

Active Directory

Active Directory is a directory service based on X.500 directory structure concepts, which support reliable synchronization (replication) of directory objects, is extensible, and supports industry-standard protocols such as Lightweight Directory Access Protocol (LDAP) and Kerberos authentication.

The primary role of Active Directory is to provide centralized authentication, authorization, account management, and directory lookup services for Microsoft network environments. Because of the ubiquitous nature of Active Directory’s primary role, domain controllers and global catalog servers are typically deployed to every location in a company. In many instances, multiple domain controllers or global catalog servers are deployed in a location to provide redundancy or increase performance. Everyone needs to be able to authenticate and access corporate services, so Active Directory needs to be everywhere and available all the time.

The Active Directory schema can also be extended to support additional objects in support of applications and services. Active Directory is excellent for applications such as Microsoft Exchange 2000 and Exchange 2003 that require a directory service and must be supported throughout an organization. Exchange 2000 and Exchange 2003 benefit from Active Directory by being able to use the existing directory structure without requiring organizations to deploy and maintain an additional directory service.

Applications also have an impact on the directory service because they require additional hardware to support increased directory lookup activity, add to replication overhead, and increase the size of the Active Directory database. Network administrators are often reluctant to allow developers to use the corporate Active Directory to support applications that require directory services. Often, developers have deployed ad hoc solutions—such as Access database lookups or network-based XML file lookup to support applications— rather than using a directory service.

In Windows Server 2003, Microsoft has enhanced Active Directory to make it easier for applications to use. Microsoft has also added a new capability—Active Directory Application Mode—to make it easier for developers to deploy applications that use directory services independently from the traditional Active Directory infrastructure.

Active Directory Application Partitions

In Windows 2000, some application data was stored in the Domain partition in the Active Directory database, which meant that all domain controllers in the domain stored the data, and global catalog servers throughout the forest stored some of the data. More commonly, application data was stored in the Active Directory Configuration partition, which meant that all domain controllers in the forest stored all the data. This increased overhead on domain controllers and increased directory replication traffic. There was no way to control which domain controllers stored a copy of the data for an application. No matter where the application was deployed, the directory service data went everywhere.

In Windows Server 2003, Active Directory supports application partitions. Application partitions are separate from domain partitions, so data is isolated from domain and configuration data. Furthermore, replicas must be manually designated so that administrators can control which domain controllers hold copies of the application data. This also means administrators can control replication issues related to application data.

In short, with application partitions administrators can feel comfortable that they can control the impact Active Directory–enabled applications have on the Directory Service infrastructure. In addition, developers can feel more comfortable writing applications that use Active Directory.

Active Directory Application Mode

To provide a solution for developers who simply don’t have or don’t want to use the corporate Active Directory infrastructure (and for administrators who would rather the developers didn’t as well), Microsoft has developed Active Directory Application Mode (AD/ AM).

AD/AM (pronounced Adam) runs as a non-operating-system service and doesn’t need to be deployed on a domain controller. You can run multiple instances simultaneously on a single box, with each instance being independently configurable. AD/AM allows an application to store directory data in a private directory service that supports only that application, potentially on the same server as the application. If required, additional copies of AD/AM can be deployed and a replication topology can be configured to support the AD/AM instance. The schema for the directory service can be tailored to meet the needs of the application. AD/AM can be managed by local-server or application administrators, or it can be centrally managed. Moreover, AD/AM can be used to provide robust directory services in Windows NT 4.0 domains, which do not support traditional Active Directory. Both corporate developers and independent software vendors (ISVs) can use AD/AM to build directory service–enabled applications.

AD/AM can be installed on any version of Windows Server 2003. It can also be installed on Windows XP Professional for application development and testing.

COM+ 1 5

COM+, an extension to the Component Object Model, consists of managed component services that have traditionally provided middleware services in support of applications built on components or requiring transaction handling. The COM+ support found in Windows 2000 has been carried over to Windows Server 2003 and extended with COM+ version 1.5. New features in COM+ 1.5 include the following:

• Applications as servicesYou can now configure COM+ applications as services. Implementing COM+ applications as services provides better startup control, and component DLLs are loaded into memory at boot time. This makes the application highly available and more reliable.
• COM+ application partitionsCOM+ application partitions allow multiple versions of COM components to be installed on the same computer. You can completely isolate the applications of one department or customer from another and reduce infrastructure costs by consolidating COM+ applications onto a single server.
• Component aliasingCOM+ 1.5 now supports component aliasing. With component aliasing, you can configure physical implementations of a component multiple times.
• Process recyclingCOM + 1.5 allows for COM+ applications to be recycled (gracefully restarted). Process recycling can be configured through the COM+ user interface or programmatically. Similar to process recycling in ASP.NET applications and in IIS 6.0 application pools, processes can shut down and restart based on criteria you specify, including elapsed time since application start, number of requests, and memory used.
• Public/Private componentsCOM+ 1.5 allows you to specify that components are public or private. Public components can be seen and activated by any application. Private components can be seen and activated only by other components in the same application, and can be configured to block access from outside of the application. Private components can still use COM+ services.
• Advertising COM+ applications as Web servicesYou can expose COM+ components directly as Web services or as components that can be consumed through remoting. This can allow requests to pass through the firewall when they might otherwise be blocked.

Microsoft Message Queue (MSMQ) 3 0

Microsoft Message Queuing Service (MSMQ) 3.0 is included in Windows Server 2003. MSMQ allows applications to communicate with one another asynchronously for simple communication and in support of transactions.

MSMQ 3.0 provides three major enhancements over previous versions of MSMQ: one- to-many messaging, messaging over the Internet using XML and SOAP messages over HTTP, and programmable management. These enhancements allow for applications that utilize MSMQ to leverage the HTTP protocol to exchange messages through firewalls and to use HTTPS (Encrypted HTTP) to provide secure message transfer.