Search our
entire site
Enter your search
terms below, or visit
our search page

Search case
studies only
Enter your search
terms below:

For the table
of contents and
hyperlinks to
general topics
proceed to toc

Some Web Object Model Construction Technologies

24 September 1998

Abstract

The World Wide Web is becoming an increasingly important factor in planning for enterprise distributed computing environments. However, as organizations have attempted to employ the Web in increasingly-sophisticated applications, these applications have begun to overlap in complexity the sorts of distributed applications for which distributed object architectures such as OMG's CORBA were originally developed. Since the Web was not originally designed to support such applications, Web application development efforts increasingly run into limitations of the basic Web infrastructure.

A fundamental direction of efforts to address the limitations of current Web data structuring technology has been attempts to integrate aspects of object technology with the basic infrastructure of the Web. A previous report, Towards a Web Object Model [Man98], identified the relationship of parts of the Web to parts of an object model, described some Web standards related to those object model parts, and suggested an overall approach for combining these standards to produce "objects" in the Web. This report describes a number of new Web technologies currently being developed that further the integration of Web and object technology. In particular, this report:

• discusses in further detail the overall approach to constructing objects in the Web introduced in [Man98], together with some general considerations for Web object model design.
• describes some technologies developed in the context of the Web that illustrate attempts to provide parts of the mechanisms needed to construct objects in the Web.
• discusses potential applications for objects constructed according to these techniques, and discusses how to construct objects in several "real" object models (e.g., OMG IDL, Java, and JavaScript) using these mechanisms.

Contents

1. Introduction

1.1 Background

1.2 Constructing Objects in the Web

1.3 Purpose of this Report

2. Web Object Model Construction and Design Issues

2.1 Web Object Model Construction Requirements

2.2 Some Web Object Model Design Considerations

3. Technology Examples

3.1 Scripting-Related Technologies

3.2 "XML-Native" Behavior Attachment Mechanisms (and Extensions)

3.3 XML Object Serialization

3.4 XML as a Programming Language

3.5 Object Interface and Messaging Technologies

4. Using these Technologies

4.1 Applications for Web Object Models

4.2 Constructing Objects in "Real" Object Models

5. Conclusions

References

 

1. Introduction

1.1 Background

The World Wide Web is becoming an increasingly important factor in planning for general distributed computing environments, for example, to support external access to enterprise systems and information (e.g., by customers, suppliers, and partners), and to support internal enterprise operations. Organizations perceive a number of advantages in using the Web in enterprise computing, a particular advantage being that it provides an information representation which

• supports interlinking of all kinds of content
• is easy for end-users to access
• supports easy content creation using widely-available tools

However, as organizations have attempted to employ the Web in increasingly-sophisticated applications, these applications have begun to overlap in complexity the sorts of distributed applications for which distributed object architectures such as OMG's CORBA, and its surrounding Object Management Architecture (OMA) [OMG97] were originally developed. Since the Web was not originally designed to support such applications, Web application development efforts increasingly run into limitations of the basic Web infrastructure.

If the Web is to be used as the basis of complex enterprise applications, it must provide generic capabilities similar to those provided by the OMA (although these may need to be adapted to the more open, flexible nature of the Web). This involves addressing the provision of higher level services (such as enhanced query and transaction support) and their composition in the Web. However, the basic data structuring capabilities provided by the Web must also be addressed, since the ability to define and apply powerful generic services in the Web, and the ability to generally use the Web to support complex applications, depends crucially on the ability of the Web's underlying data structuring facilities to support these complex applications and services.

The basic data structure of the Web consists of hyperlinked HTML documents, accessed via the HTTP protocol. It is generally recognized that HTML is too simple a data structure to support complex applications [Bos97], e.g.:

• applications that require the Web client to function as the front-end to enterprise applications or mediate between multiple heterogeneous databases,
• applications that require more flexibility in distributing processing load between Web servers and clients, and
• applications that require the Web client to present different views of the same data to different users or in which intelligent Web agents need to tailor information discovery to the needs of individual users.

A fundamental direction of efforts to address HTML limitations has been attempts to integrate aspects of object technology with the basic infrastructure of the Web. There are a number of reasons for the interest in integrating Web and object technologies:

• The Web can already be viewed as a simple form of distributed object system, where HTML pages are considered as objects, having identity provided by URLs, and methods defined by, or that are invoked via, HTTP servers. The basic resemblance of the Web to a simple object system has created a natural interest in seeing how far the resemblance can be further developed.
  
• Object technology is seen as a particularly-convenient way of adding functionality (e.g., behavior) to the Web, both by adding the behavior provided by objects to the static content of HTML, and by allowing Web clients and servers, through distributed object technology, to access other computing resources. For example:
  • Java can be added to Web pages and, once downloaded to the client, can then execute. In some cases, the client objects then interact with server objects, possibly using a different protocol, e.g., OMG's IIOP or Java's RMI.
  • Web pages can be treated as objects or collections of objects for use by other code. Dynamic HTML developments by Microsoft and Netscape, and current World Wide Web Consortium (W3C) work on a Document Object Model (see below), allow the contents of an HTML document to be treated as a collection of programmable objects. Client-side code can then access these objects and manipulate them dynamically (e.g., causing immediate changes in the document displayed to the user).

The HTTP protocol has also shown limitations in its ability to support extended Web applications. The World Wide Web Consortium (W3C) HTTP-NG activity <http://www.w3.org/Protocols/HTTP-NG/> is attempting to address these limitations, also by integrating object technology. Specifically, the activity is developing a new architecture for the HTTP protocol based on a simple, extensible, distributed object-oriented model.

There is much other ongoing work within both the Web and database communities on data structure developments to address Web-related enhancements. Work on similar issues is ongoing within the Object Management Group as well. This work has contributed valuable ideas, and the various proposals illustrate similar basic concepts (generally, movement toward some form of object model). If the Internet is to develop to support advanced application requirements, there is a need for both richer individual data structuring mechanisms, and a unifying overall framework which supports heterogeneous representations and extensibility and provides metalevel concepts for describing and integrating them.

1.2 Constructing Objects in the Web

In a previous technical report, Towards a Web Object Model <http://www.objs.com/OSA/wom.htm> [Man98], we:

• described key examples of existing work from the Web, database, and OMG communities (including those mentioned above) that contribute both ideas and technology toward providing the components of a Web object model
• identified some key underlying principles behind this work
• identified a framework which allows this work to be unified and extended to support the requirements of advanced Web applications for object technology

In particular, the report described how a number of (in some respects) separate "threads" of development in the Web community could be combined to form the basis of a Web object model to address the requirements for enhanced Web capabilities. This combination is based on the observation that the fundamental components of any object model are:

• data structures that can represent object state
• ways to associate behavior (object methods) with the object state
• ways for the object methods to access and operate on that state

Extending this idea to the Web environment, the idea is that Web pages (or parts thereof) can be considered as state, and objects can be constructed by enhancing that state with additional metadata that allows the state to be considered as objects in some object model. In particular, we want to enhance Web pages (or parts of them) with metadata consisting of programs that act as object methods with respect to the "state" represented by the Web page (or part thereof).

