Web Logo
The Web Meets CORBA the Geek
CORBA the geek

Jeff Mackay
Andersen Consulting
3773 Willow Road
Northbrook, IL 60047

Abstract

The World-wide web has reached critical mass. With millions of users accessing tens of millions of HTML pages daily, the web has quickly surpassed the reach of any other distributed information architecture by several orders of magnitude. Seamless integration between various components of the web and CORBA would benefit both the OMG and W3 consortiums and the industry as a whole. This position paper presents a road map for integrating CORBA with the web.

Introduction

The time for integrating CORBA with the World-Wide Web has come. CORBA excels as an architecture for distributing structured information, while the web's strength is as a mechanism for disseminating unstructured information. In applying the two technologies separately through efforts undertaken as part of the ARPA-sponsored Technology Reinvestment Project, we see the need for merging aspects of the two architectures.

This position paper discusses the need for integration of CORBA and the web. It covers both sides of the equation: modifications are necessary for both CORBA and for the web in order for seamless integration to occur. Note that many of the issues discussed in this paper are covered in more detail in other research efforts. The focus of this paper is on prioritizing the issues and recommending a course of action.

A Web Facility

The highest priority requirement in providing interoperability between CORBA and the web is in standardizing the interfaces used in web application development. CGI, the current method of enabling dynamic behavior for web-based applications, does not scale to complex or large applications. To address this lack of scalability, HTTP server vendors are creating their own (non-portable) application programming interfaces. Netscape and Microsoft are among the vendors who have created their own incompatible APIs for HTTP servers. With multiple vendors providing different APIs for the same purpose, this is an ideal situation for OMG standardization. The OMG should create a web common facility that standardizes these interfaces to enable portability of web applications. ORB and HTTP server vendors can add value through their implementations of the facility.

The goal of web facility is to provide well-defined interfaces that encapsulate the details of HTML and HTTP for web application developers. Until recently, dynamic content on the web was implemented with quick and dirty CGI scripts written by casual developers. A web facility would facilitate linking the web with high quality, production applications. Another benefit of a web facility is in lifting the parameter marshaling burden-a time consuming and error-prone activity-from the shoulders of application programmers. Another significant benefit would be to facilitate construction of CORBA HTTP servers that could take advantage of the CORBA common object services like naming, security, persistent objects, concurrency and transactions. Two organizations have experimented with similar ideas and report promising results. Digital Creations' ILURequestor encapsulates HTTP with ILU, and the ANSAWeb project uses IDL to encapsulate HTML.

Standard CORBA URL Access Method

A related topic is the mechanism that enables access to objects from HTML clients. A standard CORBA URL access method could be created to allow the identification of objects and the operations to be invoked from HTML form elements. For example, a URL in the form of:

corba://objName

would bind the HTML client to the object objName. When the client issues a POST method, the web facility would marshal the arguments into an CORBA name-value list and invoke a standard operation on the object, passing the name-value list as an argument. That operation would take the appropriate action and format the response back to the client. With this mechanism, standard CORBA life cycle services may be invoked using HTTP/1.1 COPY, MOVE, and DELETE methods.

This simple mechanism has several advantages. Firstly, it requires few (if any) changes to HTML clients, while enabling full access to CORBA objects. Secondly, no HTTP modifications are necessary to implement CORBA object access. Finally, and most importantly, URLs are familiar to current HTML document authors; objects could be accessed in the same way any other resource on the web is accessed.

Widespread Adoption of Standards

For the web facility to be useful, it must be universally adopted. The web facility, once adopted by the OMG, should also be submitted for standardization by the W3 Consortium (W3C) to ensure widespread adoption of the standards. The CORBA web facility should allow an alternate mapping that has no dependencies on other CORBA object services or common facilities to allow implementation by organizations that do not also offer ORB implementations.

Objectifying the Web

The next priority item involves improving the object semantics supported by the web. Current applications for the web are becoming increasingly interactive: electronic commerce, digital catalogs, virtual environments. These applications force new requirements on web developers that are not easily met by the current versions of HTTP, HTML, and CGI. According to the HTTP/1.0 specification, HTTP is a "generic, stateless, object-oriented protocol." While this is true to some extent, the semantics of the "objects" in HTTP/1.0 are extremely limited. With direct support for only three methods (GET, HEAD, and POST), and differing methods for embedding objects in documents, significant effort is required to adapt object-oriented solutions to the web framework. Enabling support for hybrid web/distributed object applications requires modifications in three areas: client-side state management, embedded objects, and a scripting mechanism.

Client-side State Management

Applications like electronic commerce require the management of state information for clients participating in transactions. This requirement is difficult to satisfy with the current "stateless" HTTP protocol. HTTP should be extended to support the management of client-side state. The current HTTP/1.1 proposal for the Connection general-header field may be sufficient to manage client-side state. No changes, other than rapid adoption of HTTP/1.1 are required.

Embedded Objects

