ActiveX documents as GIS Web Client Applications

ActiveX documents as GIS Web Client Applications

Craig McAdie
Smallworld Systems Ltd.
1140 West Pender Street, Suite 710
Vancouver, BC
Canada V6E 4G1

Abstract
The increasingly prominent role of Web-based client/server systems means that users expect these applications to deliver more functionality. Typically, client applications are implemented as either an active server page or as a stand-alone executable.

ActiveX documents combine the advantages of an application developed in Visual Basic with the ability to access the features of the Internet Explorer web browser. This paper addresses and discusses the deployment of ActiveX documents as web client applications.

The Client Application Tier of Web Based Applications
Three tier web-based systems have become a common mechanism for making GIS data accessible to end-users across local Intranets and the Internet. When designed and deployed correctly, these systems provide the scalability and versatility required to deliver this data to a large number of end users quickly and efficiently. As the name implies, these systems are divided into three levels, or tiers:

A data tier that contains the common datastores.
A web, or business, tier that provides the business logic components and the communication mechanism that performs the process of transferring data across the network.
A client tier that consists of the applications that are deployed to the end users and which allows them to request, view and process the data.

The data tier resides on the server; the web tier components can reside either on the server or on client workstations. Client applications may be loaded from the server, but are generally executed on the workstations of the end users. This paper focuses on the client tier and the options that are available for developing and deploying web client applications.

The underlying architecture of three-tier web based systems, and more specifically the separation of the client application tier from the business and data tiers, allows for a range of client applications to be designed and implemented to meet specific end user requirements. Currently, the two types of client applications that are deployed most commonly are that based on the standard web page and the stand-alone executable.

Because both types of client applications have distinct advantages and disadvantages, the decision to proceed with a specific option will depend ultimately on the requirements of those who will ultimately use the application and the corporate environment in which the application is to be deployed. If the functional and user interface requirements are not complex, and the ability to deploy the application quickly and efficiently from the server is a priority, then an extremely thin web page client may be preferable. If there are a number of different categories of end users which have different requirements, then it may be desirable to deploy a stand-alone executable to those users who require a richer feature set, along with a web page application to the other users.

The Web Page based Application
The web page based application consists of a user interface, which is usually defined using HTML, and supporting application code, which is usually written in a scripting language such as JavaScript or VBScript. This type of application may also incorporate custom or third party components, such as ActiveX controls and Java applets, which implement specific features that cannot be delivered with the standard scripting languages.

The underlying application is usually very thin. Application code is implemented primarily to provide a means of requesting data from the server and to provide some degree of interaction between the web page’s user interface elements: most of the actual data processing occurs at the server.

The primary advantages of deploying a web page based solution are:

Ease of installation. With some exceptions, the application is made available by directing an end user to the application’s web page, which is usually placed on the server. If they are not too complex, additional components on which the application depends may be downloaded automatically and registered on the client workstation when the web page is first loaded.
Platform and browser independence. Theoretically, if the application’s layout is defined using standard HTML and the application code is written with care in JavaScript, the application should be accessible by all users, regardless of the web browser they will use or the operating system on which the application will be executed.
The application can take advantage of the features offered by the web browser, such as navigation and the ability to display multiple web pages in frames.
Application enhancements or fixes can usually be made to the application’s source code at the server; there is no need to redistribute the application to the end users.

The primary disadvantages of deploying a web page based solution are:

" Using HTML to design a user interface with a precise or complex layout is much more difficult.
The use of scripting languages imposes constraints both in terms of performance and the feature set that can be supported by the application; scripting languages do not provide access to features and functionality supported by an underlying operating system. While it is feasible to add specific features and take advantage of functionality supported by the underlying operating system using ActiveX controls and other components, this will usually defeat the goal of platform independence. As well, the automatic download process provided by web browsers such as Microsoft’s Internet Explorer may fail to download and register more complicated components correctly on a user’s workstation.
Implementing a mechanism that allows web pages to communicate is extremely difficult; consequently, the primary user interface of most web page based applications must be provided on a single page.

The stand-alone executable
A stand-alone executable application is developed in a language such as Java or Visual Basic (VB) and must be installed separately on the workstations of the end users. This type of client application is implemented for those cases where the client application must support a richer feature set; this can be a result of a need to reduce the load on, or to provide functionality that can not be provided effectively by, the server.

The primary advantages of deploying a standalone executable are:

Integrated development environments (IDEs), such as those provided with Microsoft’s Visual Studio, can result in a faster development process, along with the capability of defining a more precise and complex user interface layout.
Because the application code is compiled, the performance of the application is usually better.
The ability to take advantage of functionality supported by the underlying operating system. This can result in a much richer client application that provides the user with more features and which can assist in offloading the server.
Installation of the application and its dependent files can be performed in a single, controlled process. This type of installation process is preferable in those cases where the ability to download components across a network is restricted either by an organization’s internal policies or by technical limitations to the web browser’s ability to perform the download process reliably.

The primary disadvantages of deploying a standalone executable as a web client application are:

