Building Web Applications Using Active Server Components

Home Products Support Corporate

Support Knowledge Base, Article 664

Product

General

Title

Building Web Applications Using Active Server Components - David Wihl

Solution

Building Web Applications Using
Active Server Components

By David Wihl

The combination of a browser and server-based web applications are in the process of subsuming all other forms of client/server programming. While much is made of HTML and pretty web pages, the real power of the web is the programmability of the server. The Common Gateway Interface or CGI, an often derided hack, has laid the seed for the web to come alive. If HTTP allowed only static pages, the web would not be the influence it is today. Indeed, it is the programmability of the server coupled with a friendly face that has made it possible for HTTP to replace previously popular protocols such as gopher, archie and telnet. It is only a matter of time for FTP.

Microsoft understood early about the need to radically improve programmability of the server. Even in Version 1 of Internet Information Server (IIS), Microsoft Web server product, there was a high-performance Application Programming Interface called ISAPI. ISAPI is often associated with Microsoft but in fact, it was developed by Process Software and is used by a number of different web servers. While ISAPI allowed high performance server-side applications, it was not easy for mere mortals to use.

Version 3 of IIS introduced Active Server Pages. ASP was a radical leap of power, programmability and extensibility that allowed server-side applications to be written and maintained by a much broader base of programmer.

ASP is composed of four layers as seen the in the following diagram. [diagram 1]. Each ASP page consists of standard HTML and server-side script. Server-side script is meant for interpretation and processing on the server before transmission to the browser. The script can add or change the contents of the resultant page before the browser receives it. In fact, the browser is completely unaware that any server-side processing was performed. From the browser's perspective, the processed result is indistinguishable from a static web page.

ASP is entirely independent of the browser. In fact, a given ASP page can determine the type of browser, and dynamically change the contents of the resultant page for optimal viewing on different browsers.

The concept of server-side scripting is not unique to ASP. Netscape has Livewire and several other vendors have specialized solutions using embedded tags. ASP is particularly powerful in the below aspects.

Interspersed HTML and script rather than separate files. By combining server-side script and HTML in the same page, it becomes easy to incrementally add scripting to existing static pages. A web designer can create mock-ups of the final look and feel of the web application. It’s then one step to renaming the file extension from .HTM to .ASP and add server-side script where appropriate.

Compile and Cache on Demand. There is no explicit compilation required of an ASP page. Whenever ASP detects that changes have been made to the page, it will release memory containing the current compiled page, load the newly modified page, compile it, and save the resultant compilation in memory. This make it very easy to iterate through designs.

Highly Functional Intrinsic Objects. ASP supplies six intrinsic objects that encapsulate many of the low level details that CGI and ISAPI programmers typically must deal with. The Request object contains the browser's request, including parsed form and query string data, cookies, etc. The Response object contains everything to be returned to the browser: new HTML, HTTP headers, PICS (content rating). It is even possible to transfer binary data to and from the browser or a Java applet executing within the browser. The Session object allows the ASP developer to maintain state across the page invocations of a particular user. The Application object allows sharing of data across multiple users who are accessing a given virtual root. The Server object gets and sets properties associated with the web server itself, such as the amount of time a given script is allowed to execute before ASP will cancel it. Finally, IIS Version 4 includes an ObjectContext object for participation in page-level transactions.

Interactive Debugging. This feature is also new for IIS Version 4. It allows the developer to debug scripts that are executing on the server as well as on the browser. Common debugger functions, such as breakpoints and examining data values, are easy.

Transacted Pages. A given ASP page may create a transaction context whereby all participating components may commit or rollback all actions performed within the page. Transactions are typically associated with database activity, and while database transactions can certainly participate, the innovation comes from allowing any component to participate in the transaction. For example, a given page may log an action in a database as well as send a message via Microsoft Message Queue. If the database write fails for some reason, then the entire transaction will be rolled back and the message will not be sent.

Server-side Components

ASP permits the notion of Server-side components or Active Server Components (ASC). Active Server Components permit the encapsulation of functionality into a packaged, binary, re-usable object. ASP’s use of Server-side components is its most powerful feature.

ASC’s have enormous benefit to anyone building web applications. We all know the advantages of component software: re-use, ease of maintenance, encapsulation of functionality. In IIS, Microsoft has brought the power and flexibility of COM to developers of web applications.

Re-use, Re-use, Re-use. ASC’s can be re-used in multiple applications or in multiple modules of the same application. If server-side scripting were used exclusively, there would quickly be a code maintenance nightmare as snippets of script are cut and pasted between ASP pages.

By defining a binary standard for components, Microsoft has also let blossom an after-market for hundreds of third-party components. No other web server has such an extensive collection of ready to use components from Independent Software Vendors.

Separation of Form and Function. Encapsulating functionality into a component clearly delineates form and function.

Functionality. An ASC can access the complete WIN32 API. A script cannot access operating system functions directly. It must pass through the intermediary of components. Any ASC can access the full richness of the WIN32 API and expose these functions through properties and methods of the component. For example, there are currently components on the market that allow addition or deletion of NT user accounts or sending e-mail via an ASP page.

