Interoperation Using .NET

By Scott Hofmann

Abstract

HTTP over TCP/IP has become the default universal protocol that many different platforms and hardware are built to communicate with. Hardware ranging from PDAs, printers, and network devices to servers being produced currently offer TCP/IP capability. Devices host operating systems or embedded software that support TCP/IP communication. In a networked world based on TCP/IP, the .NET Framework provides the infrastructure required to support software that is hosted on heterogeneous platforms the means to coexist without conflict and to collaborate when required. This paper describes techniques that systems administrators can use to support .NET Applications within a legacy server environment.

On This Page

	The .NET Framework
	ADO.NET
	Distributed Interoperation of ADO.NET
	IE 5.01 and MSXML Dependency
	.NET Remoting
	ASP.NET
	ASP.NET Configuration

The .NET Framework

At first it might seem as if the .NET Framework is offering a new set of functionality that introduces a new level of complexity, which will exacerbate your effort to manage and maintain a heterogeneous environment. Although the complexity exists with the new system, it does offer an alternative architecture that enhances the Microsoft operating system platform in ways that will simplify the administrator's duty to manage heterogeneous systems in a networked environment. This paper will examine the benefits that the .NET Framework offers to function with legacy systems.

There are two configurations for a .NET installation—client and server. A server configuration of the .NET Framework has stricter host requirements than does the client configuration. Only Windows 2000 (Professional, Server, Advanced Server) with the latest Windows Service Packs or Windows XP Professional can host the server configuration of .NET Framework. Server configurations for the .NET Framework also require Microsoft Data Access Components (MDAC) 2.7 on the host. Client configurations of the .NET Framework require MDAC 2.6 or later and may be hosted on older versions of Windows. For example, a Windows NT 4.0 Server can be configured only in the client configuration of the .NET Framework. Please refer to Table 1 for a summary of the software and versions required for successful installation on a target host of the .NET Framework for each configuration.

Table 1. Software Required by the .NET Framework Installation

Software

Version

Configuration

Internet Explorer

5.01 or later

Client and Server

Core WMI for Windows Instrumentation

1.5

Client and Server

Windows Installer

2.0

Client and Server

MDAC

2.6 or later

Client

MDAC

2.7 or later

Server

Internet Information Services (IIS)

5

Server (with ASP.NET applications)

ASP.NET and ADO.NET are supported only on a .NET Framework server configuration. A client configuration of the .NET Framework limits the host's support of features afforded in the .NET Framework but does enable some .NET Framework functionality on a legacy operating system. Each .NET configuration offers advantages that the administrator must consider in the context of the host requirements for the .NET solutions. Throughout this paper, strategies are presented that describe the required configurations in terms of a .NET Framework Server or Client configuration and the functionality that each may offer..

Top of page

ADO.NET

ADO.NET extends the .NET framework principles to reading and writing to data sources while maintaining much of the legacy API known to programmers as ADO. The programmer using ADO.NET has access to any data source that is networked via HTTP and TCP/IP. Technical details about the data source, transporting the dataset, and programmatically applying the dataset are hidden from the programmer. ADO.NET offers the programmer the tools to produce loosely coupled Web applications through the following features:

•	Disconnected datasets
•	Datasets formatted in XML
•	Data-source-neutral API based on a consumer/provider model

You may add ADO.NET solutions to your environment without risk of causing conflict with other applications on desperate hosts or on the database server itself. If your environment is hosting Windows 2000 servers, the likelihood is that introducing the .NET Framework would be a seamless effort that would introduce little risk of causing legacy software on the host to fail due to changes in MDAC libraries or other Windows DNA system services. Clients can use ADO.NET along with clients that use the legacy ADO on the same network and on the same host.

Top of page

Distributed Interoperation of ADO.NET

The likely scenario in your environment is that all clients accessing a database server will not be using ADO.NET. Upgrading the clients that do not use ADO.NET is not a necessity but rather an option available to your organization. A given database server can be queried by using .NET Framework clients and non-.NET Framework clients. For example, Figure 1 shows a scenario in which a SQL Server 2000 database server supports the following clients:

•	Web server ASP application
•	Desktop application hosted on LAN
•	Batch export program hosted on the database server See full-sized image.

Figure 1 Distributed system of Web server, desktop applications on a LAN, and batch export hosted on database server

