Windows 2000 Web and Application Services Technical Overview
The Microsoft® Windows® 2000 Server operating system includes integrated Web and application services. These include Internet Internet Information Services (IIS) 5.0, and technologies such as COM+, Message Queuing, and data access. This combination allows developers to use a wide variety of programming languages and tools to build applications that can easily integrate with existing systems, while taking advantage of emerging technologies. By integrating these technologies with enhanced performance, scalability, and reliability, as well as infrastructure features including Microsoft Active Directory™ service and end-to-end security, Windows 2000 provides an application server platform well suited for the next generation of Web-enabled applications.
On This Page
Internet Information Server 5.0
The Component Object Model
Windows 2000 Components: COM+
Message Queuing with MSMQ
Data Access and XML
Windows 2000 Infrastructure Services
Beyond Windows 2000: Windows DNA 2000
For More Information
The Microsoft® Windows® operating system platform has become a standard foundation for building and deploying software applications. Its broad programming language support, large third-party developer community, and cost efficiency have helped make Windows the mainstream business operating system and application server platform. With Windows 2000, application developers can use the tools and skills they already have write the new Internet-enabled applications that are increasingly required by businesses.
From Web sites to high-volume transactional applications, Windows 2000 delivers the productivity benefits of component-based development and takes advantage of industry standards for greater interoperability, flexibility, and tools support. These application services are tightly integrated into the operating system to deliver the reliability and manageability that the most demanding traditional and Web-enabled applications require.
This paper provides an overview of the services within the operating system of specific use to application developers. These include:
Internet Information Services 5.0
The Microsoft Component Object Model (COM) and COM+
Microsoft Message Queue Services (MSMQ) message queuing
Data access technologies
Common Windows 2000 infrastructure
Because a working knowledge of the component object model used throughout Windows 2000 is particularly helpful to understanding the operating system's application services support, this paper describes the evolution of the component object model and its functionality in Windows 2000. The sections of this paper devoted to distributed applications, the component object model, and transaction services provide the background required to understand how COM+ works.
To fully understand how Windows 2000 helps application developers, it helps to see how the operating system fits into the larger application development picture, Windows DNA 2000.1 Windows 2000 Server is the foundation for the Microsoft Windows DNA 2000 platform, which includes technologies, tools, and support for application developers. This paper concludes with a brief overview of Windows DNA 2000.
Internet Information Server 5.0
Windows 2000 Server includes the built-in Web service, Internet Information Services (IIS) 5.0, which is accessible from popular browsers. IIS 5.0 is the reliable, scalable HTTP portal through which Web sites and Web applications communicate with the outside world.
IIS 5.0 provides all the standard services users expect from a Web server as well as support for the latest Internet standards, including HTTP 1.1, HTTP Compression, Secure Sockets Layer, and Common Gateway Interface (CGI), and the new Internet collaboration standard, Web Distributed Authoring and Versioning (WebDAV).
In addition, IIS 5.0 goes further than a simple Web server by providing the environment and services application developers need to quickly create sophisticated Web-enabled applications. One of the most significant application development technologies included in IIS 5.0 is Active Server Pages.
Active Server Pages
Active Server Pages (ASP) is a server-side scripting environment that organizations can use to create and run dynamic, interactive Web server applications. With ASP, developers can create a Web-based interface that combines HTML, script commands, and calls to COM+ components.
An ASP page contains a simple program—a script—written in a powerful scripting language, such as VBScript, and executed at the server. ASP pages in IIS 5.0 offer developers many benefits:
Greatly improved scalability and reliability. With IIS Reliable Restart and other enhancements, IIS in Windows 2000 allows developers to build applications that support more users and stay running.
Access to COM+ objects. Because an ASP page can create and use COM+ objects, the entire world of component-based applications is accessible to it.
Integration with COM+-based applications. Because ASP is a COM+ application, all COM+ applications and capabilities are available in ASP.
Transactional ASP scripts. COM+ integration allows creation of ASP pages that are transactional, meaning that all operations performed by the script can succeed or fail as a unit.
Process isolation. ASP pages can run in the same process as IIS, offering the best performance, or in a separate process, offering greater isolation in the event of failures. IIS now supports three application protection modes: High Medium and Low, allowing developers to balance overall Web server reliability with application performance.
Ability to distribute processing load across servers. By using Windows Load Balancing Service (WLBS), included with Windows 2000 Advanced Server, processor-intensive ASP applications can be run on multiple machines to support higher numbers of users.
New ASP features in Windows 2000 Server improve performance and make it easier to write applications that use IIS 5.0 and ASP. These features include:
Error handling. ASP now has new error handling that lets developers trap errors in a custom error message .asp file. Using the new error method, developers can display useful information, such as an error description or the line number in an .asp file where the error occurred.
Scriptless ASP. ASP pages that don't contain server-side script are processed as if they were static HTML pages.
Flow control. Rather than redirecting requests, which requires a performance-impacting roundtrip to the client, Web developers can transfer requests directly to an .asp file without ever leaving the server.
Performance-enhanced objects. IIS provides updated performance enhanced versions of popular installable components.
Self-tuning. IIS can determine when executing requests need additional resources and automatically provide more threads when required.
IIS 5.0 takes advantage of the security features that are fully integrated with Windows 2000. In particular, the Windows 2000 Server Web services are fully integrated with the Kerberos security infrastructure. The Kerberos Version 5 authentication protocol provides fast, single logon to Windows 2000 Server resources within or across Windows 2000 domains. Users can securely authenticate themselves at a Windows 2000 Server Web site and do not have to undergo a separate authentication (logon) to use other resources that may be referenced in the code, such as backend databases. Windows 2000 also includes critical security elements such as enhanced certificate management to allow companies to build a reliable Public Key Infrastructure (PKI).
In addition, Windows 2000 Server now also supports the following standard authentication protocols, which are applicable to Web-based users and ordinary network users alike:
Digest Authentication: the latest authentication standard of the World Wide Web Consortium (W3C), the organization that sets standards for the Web and HTML.
Server-Gated Cryptography (SGC): used by financial institutions to transmit private documents via the Internet.
Fortezza: The U.S. government security standard.
For additional details on Internet Information Services 5.0, see the technical overview (Internet Information Services 5.0 Technical Overview).
When it was introduced, the Microsoft Windows operating system was used primarily to run standalone applications on personal computers. Since then, the capabilities of the Windows operating system have expanded to support distributed applications, which span client and server operations, and the Internet.
The application services in Windows 2000 are designed to support a three-tier (also called n-tier, or distributed) architecture. The n-tier architecture separates an application into three distinct components:
Presentation. This is the piece of the application that a user interacts with, such as the order form used in an e-commerce application.
Application logic. This component contains all the business rules and logic associated with the application, such as the credit checking application used to support an e-commerce application.
Data. This is the mechanism that stores and manages the data associated with the application, such as product inventory information for an e-commerce application. Usually this is a relational database, but it can also include other storage containers such as a file system.
Partitioning applications into presentation, application logic, and data sections results in a simplified programming model that is the standard way to build applications that take advantage of intranet and Internet communications. By adding more hardware where needed, organizations can also expand n-tier applications to handle more users and information.
The n-tier model has proven especially important to developers wanting to integrate Web technologies into business processes. Because the model separates presentation, logic, and database functions, it is much easier to insert a Web server for backend processes and a client browser for presentation processes.
Taking Advantage of Hardware
The move to an n-tier development model is the result of a significant evolution of the personal computer application development model during the past decade. In the late 1980s, applications were generally written to run completely on a single PC. In the early 1990s, the two-tier client-server model emerged. This allowed developers to offload some of the more intensive data-processing work from client machines and move it onto more capable back-end servers. In this two-tier model, presentation software (the user interface) remained on the personal computer, while the bulk of the processing work was moved to the server. The three-tier model adds a further element of separation between the data and the presentation layers, by allowing processing logic to be handled on a separate server from the database and presentation functions.
Distributed applications are written to take advantage of the processing power available on servers—such as those used for database and line-of-business applications—and the client-side capabilities of personal computers and other devices. By dividing the processes used in an application among different computers, organizations can build flexible and scalable software using commodity hardware.
The Component Object Model
The key to building distributed applications is the ability to break software applications into modules, called components, which are the building blocks of distributed applications. Each component is responsible for a specific function. To increase efficiency, these components can be distributed to run on separate computers. The Component Object Model (COM) defines of how Windows-based components work together.
Since it was first introduced in the early 1990s, COM has been an important and evolving Windows technology. In Windows 2000, this model is called COM+. To understand how COM+ works, it helps to understand how the component object model works.
How COM Works
A good example of a distributed application is an electronic-commerce order entry process, which integrates data and processes from a variety of locations, including both servers and clients. In today's development environment, such a process often combines elements of traditional software, such as a database, with those based on Internet technologies, such as a browser.
COM allows application developers to break large, complex software applications into a series of pre-built components, which are easy to understand, develop, and change. A component is a software module that is written to handle a particular type of information or a particular process. For example, a customer record can be created using a component that provides for name, address, and other distinguishing information. Components can contain relevant business logic to handle each element of a transaction, for example, specifying the proper length for a telephone number.
Each component is designed so it can be easily modified to address particular requirements. This way, rather than writing the same kind of code over and over, developers can use standard software code, say for an address record, and only adjust the elements that vary for an individual application.
To create a business process, developers connect components together. By reducing the amount of code developers have to write from scratch, this approach reduces the cost of developing software and makes it easier for organizations to modify applications as business conditions change. Because applications built using components can be linked together over networks, component software is also an efficient way to write distributed applications.
Basic COM Features
The following COM features make it a flexible technology for developers to use:
Location transparent. Every COM component can be called within a process, across processes on a single computer, or across multiple computers without being recompiled.
Language-neutral. Because COM is a binary standard, an implementation of COM written in one language is compatible with other COM implementation, making it language-neutral. For example, a Java developer can reuse other COM components written in languages such as Visual Basic or C++. This allows developers to assemble an application from components written in whatever language is appropriate and convenient.
Discoverable interfaces. Discoverable interfaces provide tools and other applications to let developers discover the interfaces and parameters that are supported by the component. This makes it easy for developers to work with the component without the need to understand its inner workings.
COM has evolved to meet the needs of the increasingly sophisticated applications made possible by networked personal computers. In particular, Windows NT® Server 4.0 expanded COM in two major areas. First, Distributed COM (DCOM) extended the COM model to span multiple networked computers. Second, Microsoft Transaction Services (MTS) allowed developers to build component-based applications with transactions that span components and databases.
These technologies have been tightly integrated and refined to create COM+ in Windows 2000. Before going into a deeper description of COM+, the next section provides a general overview of how transaction services work.
Note: You'll sometimes see the entire set of COM-related application service technologies—COM, DCOM, and COM+—referred to generically as COM.
In the mid-1990s, Microsoft broadened the applicability of COM by introducing transaction processing support as a separate service called Microsoft Transaction Server (MTS). Transaction services help developers write and manage component-based distributed applications by providing much of the software infrastructure needed to execute the business logic that runs in the middle tier of the n-tier architecture. Transaction services include code for connectivity, directory, security, process, and thread management, as well as the database connections required to create a transaction-aware application.
In Windows 2000, COM+ integrates transaction services, as described in the next section of this paper. To make it easier to understand the affect of that integration, this section provides background on how transaction services work.
How Transaction Services Work
A transaction is a set of events that are committed or rolled back as a unit—either all the events happen, or none of them do. The creation of a complete transaction can require the cooperation of a number of components. In the example illustrated in Figure 4, the order entry application is made of components that, using DCOM, retrieve and process information from several servers. Windows transaction support provides built in programming services that let developers ensure that the entire transaction either succeeds or is completely reversed, without having to write extensive custom code to handle the mechanics of the transaction.
Transaction services and COM work together to increase the capabilities of an application. The easiest way to understand how transactions and COM work together is to look at a typical scenario, illustrated in Figure 4 above. Suppose a customer is ordering products over the Internet. The entire order entry system can be built using COM components containing the business logic required to process orders. The individual elements of the customer's order will likely use several processes and databases, hosted on different servers.
For example, the process would use a customer information database to record the customer's name and address; an inventory database to make sure there is product available to fill the order, a shipping database to track the shipment, and a credit verification process to make sure the customer's credit card is valid.
When the customer places the order, all the processes and database transactions need to be recorded as a whole. The transaction service monitors the entire transaction, and only commits all the changes if the entire transaction is successful. If a communications or hardware failure should interrupt the order processing, the transaction service will either roll back the entire order, or hold it for complete processing when communications are restored. Likewise, should the customer cancel the order, the transaction service can allow the reversal of all the processes and database entries.
Note: Component Services cannot roll back changes to the file system or changes to other, non-transactional resources.
Before transaction support was offered with Windows, developers had to write scripts and components to manually track the requested changes and restore data if any changes failed. With transactions, developers simply have to designate that scripts or components require transactions. This means that developers can put together applications that use components without having to write the specialized code needed to address such issues.
Windows 2000 Components: COM+
Windows 2000 introduces the next generation of the component object model, COM+. One of the significant advances in COM+ is its integration of the previously separate transaction services, and the transaction services security model. This integration makes it easier to develop distributed applications by reducing the work associated with developing, debugging, deploying, and maintaining an application that previously relied on COM for certain services and transactions for others.
COM+ is an essential element of the Windows Web and application services. COM+ services are readily used from any programming language or tool, and components that were written using the COM model will work with COM+. The technology enables extensive interoperability between components, regardless of how they are implemented. It does this by defining a standard set of component types and making all components fully self-describing. In addition to simplifying deployment of components and applications that use them, this ensures that all COM+-compliant system services and components will be accessible to all COM+-aware languages and tools. This makes it easy for developers to integrate their code with systems from multiple vendors. In addition, COM+ extends the Windows platform support for attribute-based programming, which allows components to be used in a more flexible manner.
The major features COM+ introduces are:
The major transaction service features within COM+ include:
Automatic transactions. Automatic transactions allow the transactional requirements of a component to be configured when that component is deployed, thus increasing the potential for component reuse.
Configurable security. By allowing an administrator to define roles and specify the interfaces and components that can be accessed by clients identified for each role, transactions support greatly simplifies the work required to create secure server applications. For example, an administrator can designate that only those clients identified as managers can change credit history.
Note: The transactions security model builds on the Windows security infrastructure.
Database connection pooling. Components can reuse existing connections to a database rather than creating new ones, greatly improving application performance and scalability.
Support for multiple databases and resource managers. Transactions-based applications can access Microsoft SQL Server™, Oracle and DB2 databases, as well as other resource managers such as the Microsoft Message Queue Service. Transactions-compliant open-database connectivity (ODBC) and object linking and embedding database (OLE DB) drivers are available for many other databases from third-party providers. In addition, COM+ supports two-phase commit transactional access to any XA-compatible database.2
Automatic thread support. Application developers can write single-threaded components, and then let transactions assign threads to those components as needed.
Process isolation through packages. Individual applications can be grouped into one or more packages, and each package can run in its own process. This allows for greater fault tolerance because the failure of a single component will bring down only the package where that component is located.
Integration with mainframe transactions. Through the COM Transaction Integrator, available separately, transaction services can initiate and control CICS transactions on IBM mainframes.
A broad range of development tools. Transaction support allows developers to build applications in any of today's popular languages, including the Visual Basic, Java, C++, and Cobol.Figure 5: COM+ integrates transactions and adds support for Queued Components, Object Pooling, and Events.
The Queued Components feature takes advantage of Microsoft Message Queuing Services (MSMQ) to let server components logically participate in transactions while unavailable or offline. (MSMQ is described in detail in the next section of this paper.) This allows standard COM components to use MSMQ to deliver asynchronous capabilities. While developers can use MSMQ to write applications that use the capabilities provided by queued components, such development is relatively labor-intensive. Programming with queued components is much faster, and does not require the developer to learn new techniques.
Queued components are typically used for communications between two servers Requests that affect a queued component are transparently recorded, queued, and played back at a later time when the requested component becomes available. Such a model is particularly useful on unreliable networks or in situations where one of the servers isn't always connected to the network. Queued components can execute immediately if the servers are connected; otherwise, the component can hold execution until a connection is made.
Object pooling is an automatic service provided by COM+ that lets application developers configure a component so that instances of it are kept active in a pool, ready to be used by any client that requests the component. Developers can administratively configure and monitor the pool maintained for a given component, specifying characteristics such as pool size and creation request timeout values. Once the application is running, COM+ manages the pool, handling the details of object activation and reuse according to pre-specified criteria.
Developers can achieve significant performance and scalability benefits by reusing objects in this manner, particularly when they are written to take full advantage of reuse. Object pooling lets developers:
Speed object use time for each client, factoring out time-consuming initialization and resource acquisition from the actual work that the object performs for clients.
Share the cost of acquiring expensive resources (such as database connections, sockets, and so on) across all clients.
Pre-allocate objects at application startup, before any client requests come in.
Administratively configure pooling to take best advantage of available hardware resources—the pool configuration can change as available hardware resources change.
Speed reactivation time for objects that use just-in-time (JIT) activation, while deliberately controlling how resources are dedicated to clients.
Also known as the publish and subscribe events service or Event Notification, COM+ Events is a programming tool that lets application developers write application code (called publishers) that can notify client-side application code (called subscribers) when a particular event happens. For example, COM+ Events can be helpful to developers using queued components to help guarantee delivery of queued tasks.
COM+ Events uses a multicasting publish/subscribe event mechanism that lets multiple clients subscribe to events published by various servers. The COM+ Events system maintains an event database with information about various events, publishers, subscribers, and individual subscriptions.
To see how this works, look again at the order entry application described earlier. Using COM+ Events, the product inventory server can publish a notice when inventory levels on popular items drop below a certain level. Developers writing applications for the purchasing department—or any other areas of the company that are affected by inventory conditions—can readily use this information in their applications by subscribing to the inventory software event notification service.
Message Queuing with MSMQ
MSMQ, a separate technology introduced in the Windows NT 4.0 timeframe, complements the capabilities inherent to COM and transaction services. Because all the steps of an application process may not need to be completed at one time, many distributed applications need the ability to handle delays between a request and a response. MSMQ allows applications to use components that communicate with one another using queued messages, which is a concept similar to e-mail sitting in an inbox.
Being able to write applications that don't require immediate responses from either clients or servers lets developers provide the flexibility required to handle routine pauses within business processes. Using this service also helps developers write applications that are more readily available and more scalable.
How MSMQ Works
When developers write components that take advantage of MSMQ, their application can send messages to another application without waiting for a response. Those messages are sent into a queue, where they are stored until a receiving application removes them. If a response is expected, the sender can check a response queue when convenient.
Message queuing is a flexible, reliable approach to communication—one that's appropriate for many kinds of applications. Developers don't have to think about the details, and the system architecture takes care of the queuing processes even if the client and server aren't running at the same time.
For example, a developer can use MSMQ to write an application that will let customers submit orders over the Internet, even when the receiving Web server isn't available. Message queuing can also be used to make back-end processing more efficient. For example, when a customer places an order, not all parts of the order need to be processed right away. In the example described earlier, the shipping department does not have to receive the customer order before the rest of the transaction can be completed. Using MSMQ, the order entry application can continue running even if the shipping application isn't available.
When an order is completed, an order entry component sends a message to a warehouse indicating that the order should be packaged and shipped. Because there's no need for the component to wait for the order to be sent off, this request is made using MSMQ. When convenient, an application in the warehouse then extracts orders from a queue and ensures they are filled. Developers can use transaction services with MSMQ to ensure that the transaction completes properly.
MSMQ features that support the capabilities described above include:
COM-based access. The services of MSMQ can be accessed through a simple interface provided by COM components. This setup makes it straightforward to send and receive messages from within an Internet Information Service Active Server Page script, a transactions-based application or any software that can use COM.
Integration with transactions. MSMQ operations can automatically enlist in transactions to preserve data integrity.
Automatic message journaling. If requested, MSMQ will keep copies of messages sent or received by applications. Journals provide audit trails and can also make recovering from some kinds of failure easier.
Automatic notification. If requested, MSMQ can notify a sending application that messages were (or were not) received and processed correctly. This service lets sending applications know when they can treat messages as delivered or, if failures occur, when they must take corrective action.
Built-in data integrity, data privacy, and digital signature services. MSMQ can digitally sign and encrypt messages for transfer across the network. This capability protects messages from being viewed or changed during transmission, even when sent over public networks such as the Internet, and ensures that servers do not receive messages from unauthorized senders.
Message priority support. MSMQ allows priorities to be assigned to messages and queues, then routes and delivers messages based on these priorities. Priorities let applications handle the most important messages first.
Simplified application integration. MSMQ greatly reduces synchronization requirements between applications because message contents are easy to translate, and message-based interfaces hide the differences between different application architectures and database technologies.
Network protocol independence. All MSMQ features and functions operate independently of network protocols. Any application that knows the name of another application request queue can send requests and receive responses regardless of network type.
By providing flexible, reliable asynchronous communications between component-based applications, MSMQ plays a critical role in Microsoft component services for Windows NT 4.0. With Windows 2000, MSMQ services are even more tightly integrated with the COM programming model, as discussed in the COM+ section of this paper.
Data Access and XML
Windows 2000 Server provides high-performance access to all types of information (including relational and non-relational data) across an organization from the desktop to the enterprise. The following data access specifications are supported in Windows 2000:
ODBC. ODBC is the most widely used interface for accessing structured data. ODBC lets applications developers easily access data in over 50 different databases including Microsoft SQL Server, Oracle, Sybase, Informix, DB2, and many others.
OLE-DB. OLE DB is the Microsoft low-level interface to data across the organization. OLE DB is an open specification designed to build on the success of ODBC by providing an open standard for accessing all kinds of data.
ActiveX® Data Objects. Active Data Objects are a language-neutral object model, which expose data raised by an underlying OLE DB Provider. The most commonly used OLE DB Provider is the OLE DB Provider for ODBC Drivers, which exposes ODBC Data sources to ActiveX Data Objects.
RDS. Remote Data Service is used to transport Active Data Object Recordsets from a server to a client computer. The resulting recordset is cached on the client computer and disconnected from the server. RDS uses a subset of the ActiveX Data Objects model, the ADOR.Recordset, to provide a low-overhead, high-performance way to marshal recordset data over a network or web.
CDO. Collaboration Data Objects are a set of COM objects that provide access to data stored in Exchange.
Windows 2000 Server supports a full range of industry standards to allow you to build applications that integrate with databases, mail servers, XML, and other existing systems. XML is particularly important, because just as HTML lets developers describe the format of a Web document, XML lets them describe complex data structures. Developers can share this information across a variety of applications, clients, and servers. Using the new Microsoft XML Parser, developers can create applications that enable their Web server to exchange XML-formatted data with both Microsoft Internet Explorer and any server capable of parsing XML. Using ActiveX Data Objects 2.5, developers can also access databases and work with ASP pages using XML-enabled code.
Windows 2000 Infrastructure Services
Organizations that build applications on the Windows 2000 platform can take advantage of integrated system services and capabilities. In addition to broad programming language support, Windows 2000 provides the performance, management, reliability, scalability, security, and interoperability required for the increasingly diverse application development requirements faced by today's businesses.
This section provides a brief overview of these Windows 2000 platform infrastructure capabilities. Readers interested in learning more about these aspects of Windows 2000 will find links to helpful resources at the end of this paper.
Performance, Scalability, and Reliability
Windows 2000 Server introduces new levels of performance, scalability, and reliability, which can bring immediate benefits to applications—whether or not those applications were written to take advantage of specific Windows 2000 features. The tight integration between the application services: COM+, MSMQ, and IIS 5.0, and the operating system itself, help to magnify the performance gains throughout applications that use the COM+ technologies.
Programming and Language Support
By integrating COM+, Windows 2000 provides developers with a language neutral approach to building and deploying distributed applications. This lets developers take advantage of the skills and tools they already use, and build distributed, Web-enabled applications in the same way they build stand-alone Windows applications.
Developers can build and reuse components written in Microsoft Visual Basic, C++, Java, and any other language that can generate a COM component. Because Windows 2000 DNA Services relies on a comprehensive and integrated set of services provided by the Windows platform, developers are free of the burden of building or assembling the required infrastructure for distributed applications and can focus on delivering business solutions.
Today's corporate computer environments are often heterogeneous: Many rely on several network operating systems that must interoperate with both newer, intranet client/server environments and legacy computers and applications.
The Microsoft interoperability strategy is based on a four-layer framework that covers network, data, applications and management integration. By supporting key standards, Microsoft is committed to ensuring that the Windows 2000 Server operating system can interoperate with existing platforms and technologies.
Specifically, Windows 2000 Server lets developers create applications that can:
Communicate with other operating systems using common protocols. Using TCP/IP as a core protocol, a Windows 2000-based server is able to communicate with UNIX and NetWare systems natively over enterprise networks and the Internet.
Access file shares and printers regardless of environment. Windows 2000 Server provides the services to allow file and print sharing with NetWare, UNIX, Macintosh, and IBM (with SNA Server).
Reduce the burden of administering multiple systems. With the Active Directory service, organizations can unify and manage the multiple namespaces that now exist in corporate networks—an efficiency that delivers the high level of interoperability required for administering heterogeneous software and hardware environments
The Active Directory service is the integral directory service within the Windows 2000 operating system. It provides a centralized location to store information about people and resources on a distributed network. Developers can use a number of standard interfaces to write applications that use information stored in the Active Directory service about users, other applications, and devices. This can help them write dynamic applications that are simpler to develop and easier to manage.
Because Active Directory is based on standard directory access protocols, such as Lightweight Directory Access Protocol (LDAP), it can interoperate with other directory services employing these protocols. Several application programming interfaces (APIs)—such as Active Directory Service Interfaces (ADSI)—give developers access to these protocols. All Active Directory functions are available through LDAP, ADSI, and MAPI for extending and integrating with other applications, directories, and devices.
ADSI gives developers access to multiple directory service providers through an open set of interfaces. Applications written to ADSI will work with any directory service that offers an ADSI provider. For example, with ADSI, applications can access LDAP, NDS, Active Directory, and other directories with ADSI interfaces as long as the appropriate service providers are available.
Windows 2000 Server includes security services for enterprise-wide network authentication. Developers can build secure intranet, extranet and Internet sites using the latest standards, including 56-bit and 128-bit SSL/TLS, IPSec, Server Gated Cryptography, Digest Authentication, Kerberos v5 authentication, and Fortezza. Because the security infrastructure is integrated into the core of Windows 2000, all Web and Application Services can take advantage of it. From the kernel, through services and applications, all the way to databases on the backend, Windows 2000 provides easy to manage, single-source, high security.
Beyond Windows 2000: Windows DNA 2000
The application services described in this paper, plus other capabilities such as file and network services, let Windows 2000 provide the foundation for the Windows DNA platform (Windows DNA 2000). The Windows DNA 2000 architecture provides a blueprint that helps developers design and build distributed business applications using technologies that are integral to the Windows 2000 platform.
With Windows DNA, the idea of a platform extends beyond the Windows 2000 Server operating system to include a programming model, tools, database, and application services. Windows DNA 2000 defines a common set of services, including components, Dynamic HTML, Web browser and server, scripting, transactions, message queuing, security, directory, database and data access, systems management, and user interface. These services are exposed in a unified way through COM, enabling applications to take advantage of them easily.
Windows DNA 2000 addresses requirements at all tiers of distributed applications—presentation, business logic, and data, helping developers:
Create robust, scalable, distributed applications using the Windows 2000 platform.
Extend existing data and external applications to support the Internet.
Support a wide range of client devices to maximize the reach of an application.
Windows DNA 2000 enables developers to build tightly integrated applications using familiar tools. Because Windows DNA uses the comprehensive and integrated set of services provided by the Windows platform, developers are free of the burden of building or assembling the required infrastructure for distributed applications. The heart of Windows DNA is the integration of Web and client/server application development models through COM.
Windows DNA 2000 also describes how the family of Microsoft application development products fits together, including Microsoft Windows 2000, Microsoft Visual Studio® development system, Microsoft Exchange Server, Microsoft Commerce Server, and Microsoft SQL Server, as well as new pending products including the next version of Microsoft SNA Server called the Host Integration Server, Microsoft Application Center, and Microsoft BizTalk™ Server (for XML-based business process integration).
The application services in Windows 2000 are the result of years of refinement to meet the requirements of developers who are writing increasingly sophisticated distributed applications. These services have evolved from addressing stand-alone personal computers in the early 1990s to supporting today's diverse distributed networks with multiple servers and large numbers of clients.
IIS 5.0 provides the Web access essential to many new applications. The IIS 5.0 Web server works hand in hand with the component-based application services in Windows 2000.
At the heart of the Windows 2000 application services is the Microsoft Component Object Model (COM). The COM technologies provide a mature foundation for component-based development, and the majority of Windows-based application use COM in some way. With its integrated services and its development tool support from Microsoft and others, COM is a popular foundation for building distributed applications.
Windows 2000 introduces COM+, which fully integrates transaction services to make it easier for developers to write sophisticated, component-based, Internet-enabled distributed applications. COM+ also provides queued components and event services. These features make it easier to write applications that both allow for routine pauses in business processes and can publish information about activities that can be used by other applications.
COM+, IIS 5.0, and the broad base of application development and integrated infrastructure features including directory, security, and data access services in Windows 2000 provide the technology required to let the operating system act as the foundation for the Windows DNA 2000 platform.
For More Information
For the latest information on Windows 2000, check out Microsoft TechNet or our World Wide Web site at http://www.microsoft.com/windows2000
To learn more about the scalability and availability provided by Windows 2000 Advanced Server, see: http://www.microsoft.com/business/default.mspx
To learn more about Windows 2000 interoperability, see http://www.microsoft.com/windows2000/server/evaluation/features/interop.asp
To learn more about writing applications that use the Windows 2000 application services, visit the Microsoft Developers Network Web site at http://msdn.microsoft.com/
To learn more about COM, see http://www.microsoft.com/com/
To learn more about XML, see http://msdn.microsoft.com/xml/default.asp
|1||DNA stands for Distributed interNet Applications Architecture.|
|2||XA stands for X/Open. XA is a transaction protocol supported by COM+, the Microsoft Distributed Transaction Coordinator, as well as products from many third-party transaction processing monitor vendors. XA interfaces allow application developers using transaction services to access XA-compliant databases and create resource managers that operate with relational databases, message queuing, transactional files, and object-oriented databases.|