Though not explicitly designed for COM or DCOM, the automated code download feature solves our problem nicely. This features allows ActiveX controls (COM servers) to be downloaded from a centralized location, installed, and activated on an end-user machine when a web page containing the control is reached. As an additional feature, if the ActiveX control is already installed on the user's machine, but is of an older version, the support system will download and replace the control with the newer version. This behavior is almost exactly what we want. Paired with the code download technology is digital signature/code signing technology from Microsoft. This allows the receiver of the downloaded component to be sure of the integrity of the code during the download process, and the authenticity of the original source of the code. However, this technology is less relevant in the isolated intranet environment.
In a typical usage on a web page, an ActiveX control object is embedded in the following manner with the <OBJECT>
tag.
<OBJECT
ID="MyCalendar"
CLASSID="clsid:99B42120-6EC7-11CF-A6C7-00AA00A57DD2"
CODEBASE="http://objectstore.aw.com/controls/vbsamp/vbcalctl.ocx#Version=1,0,0,121"
TYPE="application/x-oleobject"
WIDTH=150
HEIGHT=60
VSPACE=0
ALIGN=left
>
The key attributes for version control and download are the CLASSID
and CODEBASE
entries. The CLASSID
entry contains the CLSID of the control to download, and the CODEBASE
entry contains the location for downloading the code if necessary, as well as a version number consisting of four parts. The first two parts are the two words making up the most significant double word of the version number (typically the major version number), and the last two parts are two words making up the lower double word of the version number (usually the minor version number). The new control will be downloaded if it hasn't been installed in the local machine and/or if the version number of the code on the local machine is older than the one required.
Under the hood, the browser (in this case IE3.0) uses a new API call to accomplish its task. The API is generally available, and we may use it to create centrally stored, version controlled component code for automatic distribution and version management. The name of this new API function is CoGetClassObjectFromURL()
, and is equivalent to CoGetClassObject(),
which relies solely on the SCM to check the information in the local registry.