Scalability. When a script is executed, the results are sent to the browser and execution completes. There is no way by scripting alone to create service processes or worker threads. A component has considerable flexibility to process functions even when a page is not being executed. It is possible for a component, coupled with an NT service, to perform tasks in the background. This means a quicker response to the user and greater potential scalability of the web application. More sophisticated components can be designed to off-load processing to other servers rather burdening the web server alone.

Categories of Active Server Components

Line of Business Components. Line of Business components contain the essential functionality of a web application. Typical examples include shopping carts, order processing, insurance policy processing. A well-designed Line of Business component does not have any user interface functions – it only encapsulates business rules and functions.

Utility Components. Utility components are used to access WIN32 or other functions from within a script or another component. Typical examples include sending e-mail, accessing files, reading or writing the system registry, or logging critical events to the Event Log. Utility components are highly re-useable between applications. This is also where the greatest variety of third-party components exist.

Data Components. Unlike business components which implement business rules, Data Components are useful to share data between multiple clients. Clients are not necessarily all web-based. A Data Component might be re-useable both with an ASP page as well as within a classic client/server Visual Basic application.

Presentation Components. Presentation Components interact with the user, typically by internally using the ASP intrinsic Request and Response objects. Unlike the other categories, Presentation Components are specific to ASP and cannot be re-used in other environments. For example, a component that took as input a result set from another component and displayed it using a specific HTML table definition would be a Presentation Component. By re-using this same component in multiple applications, there would be a consistent look and feel to the applications. Another example would be a graphics server that would dynamically generate JPEG files for display on the browser.

Characteristics of a Component

A component must support Automation (formerly known as OLE Automation) in order to be invoked from an ASP script. Automation is the key technique that allows a script to bind to specific functions of the component at run-time and share variables of differing types. If a component does not support Automation, it cannot be used directly from ASP script. However, it is still possible for another component to use the non-Automation interfaces.

Since the component is running in the context of the web server, performance is critical. Virtually all ASC’s are in-proc, which means that they execute within the same process as IIS, and are packaged as DLL files rather EXE files. In-proc execution can improve overhead for method invocations by as much as one-thousand fold!

Any ASC can access all of the same intrinsic objects that ASP makes available to the script: Request, Response, Session, Application, Server and ObjectContext. However, by using the intrinsic objects, the ASC can only be used within ASP. It cannot be used with Visual Basic or any other environment. It is possible to design components that can be used within both ASP and non-ASP environments. Indeed, most Line of Business components should be designed this way. Accessing the ASP intrinsic objects should be confined to Presentation Components.

A component can also decide appropriate behavior at run-time. If the ASP intrinsic objects are not available, the component can function in a degraded state rather than aborting.

And finally, an ASC can elect to participate in transacted web pages. The ASC then gets a chance to vote whether a given transaction should be committed and allowed to complete successfully, or should be aborted and completely rolled-back.

Specifics of the ASP Context

IIS is a high-performance web server. Microsoft has spent a lot of time optimizing IIS for large server loads in production environments. This has a downstream effect of placing new burdens on the component developer that do not exist in the simple world of single-threaded, classic GUI environments.

Many existing third-party ActiveX controls, components and libraries were not designed to work in the demanding multi-threaded environment of the web server. The component may still function, but if it does not correctly support the IIS threading models, overall web server performance could be significantly compromised.

If you are intending to develop components that can be used both within ASP as well as other environments such as Visual Basic, I recommend you start with ASP. The IIS/ASP environment will force you to examine and understand threading and security issues that are often neglected in non-ASP components. Adding supports for these items later on can be much more expensive. Any ASC that does not use the intrinsic ASP objects will function very well in a non-ASP environment.

ASC have no graphical user interface. This means that it is not appropriate, and usually not even possible to display a message box when an error has occurred. It also means that there is no a windows message queue. Any user interaction must be performed using the Request and Response objects. Like other NT Services, all errors should be reported to the system Event Log.

For performance reasons, IIS/ASP extends COM’s threading model. The IIS threading model has a significant impact on performance of the web server, the security context of the component and the component’s ability to support transactions. While a complete discussion of IIS threading is beyond the scope of this article, we can offer some salient points.

Threading Impact

COM defines four threading models: Single, Apartment, Free, and Both.

If an ASP page is invoking a component that is in a different threading context than the page, COM will have to intervene in order to resolve this difference. When COM intervenes, it is called marshalling, whereby COM packages the method invocation such that it is possible cross boundaries. Marshalling is an expensive operation and is to be avoided in the case of an ASC.

Single refers to main line of execution of a process. Every process has at least one thread. Components that use the Single threading model will only execute on the main thread of the process. This means that all execution within the component will be sequential. If there are multiple single threaded components on a particular web server, then all of these components will execute sequentially, even if they exist in different web applications. One user calling up an ASP page that uses single threaded components can block many other concurrent users. Except for the most simple of web sites, this is unacceptable performance. No ASC should ever use the single threading model.