The executable must be installed separately on the workstation of each end user.
The application must be re-deployed and reinstalled each time it is enhanced, fixed, or changed in any way.
The client application is almost always platform dependent.

A third option: ActiveX® documents
There may also be scenarios for which certain features offered by both the web page application and the standalone executable are required in order to meet the requirements of the end users. Consider the case where it has been decided that a standalone executable written in Microsoft’s Visual Basic programming language is to be deployed, either because a suitable application has already been written or it has been determined that this type of executable can meet specific user requirements, whereas the web page solution can not. It may also be necessary, however, to access some of the features supported by a web browser.

For example, the requirements might state that the application is to be deployed from the server; as well, the application is to be run inside one frame of a web page, with HTML help and other files occupying other frames in the same web page. A typical solution that attempts to address these specific requirements has been to implement a single ActiveX control that provides the complete user interface and all of the required functionality, and which is then inserted into a web page; the HTML code of the web page is used to place the monolithic control and the application scripting code controls navigation and communication between the page’s frames. In the case of this particular example, however, the same result could be realized, with more efficient and elegant results, using an ActiveX Document.

ActiveX Documents share some similarities with ActiveX controls. Both components are based on Microsoft’s ActiveX technology∗. As well, instances of both components must be inserted or sited into a container application: neither component can be run on their own as a stand-alone application.

ActiveX Documents differ from ActiveX controls in the following ways:

An ActiveX Document is a full and complete form based application, whereas an ActiveX control is intended to provide a single, encapsulated set of features that may or may not have a user interface. In other words, ActiveX controls can be considered to be software building blocks that are inserted with other components into a container application, while ActiveX Documents are applications in their own right.
An ActiveX control is inserted into either a web page frame or VB application form along with other components. The underlying application code provides the means by which these components interact. An ActiveX Document, on the other hand, occupies the entire area of a frame in the host application.
The menu items of an ActiveX Document are merged with those of the container application. The user has access to the application’s menu items in the usual location, and the menu items of the container application, such as navigation and the “favorites” list in the case of Internet Explorer, are still available.

History
ActiveX Documents were originally called “Office Compatible” objects by Microsoft. The intent was to provide a framework that focused on the concept that Microsoft Office files were to be considered first and foremost as documents, rather than separate files that were generated using different applications. One of the outcomes of this approach was the technology known as Object Linking and Embedding (OLE), whose original goal was to not only allow a document to be inserted into an application, but to also allow that document to be edited in place using the application which was originally used to create it.

Another outcome was the development of an application called Microsoft Binder. The goal of this application was to provide a means of allowing the user to assemble a collection of Office Compatible objects in a single container. As the user leafed through each document in the collection, the container’s menu items would change to allow the user to edit or change a specific file. Thus, the user would be presented with a group of documents that shared a consistent interface.

The technical implementation of the second version of OLE lead to its use in other types of applications, and this technology has now been given the name ActiveX by Microsoft. The design framework of the Microsoft Office application suite, which includes Word and Excel, has become known as ActiveX Documents, and the Microsoft Binder application was the first to be designed to be what we would now call an ActiveX Document container application.

While the Microsoft Binder application is not commonly used today, the underlying technology can be found throughout the range of Microsoft’s products. For example, from version 3.0, the Internet Explorer web browser has been implemented as an ActiveX Document container application. The result is that not only is it possible for a user to open a Microsoft Word file for viewing in Internet Explorer, it is also possible for that file to be edited from within the web browser; the menu items from Microsoft Word that are specific to the viewing and modification of a Word document are merged with those of the Internet Explorer browser application when the document is loaded.

Like the technology that was used to implement the second version of OLE, which is now known as ActiveX and which can be found in extensive use in other applications developed by Microsoft, the technology underlying “Office Compatible objects” can be used to develop rich, web-based client applications.

Technical Details
An ActiveX Document based application must be developed as an ActiveX executable; this allows the container application to access the interfaces required to host the client.

There are three important components to an ActiveX Document solution:

The ActiveX Document application server and its associated UserDocument object.
The VBD file.
The container application.

The “UserDocument” Object
At the heart of the ActiveX Document executable is the UserDocument object, which provides the framework on which the underlying client application is built. A UserDocument object is similar in many ways to the Form object on which most Microsoft VB applications are built, and the process used to develop the application is virtually identical. When instantiated from within the VB IDE, the UserDocument object presents a form to the developer upon which other objects and controls can be placed and the VB application code written.

The primary difference between UserDocument and Form based applications is that while the latter can be launched and run as an independent executable, a UserDocument must be hosted by a container application. Form and UserDocument based applications can launch other Forms. However, it is not possible for either to launch other UserDocument objects as independent entities; in order to display a separate UserDocument from a parent application, a new instance of an appropriate host application must be launched that contains the UserDocument.

The VBD File
The VBD file is created when an ActiveX Document project is compiled. Initially, this file contains the class identifier (CLSID) of the UserDocument object. This file is required primarily for the viewing of the application in the Internet Explorer web browser because Internet Explorer only knows only to load objects from a persisted state. For example, an HTML web page defines the state of a specific HTML “image” that is to be displayed in the web browser.

