Application Server: Frequently Asked Questions

We define the category of application server as the “system software that underlies the server-based execution of shared business applications.” Just as a file server delivers files to many users, an application server makes applications—often custom-built applications—available to multiple concurrent users.

Using application server technology, an organization can develop, run, and manage custom or off-the-shelf applications in a way that is security-enhanced and reliable, while maintaining high levels of performance for multiple concurrent users. Application servers can host applications that respond to requests, perform business logic, and coordinate updates to shared data. Concurrent user requests are ensured fairness as well as accuracy in reading and updating system-of-record data.

Web services provide a standards-based mechanism for multiple applications to intercommunicate. Application server technology can provide the infrastructure for hosting server-based systems that connect out, or accept connections in, by way of Web services. Web service clients, including smart clients built on the Microsoft Office System, can communicate with Web service providers running within application servers.

Application server technology is a natural complement to smart client technology. Smart clients are client-side applications that are easily deployed and managed and that provide an adaptive, responsive, and rich interactive experience by leveraging local resources and intelligently connecting to distributed application and data sources. Web services provide an optimal mechanism to connect smart clients to custom or prepackaged applications running on application servers.

Many companies are reorganizing information technology systems into a service-oriented architecture (SOA), allowing applications to be more maintainable, more cost-effective, and more aligned with business goals. Solid application server infrastructure plays a central role in enabling SOA for information-centric organizations.

A typical application server provides a ‘host’ process or container for business components or services. These components or services may be purchased as packaged software, or written by programmers in an IT department. An application server also provides:

Microsoft Windows Server 2003 includes the integrated capability for building, running, deploying, and managing high-performance connected applications, using the following technologies:

This functionality is complemented by other elements of the Windows platform, such as:

With a few exceptions, the integrated application server capability in Windows Server 2003 is available across the line of Windows Server product editions. For more on the features supported by each edition of Windows Server, please see http://www.microsoft.com/windowsserver2003/evaluation/features/compareeditions.mspx.

Windows Server can run applications that span a broad range of capability and performance. At the low end of complexity, Windows Server can run simple Web applications that deliver mostly static content, such as keeping logs of access. At the other end of the spectrum, Windows Server can support highest-performance, large-scale transactional systems, with the most rigorous security-related and reliability requirements. Windows Server can scale up or down as needed. Windows supports “daemon” or “agent” applications that are always on and always running, as well as applications that respond to incoming requests from clients. Included in this latter category would be Web applications and Web services. Server-side applications may be simple, single-threaded designs, deployed on a single server; or may be highly concurrent, and distributed across a reliable array of server machines. The application server infrastructure in Windows Server is flexible enough to handle applications that span the full range of connected applications.

Windows Server can handle requests from a variety of endpoints that run on any operating system or hardware platform. The only requirement is that the requesting application must be able to connect to the application server over a network. The application server infrastructure in Windows Server supports many communication options in order to work with your existing infrastructure.

Yes, any Web browser that supports HTML 3.2 or HTML 4.0 can connect to Windows-based Web applications. A variety of mobile devices can also connect.

Yes, "smart clients" based on the Microsoft Office System can use Web services protocols to connect to applications running on Windows Server.

Yes. So-called "rich client" applications, even those that do not use the Microsoft Office System or Microsoft Windows as an underlying infrastructure, can connect to applications running on Windows Server.

Yes; if they use Web services protocols, bare sockets protocols, or third-party middleware that runs on Windows Server, remote server-based applications can connect to applications running on Windows Server.

Yes, Windows Server can host AJAX or REST applications. AJAX is a model that allows Web browsers to become unbound from the model where each communication exchange results in a new browser page. REST is a model in which XML documents are exchanged between client and server.

Use of Windows Server as an application server is covered under the standard pricing and licensing terms for Windows Server 2003. For more details see http://www.microsoft.com/windowsserver2003/howtobuy/licensing/pricing.mspx.