The most significant requirement in enabling dynamic content is for the ability to embed objects in an HTML document. There are several existing approaches available for embedding objects in an HTML document. Netscape Navigator allows embedded Java applets, and supports "plug-ins." Microsoft Internet Explorer supports "built-in" support for VRML and other content type, and will soon allow embedded OLE controls. Although the motivation behind embedded objects is mainly to allow interactive documents, the embedding mechanism may also be used to maintain references to "invisible" server-side objects.

The Compound Document working document identifies a mechanism for embedding objects in HTML documents that should be adopted immediately. Again, no changes, other than rapid adoption of the Compound Document working document, are required to implement embedded objects. A scripting mechanism is necessary, however, to allow manipulation of these objects by an HTML client.

Scripting Mechanism

A scripting mechanism for an HTML document allows a finer level of control by HTTP clients. Both Netscape (with JavaScript) and Microsoft (with Visual Basic Script) are adding script language capabilities to their browsers. HTML should provide a standard scripting mechanism that identifies the capabilities and constraints for scripting languages, without specifying a syntax for the script language itself.

An important capability for an HTML script language is access to events and properties of all elements in an HTML document, including both textual content and embedded objects. The events and properties of the HTML client application should also be accessible through the script language. For example, a script should be able to access the value of an input element when it loses the input focus, and feed that value to an embedded object or change the status message displayed by the browser. This capability would allow fine-grained control over the user interface by individual documents, lessening the need for "out-of-band" communication by embedded objects and reducing unnecessary server interaction.

Bridging Overlap

The next priority is in bridging the overlapping capabilities of CORBA and the web. The most obvious requirement is in interoperability between the CORBA and HTTP security mechanisms. Assuming that IIOP and HTTP do not merge, this should be a relatively simple requirement to fulfill. As more capabilities are added to HTML and HTTP, the overlap of capability must be monitored and bridged when necessary.

Converging Protocols

The web is evolving to become a distributed object framework. HTML documents were originally restricted to text content. Graphic capabilities were then added, which will soon be followed by embedded objects. This migration toward a distributed object architecture suggests an opportunity for merging the IIOP and HHTP protocols.

While merging protocols is a worthwhile goal (and has been investigated by both ANSA and Postmodern Computing), this level of integration is probably not necessary in the short term. According to the HTTP-NG Problem Statement, requirements for the next generation of the HTTP protocol include scaling, latency and bandwidth. None of which are strong points of IIOP in its current state. HTTP-NG will require both asynchronous requests and streaming. Neither requirement is yet under serious discussion by the OMG. HTTP-NG will require backward compatibility with previous versions of HTTP. This is also unlikely to be resolved by the adoption of IIOP as the web's protocol.

There is no real immediate need to integrate the two protocols. Interoperability between IIOP and HTTP, if required, can be implemented using half-bridges specified by current OMG standards. An IIOP-to-HTTP bridge would allow communication from CORBA objects to HTML browsers. An HTTP-to-IIOP bridge would allow communication from HTML browsers to CORBA objects. Both have been implemented as part of the ANSAWeb task.

In the future, IIOP may evolve to make it a more suitable candidate for hosting HTTP. In preparation for this, the OMG should submit IIOP as an Internet Draft to the Internet Engineering Task Force (IETF). This would allow feedback from a wider audience, and would very likely improve the standard. Until IIOP evolves as an efficient mechanism for hosting HTTP, existing techniques may be used to enable any interoperability requirements. OMG and W3C Consortium efforts should concentrate on other areas that will provide greater benefit to the end-user and developer communities.

Summary

The first step in integrating the web with CORBA is to create an OMG web common facility to standardize the application programming interface for web server programs. The next task is to add additional semantics to HTTP and HTML to better support object-oriented programs. The final step is to align any common overlapping features to ensure compatibility. These steps in standardization and integration will benefit the OMG, the W3 Consortium, and the industry as a whole.

About the Author

Jeff Mackay is a Senior Solutions Architect with Andersen Consulting in Chicago, Illinois. He is currently working on delivering tools for component-based solution construction tools for the ARPA-sponsored Technology Reinvestment Project's Rapid Object Application Development (ROAD) consortium.

References

The ILU Requester: Object Services in HTTP Servers, W3C Informational Draft, 7 Mar 96, Paul Everitt, Digital Creations

A Web of Distributed Objects, Owen Rees et al, ANSA, APM

HTML Reference Manual, Sandia National Laboratories, 1996

Hypertext Markup Language - 2.0, RFC 1866, T. Berners-Lee, MIT/W3C, 1995

Hypertext Transfer Protocol - HTTP/1.0, Internet-Draft, T. Berners-Lee et al, MIT/LCS, 1996

Hypertext Transfer Protocol - HTTP/1.1, Internet-Draft, T. Berners-Lee et al, MIT/LCS, 1996

Progress on HTTP-NG, Simon Spero, UNC Sunsite/EIT, 1996

HTTP-NG Problem Statement, W3 Consortium, 1995

Last Updated: March 11, 1996
Author: Jeff Mackay