The lights under their bushels.

Sometimes one just has to wonder at the intelligence of large software companies. Two recent events have lead me to believe this is especially true of two of the biggest rivals on the web application scene: Netscape and Microsoft.

The first of these was a demonstration of what has to be the hidden jewel in Netscape’s suite of web servers and applications: the Process Manager web application environment. Process Manager is a powerful object oriented tool allows you to create process-driven applications, allowing the flow of an application to define the structure of the scripts and HTML pages.

This was followed by a technical seminar of the Back Office User Group, which took as its theme “The Hidden Microsoft”. It was somewhat disheartening to see the number of senior IT managers who hadn’t considered using any of the technologies introduced in the NT 4.0 Option Pack: the Transaction Server, the Message Queue and the Windows Scripting Host.

So what are these hidden crown jewels like, and what can you use them for? It’s time to take a look at some of the more unusual features of Windows scripting, taking advantage of its links with COM and the MTS, as well as looking at how a tool like Process Manager works.

Building XML-driven COM objects using Windows Scripting

One the most powerful features of Windows is the Windows Scripting Host. Using the Active Scripting engine that’s evolved from browser scripting technologies and Active Server Pages, the Windows Scripting Host gives you the tools to build complex server side scripts that work with COM objects – on Windows 95, 98 and NT. As more and more Windows applications start to expose COM interfaces, the Windows Scripting Host is going to become a powerful tool for system administrators – as well as developers working on Intranet applications.

Now Microsoft has extended their scripting model to introduce Server Scriptlets. Server Scriptlets allow you to use existing Active Scripting skills to build scripts that can be used as COM objects – which can be hosted in MTS packages. When combined with some of the latest web application technologies introduced with Internet Explorer 5.0, Server Scriptlets offer the web application developer with a quick and effective tool for creating middle-tier objects and components.

Two recent columns have looked at two aspects of Microsoft’s scripting environment: DHTML behaviours and the XML document object model. Combining the two technologies in Server Scriptlets, gives you an effective tool for data manipulations. The DHTML behaviour model introduced with Internet Explorer 5.0 allows the scripting content of a web page to be abstracted into external scriptlets that can be used to add actions to HTML page elements. The structure of a DHTML behaviour scriptlet is identical to that of a Server Scriptlet, both embedding scripting in an XML framework.

Server Scriptlets require a script handler to provide full functionality, and this is implement as a DLL, installed when you download the Scriptlet development kit from http://www.microsoft.com/scripting. This also contains the Script Wizard, a tool that gives you the outline framework for a scriptlets, either server or DHTML. You can use the Wizard to produce a script framework containing properties, parameters and events. The following code is a sample output from the Scriptlet Wizard, showing the structure of a Server Scriptlet:

<?XML version="1.0"?>
<scriptlet>
<?scriptlet error="true" debug="true"?>
   <registration
       description="Demo"
       progid="Demo.Scriptlet"
       version="1.00"
       classid="{ab4a5880-c51f-11d2-8e53-
                 0080c75c6a7a}">
   </registration>
<public>
   <property name="Property1">
              <get/>
              <put/>
   </property>
   <property name="Property2">
              <get/>
   </property>
   <property name="Property3">
              <put/>
   </property>
   <method name="Method1">
   </method>
   <method name="Method2">
             <PARAMETER name="parameter1"/>
             <PARAMETER name="parameter2"/>
   </method>
</public>
<implements type="Automation" id="Automation"/>
<script language="VBScript">
<![CDATA[
dim Property1
dim Property2
Property2 = "value"
dim Property3
function get_Property1()
       get_Property1 = Property1
end function
function put_Property1(newValue)
       Property1 = newValue
end function
function get_Property2()
       get_Property2 = Property2
end function
function put_Property3(newValue)
       Property3 = newValue
end function
function Method1()
       Method1 = "Temporary Value"
end function
function Method2(parameter1,parameter2)
       Method2 = "Temporary Value"
end function
]]>
</script>
</scriptlet>

You can then add your own code to the framework, so that your scripts provide the functions and modify the various properties as required.

If you’re working with ASP, you can use scriptlets to reuse commonly called code, as it is possible to create a scriptlet that has access to the ASP object model. Using this method, you can use session and application objects, as well as the response and request objects. These allow a scriptlet to interact both with a web application and directly with the browser.

