Designing a Web application is easy, right? Not always. In this day and age, with all of the “Web-ready” options available, making design decisions can be downright confusing. Different technologies and products behave differently and live in entirely different worlds. Unfortunately, as a technologist, you may have some concerns that are turned 180 degrees away from your clients’ interests. You think of such things as resources and development platforms. Your client dreams in terms of bottom-line and new business. So, what do you do? If time and cost are factors, your natural answer is to turn to IIS and ASP, together with COM components, to build a scaleable, maintainable application.

What are these acronyms, you ask? It is a valid question. IIS, or Internet Information Server, is the Microsoft Web server that runs on Windows NT. ASP (Active Server Pages) are files that are interpreted on the Web server using either VBScript or JavaScript. Finally, COM (Component Object Model) components are run-time libraries (or DLLs) that are accessed on the server by the calling application in order to support functionality; they are not implemented by either your ASP pages or HTML interface.

We may have decided what the acronyms mean, but deciding and doing anything with that decision are two totally different things. Although you may “believe” that this architecture is a good fit for the project at hand, there are some basic design considerations you must think about first. In this Daily Drill Down, we’ll examine some of those considerations and take a look at how you can make better design decisions. In addition, we’ll describe an example of such an application and review some of the details surrounding the implementation of this type of system.

Necessary infrastructure
Prior to assessing this type of design for your application, you must become aware of the infrastructure necessary to implement this solution. Listed below are the basic server requirements. Your project may require a relational database, such as SQL Server. If it does, please adjust the specifications accordingly. Depending on the scale of the application, hardware requirements will vary.

  • Windows NT Server 4.0 (with Service Pack 4 or later)
  • Windows NT 4.0 Server Option Pack (IIS 4.0)

The design phase
A large-scale project will always require a great deal of analysis prior to beginning the design phase. The analysis phase of the project should provide the details that are necessary for the designers to accomplish the task of laying the foundation for the application. By foundation, I mean deciding on such issues as the application platform, the language(s), and the components that may be necessary for encapsulating any logic requiring compilation.

In the case of platform, the decision is usually predetermined. If the environment you’re working in has more than one supported infrastructure in place, you’ll want to weigh your options. For example, if you’re primarily working in a Windows NT shop, the chances of finding qualified VB developers and IIS support is likely. Both support and a strong understanding of the development environment will play major roles in implementing a successful application.

Understanding the application deployment requirements will also assist in driving you toward either a distributed solution (such as IIS) or possibly a client-server implementation (which is growing more and more unlikely). If these qualifiers lead to “yes” (especially “NT supported” and “a good candidate for a distributed architecture”), you’re well on your way to an IIS solution.

Once the IIS decision is complete, the next hurdle is architecture. How complex are your client’s requirements? Is the data static or dynamic? These questions are important, and they will point us to our solution. In order to get there, let’s first dissect the “logic.”

COMponents
Business logic—or the illusive “middle tier,” as it is sometimes referred to—is a tricky architectural component to comprehend. You really have to understand exactly what you’re tasked with and, ultimately, what your long-term support and maintenance effort will be. If the application you’re assembling requires complex calculations and, possibly, data access, you’re most likely going to want some control over speed and maintainability. On the other hand, if the scope of the project lends itself to very little processing, there may not be an urgent need to salvage resources and segment tasks.

These issues are common design questions that arise when you start considering the use of components in your architecture. You will most certainly wish to understand what is involved in creating such programs. COM components are often referred to as ActiveX DLLs. If you’re familiar with the Windows file system, you’re aware of the Dynamic Link Libraries (or DLLs) that make up the operating system. These DLLs are programs that execute within the calling application’s memory space. One of the major benefits of creating and using COM components is the speed gained by calling a compiled application. This makes COM components perfect candidates for IIS applications, where resources are at a premium.

Move to the front of the line…
When you choose to use components within the architecture of your application, you must be prepared to use an interface design tool that can access them. A natural progression is the use of ASP, which exposes the Server.CreateObject method. This method allows the calling application to create an instance of your COM components on the Web server. This structure provides the distributed architecture that your requirements have dictated.

It’s important to reiterate that we’re using “in-process” components. The term in-process component refers to an application that’s running in the same memory space as the calling program. It makes the configuration of the IIS application very important. IIS allows an application to run in its own memory space, restricting application administration to the site level. For example, in prior versions of IIS, if a process ran amok, the possibility existed that the entire server might come crashing to a stop. Utilizing this feature, the administrator has the ability to stop the Web service just on the site and not on the entire server.

Why is this feature important to consider during the interface design of the application? When calling the component via ASP—if you’ve created an “out-of-process” application—you’d probably receive an error for attempting to create an instance of an executable file. This default mechanism of the Web server attempts to maintain security.

The implementation
To illustrate the use of this technology, we will use an example. To begin with, our test case is riddled with complications. We have a series of external clients; internally, we have a number of different machine configurations; and our server environment consists of a single Windows NT file server. The project assessment is complete, and to complicate matters further, a complex customer application process is involved.

First, let’s think about the platform. What are our distribution requirements? We’re dealing with a number of different machine configurations and an external client base. Deployment issues and connectivity are paramount.

Windows NT is currently being used to manage the existing file server. In addition to support and knowledge considerations, NT security may be used to manage your application better. These criteria make an IIS application an easy recommendation.

The “logic”
We now have a platform to begin our application design. During our assessment phase, we learned of our client’s “complex” client application process. We’ve reviewed the specifics of this process and understand that it means a number of data validation points, including repetitive calculations.

We know that ASP provides the ability to perform data access, and we could probably use VBScript to perform the calculations necessary for the process. However, multiple clients at varying points within the system will use the application process. In an effort to consolidate functionality and manage our resources, we will create a COM component to handle this task.

Simply creating this component will not be enough to use it within our application. We must register it, too. Registering an application makes the server physically aware of the program. When using a tool such as Visual Basic (or any other Visual Studio 6.0 application), you can complete the registration with the Package And Deployment Wizard. The wizard walks you through the necessary steps to install and register this component on your Web server.

When the registration is complete, we can move on to our interface design.

The presentation layer
Using our example, we have put our infrastructure in place, encapsulated our business logic in a COM component, and designed our front-end with ASP. Our server is aware of the component, and we can implement it with a simple ASP call. Now we have a completely distributed Web application.

Joe Barnes is a senior project manager for Fundamental Objects, Inc., where he works with large-scale infrastructure and software development projects. His specialties include Windows NT, Visual Basic, and Lotus Notes. If you’d like to contact Joe, send him an e-mail .

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.