In this scenario, your organization would like to update the Web server application to take advantage of the ASP.NET features. As the systems administrator, you need to introduce the .NET Framework to your environment and support it throughout the development phase of the Web server application upgrade. The Web server currently performs data access by using ASP and ADO record sets in a classic two-tier distributed environment. The Web application was developed in-house by your organization, which will perform the subsequent code migration to a .NET solution.

Check the Web server for the minimal dependencies to support the installation of the .NET Framework. In this example, the Web server is running Windows 2000 Server and can therefore host the .NET Framework as a server configuration. If the Web server were running a version of Windows NT 4.0 or Windows 9x, the Web server could not be configured as a server configuration of the .NET Framework without upgrading the operating system to Windows 2000 or XP Professional. The server configuration of the .NET Framework is a minimal requirement to support ASP.NET and the .NET Data Provider for SQL Server. Therefore, establishing the server configuration of the .NET Framework is a requirement to support the desired development effort.

Top of page

IE 5.01 and MSXML Dependency

Another dependency that the Web server must support to host .NET Framework is IE 5.01or later. This requirement in and of itself generally does not cause potential conflict with legacy applications, but the forced upgrades of certain software libraries are affected by the installation of Microsoft Internet Explorer (IE). In our example, however, IE 5.01 shipped with Windows 2000, so installing the .NET Framework will not introduce any need to upgrade other software libraries because it will install if IE 5.01 or later is present on the host. For more information about Microsoft XML Core Services (MSXML) versions and products that shipped the respective versions, please read https://msdn.microsoft.com/library/ms753751(vs.85).aspx.

If you had a Windows NT 4.0 Server that was hosting ASP pages that used the MSXML object, a conflict might arise after upgrading the server to Windows 2000. The upgrade to Windows 2000 will result in the MSXML object being upgraded to MSXML 2.5. The Extensible Style Language (XSL) and Extensible Style Language Transformations (XSLT) parsing have changed between versions of the object so that the XSL and XSLT might fail after the upgrade. To resolve this issue, a development server could be established in the short term to test the ASP code against the later version of MSXML that is being installed on the Web server. The development server should be built to match the software specifications of the production server. After the development server is established, the ASP files may be copied to the development server and tested. If a full regression test of the Web application indicates that there is failure, the ASP files might require extensive reworking to be used on the server hosting the .NET Framework.

One possible fix for the ASP files is to update the ProgID used to specify the MSXML object during XML-to-HTML rendering. The ProgID used in the ASP code to perform the XML-to-HTML rendering may be switched to specify the exact version of MSXML required instead of the general version of the MSXML. If the ASP code required the MSXML2 object, it could be explicitly requested in the ASP by changing the ProgID in a Find-and-Replace search of the ASP files from:

CreateObject("MSXML.DOMDocument")

to:

CreateObject("MSXML2.DOMDocument").

The Web server in our scenario must support ADO.NET because one of the upgrade's requirements is to capitalize on the additional features that .NET Framework affords. As the application in this example uses SQL Server 2000 on the Windows 2000 platform, ADO.NET can impact this solution tremendously. ADO.NET offers a new .NET Data Provider for SQL Server that can access SQL Server by using fewer resources than legacy data access technologies such as ODBC or OLE-DB.

System requirements for supporting ADO.NET should be examined from the client and server perspective. Both types of systems must have the .NET Framework installed, but each type may host different versions of MDAC. Server configurations must have MDAC 2.7 or later installed, whereas client configurations may have MDAC 2.6. Because our requirement demands a server configuration, we must install the latest MDAC on the Web server. Given that the version of the operating system on our Web server is Windows 2000, MDAC 2.6 is the likely version of MDAC hosted on the server.

The most recent release of MDAC is 2.8.1. It can be downloaded from the MSDN Data Access Developer Center at https://www.microsoft.com/downloads/search.aspx?displaylang=en#.

Determining the MDAC Version. Microsoft offers a special tool for determining the MDAC version hosted on any Microsoft operating system. The tool is a software program called MDAC Component Checker and is available as a free download from the Microsoft Web site at https://www.microsoft.com/downloads/search.aspx?displaylang=en#.

The MDAC Component Checker arrives in a self-extracting executable file named cc.exe. Running cc.exe prompts you to choose a location for the files to be copied, and clicking the Unzip button will result in the files being copied to the selected directory. The software does not perform a typical install, so you need to navigate through the sub-directories from where the self-extractor unzipped the files and locate an executable named ComCheck.exe.