Creating an ASP scriptlet is easy enough, just requiring the addition of a single line of code to the framework scriptlet shown earlier. This “implements” directive initialises the ASP functionality of the scriptlet handling DLL:

<implements type = “ASP”>

Once a scriptlet has been created it will need to be registered before it can be used. If you’ve installed the scriptlet development kit, a simple right mouse click will register and deregister scriptlet COM objects. Otherwise, you will need to use standard registry tools to implement your COM scriptlets. A scriptlet can then be used with an ASP application, exactly in the same manner as any other external object:

<%set scriptASP = createObject(“ASPScriptlet”)%>
<%= scriptASP.method()%>
<%variable = script.ASP.property%>

You can then access the methods and the properties of your scriptlets from your ASP applications.

It’s then possible to use XML and XSL within your scriptlets, using XSL as a data translation tool, as well as a display technology. One of the first uses for XML and XSL in scriptlets is to provide a technique for displaying XML data in non-XML aware browsers – which are most of the browsers currently in use!

An XML-based scriptlet can be used to display the contents of an arbitrary XML file and XSL stylesheet, with the filenames being passed as method parameters. The resulting code can be added as a method to a scriptlet, by implementing it as a function in a server scriptlet that uses the Microsoft XML component. The code snippet below takes an XML document, and transforms it with an XSL stylesheet, before displaying it in a browser:

