An Introduction to Scripting Technologies and Object Models

As a Win32 Scripting Journal reader, you're probably interested in learning scripting mainly to automate Windows 2000 (Win2K) and Windows NT administrative functions and even for Web site development. However, because many scripting technologies exist, you might not know where to start and have such questions as

When you understand the concepts of scripting technology and object models and know the roles that the most prominent scripting technologies and object models play in Windows, you'll have a much clearer idea of what scripting is and how to proceed to build a customized learning path. After you decide how to proceed, you can then use the resources listed in the Web-exclusive sidebar "For More Information" on the Win32 Scripting Journal Web site at http://www.win32scripting.com.

What Is a Scripting Technology?
The key to understanding scripting technologies in Windows is COM, which stands for Component Object Model. COM is a set of rules that identifies a family of software components. It is the universal glue holding together the communication layer that enables all the Windows components to interact with one another. COM isn't the only possible model for software components. Other models include Common Object Request Broker Architecture (CORBA) and Enterprise JavaBeans (EJB). However, COM is the component model you find under any 32-bit version of Windows.

When you learn about scripting, you don't need to know about COM's complex internal mechanisms. For scriptwriters, COM is a tool. Thus, you need to know how to use it, but you don't have to know how it works.

Each software component that complies with COM's set of rules is a COM object. The functionality that each COM object makes available externally is organized into groups called interfaces. If a certain object supports a certain interface, you say that the object implements the interface. Several types of interfaces exist, each of which is identified by a unique 128-bit ID.

You can classify COM objects into families of COM components according to the interfaces that the objects implement. The COM component families include Windows Explorer shell extensions, Microsoft Management Console (MMC) snap-ins, and folder namespace extensions.

A special family of COM components is automation objects. These objects act as server components and therefore follow clients' instructions. All automation objects implement an interface called IDispatch. If a client wants to use automation objects, the client calls the IDispatch interface. This interface lets the automation objects publicly expose their functionality to the client.

Scripts are often used to programmatically manipulate a COM component so that the component exposes an automation interface. Scripts can take a variety of forms, including VBScript or JScript files and C++ or Visual Basic (VB) applications.

So, a scripting technology is a service (typically a system service) that a component (typically a COM component) makes available to scripts through automation. Take, for example, the scripting technology of Active Data Objects (ADO), which lets you access, read, and write to relational and nonrelational databases. ADO is a system service that a COM component makes available to script files. A script-based client can manipulate that COM component to programmatically use ADO to access, read, and write to database records. Besides ADO, other prominent scripting technologies include Active Directory Service Interfaces (ADSI), Collaboration Data Objects (CDO), and Windows Management Instrumentation (WMI).

What Is an Object Model?
Scripting technologies provide access to a set of functions that are expressed in terms of objects, methods, and properties. The set of functions is often referred to as an object model. More precisely, an object model is a hierarchy of logically related objects, each with a set of methods and properties. A method is a function that the object can execute. A property is an attribute of the object that a script can set. A script can access those objects and invoke their methods and properties through the automation object's interface.

When you write a script within Windows, you're simply writing code that accesses one or more object models. With the exception of the scripting language's native features, everything that you can do through a script takes place only because of an object model.

Object models can be at the system or application level depending on which part of the OS exposes them. For example, ADSI, ADO, CDO, and WMI have system-level object models and each program in Microsoft Office 2000 has an application-level object model.

What Is a Scripting Language?
A scripting language is a complete yet simple programming language that you can use to create effective applications. A scripting language is complete in that it provides you with a set of tools that you can use to accomplish any reasonable task. Yet a scripting language is simple enough that you don't have a steep learning curve. You use scripting languages for quick solutions and to glue together subsystems of a given system.

Scripting languages are interpreted rather than compiled. A scripting environment provides a runtime engine (often called a parser) that processes instructions on the fly. In contrast, other programming languages (e.g., C++) must be transformed, or compiled, into a set of machine instructions to become executable. A compiled language requires a far more complex development environment but executes faster.