Windows Server and the integrated application server infrastructure supports a wide variety of protocol and data format standards. For Web applications and Web services, the relevant standards include HTTP, HTTPS, HTML, XML, FTP, SMTP, CSS, SOAP, XML-DSIG, XSL, and DOM. For the security area, the standards include X.509, Kerberos, LDAP, AES, DES, RSA, DSA, MD5, and SHA. In management, the standards include CIM, WBEM, and SNMP. And beyond de jure standards, the Windows application platform also supports de facto vendor-specific protocols and systems like LU6.2, MQSeries, Netegrity, IIOP, Tibco RV, SAP ERP, R/3, and others. Applications written with the .NET Framework can connect to SQL Server, but also Oracle, IBM DB2, Sybase, and many other databases. What all of this alphabet soup means is that applications deployed on Windows Server can interoperate with whatever else you have deployed in your network.

There are a variety of options for interconnecting applications running on Windows Server with applications running on IBM systems, including CICS, IMS, DB2, Lotus, and Tivoli systems. Applications running on Windows can connect to many of these systems without additional infrastructure software. In some cases, additional capability is desired, for example two-phased commit transactions with mainframe resources. In these cases, Microsoft Host Integration Server can provide additional capability. It is also possible to use other integration middleware (IBM’s MQSeries provides one such option). Custom applications written for the Microsoft application server can take advantage of transactional store-and-forward messaging with MQSeries to interconnect with many IBM systems. There are many other interconnect options based on either standard protocols, such as Web services and SOAP, or IBM-specific protocols such as LU6.2 and DRDA. Most enterprise customers have the need to interconnect heterogeneous systems, either their own networks or systems that span the networks of partner organizations. The Microsoft application server can support those requirements.

The standard Web services protocols supported by Windows Server and the .NET Framework mean that .NET-based applications can interconnect with any other system—running on any platform and written in any language—that supports those same protocols. There are many Java-based Web services libraries that allow interoperability and intercommunication between Java-based systems and .NET-based systems running on Windows Server. For more information, see the Java Interop site.

Microsoft introduced ODBC as a database interoperability layer in 1991, and since then has continued to improve and extend the ability of Windows-based applications to connect to any database system. Today, by way of the ADO.NET subset of the .NET Framework, Windows applications can connect with high performance to Oracle, DB2, Sybase, and Informix, as well as many other less-common systems. And, Windows Server can connect over the network to databases running on non-Microsoft platforms and deliver great performance while doing it. For more information, see the ADO.NET overview.

Based on security protocol and data encryption standards such as X.509, Kerberos, and RSA, DSA, MD5, SHA, and AES, applications written in .NET and running on the application server infrastructure contained within Windows Server can interoperate in a security-enhanced manner with applications running on other platforms. The Microsoft platform supports WS-Security; any Web service client that runs on any platform supporting WS-Security will be able to engage in a security-enhanced Web services connection with Web services applications on the Microsoft platform. In the area of identity interoperability, Active Directory Federation Services (ADFS) is a new feature in Windows Server 2003 R2 that makes it possible for organizations to share a user's identity information in a security-enhanced way over federation trusts. For example, via ADFS a .NET application may authenticate a user against an identity store maintained by an IBM directory or a Netegrity store. For more on ADFS, see the ADFS Overview.

Windows Server 2003 allows the administrator to configure the server into one or more roles, including the role of application server. For more information on this, see Server Roles: The Application Server.

Windows Server includes management interfaces for all aspects of the infrastructure that requirement management. This includes management scripting APIs for automated management tasks, as well as graphical management interfaces. For example, using either programmatic or graphical interfaces, administrators can add queues, set up clusters and load balancing, enable or disable distributed transaction support, or adjust security levels on Web sites. In addition to these built-in tools, there are third-party add-on tools that aid in managing Windows servers.

There are programmatic as well as graphical ways to monitor the performance of Windows-based applications. For example, administrators can observe the rate of transaction throughput on an application, or on the entire server computer, using the built-in Windows performance monitor tools. Administrators can also monitor and observe the usage of various machine-specific resources, such as CPU, memory, or I/O. Using extended management tools such as Microsoft Operations Manager, administrators can set alerts and be notified or perform other scripted tasks when specific parameters exceed a configured threshold.