A more complete integration of object technologies into the Web provided by a Web object model would provide the basis of both powerful capabilities for integrating all kinds of data and information, and a wide variety of enhanced services, within a distributed architecture that is both widely-available, and easy-to-use and extend.

[Man98] noted that progress toward a Web object model requires:

• a richer base representation than HTML, in order to better represent "object state" (in particular, provide better support for semantic identification of fields, rather than simply supporting the presentation aspects of text)
• an API to this state, so that programs can readily access it (without complex parsing)
• an enhanced ability to define relationships between this state and specified pieces of code that can serve as object methods, to provide an enhanced ability to compose objects from both existing and new Web resources

At the same time, the openness of the Web compared to conventional object models needs to be preserved, due to the distinct requirements of the Web environment for openness, scalability, and support for heterogeneity.

The report also identified, as key component technologies to support these requirements:

• the Extensible Markup Language (XML) <http://www.w3.org/XML/>. XML provides a richer representation for object state than HTML, including both application-specific tagged data elements and nested structures, and more powerful linking facilities. In supporting an object model, XML pages (like HTML pages) can also be used as containers for embedded objects and object methods (e.g., Java applets).
• the Document Object Model (DOM) <http://www.w3.org/DOM/>. The DOM provides an API (currently defined using OMG's IDL) for XML documents used as object state, and provides a mechanism for integrating object state and associated code.
• mechanisms for representing and implementing embedded object methods, including:
  • the OBJECT element from HTML 4.0 for representing and implementing embedded object methods
  • arbitrary pieces of code defined as or within Web resources separate from the state (e.g., code libraries), identified by URLs, that are designed to access the state via its DOM-based interface, and that are associated with the state via the relationship mechanism mentioned in the next bullet
• concepts from the Platform for Internet Content Selection (PICS) <http://www.w3.org/PICS/> and Resource Description Framework (RDF) <http://www.w3.org/Metadata/RDF/> Web metadata models. These technologies provide standardized attributes, data structures, and infrastructure for representing and implementing basic aspects of an object model, including,
  • relationships between documents containing state and documents containing metadata (including type information and code implementing object methods)
  • a framework for accessing and invoking object methods contained in separate Web resources when documents requiring those methods are accessed
  • type definitions and relationships between types (e.g., inheritance), depending on the details of the object model chosen

These same technologies can also play other valuable roles in distributed object architectures (for example, XML could be used as a serialization representation for moving objects within a network).

In addition to using these emerging Web technologies, the report also proposed taking advantage of other existing aspects of the Web, e.g.:

• Web clients already have the capability to invoke some forms of code associated with Web pages (e.g., Java applets and plug-ins)
• Web clients will soon provide support for PICS. This establishes the principle of intercepting requests for Web pages in order to perform intermediate processing on the request (in the case of PICS, checking content ratings prior to displaying the page).
• Code libraries currently exist on the Web, with metadata describing them. Thus, it is not a major extension (at least in principle) to allow this code to be associated with "data pages" in order to form objects.

1.3 Purpose of this Report

Overall, [Man98] identified the relationship of parts of the Web to parts of an object model, described some Web standards related to those object model parts, and suggested an overall approach for combining these standards to produce "objects" in the Web. This report goes into more detail about some specific technologies that further the integration of Web and object technology, and could be useful in building objects in the Web. In particular:

• Section 2 discusses in further detail the overall approach to constructing objects in the Web introduced in [Man98], together with some general considerations for Web object model design.
• Section 3 describes some technologies developed in the context of the Web that illustrate attempts to provide parts of the mechanisms needed to construct objects in the Web.
• Section 4 discusses potential applications for objects constructed according to these techniques, and discusses how to construct objects in several "real" object models (e.g., OMG IDL, Java, and JavaScript) using these mechanisms.
• Section 5 presents some general conclusions to be derived from these technologies.

As this report will show, considerable work is in progress on technologies that are relevant to object construction in the Web, and there are numerous alternative technologies available to address various parts of the problem. Hence, the integration of Web and object technologies as described here is extremely promising. What will be important will be the emergence of a few relatively popular mechanisms for addressing the various parts of the problem, together with widespread support from the Web infrastructure, products, and standards.

Caveats

The following subsections describing the various technologies include text and specific examples taken from the cited references. As with the previous report, the purpose in doing this is to bring together in one place enough material to illustrate key concepts and the roles they might play in supporting a Web object model, and to give the reader a feel for how generalizations of these concepts might be developed. Hence, this report makes no claims of originality for most of this material, and readers should refer to the cited sources for further details.

In addition, this report does not claim to be totally comprehensive. The specific technologies cited are not necessarily the only technologies in these areas under development; instead, they are cited as examples or illustrations of the types of technologies being developed. New technologies appear quite frequently.

Finally, a number of the sections refer to ongoing activities of the World Wide Web Consortium (W3C). The reader should be aware that in many cases the specifications and capabilities described are works in progress. As a result, some of the details described in this report, as well as the source references, may no longer be completely accurate (or accessible due to changed URLs) by the time this report is read. The latest information on these activities can always be obtained through the main W3C Web page <http://www.w3.org/>.

2. Web Object Model Construction and Design Issues

[Man98] described a general approach for integrating Web technologies to form a Web object model, based on the idea that an "object" in a conventional object model is basically a piece of state with some attached (or associated) programs (methods). In many object model implementations, this idea is exactly reflected in the physical structure of the objects. For example, a Smalltalk object consists of a set of state variables (data), together with a pointer (link) to a class object which contains the object's methods. The structure is roughly:

    Object (state)                Class object
  +---------------+              +-------------+
  | class pointer |------------->| Class data  |
  +---------------+              +-------------+
  | variable 1    |              | method 1    |
  | variable 2    |              | method 2    |
  |   ...         |              |   ...       |
  | variable n    |              | method m    |
  +---------------+              +-------------+

C++ implementations use similar structures. The state is a collection of programming language variables, which (usually) are not visible to anything but the methods (this is referred to as encapsulation). A typical object model has a tight coupling between the methods and state. All the structures (class objects, internal representation of methods and state, etc.) are determined by the programming language implementation, and are created together as necessary. The class (in particular, the methods it defines) defines the way the state should (and will) be interpreted within the system, and hence is a form of metadata for the state. As a result, the link between an object and its class is essentially a metadata link.

Extending this idea to the Web environment, the idea is that Web pages (or parts thereof) can be considered as state, and objects can be constructed by enhancing that state with additional metadata that allows the state to be considered as objects in some object model. In particular, we want to enhance Web pages (or parts of them) with metadata consisting of programs that act as object methods with respect to the "state" represented by the Web page (or part thereof). The resulting structure would, at a minimum, conceptually be something like:

                       +----------+
           +---------->| method 1 |
+-------+  |           +----------+
|  Web  |--+              ...
|  page |--+           
+-------+  |           +----------+
           +---------->| method n | 
                       +----------+

There are already a number of mechanisms used in the Web to integrate code (behavior) with Web pages, so the construction mechanism may be either simple or complex.

Constructing these object model structures requires a number of "pieces" of technology. [Man98] identified the following pieces:

• a representation for object state; this role to be played by XML pages (or parts of them)
• an API to this state, so that programs can readily access it; this role to be played by the DOM
• pieces of code to serve as object methods; this role to be played by
  • OBJECT elements embedded in the state
  • other pieces of code defined as or within Web resources separate from the state, identified by URLs, that are designed to access the state via its DOM-based interface