However, Internet Explorer can not actually launch an application. Internet Explorer can be loaded with a Microsoft Word document because the Word document format identifies the ActiveX server that can be used to process that type of file. Similarly, the VBD file contains the means of identifying the application server that has been implemented as an ActiveX Document.

In terms of deployment, a reference to the VBD file can be used within a web page in a manner almost identical to a reference to other HTML based web pages. A user can navigate directly to VBD file by specifying its location in the URL window of the web browser, or the file can be set to be the initial page of a frame. Similarly, a VBD file can be the target of a hyperlink.

The Container Application
As previously stated, ActiveX Documents must be hosted by an application that provides an appropriate container. In order to be an ActiveX Document container, an application must support a specific set of COM interfaces and it is feasible to develop a new container application from scratch. At present, Microsoft has implemented the following applications as ActiveX Document hosts:

From version 3.0, the Internet Explorer web browser. In all probability, this will be the container that will be used most often to host ActiveX Document based web client applications.
Office Binder. This is not commonly used today, but it may have some uses for your organization.
Microsoft’s VB Integrated Development Environment and Microsoft’s FrontPage Editor Application, which can be used as a host during the development of an ActiveX Document based application.

Deployment Issues
The VBD file can be installed either on the server, where it can be downloaded to the user’s workstation, or installed separately on each user’s desktop.

The ActiveX Document application itself can be deployed to users in one of two ways:

As a file on the server to which the end user can navigate using Internet Explorer. If the user does not have the application installed and registered on his or her workstation, the web browser will attempt to download it in a manner similar to that used to download and register ActiveX controls.
As a setup package similar to that used to distribute other standalone executables.

Experience has shown that the process of downloading the application using Internet Explorer is far less reliable than using a setup package. In addition to failing as a result of restrictions imposed by the web browser’s security settings, attempting to download a more complicated application may result in a failed installation if the application or any of its dependent files require the workstation to be rebooted once the application has been installed. These problems are similar to those that may also occur during the process of downloading ActiveX controls; typically, however, the ActiveX Document application will be far more complicated than an ActiveX control and, as a result, there is a greater probability of failure. A general rule of thumb is that the level to which problems will be encountered deploying ActiveX Document based client applications will be proportional to those experienced during the distribution of more complex ActiveX controls: if no difficulties are encountered while deploying complex ActiveX controls using Internet Explorer’s download process, then there should be relatively few problems encountered deploying ActiveX Document based applications using the same mechanism.

However, the decision to choose an ActiveX Document is usually the result of requirements that call for a more complex feature set in the client application; the result is a need for a client application that is, at its heart, a VB executable. It is therefore strongly recommended that the standard setup process be considered for the installation of ActiveX Document applications on client workstations.

Migrating existing VB Applications
One example that was provided for the use of ActiveX Documents was that of migrating an existing VB application to a web based environment. The Visual Basic IDE provides a packaging wizard that will convert an existing formbased application to an ActiveX Document.

The wizard’s migration process performs the following tasks:

If required, converts the project type to be either an ActiveX executable or ActiveX DLL.
Creates a new UserDocument object.
Transfers the properties, controls, and code from the application’s main form to the new UserDocument object.
Comments out any code that is illegal in a UserDocument. Because the lifetime of the UserDocument is determined by the host container application, this will include any code for the application to terminate that is called from within the application itself.
Replaces, wherever possible, event handlers by replacing the term “Form” with “UserDocument”.

The wizard is relatively straightforward to use; however, it should be noted that its conversion of the source application will not necessarily be complete in terms of its ability to produce an equivalent ActiveX Document based application. Because code considered to be invalid in an ActiveX Document, such as that which controls the application’s lifetime, is commented out, and because some form events, such as “Load”, do not have direct counterparts in the UserDocument object, the resulting application should be checked by the developer to confirm that the changes made by the migration wizard are acceptable. Modifications to the application’s code may be required in order to ensure that it will behave in the same manner as the original form-based application.

As well, additional code may be required in order for the new ActiveX Document application to be controlled from within the host application.

Summary and Conclusions
The ActiveX Document is not intended to be a solution that will meet the requirements of all web client applications; rather, it is a Microsoft solution that should be used only in those cases where a very specific set of requirements exists.

As well, if the requirements call for a thin client application, an ActiveX Document solution will not magically provide a web page with the features and functionality that can only be provided by a standalone executable and allow that web page to remain a thin client. However, ActiveX Documents may be considered as a client application solution when it is desirable for a feature rich client application to form part of an overall web page based solution.

The most common container for hosting ActiveX Document based GIS client applications has been Microsoft’s Internet Explorer web browser. Although the ActiveX Document is developed as a feature rich application, it can be placed and controlled within this particular container as if it were a standard web page; this means that the HTML and scripting language code of the host application’s web page can be used to insert and navigate to the ActiveX Document, and the host can respond to events raised by the application itself.

Consequently, although not in common use, ActiveX Documents may provide an elegant solution in those cases where the requirements call for a complex and feature rich executable to be an integral part of an overall web page based client application framework.