Apartment allows multiple threads, but execution within a specific instance of a component is sequential. Let’s say a user calls up a specific ASP page that creates an ASC. All of the methods call to that ASC on that page will be sequential. At the same time, another user calls up the same page. A second instance of the component will be created. The two different instances can execute in parallel on separate threads. COM will guarantee that method calls are sequential within a specific instance, and allow multiple instances in different threads.

The Apartment model is an example where IIS extends the COM threading model. COM’s formal rules specify that if a component uses the Apartment model, the component will be created on a single thread, have all method calls on that same thread, and terminate on that same thread. If IIS were to implement this, it would have to maintain hundreds of threads on a moderately loaded server. Instead, IIS uses a thread pool. For the component, there are important ramifications. It means that the component is no longer guaranteed to be created on the same thread where method invocations will occur. This restricts options available to the component: it cannot use thread-local storage, and it cannot create other components in a different apartment using standard COM API calls. Creating components in a different apartment means that COM will create a proxy to marshal calls across apartment boundaries. This proxy exists in thread-local storage which may disappear between method calls, causing calls to the sub-component to fail. Instead, ASP provides a helper method in the Server object to create sub-components which avoids this problem.

Free threading allow a component to receive method calls concurrently from many threads. All synchronization must be handled internally to the component.

"Both" means that a component supports both the apartment and free threading models and is equally adept in either context. This is the preferred model for use within ASP since it avoids marshalling in all possible ASP contexts.

Threading and Security

IIS uses a standard technique of NT Services called Impersonation. Impersonation allows a server process to behave in the security context of a client. When the server is impersonating the client, the server has exactly the same permissions and access to resources as if it was the user himself.

If no authentication is used for a given web application, IIS uses a default security context call anonymous. The anonymous user is mapped to a pre-defined local NT account called IUSR_<machinename>, where <machinename> is the name of the server running IIS. All anonymous page requests will be executed in the security context of IUSR_<machinename>.

When a user requests a given ASP page that requires authentication, IIS will create the correct security context so that any script or component method calls on that page will be executed as the impersonated user. For example, any component that accesses files on the web server will be restricted by the permissions of the user requesting the page.

However, when an ASC is using an incorrect threading model, the IIS-supplied security context will be lost during the method invocation. When the security context is lost, the default reverts to the NT LocalSystem account, which is a very powerful account on the local machine, but has no network access privileges whatsoever.

Any component that uses the single or free models will lose the security context. Also, any component that is out-of-proc (i.e. an EXE, not a DLL), will also lose the security context. Only components that use the apartment or both models will preserve the correct IIS-supplied security context.

Transaction Support

IIS 4 offers an entirely new innovation for web servers: the notion of transacted web pages. IIS 4 integrates Microsoft’s Transaction Server as a native facility available to developers building web applications.

When a user requests a page, a special directive at the top of the page tells IIS to create a transaction context for the duration of the page execution.

Every ASC that is called within the page can elect to participate in the transaction. Each ASC performs any methods asked of it. If everything is successful, the component votes to commit the transaction. If there was a failure, the component votes to abort the transaction. A single abort vote will cause the entire transaction to rollback. Every participating component must place a vote.

The script is notified by an event that the transaction committed or rolled-back. The script can then send an appropriate message to the user.

Language Choices

ASC can be written in any language that supports COM and Automation. This includes common Microsoft languages such as Visual Basic, Visual C++, Visual J++ as well as many others.

Visual Basic is a popular language for development of Line of Business applications. It is powerful and easy to use. Visual Basic Version 5.0 components are single-threaded by default. Starting with Visual Studio Service Pack 2, Visual Basic has been updated to allow creation of components that are apartment-model. Any ASC developed used Visual Basic should ensure that the apartment model is enabled.

Visual C++ can create high performance components that use any threading model. It also offers the greatest flexibility in accessing system services and APIs. Visual C++ is the language of choice for ultimate performance and flexibility at the expense of highest development cost.

Java, or more specifically the Visual J++ variant, can create high performance components that use any threading model. It is not as flexible as C++ in accessing system services and APIs, but can be easier to use, especially with regards to pointer manipulation. Starting with IIS 4, there are a series of helper Java classes to ease the burden of development, and most of the sample ASC supplied by Microsoft are written in Java. There is also a third-party tool that allows execution of standard Java servlets as ASCs.

For most rapid development time, use Visual Basic. For highest performance and flexibility use Visual C++. The best overall compromise, assuming you are not already strongly committed to Visual Basic or C++, is Visual J++.

Conclusion

Active Server Pages, with a combination of server-side scripts, components and transacted-pages, is a very compelling and powerful environment for building web applications.

Any non-trivial web application should be built on a solid foundation of Active Server Components. Active Server Components promote re-use of functionality and allow scalability beyond scripting. A dynamic and growing third-party market for Active Server Components provides "off-the-shelf" components for many common utility functions.