Web Services in an Intranet Environment

Last month’s issue gave a broad overview of some of the ways Web services will alter application architecture. This article will take a more detailed look at how Web services can be used in an intranet environment, specifically focusing on application deployment and support.

When .NET was first introduced, it was touted as a significant upgrade to the existing set of Microsoft development tools; one that allowed not only for rapid software development but easier maintenance. It marked the end of “dll hell”. Unfortunately, almost two years later, a number of IT managers still don’t understand how (or if) this affects their applications. Perhaps the best way to illustrate this concept is by examining an existing intranet application (based on ASP and VB6 software) and how it might be altered to take advantage of Web services.

Current Environment:

(1) A web-based client interface that uses standard 3-tier architecture (ASP page in the presentation tier; VB6 dll in the business tier; SQL Server database in the data tier). The ASP page authenticates the user using Windows Authentication. The dll authorizes a data request against Active Directory, queries the database and returns XML.

(2) A windows-based administration tool that uses the same 3-tier architecture (VB6 executable in the presentation tier; the same dll and database in the other tiers).

Current Deployment Plan (when the application software is ready to be installed)

On the Web Server
     1. Register the business logic dll
     2. Create a virtual directory containing the ASP page

For each Administrator machine
     1. Register the business logic dll
     2. Copy the executable and related files to a desktop folder

Current Maintenance Plan (when the application software is updated)

On the Web Server
     1. Stop the IIS service (this disables all web applications on the server)
     2. Unregister the old business logic dll
     3. Register the new business logic dll
     4. Restart the IIS service

For each Administrator machine
     1. Unregister the old business logic dll
     2. Register the new business logic dll
     3. Copy the new executable (that was compiled with the new dll)

What are the Maintenance Challenges?
  • Necessity of stopping the web server for every dll change
  • Coordinating the version of the dll on the server and desktops
  • Coordinating the version of the dll on the desktops with the version that the executable was last compiled with. This is “dll hell”! If the version of the dll is updated without first recompiling the executable the administrator tool will stop working. It is the responsibility of the developer to maintain this version synchronization.

Where do Web services fit?

The middle tier dll can be replaced with a Web service that performs the same functionality by doing the same authorization checks, database queries and returning the same XML. The ASP page will communicate with the Web service via a standard HTTP request so presentation side alterations will be minimal. In effect, the business logic has been replicated while eliminating the version synchronization issues.

What are the benefits of using a Web service?
  • A new version of the dll no longer needs to be created
  • The web server does not need to be stopped to implement changes
  • The desktop executables do not need to be recompiled… “dll hell” is gone!
  • Data is available via an HTTP request and is more easily shared

This article proposes a way to integrate web services in an existing intranet environment to facilitate ASP/VB6 application support. With .NET, Microsoft has added new robust mechanisms for dll versioning to deal directly with “dll hell”. That is, building the application above with .NET wouldn’t require a Web service (but it could be used). While the power of Web services will always reside in their ability to facilitate data communication between disparate sources they also have substantial value in internal IT environments.