For a long time, Windows lacked a scripting environment that was easy to use yet powerful. The only way you could automate tasks in Windows was with the old-fashioned, poorly designed batch (.bat) files, whose birth dated back to the first few versions of MS-DOS.

Then, Microsoft introduced Windows Script Host (WSH) 1.0 in early 1998 and WSH 2.0 in late 1999. WSH is now the official Win2K scripting environment. You can also use WSH with other Win32 platforms, including NT 4.0 and Windows 9x. More important, WSH is an easy-to-use yet powerful script environment in which you can run VBScript and JScript files as if they were executable files. VBScript and JScript are just a few possible script languages that you can use with WSH.

What Should I Learn First?
Because of WSH's importance, becoming familiar with the WSH object model is the first step for novice scriptwriters. However, learning the WSH object model doesn't mean you don't need to learn about other models. If you want to write scripts that automate administrative tasks in a Win2K or NT system, you need to have some degree of knowledge about several prominent scripting technologies and object models. You need to know about ADSI, ADO, CDO, and WMI and their system-level object models. You also need to know about the application-level object models for the programs you use (e.g., Office 2000 programs, third-party programs). Finally, you need to know about Extensible Markup Language (XML).

WSH. The WSH object model isn't a Windows object model; rather, it provides some features for scripting within the Windows OS. The model has three main objects: WScript, WshShell, and WshNetwork. The top-level object in the WSH object model is WScript. Through this object, you can access any of the other objects in the model.

The WSH scripting engine automatically creates the WScript object before it starts processing your script. Thus, you can immediately start using this object in your script. However, before you can use any of the other objects, you need to explicitly create instances of (i.e., instantiate) them. To conserve system memory and resources, WSH creates instances of objects (i.e., references or pointers to existing objects) rather than making copies of them. After you instantiate an object, you can use any of the object's properties and methods.

ADSI. ADSI is a layer of system code that hides the differences between existing Directory Services (DSs), thereby providing a common way to identify DS objects. ADSI works around the different naming conventions that the DSs might employ by merging several existing technologies, including Lightweight Directory Access Protocol (LDAP), dynamic DNS (DDNS), TCP/IP, and Kerberos.

You don't need to create ADSI objects before using them. The entry point in the ADSI object model is VBScript's GetObject function (or its equivalent in another scripting language). To obtain the root object, you provide this function with a formatted string identifying what ADSI calls a namespace. A namespace represents a DS available on the system to which you're connected (e.g., WinNT:). Using a namespace's syntax, users can issue queries and access objects.

With the objects, methods, and properties in the ADSI object model, you can easily access a network's users, groups, printers, and services. For this reason, I recommend that you try to learn as much as possible about the ADSI object model as soon as possible.

ADO. Microsoft designed ADO to simplify access to OLE DB data sources. Everything you can access through ODBC you can access through OLE DB as well. ADO is the only way you have to connect to a database through scripting.

The ADO object model consists of seven objects (Command, Connection, Error, Field, Parameter, Property, and Recordset) and four collection objects (Errors, Fields, Parameters, and Properties). The Connection object is the top-level object. It establishes a physical connection to the data source by providing a channel through which the client and the data source exchange data. Unlike the WSH top-level object, the Connection object must be instantiated before you can set its properties to specify the OLE DB provider you want to talk to and other environmental settings regarding the location and the type of cursor.

Although you always need a connection to the data source, you don't have to explicitly create it. The Recordset object will create a hidden Connection object if you don't specify a connection when you call the Recordset's Open method.

Reasons exist to create and not create an explicit Connection object. If you create an explicit Connection object, you can take advantage of transactions. In addition, you have access to an ADO object that lets you report errors and trace activities. If you have the Recordset object create a hidden connection, you save lines of code, making the script leaner and more easily readable. However, in terms of performance, the differences between the two approaches aren't that significant. Both ADO and the underlying OLE DB layer implement their pooling mechanisms, which makes the repeated creation of Connection objects far less expensive in terms of performance.