set doc = Server.CreateObject(“Microsoft.XMLDOM”)
doc.load(Server.MapPath(xmlfile)
set style = Server.CreateObject(“Microsoft.XMLDOM”)
style.load(Server.MapPath(“xslfile)
result = doc.transformNode(style.documentElement)
response.write(result)

Calling the scriptlet from an ASP application is easy enough:

<%@Language=VBScript%>
<HTML>
<HEAD>
<TITLE>XML via the Scriptlets ASP Handler</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<H1>XML via the ASP Handler</H1>
<%Set sctASP = Server.CreateObject("XMLXSL.Scriptlet")%>
<%= sctASP.XML()%>
</BODY>
</HTML>

Using scriptlets in your ASP applications is an easy way of reusing VBScript and JavaScript code across a range of ASP pages – and across applications. Whilst scriptlets are slower than the equivalent Visual Basic components (and much slower than Visual C++!), they allow you to use existing skills as a basis for developing quick solutions, and for adding transactional components to your ASP applications. It’ll also give you a basis for working with technologies like SQL Server 7.0’s Data Transformation Services and the forthcoming COM+ distributed application environment that will form the basis of Windows 2000.

Netscape Process Manager

Netscape’s Process Manager is a powerful, and often over-looked piece of web application development software. The current release, version 1.1, is a workflow management tool based around web-page publishing and forms processing, but it’s Process Manager’s integration with LDAP that makes it so powerful. Netscape define it as a “suite for end-to-end process management”, but that’s only part of the picture, as it’s really a component architecture that allows you to build user-focussed web applications. It’s definitely not just workflow tool for the web, and applications you build in Process Manager can be used to link multiple groups through the web, on extranets as well as intranets.

As it’s purely a server-side tool, Process Manager is a “browser agnostic system”, capable of being used with any browser you want – and with any email tool you want (though HTML mail support is helpful!). You do, however, need to be running a Netscape Enterprise Web Server, as well the Directory Server LDAP system. This is as all applications built using Process Manager are in fact LiveWire web applications, using a mix of custom and provided scripts that deliver HTML and email, whilst using user information you’ve installed in your LDAP system.

The Process Manager system is a typical component-based development environment, and is similar in concept to Microsoft’s Commerce Pipeline provided with SiteServer 3.0 Commerce Edition. The heart of the application is a set of server-side components, which are managed using the Process Manager Builder. This is a Java application, based on Netscape’s Visual JavaScript LiveWire development environment, which allows you to graphically define a process at a business level – rather than starting with the code! Using the Builder you can create start-points and end points for your process, along with any intermediate stages, linking the objects with process paths.

Unlike tools like Lotus Notes, Process Manager isn’t rules driven, and the Builder isn’t designed to create process rules. Using the library of process components, you use the Builder as a framework for creating your process model. Once a sequence of process components is complete, you can then start adding code, building the underlying application. Each point in a process can be a collection of processes, a script or an HTML form, and Process Manager Builder gives you the tools to add all these.

Whilst the Process Manager Builder script-editing environment is rather primitive, it’s suitable for quickly putting together your initial scripts. If you’re planning on complex developments, then you’ll need to invest in a third-part script development environment that allows you to work with server-side JavaScript. Surprisingly there aren’t many of these around – with the best known being NetObjects’ ScriptBuilder (version3.0 of which has just been released).

LDAP is one of the unsung heroes of the Internet. The Lightweight Directory Access Protocol, LDAP is a tool for accessing Internet-based directory services. A descendent of the X.500 protocol, LDAP is designed to make querying a directory both fast and efficient. You can use an LDAP directory to store user information, or to act as a registry for application data. Most LDAP systems are used for user information storage, and you’ll most likely be familiar with the large Internet email address registries like Four11 and Bigfoot, which provide LDAP interfaces for LDAP-aware email clients. You’ll find both Netscape’s and Microsoft’s email tools can use these services to track down email addresses.

You will need to have set up – and populated – an LDAP server before using Process Manager in anger. Not only are your applications dependent on the information in the directory, but also the Process Manager Builder stores processes definitions in the LDAP server. If you’re using Process Manager’s visual application builder tools, you’ll have direct access to the Netscape Directory Server databases. You can then use this information to define groups and roles for your application. Process Manager is designed to use relationships between individuals as the basis for its applications, and uses LDAP-based information to handle automated form processing and message routing. Using this you can build human resources intranet applications that automatically route forms from a user to their manager for approval before entry into an HR database system.

Once you’ve defined the users of an application, you can then start building the code. It’s possible to use external applications as processes, if they can be called via JavaScript. As LiveWire provides links to Java server applications, your custom components are likely to be written in Java. The HTML forms used to provide user interfaces can be built using Process Manger Builder’s own tools, or in your preferred HTML editing suite, such as Netscape Composer or Microsoft FrontPage. Once you’ve created a form and added it to your application, you can then use Process Manager Builder to link it to both a process – and a class of user – using a presentation matrix. This allows you to give different groups different views of the same information, without requiring you to develop complex authentication code.

Once completed, a Process Manager application can then be deployed to a "cluster". A cluster is a Netscape Enterprise Server, with the Process Manager engine installed. This is a NSAPI plug-in, and is designed to deliver a user interface via a separate application, Process Manager Express. The Process Manager engine uses both the LDAP server and an external database to manage state, and an Administration tool allows you to monitor and control the server. Process Manager gives you several different deployment modes, as it can be difficult to implement and debug a workflow application without affecting users! You’ll find the test mode useful, as it sets all users to “creator”, allowing a single developer to test an application from end to end.

It’s important that the administrators of a web-based process can view how it’s performing, and how it’s being used. The disconnected nature of a web application makes it difficult to track performance accurately, so Process Manager stores audit information in an external database. This audit trail can be then be viewed, either using Process Manager’s own tools, or via your own database queries.

There are several issues that arise from Process Manager’s reliance on LDAP systems, with the main one being it’s interaction with other directory services, as many organisations are already running directory services of their own or are planning on rolling them out in the near future. With Netware’s NDS system in widespread use, and Windows 2000 requiring use of Microsoft’s forthcoming Active Directory, organisations will need to work with multiple directory services. The prospect of replicating data from Active Directory to LDAP and back again is one that will cause most system administrators to shudder with fear – as thousands of records will be travelling backwards and forwards over a network in each replication. Netscape are promising a “MetaDirectory” tool that will control replication between different directory services, but this is unlikely to appear for sometime.

As it stands, Process Manager is one of the most useful web application development tools around, precisely because it is designed for one specific purpose. However, Netscape are currently working on version 2.0, which will extend its functionality considerably. Plans for Process Manager’s future development not only include a public API, but also integration with Netscape’s Application Server environment.

Summary

  • Market leading companies often ignore or fail to publicise significant web application technologies.
  • Server Scriptlets allow VBScript and JavaScript code to be reused as COM components.
  • By implementing an ASP-aware scriptlet you can use the ASP object model in your scriptlets.
  • Netscape’s Process Manager 1.1 is a tool for building process-driven web applications.
  • A graphical development tool allows you to build applications from process-flow diagrams.

 

Hidden Web Tools
Home
Columns