• a way to define the relationships between the state and the methods (the linkages in the above diagrams)
• a way to access and invoke the code as necessary when the state (Web document) is accessed

Section 2.1 goes into somewhat more detail on these Web object model "pieces", both identifying additional "subpieces", and also identifying some technologies for implementing those "pieces". Some of these technologies are covered in additional detail in Section 3. Section 2.2 then discusses some considerations that apply to Web object model design.

2.1 Web Object Model Construction Requirements

As noted above, objects consist of a number of different "pieces". Hence, when constructing objects, it is necessary to provide for the implementation of each of those "pieces". This section reviews these pieces, briefly reviews some alternative means for implementing them, and also reviews some additional requirements related to object construction in the Web. The various pieces identified here are in some sense conceptually distinct. However, a given technology may bundle several of these pieces together so that they do not appear as separate concepts.

2.1.1 State Representation

An object's state representation is used to hold various pieces of data that are operated upon by the object's operations, and that retain information from one operation invocation to the next. [Man98] discussed using XML documents as the basic representation for the state of objects in a Web object model, but made no other assumptions about the format of state. That is, there were no assumptions about a specific data/object model for state, about required elements, etc. In general, it is desirable to be able to create objects from any well-formed XML, and hence there should be minimum restrictions on the form of such XML.

These assumptions (or rather, the lack of them) means that the state can have a very general form, given the generality of XML. For example, the state of an object need not be all in one unit (or file), since XML allows a document to refer to external entities that can contain either XML or data in some arbitrary representation. In addition to referencing other data using entities, XML documents, like HTML pages, can also use hyperlinks to other documents or Web resources, and these could be considered as part of the state defined by the document, depending on the semantics that the software that interprets the object attaches to this linked material. At the same time, the state of an object could be defined as being a subset of an XML document, i.e., a given XML document could represent the state of multiple objects. This is so because an XML document represents a tree of separately-marked elements. A given element could be interpreted as being a separate object, with its type and associated methods identified by the element tag. Some of these techniques are discussed in Sections 3.2 and 3.3. (Introductory material on XML may be found in [Man98], or in a number of recent texts, e.g., [Har98, Hol98, Lig97, Meg98, StL98].)

2.1.2 Methods (Behavior)

An object's methods (programs) implement the operations that can be applied to the object. Supporting object methods imposes a number of requirements:

• There must be a way to represent the methods (the code).
• There must be hardware or software (an interpreter) to interpret/execute the methods. In addition, if objects support methods written in different implementation languages, there must be a way to identify the appropriate interpreter for each method.

Behavior associated with Web pages today is represented as binary executables (e.g., plugins, DLLs, ActiveX controls), Java bytecodes, and scripts in various scripting languages. Each of these forms requires its own interpreter. Binary executables are generally interpreted by the hardware. Java bytecodes require the Java Virtual Machine. A scripting language requires an interpreter for that language. In a situation where methods may have multiple representations or languages, the interpreter that must be invoked to interpret a given piece of code must somehow be indicated. This may be done in various ways, e.g., by the file extension of the file containing the program, or by the LANGUAGE or TYPE attribute in an HTML SCRIPT element. The need to support multiple interpreters is illustrated by Microsoft's Internet Explorer 4 (IE4) browser, which supports HTML pages having scripts in either VBScript or JScript (Microsoft's implementation of JavaScript). The SCRIPT element must indicate which scripting language is being used (a given page can contain scripts in both languages).

Proposals have also been made to represent programming language constructs directly in HTML and XML (i.e., define elements/tags which represent programming language statements for control flow, function calls, etc.) as yet another representation of Web page behavior. Several such approaches are discussed in Section 3.4. These approaches effectively define another scripting notation, where the special tags are interpreted by their own interpreter to generate the specified behavior.

2.1.3 Method/State Relationships

Object construction involves supporting two types of method/state relationships:

• There must be a way to identify which methods apply to which objects, i.e., to associate specific methods with specific units of state.
• There must be a way (an API) for the methods to access the state during their execution.

In non-object software, programs and data are separate, and programs are explicitly passed the data they are to operate on. Objects, on the other hand, involve a more explicit specification of which programs (methods) apply to which state. Methods can be associated with the state to which they apply in a number of ways, and for purposes of this paper, we take a rather loose interpretation of how tight this association must be. This is discussed further in Section 2.2.

[Man98] noted that programs, as descriptions of behavior, could be considered a form of metadata, and hence could be described using either embedded or separate RDF resources. For example, an RDF resource associated with a given Web page could contain OBJECT elements (or some corresponding XML constructs) that identify the programs that act as the page's methods. Alternatively, the RDF resource might refer to programs defined as Web resources using some mechanism other than the OBJECT element, and also include a reference (possibly as an OBJECT element) to a "loader" mechanism capable of accessing those programs and providing them to the client on request. RDF resources contain explicit references to the Web pages for which they define metadata. However, they do not require that the Web pages themselves be aware of the existence of this metadata, and hence do not require that the pages be created with (or modified to contain) references to the metadata. Thus, using an RDF-based approach would allow Web pages to be associated with object methods without the pages themselves having to contain references to the methods.

However, while methods can be considered a form of metadata, and hence could in principle involve RDF, there are a number of alternative (and generally more straightforward) mechanisms that are also available.

Possibly the most straightforward approach to associating methods with a Web page is to embed either the method itself, or a pointer to it, in the page. Scripts are often implemented as directly embedded methods, using the HTML SCRIPT element to contain the script. Applets are usually implemented by embedding a pointer to the file containing the applet in the page, using the HTML APPLET or OBJECT tag. Scripts can be implemented using pointers to external files as well. In particular, SCRIPT elements can be used to associate collections of scripts with a page, thus forming something akin to an object class. Separately linked style sheets also provide a way of associating sets of behaviors with HTML documents.

These mechanisms for associating methods with HTML pages involve the use of special tags, e.g., OBJECT and SCRIPT, along with built-in mechanisms for processing them. XML per se does not define such standard tags. However, XML defines a number of mechanisms that can be used to define elements that contain scripts or other method representations, or pointers to them. These methods could then be processed (interpreted) by separate interpreters (much as Web browsers refer HTML SCRIPT and OBJECT elements to specific interpreters). In addition, W3C's Extensible Style Language (XSL) <http://www.w3.org/TR/WD-xsl> represents work toward a way of associating formatting behavior with XML documents. Additional XML-related technology is also being developed to support other ways of associating behavior with XML pages. These XML-based technologies are discussed in Section 3.2.

Current HTML mechanisms for associating methods with Web pages deal not only with associating methods with pages as a whole, but also with associating methods with specific parts of Web pages. For example, a given script can be associated with a particular HTML element to provide behavior for that specific element (e.g., to define what happens when the user clicks on it). The same script could also be associated with multiple elements. Stylesheets also provide mechanisms for associating styles with specific HTML elements (or possibly all elements satisfying specific criteria). Mechanisms for associating methods with XML pages must provide corresponding capabilities. This is particularly important in the context of XML, since each XML element type (tag) potentially represents distinct semantics, and hence may need to be associated with behavior specific to those semantics.