After double-clicking ComCheck.exe in File Explorer (or using the Run command window in the Start menu) to start the program, the Component Checker will open. As shown in Figure 2, you will be prompted to choose the analysis type. You can select from the following options.

•	Perform analyses of your machine and automatically determine the release version. (Default)
•	Perform Analyses Against Selected Version (a combination box is provided that lets the user select an MDAC version to validate the machine's current installation configuration of MDAC).
•	Scan your machine. Do not perform analyses. See full-sized image.

Figure 2 Screen capture showing the Component Checker prompting for the analysis type you wish to perform

When you select the desired analysis type and click the OK button with the desired selection, the Component Checker will inspect the DLL versions installed on the host and determine the version of MDAC installed. You will see a pop-up dialog box citing the version your host most closely contains. Figure 3 shows an example of the MDAC Component Checker that has performed an analysis on a given host and determined that MDAC 2.7 is installed.

Figure 3: MDAC Component Checker after performing analysis to determine that MDAC 2.7 is installed
See full-sized image.

After the software dependencies have been met on the Web server, the .NET Framework should be installed. The .NET Framework may be installed from a redistributable version of the .NET Framework. It also ships with Visual Studio.NET, and the .NET Framework does not require a license fee for deployment. For the .NET Framework redistributable download page or the CD order page of the redistributable version of the .NET Framework, please visit Get the .NET Framework 1.1 on this developer center.

After the Web server is hosting the .NET Framework, ASP.NET pages using ADO.NET datasets may be deployed to the same server running a legacy application that consists of ASP pages using ADO with record sets. The database server does not require an upgrade to support the Web server upgrade to the .NET Framework. None of the other clients to the database server will be adversely affected by the Web server upgrade either.

In the case of the desktop client accessing the database, the data access strategy is unknown because the application was purchased from a third-party software vendor. Given the time period of the last upgrade, it is impossible that the application uses ADO.NET or any facilities of the .NET Framework. The likely access mechanism is via an ODBC driver or an OLE-DB provider, however. The goal for the systems administrator is not to upgrade these clients but to ensure that required upgrades to the hosts throughout the LAN do not conflict with their ability to read and write data to the database server. The only risks that could affect these clients being allowed to perform their duty are changes to the database server and changes to the LAN configurations.

Limiting Access to the Database Server. The systems administrator must consider options for securing the LAN environment and access to and from the database. The goal is to prevent unauthorized access to the database server, and one strategy to secure the database server is to use a firewall. The firewall will restrict communication on all network protocols except via specified ports. The firewall can also restrict network access between hosts and specified data types with the communications. In our example, the Web server is the only host that requires public access, so the firewall could be set up to exclude network access to the database from all hosts except the Web server and the LAN workstations.

SQL Server 2000 listens to port 1433 and dynamically establishes a port for communication on the client connection between 1024 and 65335. Named instances of SQL Server 2000 listen to port 1433 and dynamically establish a port for communication on server startup between 1024 and 65335. Due to the wide range of available ports that must be left open for the database server to communicate with clients, it is beneficial to limit the number of open ports that are available to the database server. To learn more about the open ports on SQL Server, please visit https://support.microsoft.com/default.aspx?scid=kb;EN-US;287932&sd=tech

Using a named instance database with ADO.NET can provide an organization the ability to set a port that SQL Server will use for communication. Named instances are distinguished from the default instance because they are identified by <server name>\<instance name>. The database and the client requesting data from the named instance of SQL Server will communicate only on that port. Under these conditions, the firewall can be set to exclude port 1433 and the range 1024 to 65335. Only the desired port needs to be opened in the firewall to allow access between the database server and the clients reading and writing data on that database instance.

You can configure SQL Server 2000 to set a named instance to use a single port by using the SQL Server Network Utility. Figure 4 shows a screen capture of the SQL Server Network Utility. The utility opens to the default instance on the host. The name of the default instance is the name of the server itself. The utility lets an administrator choose the protocols for network communication and the properties for their use. In the case of TCP/IP, the administrator is allowed to set the port number.

Figure 4: SQL Server Network Utility opened to the default instance of SQL Server
See full-sized image.

To set the port value for a named instance on the database server, choose the named instance in the Instance(s) on this server combination box. Highlight the TCP/IP protocol choice in the Enabled protocols list and click the Properties... button. In Figure 5, the named instance AMD1700\NetSDK was chosen for configuration, and the properties dialog box for TCP/IP is opened. SQL Server chose the port 1044 shown in the default port text box automatically at startup. The administrator can now set the port that the SQL Server will use to communicate with clients on for the database instance AMD1700\NetSDK.

Figure 5: TCP/IP properties opened for named instance to set port number
See full-sized image.

The ASP pages in the Web application must also request data from the named instance using the specified port. The connection string used by ADO may cite the chosen port, or the registry on the client machine may be edited by using the SQL Server Client Network Utility. In the connection string, the database parameter must be changed from Data Source=<server name> to Data Source=<server name>,<port number>. It is not likely to find the SQL Server Client Network utility on any host unless the SQL Server client tools were installed on it, such as is the case with a Web server.

If the desktop application in this example supported the ability to configure the database connection via an application administrative setting, then the systems administrator could also lock down access from the internal LAN and set the database network configuration so that access for all clients is through a single port. Using Named Instances in SQL Server requires the client host to have MDAC 2.6 or later installed, however. If it is unknown what the MDAC requirements are for the desktop application or if it is known that they might require the use of a version of MDAC prior to 2.6, the registry may be configured to support a selected default port. To learn more about configuring legacy clients to use named Instances without MDAC 2.6 or later installed, please visit https://support.microsoft.com/default.aspx?scid=kb;EN-US;265808&sd=tech.

Top of page

.NET Remoting

.NET Remoting enables software to consume and be consumed by other software without respect to physical boundary. Prior to .NET Remoting, programmers were restricted to using software hosted on the same computer that the software being produced was hosted on, unless they used Distributed COM (DCOM) and wanted to consume a COM object. Unfortunately, DCOM was a firewall-unfriendly technology and could not function across the Internet reliably. If a systems administrator were placed in the position of managing an environment supporting DCOM, they would need to cripple the firewall rules across the DCOM port range 1024 and 65535 between servers using access to the DCOM component and enable binary communication on that port range..

Distributing software using .NET Remoting places more deployment options in the hands of the systems administrator instead of the technology dictating the decisions to the administrator. The administrator can make decisions about how the software is hosted, secured, and communicates without regard to the functionality of the software in many cases. .NET Remoting offers the administrator greater control over the business-layer deployment in a way that has mostly been dictated by the limitations of object sharing technology of the past.

.NET Remoting is also the preferred technology for bridging the gap for .NET Managed code and unmanaged code to work together. Many organizations support applications that consist of compiled code solutions. The business logic is often encapsulated in DLLs that might be COM objects, static Windows 32-bit libraries, or Windows dynamic linked libraries. Because the .NET Framework produced such a radical change in the Microsoft DNA architecture through the introduction of a managed runtime environment, a mechanism was required to support legacy-compiled code solutions written in languages such as VB and C++. .NET Remoting provides a means for .NET software to use non-.NET software and for non-.NET software to use .NET Software..

For example, you support an organization that built a classic three-tier Web application using ASP files for the presentation logic and COM objects to encapsulate the business logic. Also, the data logic resides in a database. The greatest development expenditure for the application went into the development of the COM objects. The organization is planning to enhance the application by introducing ASP.NET using Web forms and Web services. The existing application consists of IIS hosted on a Windows NT 4.0 Server that hosts the ASP files and the COM objects. The COM objects read and write data to a SQL Server 7.0 database. Figure 6 presents a diagram showing this environment.

Figure 6: Web Server hosted on NT4.0 Server using ADO 2.5 to access a database server
See full-sized image.

The requirements of the .NET Framework prevent the Windows NT 4.0 Server from acting as a .NET Framework server configuration with Windows NT 4.0 as the operating system. Because a .NET Framework server configuration of the host is a requirement to support ASP.NET and ADO.NET, a Windows NT 4.0 Server hosting the .NET Framework cannot host applications that require the use of ASP.NET or ADO.NET. The only possible option available for installing the .NET Framework on the Windows NT 4.0 Server without upgrading the operating system to Windows 2000 or Windows XP is to set up the Windows NT 4.0 Server as a .NET Framework client configuration.

A third server may be introduced into the solution to host the Web server applications built on ASP.NET. The Windows NT 4.0 server can act as an application server to the ASP.NET applications hosted on the Windows 2000 Server. The Web Forms and the Web Services created on the Web server can consume the functionality encapsulated in the COM objects on the Windows NT 4.0 server by using .NET Remoting and Simple Object Access Protocol (SOAP) while it continues to function as it was previously serving Web pages. Figure 7 shows a diagram of a distributed solution using the Windows NT 4.0 server as an application server.

Figure 7: Using the Windows NT 4.0 Server as an application server and introducing ASP.NET applications
See full-sized image.

To make the Windows NT 4.0 server function as an application server so that .NET Remoting can let other .NET applications consume the COM objects it hosts, the .NET Framework must be installed on the Windows NT 4.0 server. To get the .NET Framework installed on the Windows NT 4.0 server, MDAC 2.6 and IE 5.01 or later must be installed. Upgrading to MDAC 2.6 will not cause the Web application to fail because the ASP Web application did not use or rely on the OLE-DB interfaces of MDAC 2.5. In this example, the legacy application did not use the MSXML object, so upgrading IE to version 5.01 would not effect the existing ASP application. If a version of IE were discovered on the server that was earlier than IE 5.01, and the Web application used XSL or XSLT to render HTML pages from XML, upgrading IE to version 5.01 or later will change the MSXML version installed. Upgrading MSXML might cause the Web application to fail on any parts of the application that convert XML to HTML via XSL or XSLT. The development staff will need to change the XSL or XSLT code to support the latest XSLT standard. For more information about MSXML versions and products that shipped the respective versions, please read https://msdn.microsoft.com/library/ms753751(vs.85).aspx.

After the Windows NT 4.0 server is updated with the .NET Framework, the .NET Remoting on the hosting server must be configured to publish the objects so that Web applications hosted on the Windows 2000 Web server can consume them. Configuring may be performed by using a programmatic solution or by editing the respective application configuration file or the machine configuration file.

After the objects are configured on the Windows NT 4.0 server, the systems administrator can use the .NET Framework Configuration tool to alter the .NET Remoting settings for the server. The .NET Framework Configuration tool is a Microsoft Management Console (MMC) plug-in that allows systems administrators easy access to change certain .NET Framework settings. Under .NET Remoting Services, the tool has settings that let the systems administrator change the type of .NET Remoting communication channels being used and their properties. Figure 8 shows a screen capture of the tool with the channels property page open.

Figure 8: .NET Framework Configuration Tool with the .NET Remoting Channels Property page open
See full-sized image.

As the solution for this example uses SOAP and XML, the HTTP Channel must be utilized. If the servers were hosted in the same physical location or if a firewall does not exist between the Windows NT 4.0 Server and the Windows 2000 Web server, adopting the TCP Channel might offer a better solution if performance becomes a problem when you use the HTTP Channel. The TCP Channel lets binary communications exist between consumers and providers, thereby offering better performance. Default firewall rules often exclude non-displayable characters from passing, and because binary datagrams consist of non-text characters, the firewall might exclude the use of the TCP Channel. The HTTP Channel is a better solution when firewall rules might affect communication between the providers and the consumers.

Top of page

ASP.NET

ASP.NET applications can run on a given Web server along with ASP and COM applications. A common task that an organization might perform is to migrate ASP.NET applications into existing solutions that involve legacy technologies. Because the filename extensions of ASP.NET applications are different than the legacy file extensions that have classically been in place on an IIS Web server, running ASP files and ASPX files side by side is not a problem. After the .NET Framework is installed on Web server in the .NET Framework server configuration, aspx files may be deployed and run under the .NET Framework along side the asp pages.

Top of page

ASP.NET Configuration

ASP.NET uses an Internet Server API (ISAPI) extension mapped to a file extension to establish which files may be processed by the .NET Framework. IIS uses the same mechanism to associate .asp files to the ASP processing software housed in ASP.DLL. The applet is accessed from the Configuration... button on the Home Directory tab of the IIS property page for any given Web site instance or for the WWW Services Master. Figure 9 depicts a screen capture showing the IIS applet for Application Configuration.

Figure 9: Application Configuration applet showing aspx files mapped to aspnet_isapi.dll and asp files mapped to asp.dll
See full-sized image.

IIS also applies configurations to an ASP.NET Web application separately from a legacy ASP application. One of ASP.NET's great benefits is that it provides a greater level of granularity to control the ASP.NET Web application. The IIS properties applet may still be used to configure a Web site hosting an ASP.NET Web application globally, but a new mechanism is available via the Web.config file. The Web.config file is an XML file that is always found in the directory that ASP.NET code files are stored. Table 2 provides a summary of the Web.config elements and their purpose.

Element Name

Purpose

 

compilation

 

To establish default language used in the ASP.NET application and whether debug information should be maintained on compilation.

 

customErrors

 

To turn on the ability to return custom error messages or enable them only on the host server.

 

authentication

 

To establish authentication policies at the current directory and all subordinate directories thereafter unless otherwise specified in the subordinate directories.

Provides similar functionality as the Authentication Methods applet from the Directory Security tab in the IIS Property page.

 

trace

 

Determines if application debugging data should be logged or made available to developers or systems administrators and defines the output formats.

 

sessionState

 

Sets the means whereby the server may maintain the session. Configurations enable session tracking to occur by using cookies or URL session identifiers or via a session server.

 

globalization

 

Sets the globalization setting used by the server for text transmission.

Table 2 Elements within Web.config and Their Purposes

The benefit of the Web.config file for systems administrators is that they do not need to manually perform IIS configurations instructions to deploy a Web application. Deploying the Web.config file for a respective Web application to the production environment will deploy the configuration settings. The Web.config file may be reviewed to determine adherence to production environment policies, but other alternatives require less effort on the systems administrator's part, such as manually configuring the server for the deployment or running a configuration script.

Web sites can host both ASP.NET and traditional ASP and HTML solutions with minimal configuration conflict. A better way to understand the issue is to examine it in terms of the scope ASP.NET has verses the scope of IIS. In general, ASP.NET could be thought of as an enhancement to IIS; therefore, ASP.NET subordinates to IIS. Figure 10 shows a diagram demonstrating the order of configuration precedence. The configurations of IIS relate to the Web server, so those settings have a global context. They apply to all files subject to HTTP requests that occur through IIS. The configurations of the Web.config file apply to all files that are mapped to aspnet_isapi.dll in IIS. In the cases of conflict of configuration, the stricter policy is adhered, and it is applied only over the scope of application.

Figure 10: Diagram summarizing the order of configuration precedence among IIS configurations and ASP.NET configurations
See full-sized image.

For example, in the Web root of a Web server hosting the .NET Framework, there are three files that exist with the following file extensions:

html

asp

aspx

Using the Web.config file and the IIS Authentication Methods from the Web server properties page, an administrator can establish access control or roles for an end-user requesting IIS files. Setting the IIS Authentication Methods from the Web server properties page to not Allow Anonymous Access and support Integrated Windows Authentication will prompt the user for a login and password on the first request for any file (asp, html, or aspx) from IIS using a Web browser. All subsequent requests will be performed under the credentials supplied by the user.

If the Web.config file is placed in the Web root with the mode attribute of the authentication element set to "Windows," IIS will respond the same way and prompt the user for a login and password on the first request for the aspx file from IIS. The following XML shows an example of a Web.config file that will achieve the same access control behavior from IIS for ASP.NET files as setting the IIS Authentication Methods from the Web server properties page to not Allow Anonymous Access and support Integrated Windows Authentication for the same respective subdirectory in which the Web.config file would have been placed.

<configuration>

<system.web>

<authentication mode="Windows" /> .

</system.web>

</configuration>

If the Web.config file were set for anonymous access by setting the mode attribute of the authentication element set to "None" and IIS were still set to restrict users who authenticated, IIS would still prompt the user for their login and password the first time for either aspx files or HTML files. Because the IIS Web server property-page configurations were stricter and have a global scope over the Web-server instance, they took precedence over the Web.config settings.

Interoperation has often posed challenges to systems administrators by limiting their ability to perform server maintenance with grace. The .NET Framework represents a culmination of design and engineering that has resulted a product that empowers the systems administrator to manage a heterogeneous server environment. Legacy solutions and .NET applications can function on the same physical host without conflict and offer systems administrators greater control over the deployment and support of the solution. The systems administrator has more tools to apply a greater level of granularity around the security of a Web application and management of software deployment.