A Server Scriptlet is a script file that works as a real COM object. In fact, a Server Scriptlet is still a script file—but one which is interpreted by a run-time module that eventually implements the needed and referred COM interfaces. This module takes care of creating the standard layer of code for all the COM-aware development tools and all the COM-aware applications .
Without this run-time engine—called scrobj.dll—you simply don't have a COM scriptlet. Of course, when planning how to distribute your Server Scriptlet you should make sure that such a library is available on the client machine. However, personally, I think that by the time the Server Scriptlet Package gets released Microsoft will include a Setup Wizard or include the needed file with Internet Explorer.
To understand the role of this run-time engine, let's consider how a method gets called in a DHTML and Server Scriptlet. In the first case, the container—be it IE4 or the Microsoft scriptlet Control used in Visual Basic—is aware that the object being referred to is a scriptlet. Therefore, it knows about its public_description object and its public methods and so it's easy for it to invoke the right script function.
As explained above, a Server Scriptlet can act as a traditional DHTML Scriptlet if you add a public_description object and insert it in a HTML page—specifying the scriptlet's MIME type. However, a Server Scriptlet can also be exploited through its COM automation interface. You can create an instance of it with the following syntax:
Set obj = CreateObject( "Time.Scriptlet" )
When next you attempt to invoke its methods and properties the underlying environment will completely ignore that it's made of JScript or VBScript code. What matters is that the ProgID passed in (the string Time.Scriptlet in the above example) links to a COM server regularly registered in the client machine. From the ProgID the executor of the code will go up to the CLSID of the server. This information is stored in the registry. The next figure shows where and how.
When it's time to execute a method on that object,
Set obj = CreateObject( "Time.Scriptlet" )
obj.GetCurrentTime
there's no more public_description variable to take care of. The CLSID points to a library name to be loaded. The next figure demonstrates that the scrobj.dll is the library associated with the CLSID assigned to the Time Server Scriptlet seen above. Note the correspondence between the CLSID shown in the figure and the one in the source code of sstime.sct.
scrobj.dll is a common interface for all the Server Scriptlets. A COM-aware development tool attempts to use such a component, it accomplishes the same steps as for any other COM object. It's up to scrobj.dll to map any call it receives to the right scriptlet URL. The diagram shows the role played by this run-time module. It implements the COM interfaces necessary to talk to the clients and translate the calls back to the specific SCT file whose name is coded in the ScriptletURL key of the registry.
In other words, this run-time module works as an interpreter between the client (say, a Visual Basic program) and the server (say, a Server Scriptlet).
Invoking a method the COM way actually results in calling the Invoke function of the IDispatch or IDispatchEx interfaces. A Scriptlet doesn't know anything about it, but scrobj.dll does, and proceeds to translate the call into something that the Scriptlet can understand.
The code sufficient to implement an automation interface with methods and properties is stored inside scrobj.dll. This module at the moment only offers support for the dispatch interfaces mentioned above. A COM server, instead, could do much more and may need other interfaces to be implemented. For any COM interface that you want your Server Scriptlet to support, you need a kind of interface handler, that is, a module (mostly written in C++) which takes care of exposing the interface pointers to the clients and turning back to the script code for the actual code execution. As I have already mentioned, we have only scrobj.dll that handles the IDispatch interface needed for automation at the moment. In the future, however, we can expect both Microsoft and third-party companies to provide other specialized interface handlers.
An interface handler is a COM server with a predefined behavior. It will work in conjunction with (and not replace) the scrobj.dll. Actually, it is helpful to think of an interface handler as an extension of the run-time module. There is no documentation yet for writing interface handlers, but it will surely be available in the months to come.
The previous figure shows a more detailed view of the Server Scriptlet's architecture. In the next section, we'll start examining the inner structure of a Server Scriptlet and have a closer look at the new tags.