Another form of method/state relationship is the way the methods gain access to the state (for reading or updating it). The form of this access is a particularly important consideration in building objects from XML documents, which may have a complex structure, as opposed to the simple "flat" state typically found in programming language objects.

The most straightforward approach for providing this access would be to simply provide each method with access to the character string making up the XML state. However, this would require that the method effectively parse the state in order to find the particular part of the XML document it needed to work on. [Man98] identified the W3C's Document Object Model (DOM) as a means by which methods could conveniently access the (XML-based) state. The DOM provides a generic object-oriented API for XML documents, permitting methods to access individual elements (and other components) of the XML without having to parse the document. The use of an explicit DOM interface to the object state representation also provides another advantage, namely an additional degree of generality in choosing the state representation. This is because, if methods access the state through the DOM interface, any representation (not just XML) could conceivably be used in building an object, provided that a DOM (or DOM-based) interface could be defined for it.

The DOM itself defines only a generic API to an XML document (e.g., it presents the document as a collection of objects of types such as Document, Element, and so on). It does not provide for the construction of application-specific interfaces based on the interpretation an application may assign to specific element names (e.g., the DOM does not provide a specialized interface for an AUTHOR object even though the document's outer element tag may be AUTHOR, and those are the intended semantics of the document). Instead, additional processing must be applied to the XML to provide such interfaces, possibly as specializations of the DOM-defined interfaces. Examples of technology to define such interfaces are described in Sections 3.1 and 3.3.

In some cases, providing a method with access to state needs to be done in what might be considered multiple steps. For example, Java applets associated with a Web page have no native way to access the page directly. Netscape's LiveConnect technology, discussed in Section 3.1, provides such a mechanism.

The approaches discussed above are more-or-less "Web-native" ways to associate behavior with Web pages. A conceptually different approach is that used in providing object interfaces to non-object data (such as relational databases) in distributed object systems using object "wrappers" or "shells". In this approach, ordinary objects in some object-oriented implementation technology are created, which use Web data as their state (e.g., they might retrieve data from the Web when they need access to state information). These approaches are not discussed further here, but are discussed in, e.g., [App97, OH98].

2.1.4 Interfaces and Related Metadata

In addition to methods and state, objects typically define interfaces for use by other objects or external clients. An object's interface is an API that determines which object methods and state are revealed to external clients, and that conceals (encapsulates) the details of the actual method and state representations from those clients. Supporting object interfaces creates several requirements:

• there must be a model for the interfaces (to define what must be contained in the interfaces)
• there should be a way to specify the interfaces (an Interface Definition Language)
• there must be a way to represent the interfaces (as metadata, for use by any components that need to access the interface definitions)

The extent to which an interface is needed in constructing objects in the Web depends on how serious the desire is to create "true objects" (e.g., objects with characteristics similar to those of programming language objects). If all that is required is some loose idea of Web pages with behavior, no specific interface technology is required. On the other hand, if it is desired that the XML plus behavior appear to be an object in some well-defined object model, such as a JavaBean or CORBA object, then specific interface support technologies become more relevant.

Generally, it is possible to define objects in many different object models using the same basic internal components (e.g., methods and state). The W3C DOM specifications illustrate how an XML document can be represented as objects in CORBA IDL, ECMAScript, and Java. Section 3.1 illustrates how XML can be used to construct objects in both Java and JavaScript (despite the similarity of the names, these are two distinct object models) using some specific interface support technologies.

The NCITS Object Model Features Matrix [Man97] identifies many different object models, with widely differing characteristics and ways of defining object interfaces. Different object models could also be used for objects in the Web. The details of the structures to be supported in a Web object model depend on the details of the object model we choose to define. For example, many object models are class-based, such as the C++ and Java object models. Choosing a class-based model for the Web would require defining separate class objects to define the various classes. Other object models, such as JavaScript, are prototype-based, and do not require a class object (each object essentially defines itself).

In typical distributed object systems, such as CORBA, interface definitions are sometimes used by stub generators to generate code for accessing objects, and hence the interface definitions themselves may not be needed at run time in processing method invocations. However, in other situations (such as dynamic invocation) it may be necessary to access the interface definitions at run time. As a result, the interface definitions are saved in some form of Interface Repository so they can be accessed when needed. This requires that an explicit representation for interface definitions be considered. In the context of the Web, a straightforward approach would be to represent object interface definitions in XML. A number of Web technologies described in Section 3 use XML to define interfaces. The XML element types (tag names) used in these XML representations are based on the particular object model chosen.

An important supporting technology in the definition of interfaces for objects in the Web (and in expanded applications for XML in general) would be improvements in the ability to define data type information for XML. XML Document Type Definitions (DTDs) are sometimes characterized as being like database schemas, or object class definitions; i.e., as defining the characteristics of a collection of instances (individual XML documents). However, this is only true to a limited extent. David Megginson, in a recent email message to the xml-dev email list, has noted that XML DTDs actually "bundle" several roles (inherited from SGML DTDs):

• they provide a schema for validating the logical (element/attribute/data) structure of an XML document (this can also provide enough information to control a guided XML authoring tool).
• they declare the entities (internal strings or external objects) that make up the physical structure of an XML document (see the discussion of XML entities in Section 3.2.1).
• they provide default logical content for an XML document (such as default attribute values).

Unlike a schema or class definition, the DTD for a given document may be partially contained in the document itself (the internal subset). In addition, DTDs provide only very limited support for defining what would be recognized as data types in an object model. Most XML elements are from the single domain "character string". Although external entities having non-character representations can be identified using XML NOTATION specifications (see Section 3.2), these resemble MIME types rather than data types, in that they can be used to identify a processing application, but do not constrain the data at the individual data element level as a conventional data type mechanism would.

A number of proposals have been made for alternative schema and data type facilities for XML, including:

• XML-Data <http://www.w3.org/TR/1998/NOTE-XML-data>, a W3C submission defining a mechanism for describing DTD information and "schemas" directly in XML.
• XSchema <http://www.simonstl.com/xschema/>, another mechanism for describing DTD information directly in XML (not submitted to W3C).
• Document Content Description for XML <http://www.w3.org/TR/NOTE-dcd>, a W3C submission from Microsoft and IBM defining another XML structural schema facility (it defines a subset of XML-Data as RDF metadata).

However, none of these is an official W3C specification. In addition, in related work:

• the W3C's RDF activity has defined RDF Schemas <http://www.w3.org/TR/WD-rdf-schema> as a type system for RDF.
• the HTTP-NG activity has defined a proposed type system in their Architectural Model working draft <http://www.w3.org/TR/WD-HTTP-NG-architecture> (see Section 3.5.3).

It is generally agreed that improvements are needed in XML's structural schema and data typing facilities. There is also considerable agreement that the data typing facilities should be unbundled from the structural schema mechanism. These technologies will not be discussed further here. However, it should be noted that there are plans for W3C's XML activity to begin work on improvements in schema and data typing facilities for XML.

2.1.5 Pulling Objects Together

An interface definition only defines an interface (object API). The effect of the interface (an implementation for it) must also be provided. That is, there must be something that combines the interface, state, and methods into an object (unit of software). In conventional object-oriented programming languages, these "pieces" are compiled into the objects, which themselves (possibly together with some built-in run time support, such as a dispatcher) provide the implementation. In other cases, such as CORBA implementations, the system is designed to allow separate pieces of state and methods to be combined to form objects. In these cases, a conceptually-separate layer of software (in the case of CORBA, an Object Request Broker) is involved. This software (generically speaking) accepts a call on a method of a particular object, finds the state and method code referred to in the request, and invokes the method on the state.

Both these approaches to "pulling objects together" are illustrated by the technologies discussed in Section 3. In some cases, XML-encoded information, possibly together with other object "pieces", is translated into objects interpretable by an existing object interpreter (e.g., into Java or JavaScript objects). In other cases, a separate interpreter or other piece of software is used to interpret the XML and other object "pieces" as objects (e.g., the Scriptlets runtime engine discussed in Section 3.1.4.2).

2.1.6 Additional Requirements

In addition to the "pieces" identified above, creation of a fully-general Web object model requires addressing a number of additional issues. For example, changes in the architectures of Web clients and servers may be required. The WebBroker technology described in Section 3.5.1 involves adding an HTTP server to the client. [StL97] discusses extended architectures for both Web clients and servers, as well as extended file system (or OODBMS) support, for use with enhanced Web technologies.

Other, more general, architectural issues must also be addressed. For example, if the Web is to be used as a generalized information repository (whether objects are used or not), the issue of updating needs to be addressed. The DOM provides a general interface (at least potentially) for updating XML documents on the client side. However, better mechanisms are needed for conveying these updates to the server, and implementing them there. This includes protocol-level work such as WebDAV (Web Distributed Authoring and Versioning) <http://www.ietf.org/internet-drafts/draft-ietf-webdav-protocol-08.txt>, work on improved security mechanisms, and work on higher-level mechanisms for synchronizing concurrent updates. Such work includes work on versioning, simple locking (which is covered in the WebDAV work), and higher-level database-like transaction mechanisms (the WebDAV work uses XML to represent both method input and output information in its protocol). Additional work is also required on improved Web messaging protocols. A number of mergers of Web and object technologies, such as the WebBroker technology discussed in Section 3.5.1, use the existing HTTP protocol for object-oriented messaging. However, work such as HTTP-NG <http://www.w3.org/Protocols/HTTP-NG/> aims at improvements in the Web's support for "purer" object-oriented messaging (e.g., the use of a binary, rather than a text-based, format). Addressing these and other issues, such as support for improved caching schemes, will make the Web an even better vehicle than it is now for efficiently implementing objects.

2.2 Some Web Object Model Design Considerations

[McG98] notes that: "With the addition of purely electronic media, the already nebulous notion of a document becomes even more so. Electronic document content can include sound, video, virtual reality simulations, and so on. Furthermore, such documents can contain behaviour. The emergence of Object Orientation as a development paradigm has lead to a convergence of the concepts of document and object. Documents that can contain behavior (i.e., executable code) plus state information as well as data can be thought of as persistent objects in OO terminology."

However, creating objects from Web resources involves reconciling two organizational philosophies that appear somewhat distinct. On the one hand, the conventional idea in object-oriented programming is that the behavior defined for an object is "mandatory"; an essential component in defining the semantics of an abstract data type. Having only data, even using semantically-meaningful attribute names as in XML, could allow the data to be used inappropriately, in a way that is not consistent with the actual intended type semantics (which are defined by the operations).

On the other hand, the SGML philosophy (from which XML and much of the Web derives) is that the essential semantics are wrapped up in the data alone (in particular, in the element names). In this philosophy, there are a number of good reasons for not binding operations too tightly to the data (if at all). For example, labeling elements instead of explicitly binding them to code avoids locking information into one program, or even one purpose [DeR97]. This is particularly important in the case of a representation (like XML) with possibly-rich semantics, which may be moving between organizations. For example, a Purchase Order represented in XML, and transferred between two businesses, will probably not be processed by the same programs at each end. Instead, the XML would be linked to distinct (company-specific) processing. So, according to this approach, it is enough to tag the document as being a PURCHASE-ORDER, and rely on a separate mechanism to associate a PURCHASE-ORDER with the appropriate application(s). The use of MIME types in the Internet illustrates the value of this general approach, since it allows the use of different programs on the same data, while also providing information (the MIME type) that helps see to it that only programs capable of processing the data are actually used. The use of XML element names provides a similar form of indirectness in associating behavior with data, but at the granularity of individual elements. This same concept is also very much along the lines of the thinking behind the use of a relational database as a generalized information repository which can then be used by multiple applications. The need for care in how tightly behavior is associated with data also shows up in object analysis and design.

In general, it is desirable to support flexibility in how tightly behavior is associated with data, since in some cases a tightly-coupled object-oriented programming style will be appropriate, while in other cases a looser coupling will be appropriate. For example, in some cases it might be appropriate to agree on a definition of each element type, and possibly even to include a pointer to a machine-accessible version of that definition as metadata (e.g., an ontology), but not to require the use of a specific piece of code to process it. On the other hand, in some cases it may be desirable to provide standard pieces of code to process particular elements (e.g., to implement industry-standard semantics where process interoperability is involved, or industry-standard algorithms for certain kinds of processing exist). In addition, it is desirable to support the ability to change the decision as to how tightly behavior is associated with data, to accommodate changes in requirements or other circumstances.

These requirements for flexibility particularly exist in the Web, given its dynamic and heterogeneous nature. At the same time, however, Web technologies provide the necessary infrastructure to support these requirements. For example, the Web infrastructure supports remote access to code, which makes tightly coupling data with "standard" code more feasible. Moreover, XML and related technologies described in Section 3.2 illustrate that a range of mechanisms exist for supporting both loose and tight coupling of data and behavior. Interface implementation mechanisms such as Object Request Brokers provide another mechanism for flexibly associating data and behavior. A Web object model must support these flexibility requirements, and take maximum advantage of the Web's capabilities in doing so.

The above comments have primarily concerned flexibility in the Web at the object construction level. Flexibility is also required at the model level. An object model for objects in the Web itself needs to be flexible, in the sense of providing support for interoperability among the wide range of data and processing resources on the Web, much as a global data model provides this type of support in a heterogeneous distributed database system [SL90]. Section 3.1 describes some existing forms of interoperability between different object models in the Web. The idea of a global object model for the Web is discussed further in Section 4.2.

3. Technology Examples

There are numerous technologies being developed that apply to aspects of the problem of creating objects in the Web (combining state and behavior in the Web context). This section describes some of them. The primary goal is to identify what aspects of the problem they address, what sorts of lessons we can learn from them, and the state of associated technology. These descriptions should be considered as only a limited snapshot, since technology in these areas is progressing at a very rapid pace.

3.1 Scripting-Related Technologies

Currently, the most straightforward way of merging behavior and Web state is via scripting, using the Dynamic HTML (DHTML) facilities implemented in popular Web browsers. This section describes some current mechanisms for using scripting to associate behavior with HTML Web pages. As the name indicates, DHTML is an HTML technology, rather than an XML technology. Corresponding facilities must be defined for XML in order to allow XML-based scripting, and the primary purpose of this section is to give some examples of requirements for those facilities. One such facility is the W3C's Document Object Model (DOM). DOM was described in [Man98]. DOM defines an API to an HTML or XML document, by defining a representation of the document's contents in terms of a collection of objects. These objects can then be manipulated from scripting (and other) languages. The collection of objects defined in DOM is a generalization of corresponding objects defined in current DHTML implementations. Explicit mechanisms for associating scripts with XML documents must also be defined. Some mechanisms for doing this are described in Section 3.2.

This section also discusses some technologies that go beyond straight HTML. Specifically, Section 3.2.3 describes some techniques which explicitly make use of XML, or XML-like extended tags, together with scripting, for creating components (objects), in several object models, which can be embedded in Web pages.

3.1.1 DHTML and Scripting

DHTML provides a means for scripts to manipulate an HTML document's structure, style, and contents in response to events, to produce a dynamic display. The various implementations of DHTML are thoroughly described in widely-available texts, e.g., [Fla97, Isa97, StL97], so this section will only provide a very brief introduction.

DHTML defines objects that represent both an HTML document (and its contents), and also the browser environment, e.g., the browser and the browser window. A script is associated with the document using an HTML SCRIPT element. The SCRIPT element may either directly contain executable code in a specified scripting language, or associate external script libraries with the document by referencing an external file. Other elements on the page can then include specifications of particular events, e.g., onClick to indicate a user selecting the element, together with the script-defined function to be invoked when that event occurs with respect to that element. An important capability of DHTML (and the reason it is called "Dynamic") is that scripts can dynamically change what is seen by the user. Whenever a script manipulates and changes an attribute of an element or modifies the contents, the document is redisplayed with the new information. The exact DHTML facilities provided currently differ among browser implementations, which is the basic reason for the W3C DOM standards activity.

The JavaScript scripting language supported by Netscape and Microsoft (as JScript) provides the usual means for scripting in DHTML (although Microsoft Internet Explorer also supports VBScript). Some simple examples of JavaScript are distributed throughout this report (see the cited texts for more detailed examples). A particularly interesting aspect of JavaScript is its extremely flexible object model (described in the following section). For example, unlike conventional object-oriented programming languages, JavaScript functions and properties can be dynamically added to any object, and predefined behavior can be overridden. An eval method is also available that can evaluate a passed-in string as a script, and return the result.

DHTML (at least in principle) allows elements to be dynamically added to a document, either by creating a new element in memory and associating it with the document, or by directly modifying the underlying HTML contents. DHTML exposes all information about the document, including unrecognized elements and attributes. This feature can be used in some cases to create user-defined behavior based on custom elements and attributes. E.g., by adding unrecognized attributes (attributes not defined in HTML) to existing elements, the elements can be provided with additional behavior (thus providing a way to simulate subclassing of an element). In addition, user-defined elements can be added, and behavior attached to them. (The ability to do this depends on the specific browser involved, and also on the way current HTML browsers generally ignore unrecognized elements and attributes).

The HTML OBJECT element allows controls and applets to be included in a page that extend the available behavior. For example, objects can be defined to embed graphics or even other documents directly into the document.

Motivations cited for the use of scripting languages versus more conventional programming languages (in some cases, including Java) include:

• Use of scripting languages avoids the need to use a separate development environment and write a program in order to add active content to a Web page
• Binary objects (including ActiveX controls and non-Java programs) are inherently platform-dependent; there would need to be a system-specific version of the program for each runtime environment.
• Downloading binary objects incurs additional delays, a particular issue for low-bandwidth Internet connections

DHTML provides support for a number of the "pieces" required in constructing objects in the Web:

• a way to encode the behavior (the scripting language)
• a way to associate the behavior not only with the page as a whole, but also with specific parts of the page (SCRIPT elements)
• a way for the behavior to access the page (the DOM)
• an interpreter for the behavior (the script interpreters in or accessible from the browsers)
• a way to invoke the behavior (based on either page-oriented events, or direct invocation of script-defined functions)

Similar facilities will need to be provided to support XML-based scripting. Some of these facilities are defined already (e.g., the DOM for XML); others are discussed in Section 3.2.

3.1.2 ECMAScript Object Model

ECMAScript [ECMA97] is an object-oriented programming language for performing computations and manipulating computational objects within a host environment. ECMAScript is essentially the standardized specification of JavaScript (it is based on both Netscape's JavaScript and Microsoft's JScript scripting languages), and hence was originally designed to be a Web scripting language, providing a mechanism to add behavior to Web pages in browsers and to perform server computation as part of a Web-based client-server architecture. However, ECMAScript can provide core scripting capabilities for a variety of host environments, and therefore the ECMAScript language per se is not intended to be computationally self-sufficient. For example, there are no provisions in the ECMAScript specification for input of external data or output of computed results. Instead, it is expected that the host environment of an ECMAScript program will provide not only the objects and other facilities described in the language specification, but also certain environment-specific host objects, whose description and behavior include properties and functions that provide the necessary additional facilities, and which can be called from an ECMAScript program.

For example, a Web browser (client) provides an ECMAScript host environment for client-side computation which includes objects that represent windows, menus, pop-ups, dialog boxes, anchors, frames, history, cookies, and input/output (these objects are defined by DHTML's Document Object Model, and the DOM being specified by the W3C). Further, the host environment (DHTML in this case) provides a means to attach scripting code to events such as change of focus, page and image loading, selection, form submission, and mouse actions. Scripting code appears within the HTML, and the displayed page is a combination of user interface elements and fixed and computed text and images. The scripting code is reactive to user interactions and there is no need for a main program. A Web server would provide a different ECMAScript host environment for server-side computation which includes objects representing requests, clients, and files, and mechanisms to lock and share data. By using browser-side and server-side scripting together it is possible to distribute computation between the client and server while providing a customized user interface for a Web-based application. Each Web browser and server that supports ECMAScript supplies its own host environment, completing the ECMAScript execution environment.

ECMAScript is object-based: basic language and host facilities are provided by objects, and an ECMAScript program is a cluster of communicating objects. An ECMAScript object is an unordered collection of properties. Properties are containers that hold other objects, primitive values, or functions. A function stored in the property of an object is called a method. A property can also have 0 or more attributes which determine how the property can be used--for example, when the ReadOnly attribute for a property is set to true, any attempt by executed ECMAScript code to change the value of the property has no effect. A type in ECMAScript is a set of data values. A primitive value is a member of one of the following built-in types: Undefined, Null, Boolean, Number, and String; an object is a member of the remaining built-in type Object.

ECMAScript defines a collection of built-in objects which completes the definition of ECMAScript entities. These built-in objects include the Global, Object, Function, Array, String, Boolean, Number, Math, and Date objects. ECMAScript also defines a set of built-in operators which are not, strictly speaking, functions or methods, including various unary operators, mathematical operators, bitwise operators, relational operators, assignment operators, and so on.

ECMAScript syntax intentionally resembles Java syntax, but is relaxed to enable it to serve as an easy-to-use scripting language. For example, a variable is not required to have its type declared, nor are types associated with properties; the values stored in properties can change type at runtime.

ECMAScript does not provide classes such as those in C++, Smalltalk, or Java, but rather, supports constructors which create objects by executing code that allocates storage for the objects and initializes all or part of them by assigning initial values to their properties. All functions including constructors are objects, but not all objects are constructors. Each constructor has a Prototype property which is used to implement prototype-based inheritance and shared properties. Objects are created by using constructors in new expressions, for example, new String("A String") creates a new string object. Invoking a constructor without using new has consequences that depend on the constructor. For example, String("A String") produces a primitive string, not an object. Storage management is handled by a garbage collector.

ECMAScript supports prototype-based inheritance. Every constructor has an associated prototype, and every object created by that constructor has an implicit reference to the prototype associated with that constructor. A prototype may have a non-null implicit reference to its prototype, and so on; this is called the prototype chain. When a reference is made to a property in an object, the reference is to the property of that name in the first object in the prototype chain that contains a property of that name. In other words, first the object mentioned directly is examined for the property; if that object contains the named property, that is the property to which the reference refers; if that object does not contain the named property, the prototype for that object is examined next; and so on. All objects that do not directly contain a particular property that their prototype contains share that property and its value.

Unlike class-based object languages, properties can be added to objects on the fly simply by assigning values to them. That is, constructors are not required to name or assign values to all or any of the object's properties.

There is a unique global object which is created before control enters any execution context. Initially the global object has the following properties:

• Built-in objects such as Math, String, Date, etc.
• Additional host-defined properties. This may include a property whose value is the global object itself, for example, window in HTML.

As control enters execution contexts, and as ECMAScript code is executed, additional properties may be added to the global object, and the initial properties may be changed. This, among other things, provides support for global variables.

ECMAScript's flexibility, as well as the fact that it is a "native" (to Web browsers) way of specifying behavior, allows it to play the role of an integrating technology in associating behavior with Web pages. This will be illustrated in several of the subsequent sections.

3.1.3 LiveConnect

LiveConnect is a technology introduced in Netscape 3.0 for providing an interface between JavaScript and Java [Hal98]. Such an interface is important because, while a JavaScript script has direct access to the page in which it is contained, an ordinary Java applet does not. This is so even though the applet is referenced from the HTML document, and its output might be displayed within the resulting page. LiveConnect allows applets to manipulate frames and windows, control images loaded from HTML, and do other things previously restricted to JavaScript, while also allowing JavaScript to access the capabilities of applets. In addition to its use in Netscape products, LiveConnect software can also be supported within Microsoft Internet Explorer 4.0.

One "direction" of using LiveConnect allows Java applets to be accessed from JavaScript. For example, if JavaScript needs to perform a complex computation, it may be easier to write this as a "hidden" applet called from JavaScript than as a native JavaScript function. JavaScript can access applets via the document.applets array, which is an array of objects representing each applet in the document, and is defined as part of DHTML's Document Object Model. (The W3C's DOM (HTML) Document object has a corresponding applets collection). If the applet is named, it can also be referred to by name, i.e., document.<appletName>. Any public method of the applet can be called by JavaScript. In the following example (from [Hal98]), the applet Acoustics supports a way of computing sound propagation through water, and a Web page is being created that requires that computation. The applet would be included in the page using:

<APPLET CODE="Acoustics" WIDTH=10 HEIGHT=10 NAME="acoustics">
</APPLET>

A JavaScript function calling the public getSignalExcess method of the acoustics applet would then be defined as:

function signalExcess(...) {
   return(document.acoustics.getSignalExcess(...));
}

The JavaScript signalExcess function could then be used wherever needed to compute the required values (in effect, the applet call is wrapped by the JavaScript function). In this case, the applet is referred to by the name document.acoustics.

The other "direction" of using LiveConnect allows applets to access JavaScript. This allows the use of Java syntax to access all JavaScript objects, read and set all available properties, and call any legal method. To use this approach, Netscape's JSObject class must be obtained and imported into the Java applet. This class supports a static method getWindow that allows the applet to obtain a reference to the window that contains it (as an object of type JSObject), as in:

JSObject Window = JSObject.getWindow(this);

The Window object's getMember method can then be used to read properties of the main window, and via the values of these properties, other parts of the window (JavaScript objects) can be accessed.

The ability to access page contents as data (i.e., an API to the page) is clearly a necessity in adding behavior to pages. LiveConnect provides this capability for HTML and Java, and some such capability is also required for XML. The most straightforward means of providing this would be for XML-supporting browsers to directly support DOM interfaces in a range of programming languages (including Java).

3.1.4 Script Components

Two relatively recent technologies, JavaScriptBeans from Netscape, and Scriptlets from Microsoft, illustrate a more thorough integration of Web pages with behavior and interfaces, by using XML (or XML-like) markup, together with scripts, to define components. These technologies combine:

• specialized tags to define an object interface
• tags to define a script that provides the methods and variables (state) to implement that interface
• a mechanism for interpreting those tags to make the component behave as an object

3.1.4.1 JavaScriptBeans

JavaScript Beans (henceforth JSBs), also referred to as JavaScript components, are described in an online article Picking the Newest Crop of Beans, by Emily Vander Veer [VV97] <http://www.sigs.com/publications/objm/9711/vanderveer.html>, and in [Nic98]. JSBs are packages of JavaScript code that support an interface exposing properties, events, and methods. JSBs are implemented by text files with a .jsb extension. The files can be created by hand, or by using Netscape's Component Builder. Each .jsb file defines a JSB's properties, methods, and events, using HTML- (or XML-) like tags.

The following example <http://www.sigs.com/publications/objm/9711/vanderveer.code.html> defines a non-persistent client-side JSB that displays a configurable scrolling message in a browser's status bar. The JSB_PROPERTY and JSB_METHOD elements define the properties and methods, respectively, exposed at the component's interface. To use the AWT 1.1 event model, the additional elements JSB_EVENT and JSB_LISTENER would be used. If a method has parameters, each parameter is specified using a JSB_PARAMETER element inside the corresponding JSB_METHOD element. The JSB_CONSTRUCTOR element contains the JavaScript code (omitted here) for each defined method, and a constructor function (the last function defined) for the JavaScript component. The constructor code of a JSB is similar to the code that would be run to construct a user-defined object in JavaScript. Once the component is instantiated, it's scroll(), stop(), and reset() methods will be exposed for invocation from other components.

<JSB>
      <JSB_DESCRIPTOR NAME="netscape.peas.ScrollingBanner" 
            DISPLAYNAME="Scrolling Banner" 
            ENV="client" 
            CLASS="" 
            CUSTOMIZER="" 
            SHORTDESCRIPTION="JavaScript Scrolling Banner">
      <JSB_PROPERTY NAME="msg" 
            DISPLAYNAME="Message" PROPTYPE="JS" TYPE="string" 
            READMETHOD="" WRITEMETHOD="" 
            SHORTDESCRIPTION="Text message to scroll in status bar">
      <JSB_PROPERTY NAME="speed" 
            DISPLAYNAME="Scroll Speed" 
            PROPTYPE="JS" TYPE="number" VALUESET="0:200" 
            READMETHOD="" WRITEMETHOD="" 
            SHORTDESCRIPTION="Scrolling speed">
      <JSB_PROPERTY NAME="position" 
            DISPLAYNAME="Start Position" 
            PROPTYPE="JS" TYPE="" 
            READMETHOD="" WRITEMETHOD="" 
            SHORTDESCRIPTION="Starting position of message">
      <JSB_METHOD NAME="scroll" TYPE="void"> </JSB_METHOD>
      <JSB_METHOD NAME="stop" TYPE="void"> </JSB_METHOD>
      <JSB_METHOD NAME="reset" TYPE="void"> </JSB_METHOD>
      <JSB_CONSTRUCTOR>
            function scroll(){ //snip script }
            function stop(){ //snip script }
            function reset() { //snip script }
            function netscape_peas_ScrollingBanner(params){ //snip script }
      </JSB_CONSTRUCTOR>
</JSB>

Tools that read JSBs, like Netscape's Visual JavaScript, use the JSB file as the basis for automatically-generated JavaScript code, essentially translating the JSB into conventional JavaScript which can be interpreted by the browser. Since the result of a JSB is actually JavaScript, the JSB can be linked with other components on the page (or, using LiveConnect, with applets). JSBs can run on both Netscape Navigator or Microsoft Internet Explorer clients, and on Netscape's Enterprise Server (the JSB definition provides control over whether the bean can run on the client, the server, or both).

If a JSB has no support files, it can be used in a single .jsb file. However, JSBs can be made up of more than one file, including JavaScript code or external Java .class files. In this case, all the files can be packaged into a Jar file, for distribution as a unit.

[Nic98] notes that Visual JavaScript allows CORBA objects to be used in much the same way as JavaBeans and JSBs, through the use of JSBs. To do this, a file containing the IDL definitions for the CORBA objects is loaded into the Visual JavaScript tool. During this process, each IDL interface definition in the file is converted to a JSB, which serves as a wrapper or proxy for the (potentially remote) CORBA object. IDL attributes are converted into JSB properties. Other properties are also added by Visual JavaScript, e.g., an ObjectURL property, which allows the user to specify a URL which identifies the actual location of the CORBA object. At runtime, the CORBA object is found using the value of this property. IDL operations are converted to JavaScript method declarations (with data types converted to Java data types). Again, these methods serve as wrappers for the methods of the CORBA object. At runtime, the component will be connected to an actual CORBA object on the server. The JavaScript program references this object through a property called corbaObject.

Another technology for defining interfaces between JavaScript and CORBA objects is the CORBA Component Scripting response (orbos/97-11-27) from Netscape, Oracle, Visigenic, Sun, and Genesis to the CORBA Scripting Language RFP. This response proposes JavaScript (ECMAScript) as a CORBA scripting language, and is based on the use of LiveConnect technology. The approach involves constructing a JavaScript reflection of CORBA objects, which allows the CORBA object to be manipulated as if it were a JavaScript object. Property access and function calls in JavaScript are translated to accessors and method calls on the corresponding CORBA object. To construct the reflection, the CORBA IDL interface is mapped to a JavaScript object which serves as a prototype. Instances of that interface are represented by a JavaScript object whose prototype is the interface object. Attributes are mapped to properties of the JavaScript object. Methods are mapped to (JavaScript) function-valued properties of the JavaScript object. Invoking these functions from JavaScript causes the appropriate interface method to be invoked through the CORBA Dynamic Invocation Interface.

The response defines a complete language mapping from IDL to JavaScript. This closely parallels the LiveConnect language mapping from Java to JavaScript, which already permits JavaScript to act as an implementation language for JavaBeans and Java objects. No reverse JavaScript to IDL mapping is needed. JavaScript objects, because of runtime typing, can masquerade as objects implementing arbitrary IDL interfaces. This is implemented by using CORBA's Dynamic Skeleton interface to handle CORBA operations with JavaScript function calls or property references. Circumventing CORBA's type system in this way means that some errors will not be detected until runtime. If the JavaScript object does not have the necessary properties to implement an invocation on the interface, the CORBA::NO_IMPLEMENT exception is raised.

3.1.4.2 Scriptlets

Scriptlets <http://www.microsoft.com/sitebuilder/magazine/xmlscript.asp> (originally called "Server Scriptlets") are a Microsoft technology that allows COM components to be written in a combination of XML and a scripting language (see also [deB98, Esp98a,b]). These components can be used in the same way as any other COM component, e.g., they can be used by COM clients such as Microsoft Office, or embedded in Web pages like ActiveX components. Scriptlet support is defined as part of Microsoft's Internet Explorer 5.0 (IE5.0) Developer Preview <http://www.microsoft.com/ie/ie5/overview.htm>.

A scriptlet is defined by a file with a .sct extension, which contains script code and XML markup (using a specialized tag set). An example (from [Esp98a] is:

<SCRIPTLET>

<REGISTRATION
        Description = "Factorial"
        ProgID = "Factorial.Scriptlet"
        Version = "1.00"
        ClassID = { ***UUID for the class*** } >
</REGISTRATION>

<IMPLEMENTS ID="Automation" TYPE="Automation">
        <METHOD name="Calculate">
                <PARAMETER name="num"/>
        </METHOD>
</IMPLEMENTS>

<SCRIPT language="JScript">

function Calculate(num) {
        if(num<2)
                return 1;
        return num*Calculate(num-1);
}

</SCRIPT>

</SCRIPTLET>

The <IMPLEMENTS> element can also define component properties as well as methods, using a <PROPERTY> tag. A property can be defined either by specifying its name, as in

<PROPERTY name="Text"/>

or by explicitly specifying GET and PUT methods (which refer to functions written in the scripting language), as in

<PROPERTY name="Text">
        <GET internalname="DoGetText"/>
        <PUT internalname="DoPutText"/>
</PROPERTY>

Explicitly specifying GET and PUT methods allows for custom read and write functions, and also allows the definition of read-only and write-only properties (by only specifying a GET and PUT method, respectively).

The <REGISTRATION> tag defines the information needed to identify the COM object defined by the scriptlet. The CLSID is used instead of the file name to identify the component (e.g., in referring to it from other files). The association between the component and the file name is stored in the Windows Registry during the registration process.

Part of the implementation of scriptlets is a DLL called scrobj.dll. This is a runtime engine that interprets and executes the XML code of the scriptlet. It also acts as a broker between clients and the scriptlets. A module in the DLL provides a default implementation for the standard COM server interfaces IUnknown, IClassFactory, and IDispatch. The DLL also handles registration and dynamic instantiation.

An application uses the object's ProgID to identify the object. The ProgID is matched to a Registry entry that stores the path both to scrobj.dll and the .sct file that defines the component. Each time the client calls one of the component's exposed methods, scrobj.dll loads the proper script from the linked .sct file. A scriptlet can be inserted in an HTML page by referencing it like an ActiveX control, and invoking its methods from JavaScript.

IE5.0 also defines a mechanism called DHTML Behaviors which allows scriptlets to be associated as behaviors with specific document elements using CSS stylesheets (see Section 3.2.2.2). Scriptlets used to implement DHTML behaviors do not require registration to be used within Web pages (they are downloaded as needed). By adding a behavior handler (by specifying <IMPLEMENTS TYPE="Behavior">), such scriptlets can also expose custom events to the page, access the containing page's DHTML (DOM) objects, and receive event notifications.

Multiple scripting languages can be used for a single scriptlet's methods (a separate <SCRIPT> element is required for each language); the runtime module calls the appropriate script language interpreters as necessary.