An interesting feature of OLE DB and ADO is their ability to support a variety of data sources. In addition to Microsoft SQL Server, Oracle, Microsoft Access, and other databases, ADO can talk to special OLE DB providers such as Microsoft Index Server and, more important, the Active Directory (AD) OLE DB provider. In other words, you can access the objects published on the company's network through ADSI or ADO.

In general, ADO is a multipurpose programming layer capable of interfacing with any COM component that exposes a certain number of interfaces. Because of its abilities to interface with any COM component and to access relational data, I recommend that you try to learn as much as possible about ADO as soon as possible.

CDO. CDO lets you develop messaging and collaboration applications. Because CDO doesn't have any user interface (UI) elements (e.g., a logon dialog box), CDO is mainly used in scripts that automate tasks in Microsoft Exchange Server, Outlook 98, and Outlook Web Access (OWA). For example, you can write client scripts that use CDO to create or read email messages. You can also use CDO to automate more advanced email features, such as calendaring, threaded conversations, collaboration, and workflow.

In general, CDO is most helpful for automating Exchange Server's advanced features. For simpler features, such as sending email messages, you can use CDO for NT Server (CDONTS) instead. CDONTS is easier to use than CDO. The main object in CDONTS is NewMail; with its properties and methods, NewMail fully represents an email message.

CDONTS is a sub-object model that comes with CDO. However, you can also obtain CDONTS by installing Microsoft IIS 4.0 and the mail services of NT Server 4.0. However, you can't use CDONTS on Win9x unless you use a workaround COM object.

WMI. Microsoft introduced WMI to help manage systems, applications, and networks as they become larger and, consequently, more complex. WMI is part of Win2K but is also available for NT and Win9x. WMI lets scripts use one API to access infomation for numerous disparate sources, regardless of whether those sources are local or remote. Remarkably, WMI doesn't introduce additional overhead if the managed sources are remote rather than local. Another remarkable characteristic is that WMI treats data much like a relational database. In other words, with WMI, you can use SQL-type queries to filter data.

WMI relies on providers that expose system information to client applications, including scripting applications. Win2K comes with providers for the Win32 environment, the Registry, the event log, the Performance Monitor, and the AD store. You connect to WMI through VBScript's GetObject function, invoking a namespace called WinMgmts:.

WMI lets you accomplish tasks that you can't accomplish through any other object model. For example, provided that you have the necessary permissions, you can write a script that reboots your coworker's desktop system. WMI also gives you alternatives for tasks that you can accomplish with other object models. For example, WMI lets you check disk space. Because you can use WMI to accomplish so many tasks, it might eventually become the Windows object model. For this reason, I recommend that you learn about the WMI object model (but in no particular rush).

Application Object Models. Most Microsoft and third-party applications available today expose an object model that makes them easily programmable through scripting. The idea behind programmable applications is that humans are no longer the only users of programs. Scripts and other software can access the applications to invoke their functionality. In most cases, the applications offer the same functions regardless of whether a human or a script invokes them.

Each application has a unique object model. I recommend that you learn about the object models of the applications that you regularly use (but in no particular rush).

XML. XML is simply a language to describe data. This text-based formatting tool has tags that let you mark up and display virtually any sort of data, from binary streams to structured documents. As such, XML isn't strictly related to scripting. One notable feature of XML is that you can use it to describe complex models of data across different systems and platforms.

You can render the content of an XML document through an object model, but this rendering makes the XML document platform-dependent. The component that enables rendering is the parser. For the Win32 platform, Microsoft provides a parser as part of Internet Explorer (IE) 5.0. After you create an instance of the object, you simply load the XML document into the script. You can then use the object's methods to navigate and manipulate that document.

XML's significance in the scripting arena is steadily increasing because you can use it to exchange information with other systems and platforms. Thus, you need to eventually learn about XML.

An Important Subject
Scripting is playing an increasingly significant role in the Windows platform. This trend is evidenced by the fact that all new system services and most applications expose object models and therefore are scriptable. Because of scripting's increasing importance, you need to learn as much as possible about the various scripting technologies and object models available. The scripting technologies and object models discussed here are a good place to start.