OBJS Logo

Web + Object Integration

Contents

Introduction

This section is about the melding of internet technologies and the technology for building and executing distributed, heterogeneous object-oriented applications. Driving forces behind the integration of the Web and objects can be found in the Visions section of the Internet Tool Survey. In particular, the section Requirements for OO+Web Integration lists requisite architectural and functional requirements for integration to occur. This section describes the enabling technologies that make interoperability and integration possible, and the various distinct architectural approaches being taken with Web+Object integration. The focus is not on individual capabilities or maturity of the specifications and the systems that conform to them.

To understand why Web+Object integration can and is happening, it is necessary to understand the evolutionary trend of the Web. We first provide this context with a brief summary of Web evolution. To understand proposed architectural variants of the Current Web Architecture and what integration approaches are feasible, it is necessary to understand the technology that exists today that enables integration. Therefore, we next list and describe each enabling technology briefly. Then we categorize the different proposed architectural approaches to web-object integration, and briefly analyze them w.r.t. their advantages and disadvantages. We conclude with a summary of the prevalent emerging approaches and future directions. Finally, we give a brief description of relevant projects, systems, and products and their underlying technology that have contributed towards Web+Object integration.

Evolution of the Web

The WWW is a distributed hypermedia system constructed on the Internet, a global system of heterogeneous networked computers. [Web-based information systems can, and are being, constructed on Intranets.] Advances in networking and Web/Internet technology are leading to a network-centric computing model, and the Web and Internet are evolving into the infrastructure for global network computing. By populating this infrastructure with object-based components and combining them in various ways, one can enable the development and deployment of interoperable distributed object systems on the Web. The marriage of the Web with objects presents a compelling computing model. The object model provides the ability to mimic real world processes in a fluid, dynamic and natural way. The Web allows for objects to be distributed to servers thereby centralizing access, processing, and maintenance, provides a multiplexing interface to distributed objects, and allows thin-clients. One can safely now say that Web+Object integration is a viable reality. This is evidenced by organizations using Web-enabled distributed object technology, in the form of intranets and extranets, to solve their computing problems, and the emergence of an industry that provides Web and object interfaces to distributed object tools. Additionally, the Web is considered to be the platform for next-generation business applications. Business objects mirror the business itself, allow process, policy, data and definitions to be shared, and enable the business process to be re-engineered.

But the Web didn't start out this way. Network-centric object computing is the result of a logical technological progression. As originally conceived, it was driven by hypertext documents called Web pages or HTML documents. Initially Web pages had static content in that they contained rich graphics and text, and were interlinked. Browser applications running on user PCs/workstations were used to retrieve documents housed on servers. Helper applications supplemented the browser, handling other document types such as Word, postscript, pdf, graphics, video, and audio. Web pages soon contained dynamic content as helper applications, called plug-ins, were integrated into the browser and CGI scripts enabled users to input data to a Web server and access Internet services, such as a query search, that are executed on the server. Finally, programmatic content was added via Java applets, Visual Basic Scripts, and JavaScripts, to provide further interactive functionality and modify content in-place. These languages enable richer documents, e.g., animation and forms generated on-the-fly. Note that programmatic content can also include server-side execution of code such as accessing a remote database service.

Prior to the addition of programmatic content, the Web was based on a client/server computing model which lacked scalability, common services, security, and a development environment needed to develop and deploy large-scale distributed applications. CGI scripts are not scalable because each requires a separate server-side process to handle each client request, services are limited to accessing database servers via CGI scripts, transaction information (such as credit card information) is not encrypted, and the programming model offered by HTML/HTTP using CGI and a three-tiered system is limiting, e.g., CGI is not object-oriented and offers no type saftey, dynamic interaction with the user is difficult, the interface between the server and database manager is ad-hoc, the interfaces cannot be combined or extended, client data is strings the server must explicitly decode, there are no standard definitions of service interfaces, and interfaces are not self-describing. Consequently, for the limitation point, applications are more error-prone, are harder to maintain, and are not likely to be reusable. With the advent of Java, and the distributed object infrastructures CORBA/IIOP and OLE/DCOM, the stage was set to evolve the Web from a document management system to a platform for distributed object computing and electronic commerce. Bringing distributed objects to the Web offers extensibility (e.g., for applications, services, and APIs built from objects, objects can easily be replaced or added, [list of kinds of? TBD] ), cross-platform interoperability, independent software development, reusable software components, componentware, network services, and better utilization of system resources, to name but a few advantages. Existing legacy applications can even co-exist with distributed objects through the use of object wrappers (cf. the Wrappers section). The interface could either be the client browser or browser-like with superpositioned distributed object infrastructures.

Emergence of the Object Web

As mentioned in the previous section, recent trends in distributed object and Internet computing technologies has hastened the development of heterogeneous object computing over the Internet. However, the technology exists in several competing forms, creating a dilemma of which will survive and is therefore the one to use (see Enabling Technologies). What the final superposition of Web and distributed object technologies will end up being remains to be seen (see Prevalent Directions). Nevertheless, concurrence that it will happen is supported by many researchers, such as Orfali, Weiss, and Resnick, and the authors of many current articles published on the subject and papers presented at workshops devoted to the topic.

Orfali has dubbed the concept of a distributed heterogeneous object computing network the Object Web, an apt term we also adopt to characterize the integration of the Web/Internet with objects. The Object Web is logically a 3-tiered client/server architecture involving disparate technologies. The 1st tier consists of client objects – HTML pages with forms, Java Applets, COM objects, CORBA objects, and/or client applications – and a CORBA ORB. These client objects invoke server objects in the 2nd tier by sending messages in various protocols – HTTP, IIOP, RMI, DCOM, or RPC. The middle tier contains HTML documents, CGI-scripts, CORBA services, COM services, business objects, other middleware (e.g., OSF's DCE, products based on Microsoft's ODBC or Sun's JDBC that gives clients native access to a variety of databases, security software for secure transacting, and mobile agents), and/or a CORBA ORB. For client and server objects written with different object models to coexist and collaborate in various frameworks, bridges or adapter components are used. Server objects invoke functions in the 3rd tier to access data and legacy systems. The 3rd tier includes TP Monitors, MOMs, DBMSs, ODBMSs, and Email.

The Object Web differs from traditional distributed object computing. Distributed object technology, coupled with a communications infrastructure, enables traditional monolithic client/server applications to be divided into self-managing components, i.e., objects, that can interoperate across disparate networks, platforms, and operating systems. The Internet provides the requisite communication framework for Web-based, distributed object applications. Such applications can be built from new and legacy code encapsulated in objects, run on heterogeneous systems both inside and outside a firewall, and made to interact and communicate with each other through middleware using defined interfaces.

In addition, application areas such as electronic commerce/business are pushing this distributed computing model even further. The next generation business computing is built on the same distributed object computing model plus business objects that embody business entities, processes, and rules. However, distributed business applications have additional requirements beyond conventional Web-based computing – scalability, high availability, ease of administration, high performance and data integrity. Relevant technologies being used for business computing are OMG CORBA for scalability; the CORBA Object Transaction Service for reliable transactions; the CORBA business object facility, infrastructure to support distributed cooperating buisness objects; mobile intelligent agents for sequencing events; the use of component assembly to build business applications; and the OPEN method, a third generation OO methodology with full lifecycle support for process.

Enabling Technologies

In order to understand the architectural variants of the Current Web Architecture, it is necessary to understand the technologies on which they are based. Therefore, before presenting the different integration architectures, we first present a brief description of each enabling technology: The Common Object Request Broker Architecture (CORBA) and the Distributed Component Object Model (DCOM) are two principal competing foundation architectures which together with IDL provide the interoperability infrastructure for linking up objects on the Web. The Distributed Computing Environment (DCE) is a non-competing complementary technology. Java and trends in component infrastructures provide programmatic components for constructing Web applications.

CORBA/IIOP

CORBA

CORBA is a standard specification for distributed object systems. In the CORBA architecture, there is a client, an object implementation, and an Object Request Broker (ORB). An object's interface is defined in the OMG language-neutral Interface Description Language (IDL). OMG standard language mappings specify how IDL types and method signatures convert to language-specific types and functions. An IDL compiler generates stubs for the client and skeletons for the server which process a client request and server response, respectively. All client requests (invocation of an object) go through its local ORB. If the object is remote, an ORB-to-ORB communication pathway provides interoperability for all CORBA objects on a network. An ORB uses an Interoperable Object Reference (IOR) to pass object instance information to other ORBs; it is sufficient to pass object references around thereby avoiding the issues of object migration. Shared IDL interface definitions are maintain by each ORB in its Interface Repository (IR). Using the IR a client can dynamically discover the names of classes, methods, and method signatures and a method invocation can be assembled dynamically via the Dynamic Invocation Interface (DII). The server-side equivalents are called the Implementation Repository and the Dynamic Skeleton Interface (DSI).

Built on top of the CORBA architecture is the Object Management Architecture (OMA). It provides application objects called CORBA services and CORBA facilities. CORBA services are basic standard services need by nearly any object-based application. There are currently 13 base services with 3 more being specified. CORBA facilities are intermediate-level common data types and functionality needed by horizontal (enterprise-wide) and vertical (industry-specific) applications. Most of the CORBA facilities are currently being specified.

Commercial implementations of CORBA include DEC/BEA's ObjectBroker (and here), IONA Technologies Orbix, IBM's DSOM, Sun's Joe/Neo, and Visigenic/Inprise's VisiBroker. A more complete list can be found here.

A brief description of CORBA can be found at TechWeb's Technology Encyclopedia.

IIOP  (Internet Inter-ORB Protocol)

The General Inter-ORB Protocol (GIOP) defines a standard message format that CORBA 2.0 compliant ORBs can use to transmit object references. The Internet Inter-ORB Protocol (IIOP) specifies how GIOP maps to TCP/IP. An object accessible via IIOP is identified by an IOR. IIOP is the communication protocol for object interoperability over the Internet and a separable CORBA runtime service. Using IIOP, CORBA 2.0-compliant ORBs from different vendors can interoperate.

Java

Java is an object-oriented programming language that is compiled to a platform independent bytecode and executed by a Java Virtual Machine (JVM). While providing downloadable behavior to a client from a server, Java by itself lacks the support for distributed computing. Some of the shortcomings are: 1) Java applets in a HTML page are independent and cannot be integrated; 2) Java objects cannot be stored in persistent storage; 3) there are no services needed to build distributed object applications; and 4) there is no paradigm to invoke client/server methods. However, numerous initiatives overcome these shortcomings, namely, Sun's JavaSoft's JavaBeans, IBM tools (Arabica, Component Assembly Tool (CAT) and Aglets Workbench at alphaWorks, and Shareable Frameworks), Netscape One, and Oracle's Network Computing Architecture (NCA). A Java Bean can interoperate with other Java applets and applications. CORBA services are accessible using Sun's Joe which links Java applets to Sun's CORBA-based NEO server environment. Object serialization, a core Java API available in JDK 1.1, allows a Java Bean to have its internal persistent state saved; additional persistent mechanisms are planned. For building distributed Java applications, Java's Remote Method Invocation (RMI) facility provides access to remote Java objects. In addition to RMI, JavaBeans also supports the network access mechanisms CORBA IIOP and JDBC, the Java database API for accessing SQL databases. Note: Java is being used or planned to be used to implement software in each tier of the 3-tiered client/server architecture. For example, Netscape plans to implement Communicator in Java, numerous ORBs are written in Java, and it is a matter of time before a DBMS is written entirely in Java.

Distributed Computing Environment (DCE)

DCE is a middleware infrastructure that provides security, directory, time synchronization and file sharing services for building distributed applications across heterogeneous networks. The underpinnings, namely the Remote Procedure Call (RPC) and DCE Interface Definition Language (IDL), are analogous to the CORBA underpinnings, namely, the ORB and OMG IDL. However, DCE is a lower level facility than CORBA and details handled transparently by CORBA must be explicitly handled by the DCE programmer. This is illustrated by the steps involved in making a RPC. They are the same as those an ORB takes when a client makes a request, namely, arguments of the request/call are marshalled, a server located, the request/call transmitted via some network protocol, the arguments are unmarshalled and the method/procedure called. Similar steps are performed in reverse for the return values and exception information. Also, an IDL compiler generates the client and server stubs that deal with all marshalling and unmarshalling for remote procedure invocation. The IDLs are different in that DCE IDL is based on C, CORBA IDL is based on C++ (although CORBA also supports a C binding); CORBA's supports inheritance, DCE's does not; and CORBA's allows polymorphism in the sense of overloading methods, DCE's does not. Also, a DCE interface name is the basis for locating the server for the interface while an ORB uses the IOR. As an alternative to CORBA's IIOP, the DCE Environment-Specific Inter-ORB Protocol (DCE ESIOP) specifies a communication standard based on DCE's Network Data Representation, transmitted via DCE RPCs. In fact, inter-ORB backbones can be built on DCE/ESIOP as witnessed by DEC's CORBA implementation, ObjectBroker, and HP's ORB Plus. CORBA could have been built on top of DCE which is what Microsoft is attempting to do in the form of OLE/DCOM. DCE will interoperate with CORBA IIOP because both use the CORBA object model. So the merging of DCE and IIOP in the CORBA 2.0 specification provides two complementary technologies for ORBs -- DCE enhances CORBA with a RPC infrastructure while CORBA enhances DCE with an open platform for objects.

Unlike CORBA which is just a specification, there is a reference implementation of DCE. All DCE products are based on the same OSF code which allows all DCE-based ORBs to interoperate via ESIOP. For CORBA there is no reference implementation and ORBs implemented by different vendors initially were not necessarily compatible. The advent of IIOP in CORBA 2.0 allowed different ORBs to interoperate, and the support of DCE ESIOP allowed CORBA ORBs to interoperate with DCE-based ORBs.

DCE also provides a number of services, some of which are similar to those defined by CORBA. The two most significant ones are the naming and security services.The naming services provides a tree-structured namespace. The security services provides authentication, authorization, and privacy in a distributed environment. There is also the Distributed Time Service that synchronizes clocks on all hosts in an administration domain. Other useful aspects of DCE are support for Posix threads used by RPC servers to handle multiple requests concurrently, and the Distributed File System that combines multiple host file systems into a single uniform namespace. DCE also implements functionality that only appears in CORBA specifications. This is why a DCE-based ORB, such as ObjectBroker, is so much more capable than a CORBA ORB, such as Orbix.

OLE/DCOM

A comprehensive collection of technical articles about OLE, COM, DCOM, and ActiveX can be found here.

OLE†

Microsoft's Object Linking and Embedding (OLE) is a family of technologies ranging from compound documents to standard interfaces and services all built on the foundation of the Component Object Model (COM). OLE provides a standard framework for building reusable, integrated software components. ActiveX is the new name for OLE technologies, especially in reference to Internet applications. COM and DCOM are local and remote communications standards which OLE uses to handle object creation and local/remote transparency services.

OLE is an environment where objects interact. Originally OLE stood for Object Linking and Embedding and was intended to allow people to cut a piece of a spread sheet out of Excel and paste it into Word. It has grown into much more. Now, OLE composes arbitrary objects, not just documents, through strict interfaces. OLE's definition of "object" is quite a bit different than what is traditionally meant. About the only similarity is encapsulation.

OLE encapsulates objects in several dimensions. OLE supports evolution as C++ classes do, but without recompilation. Each incarnation is given a unique identifier and a version stamp. OLE supports heterogeneity of both language and hardware. Language heterogeneity usually refers to programming languages. In this case it also refers to human languages. Encapsulation includes licensing on an object by object basis.

The key to encapsulation, as in other object systems, is interfaces. An object can only be accessed through an interface. The difference in OLE is that objects support many interfaces. Coming from a pure object-oriented background this capability is extremely confusing. It is best to think of OLE interfaces as object-oriented views. An object can have multiple and even semi-redundant views. There is no inheritance or subtyping of interfaces; the space is completely flat. The ability of delegation does not exist within OLE. It is only a pragma or pattern used by implementors. Any object implements any interface in whichever way it chooses.

A client accesses each interface to an object through a distinct handle. Since objects support multiple interfaces, OLE provides a means to query an object for an interface through any handle. In addition, OLE allows objects to store type information in a library available at compile time and run-time. One of the most powerful features of OLE is the ability to bind to completely new services at run-time without recompilation. This flexibility allows for many desirable software management activities such as rapid prototyping, incremental enhancement, and migration to lower cost service providers.

As with other object service architectures, objects are created with a class factory. The class factory enforces licensing restrictions, but it does not prescribe the restrictions. The restrictions are defined by the class itself. Clients bind to objects using abstract monikers defined by the class. A moniker is a COM object that creates and initializes one other object, returning a pointer to it. The process of establishing a connection between a client and an object referred to by the moniker is called binding to the object. Each time an object is bound, a reference count is incremented. When the count returns to zero, the object can free its resources.

OLE is a binary standard that is essentially the run-time environment of a language which does not exist and is not even specified. ( Since OLE manipulates binary components and is not concerned with the implementation language, it is language neutral and the implementation language can be considered to be hypothetical.) The rules of the language must be internalized and exercised by programmers implementing in their host language usually Visual Basic (VB) for OLE clients and C++ for OLE object developers. VB provides a very high level of support for using objects, but less support for implementing them. Support for OLE is not provided through C++. Rather, there is some support in Microsoft's application framework (MFC) and most of the support is actually in the authoring tool Visual C++ (VC++). MFC and VC++ do not provide access to the full power of OLE, but only to a subset suitable for common applications.


† The description of OLE is an adaptation of Dave Langworthy's technical brief Microsoft OLE.

COM

Higher-level services provided by ActiveX and OLE rest on the foundation of the Component Object Model (COM), a software architecture that allows applications to be built from binary software components and interoperate. A COM object, called a component, is a piece of compiled code that provides some service to the rest of the system. A component can be implemented in any programming language that can create structures of pointers and explicitly or implicitly call functions through pointers. Component-based applications interact with each other and with the system through interfaces. A COM interface is a strongly-typed contract between software components to provide a set of operations (methods). A component can dynamically expose its interfaces via the QueryInterface request mechanism. COM components always access other COM components through interface pointers; a components data is not directly accessible. If the access object is running in another process or on another machine, COM can intercept the interface call to an object and use RPC. Remote data access is through methods that can be accessed through a proxy-stub pair that forward the request from the client component to the server component and send back the response. The mechanics associated with launching components and establishing connections between components are embodied in the COM Library, an operating system component.

DCOM

Distributed COM (DCOM), aka Network OLE, extends COM across networks using standard communication protocols. DCOM is an application-level protocol for object-oriented remote procedure calls and is thus also called "Object RPC" or ORPC. The generic protocol consists of a set of extensions, layered on the DCE RPC specification and facilitates the construction of task-specific communication protocols.

ActiveX

There doesn't seem to be one definitive definition of ActiveX, but those characterizing it are similar. According to the Microsoft paper, What is ActiveX?, and a whitepaper, "ActiveX™ is a set of technologies from Microsoft that enables interactive content for the World Wide Web." "ActiveX provides the glue that ties together a wide assortment of technology building blocks to enable these 'active' Web sites." Furthermore, ActiveX's elements include both client and server technologies: ActiveX controls, ActiveX documents, ActiveX scripting, Java VM, and an ActiveX server framework. In this view, ActiveX is an all-encompasing term for the technologies comprising Microsoft's component architecture, including OLE, OLE controls, COM, DCOM, and ActiveX controls.

Another view is that ActiveX is an integration technology – a component framework that allows component objects, called ActiveX controls, embedded within documents to communicate with one another and with the framework. It enables software components to interoperate in a networked environment using any language. ActiveX essentially extends Microsoft's OLE and COM technologies to the Web. The COM technology is the primary foundation for ActiveX technology. DCOM extends interactions between components across networks.

ActiveX controls, aka OLE controls (OCXs), are reuseable, prefabricated components (objects) that can be inserted into a Web page, another application, or development tool to provide specialized functionality. ActiveX controls are akin to Java Applets/Beans and Netscape plug-ins, but additionally can be used in applications writen in numerous Microsoft programming and database languages. ActiveX controls provided by 3rd party vendors can be found in the ActiveX Component Gallery.

ActiveX licensing ensures downloaded ActiveX controls are safe. When downloaded, a check is made to see if it has been digitally signed by a software publisher using code signing Authenticode™ technology. The software is only downloaded if the client interactively accepts the terms and conditions of the license.

Java applets can interoperate with ActiveX technologies – ActiveX controls, ActiveX documents, and Active scripting. This ability for Java applets to work with other software using ActiveX is made possible by Microsoft's Java Virtual Machine for Java applets and JView for Java applications. (see Web+Java/COM).

ActiveX is a direct competitor with JavaBeans.

Componentware Trends

There are two basic approaches to composing applications out of reusable components: one via component model and the other a compound document framework.

A compound document framework is a software infrastructure and protocols that enable separately developed objects to be visually integrated on a desktop. Compound document technology provides the ability to build an application out of components in a standard documen that is the universal client front-end to servers; the compound document framework is built on top of an object bus and core object services. A compound document consists of components and containers. Containers hold related components and provide the context for component interaction. Containers can also be components. Compound documents provide a strategy for using components in a distributed computing environment. By leveraging established distributed computing technologies, such as CORBA, a compound document can provide access to services required by a distributed application. Using scripts, an intelligent document can route work from one machine to the next; functionally this is a form of mobile intelligent agents.

Currently there is no effective Internet-oriented compound document framework, but making Java and JavaScript or ActiveX/DCOM work seamlessly in a Web browser is one possibility as is OpenDoc, a compound document framework layered on top of IBM's CORBA ORB, SOM. However, use of OpenDoc is no longer a viable approach. Apple has decided to discontinue the product past Version 8.0 of the Macintosh operating system, the OpenDoc consortium (Apple, IBM, Novell) is falling apart, application development tools are lacking, and OpenDoc's concept of compound documents does not take the Web into consideration. One effort that may keep OpenDoc alive lies in the OMG's OpenDoc Common Facility. Given the probable demise of OpenDoc, this technology per se will not be covered.

A component model is an architecture and set of APIs that allows software components to be dynamically combined together to create an application. Containers hold related components, and provide the context for component interaction and arrangement. Containers can also be components. The two primary competing component models are Microsoft's ActiveX and Sun's JavaBeans.

Examples: ComponentWare Consortium, Infospheres Component Network, Microsoft's Object Technology Strategy: Component Software.

Integration Architectures

Enabling object technologies are being combined in different ways to create an integrated distributed computing infrastructure thereby bringing about heterogeneous network computing. The purpose of this section is to provide a taxonomy of the architectural approaches to Web+Object interoperation and/or integration that we have so far identified within several ongoing web-object integration projects, systems, and products. A companion section, Web + DBMS Integration, covers software architecture approaches for the integration of the Web with DBMS systems.

We had planned on having a comparative analysis section, but decided against it for numerous reasons. First, the prevalent technologies, namely CORBA and DCOM, are going to coexist and converge over time. Todays differences for making a selection are constantly changing and narrowing. (For a detailed architectural comparison, see the Chung et al paper.)  Second, Orfali's book on CORBA and Java programming has chapters devoted to comparing Java/CORBA ORBs with its competitors: sockets, HTTP/CGI, RMI, and DCOM plus tables comparing features. Therefore, we have followed this section with a discussion on prevalent directionsandfuture directions.

Only some of the many architectural variations need to survive. The long term goal is an integration architecture that has good performance, is scalable, has a migration path from today's architecture, and is compelling. That is, a proposed solution should provide a path to meet imagined requirements or the ideal architecture, or be a useful stop along the way.

All approaches to Web+Object integration are not considered. For example, the use of CGI to integrate with backend non-CORBA OO systems is excluded. Instead, only those approaches which are expected to dominate are considered. The primary taxonomic categories for Web+Object integration architectures are:

Web+CORBA

Description: The integration of the Web and CORBA middleware system provides bi-directional access of three-tiered services, i.e., Web clients can invoke CORBA services and CORBA clients can invoke Web services. In this architecture, a client interacts with the Web which in turn interacts with a CORBA gateway that provides access to distributed CORBA services via the ORB. Going in assumptions are that CORBA is used to wrap legacy information systems and build a secure reliable gateway between them (and web servers), and that CORBA provides gateway interoperability to other CORBA implementations and to a collection of CORBA services and CORBA facilities.

The various Web+CORBA architectures are:

Specific WWW Server Gateways

Description: A CCI Browser communicates with a CGI Server via HTTP which invokes a specific CORBA client via precompiled IDL client stubs.

Advantages: simple, no modification needed to CORBA or to WWW.

Disadvantages: a) invokes a new gateway script each time; b) specific gateway scripts for each kind of Corba object; c) memoryless.

Examples: W3Objects, NEXT/Apple's WebObjects and CERC's Web*.

GenericWWW Server Gateway

Description: CGI scripts are written that will materialize references to OMG classes stored in the OMG Interface Repository in the form of HTML (with links). Also, HTML forms are used to select operations and arguments, and the object constructor makes a CORBA DII call to the object implementation and returns results in HTML or exception handling returns an error message.

Advantages: no changes needed to Web or OMG architectures.

Examples: DSTC's CORBA Desktop.

CGI Gateway Replacement

Description: The CORBA middleware is used as a transport mechanism for the HTTP protocol messages. A CORBA object is created using data extracted from the client's HTML document, and the remote method of the object is invoked to service the user's request. The returned result is extracted and inserted into a meta html file that is returned to the user.

Advantages: a) performance is better because it is not necessary to spawn a separate process for each invocation; b) gateways can be stateless or stateful where CGI forces a gateway to be stateless since a new process is started for each invocation; c) separation of service and presentation logic.

Examples: HP Laboratories' CorbaWeb and DEC's Web Broker.

Unifying Communication Protocols

HTTP-IIOP Gateway
Description: Add interoperability of HTTP with other communication protocols such as IIOP and DCE. This approach relies on gateway programs to connect the client and server, and a HTTP-to-IIOP and IIOP-to-HTTP protocol converter.

Examples: ANSAweb, W3Objects, and Xerox PARC's Bayou project.

HTTP-NG
Description: Define object types and wire protocol - changes notion of what a document is.

Examples: Inter-Language Unification (ILU) from Xerox-PARC; Digital Creations ILU Requestor; EC/ACTS DOLMEN project.

Digital Library Interoperability Protocol
Description: A protocol for CORBA to interface to library service proxies.

Examples: Stanford Digital Library Project.

DCE CIOP
Description: Instead of using the CORBA IIOP as the underlying communications base for ORBs, one could use an environment-specific inter-ORB protocol which also maps to TCP/IP. The DCE Common Inter-ORB Protocol (CIOP) acts as the glue between the DCE ESIOP and TCP/IP for those specific environments where the DCE protocol is useful. CORBA 2.0 supports DCE CIOP to enable independently implemented ORBs to communicate.

Microscripting

Description: Embedding scripts into HTML.

Advantages: Easy incorporation of small amounts of code into mostly HTML applications. Scripts can validate information on the client-side before passing it to the server, e.g., validate a query to avoid later rejection by the server or check if manditory fields of a CGI form are filled in.

Disadvantages: a) need session control and transactions; b) need event notification; and c) need user authentication.

Examples: The HP CorbaWeb and CorbaScript, Netscape's Visual JavaScript, Sun Labs Tcl/Tk Project, and Web*.

Web+Java

Description: In a pure Java approach to client network computing, a Java program can communicate with a remote Java object using either sockets, RPC, or a non-CORBA compliant ORB. The Java language supports access to sockets via the java.net package. When using a RPC, the RPCs must be encapsulated in a Java wrapper using Java's native method mechanism. The RPC handles all the network details; arguments and return values are encoded in an external data representation, such as XDR.

Disadvantages: These approaches are hand-tailored solutions duplicating common functionality. 1) When using Java sockets, a Java application or applet invoking distributed objects must manage its own communication, e.g., data formats, marshalling and unmarshalling. In effect, the CORBA ORB communication paradigm must be implemented on top of the built-in socket layer. Furthermore, access is restricted for security reasons. For example, Netscape Navigator permits applets to open socket connections only to the host that served them. 2) Native methods cannot be verified by the JVM since they are implemented in another programming language. Since the low-level bytecode checks are bypassed, this presents a security hole. 3) RPCs are not object-oriented. Therefore one must design a protocol to encode the transmission of method invocations and responses. In effect, an ORB must be implemented on top of the RPC layer. However, RPC does not support polymorphism or inheritance. When a Java client invokes a Java object via RPC, server-sided overload resolution is not possible since Java does not provide a way to invoke a method from a string representation of the method's name. 4) Java only provides node-level security, but network security mechanisms are being proposed, such as digital signatures for verifying that code comes from a trusted source.

Examples: WebLogic's jdbcKona/T3uses sockets for communication between a Java client and a Java application which in turn accesses one of several relational databases. Java wrappers around RPCs are also used to access relational databases. The communication mechanism for remote method invocation and responses is the network message system with the interpreters at each end marshalling and unmarshalling the messages. Nagaratnam and Srinivasan have implemented a distributed Java prototype calledRemote Objects. By extending the language with the new keyword remotenew, an object can be created on a remote machine. Japan's Electrotechnical laboratory (ETL) has implemented a Java-based ORB called HORB. The Java Remote Method Invocation (RMI) provides a Java-to-Java ORB framework.

Web+Java/CORBA

Description: 1) Using a two phased integration mechanism, a Java-enabled browser downloads a Java applet using standard HTTP streaming and executes it using the browser's JVM. The Java applet, using a built-in mini-ORB implemented in Java and downloaded with the applet, acts as an ORB client to invoke methods on remote CORBA servers via IIOP. Using a CORBA ORB requires there are IDL specifications for the remote objects and an IDL-to-Java compiler to generate static interfaces to object services, and the Java client communicates with them either via the static stubs or DII. Proposals for IDL-Java mappings have been submitted to OMG by Xerox (Java Mapping to CORBA) and SunSoft (CORBA the Geek gets Wired on Java). 2) Use one of the Web+CORBA gateways described previously.

Disadvantages: Using a gateway is not as unified an approach as using the a CORBA ORB, for CORBA naming or trading services cannot be used to find services and Java applets cannot benefit from CORBA security and licensing services.

Examples: SunSoft's Java Object Environment (Joe/NEO), Iona's OrbixWeb for Java, Visigenic/Inprise's VisiBroker for Java, APM's Jade (deprecated), and Netscape's Caffeine. Both Visigenic/Inprise's VisiBrokerand Sun's NEO's CORBA 2.0 ORBs are Java-based and support the mapping of IDL to Java.

Web+Java/COM

Description: The Java/COM integration model involves support for Java programs to access COM objects and the creation of COM objects in Java. It is based on type libraries each of which contains complete type information about one or more COM objects. Special tools are used to create Java class wrappers from a type library, i.e., to convert type library information into Java .class files. COM support resides in Microsoft's Java VM which their Internet Explorer browser uses to run Java applets and JView uses to run Java applications. The Java VM recognizes the Java class as a COM wrapper and translates all Java method invocations on the class into COM function calls on the COM class.

Java can be used to implement COM objects callable from languages such as Visual C++, Visual Basic, and VisualJ++. All Java classes are automatically exposed as COM objects. Basically this entails writing the COM class in Java, generating COM class wrappers using a special tool, and modifying the Java code to implement the interfaces defined in the COM class wrappers. When the COM object is called, say from Visual C++, the Java bytecode is executed by the Java VM.

Disadvantages: This is not a total solution. At this point, COM is not platform-independent, but available primarily on Windows platforms. However, DCOM (which is based on COM) is being ported to Unix platforms, such as Sun's Solaris. Also, it is non-trivial to use COM services from Java to access ActiveX services, and currently there are no wizards to automate the process. However, a future release of Visual J++ will provide a new class library with the functionality of the COM library API and ease integration with ActiveX services. However, there is a much simpler means of accessing ActiveX services from Java, namely, to use the Java Beans API and the Java Beans/ActiveX bridge.

Web+DCE

Description: As stated in the description of DCE above, it is similar to CORBA but differs from it in one fundamental way, namely, DCE has no explicit object model -- it does not support objects per se. DCE was designed to support procedural programming while CORBA was designed to support object-oriented programming. However, DCE is evolving towards a more object oriented model. One approach is by augmenting the DCE programming paradigm to be more object-oriented. This is the path taken in HP's OODCE and DCE 1.2. DCE 1.2.1 provides an extended IDL compiler, XIDL, which supports C++ applications. A set of C++ classes provides access to DCE APIs. This same approach could be taken with Java. Another approach is to layer a distributed object model over DCE such as CORBA or Microsoft's Distributed Component Object Model (DCOM). This enables the object technologies to utilize the DCE security service, RPC, and CIOP. It remains to be seen how good the technical fit is.

While not useful by itself to build distributed object applications for the Web, DCE is a good choice as an infrastructure for supporting distributed applications. The DCE RPC is useful within the CORBA 2.0 and OLE/DCOM. The CORBA 2.0 specification permits ORBs to optionally support alternative interoperability protocols, known as Environment-Specific Inter-ORB Protocols (ESIOPs) in addition to the IIOP. CORBA can use the DCE Common Inter-ORB Protocol (DCE CIOP), which is based on DCE RPC, as an environment-specific protocol to provide interoperability. DCOM is a generic protocol layered on the DCE RPC -- DCE RPC is ActiveX's communications protocol, its only underlying method invocation mechanismf.

Advantages: 1) Instead of competing with CORBA, DCE complements it. ORB and RPC method invocation are two similar mechanisms but different because RPCs are not object-oriented. With RPC you can only invoke a specific routine while with an ORB the response may be different because of polymorphism. Note that DCE is actually used in some CORBA implementations to implement method invocation. 2) The Web currently only offers the secure sockets layer (SSL) and secure HTTP (S-HTTP) appropriate for a limited number of applications. DCE provides network security in the form of user authentication, data protection (encryption), and authorization (resource access control).

Examples: The DCE-WEB Project conducted as part of an Advanced Technology Offering (ATO) by the OSF Research Institute (the WanD (Web and DCE) Server handles both standard HTTP-over-TCP and the DCE Web's RPC-based protocol); Gradient's NetCrusader; and HP's OODCE, a C++ application framework and IDL++ compiler that creates an object-oriented programming environment that supports access to DCE capabilities. The recent OSF Jade (Java and DCE ) Project enables Java client applets to use DCE security services to access remote resources.

Web+OLE/DCOM

There is an effort to standardization DCOM. According to the referenced OMG document comparing ActiveX and CORBA/IIOP, COM/CORBA interworking technology is part of the published CORBA specification. Also, "OMG is running a separate technology adoption process for DCOM/CORBA interworking, the results of which will be available in 3Q97."

There are some interworking products, e.g., HP's CORBA Connect, a component of HP ORB Plus that enables bi-directional messaging between CORBA objects and OLE Automation, COM and OCX objects.

Interface definitions are specified in Microsoft IDL (MIDL).

Web+Everything

Description: The kitchen sink, cover-all-your-bases approach, is to support in one framework all key technologies that enable the development of component-based, network-centric applications. This allows enterprises to still use legacy systems while developing next generation, platform-independent applications. The Web page is the universal desktop on which applications execute. When requested by a user or program, the platform-independent client part of the application is downloaded from the application server and executed by the client browser. The client then uses Internet protocols to interact with the server-based parts of the application and services. This interaction is bi-directional. Server parts can request code be executed on their behalf by a client. Servers provide database connectivity to major databases. A client's query is transported to the server that interfaces to the database server. Query results are returned as dynamic content of a Web page. APIs provide a unifying object model so platform-independent and native components can interact and communicate, and components can access legacy applications.

The problem with this approach is that the technologies are not integrated seamlessly to form a network computing environment, but instead form a pool from which to mix and match when developing a distributed application. While the approaches provide a service-based architecture that accommodates cooperating distributed applications and network services, the underlying enabling technologies are loosely coupled. Part of the reason for this is there are two competing computing technologies, namely, CORBA/IIOP and OLE/DCOM/ActiveX. Vendors of all-encompassing network computing environments want their product to handle components from both camps as well as native legacy applications. Until one approach prevails or they merge, this trend of providing APIs and bridges for interoperability will continue.

Examples: Netscape ONE, Oracle's Network Computing Architecture, and IBM's Open Blueprint.

Component Architectures

Both compound documents and the component model are component architectures for creating component software. They both use a model in which the client application is designed as the container that holds the other components/objects. Originally, a compound document was more a combination of data structures such as text, graphics, spreadsheets, and hypermedia, while the component model was more a combination of reusable program modules. Both data and program modules are designed to communicate and interoperate with each other at runtime. Whereas a compound document exists in a browser, component software can be stand-alone and run anywhere. As compound documents become more programatic in nature, its distinctions from the component model are narrowing.

Examples: JavaBeans, Netscape ONE, ActiveX, OpenDoc.

Prevalent Directions

The objective to bring objects to the Web is simply stated as "How to access objects remotely?" (An object may be accessed locally, e.g., using call-by-value or downloading a Java applet/application, but this still involves accessing the remote object first.) All of the systems/projects/products described below are means to achieving this goal. They range from minimalist protocol-based approaches to all encompassing approaches like Netscape ONE and Oracle's NCA. The latter two unify into a single platform most of the key Internet standards, such as HTTP, HTML, LDAP, and Java plus a collection of open, cross-platform software solutions and technologies for creating distributed applications on both the Internet and Intranets. This includes underpinning support for a distributed computing model (the choice is between DCOM and CORBA) and a model for composing applications out of components (the choice is between ActiveX and JavaBeans). These two choices are tied together, but as bridges are created to support interoperability, the choices could be made independently. However, it is unclear which of these developers will prefer and how seamless the integration will be.

Distributed Object Model War

There are two competing distributed computing models, namely, Microsoft's Distributed Component Object Model (DCOM) and OMG's distributed object model based on CORBA and IIOP. The war of the object worlds is coming down to OLE/DCOM versus CORBA/IIOP; both are here to stay and will continue to mature. The former is based on proprietary standards while the later is based on open standards (although Java is still a proprietary standard). A more fundamental difference is that a DCOM object (component) is not the same as an OMG object in the traditional sense. It is unclear which development strategy will dominate. Most likely network-centric computing environments will support both, but an important deciding factor is the move away from proprietary technologies to open ones. ISVs and corporate software developers will be able to use both in developing their component strategies through either gateways, wrappers, or bridges. "Legacy" technology such as ActiveX will be one element of the network infrastructure.

Using CORBA/IIOP, developers can define standard network interfaces for their applications using a cross-platform, cross-language, distributed object model. The ability to encapsulate existing legacy applications and data and make them accessible via network interfaces provides a migration path for enterprises from leveraging existing corporate applications to building next generation network-based applications.

Neither CORBA nor DCOM alone is complete solution for network programming, i.e., for building enterprise-level distributed application. Both just provide the plumbing and a communication mechanism for a collection of cooperating objects and ORBs running across a heterogeneous network of processors and OSes. Real applications also need services like naming, event notification, transactions, concurrency control, and life-cycle control. For CORBA environments, some CORBAservices are provided in an ORB implementation. For DCOM many of these services are being developed (see DCOM: A Business Overview).

Component Object Model War

The other raging battle (tied to the first) is over component frameworks -- JavaBeans versus ActiveX. Both are being used for the development of Internet/Intranet applications. Both provide a component framework that allows component objects (Beans vs ActiveX controls) to communicate with one another and with the framework. JavaBeans is designed to interoperate with CORBA and ActiveX while ActiveX is designed to interoperate with DCOM. A Java application that is 100% pure Java is truly cross-platform, while ActiveX is not yet truly cross-platform, i.e., it doesn't run under MacOS and Unix. The list of differences goes on and on, which in time most likely will become secondary as the two products mature. Better visual development tools will be developed, components will be able to be written in a variety of languages, applications will be able to intermix Beans with ActiveX controls, performance will be competitive, components will be first class citizens (i.e., have all the power and capabilities of any native application), and details of component development will be automated by wizards. There are other practical considerations to be considered in making a choice, in particular, security, but actually neither is foolproof at this point. Java Beans uses the JVM which prevents applets from accessing files or applications. (Note: this sandbox restriction does not apply to standard Java applications.) AcitveX controls have access to a platform's OS, files, and applications; security depends on trusted servers and digital signatures.

Which component object model suits application developers best remains to be seen. Which framework will prevail is not yet predictable.

Leveling the Playing Field

A number of recent developments have narrowed the differences between OLE/DCOM and CORBA: However, one big problem remains, namely, the interoperation of multiple component architectures: Netscape's Internet Foundation Classes (IFC), JavaBeans, ActiveX, IIOP, Java RMI, and Netscape's LiveConnect. Moving component development knowledge from client to server will be difficult.  [This last comment could be elaborated on a bit.]

Interoperability

CORBA is one key technology that can fuse the rival ActiveX and Java Beans initiatives into a viable component application model. A number of recent developments in this direction are: 1) Sun's Joe interface which links Java applets to Sun's CORBA-based NEO server environment and its CORBA services; 2) OMG's promise to provide an official standard for linking Java to CORBA-compliant applications; and 3) Digital's and Iona's latest ORB efforts to provide CORBA, Java, and ActiveX interoperability. In addition, these developments allow legacy applications to be accessed through CORBA using Java.

DCOM and CORBA are two major incompatible standards for distributed objects whose interoperability is necessary if development tools are to support seamless system integration.  Strategies for interoperability are:

Java is positioned to provide interoperability between the distributed object standards. Complete interoperability is possible when running orblets on Microsoft's Java VM. Using VisualJ++, ActiveX controls developed in Java use the same notation to operate on Java objects and COM objects. The Java VM, itself an ActiveX control, mitigates the difference between COM and Java objects (see Web+Java/COM). Inside the ActiveX control, objects in Java are treated as if they were COM objects.

IBM's JavaBeans Migration Assistant for ActiveX tool converts ActiveX controls to a JavaBeans component. The tool analyzes an ActiveX control's properties and creates a Java container that takes on the features of the ActiveX control and implements the component functions.

In recent interoperability developments, JavaSoft is building the equivalent of Microsoft's COM for the next generations of JavaBeans, while Microsoft is extending COM and porting the DCOM communication mechanism to Java. Microsoft's extensions to COM consist of message-queuing technology to enable asynchronous communication among networked objects, garbage collection to alleviate resource-leaking problems, persistence, distributed debugging, and DCOM rewritten in Java so COM objects running in Windows can interact with Java applets. JavaSoft's extensions to Java Beans consist of an aggregation/delegation model for composition, separate design and run-time support for JavaBeans, a drag-and-drop system for visually manipulating JavaBeans, a composite GUI that embeds a user interface in a JavaBeans component, persistence, and data-typing and registry capabilities so a Bean can determine if other Beans are installed on a Windows platform.

Recent Developments

One problem with a survey is keeping up the advances in the technology surveyed and the changes in the vendors supplying that technology. There has been recent movement in both the COM and CORBA camps. In September 1997, Microsoft announced plans for COM+.  Around this timeframe, Inprise (formerly, Borland) bought Visigenic, and a number of vendors dropped their ORB products, namely Sun (NEO), IBM (SOM), and HP (ORB+). However, IBM is working on Component Broker due sometime in 1998, Netscape has embedded the Visigenic ORB in Communicator, Sun and SGI are embedding ORB technology in their operating systems,  and IIOP is being layered on Java RMI. With these latter developments the foundation will be laid for ubiquitious access to CORBA services and provide the impetus for vendors to implement OMG's service and facility specifications. Furthermore, the bundling of  CORBA in Sun's JDK 1.2 and the development of the Java Enterprise API's will have additional impact of the pervasiveness of CORBA.  Expertise ORB development is ending up concentrated in a few vendors, namely, BEA, Visigenic/Inprise, and Iona who are focused on providing a heterogeneous platform solution. Meanwhile, there are still numerous free ORBs such as ILU.

Future Directions

The Web is in a state of transition as it moves from a document-centric, information infrastructure towards an infrastructure for global network-centric object computing. In this section we examine the key technology advancements and enhancements that need to take place to achieve reliable, secure internet computing and develop internet applications. The text is a mixture of on-going activities, proposed activities, and suggestions.

One overarching problem is the lack of standards and the diversity of approaches. Objects enable Web applications to be built out of common APIs and reusable components, and rely on common object services. Unfortunately, there is no standard object model and we will have to contend with interoperability mechanisms for years to come (see Prevalent Directions above). Common standards are also lacking in other areas, e.g., at the transport protocol level and access to remote objects. Competing purposed and proprietary standards from OMG, IETF, W3C, Open Group, Microsoft, Netscape, and others need to converge; otherwise, developers will have to contend with interoperability bridges. The OMG approach of merging the best of submitted RFPs into a single specification seems like a viable strategy, but probably will not happen given the different business models of the commercial players.

The key areas that need to be addressed by researchers are:

Architectural

Treating the Web as a metacomputer for performing network computing across 3 or more tiers requires additional functionality currently lacking, e.g., providing quality of service (QoS) to users in a timely manner and optimizing performance. Such capabilities require supporting infrastructures, in particular, the performance of the Web must be monitored. The challenge is determining how to integrate the architectural support into the existing Web's architecture, existing plumbing infrastructure such as CORBA and DCOM, Web programming languages such as Java, and object services. OMG's Internet SIG has produced a list of recommendations for composable architectures and extending the OMA to an Internet Services Architecture.

CORBA-NG

The next generation of CORBA should support the following functionality at the core, service, and facility levels: Many of the above ORB-related technologies have been submitted by multiple vendors to OMG and are in the process of being merged into final specifications (expected by mid-1997). All of the above enhancements are not expect to be supported. The end result will be known as Corba 3.0.

HTML-NG

W3C HTML Extensions

W3C's 1997 roadmap for new HTML features includes: Netscape's Communicator browser will support both style sheets and dynamic fonts.

For a complete list of extensions currently under consideration and their descriptions, see here. The list includes

Dynamic HTML

Dynamic HTML lets a Web page change itself once downloaded. Downloaded information can be kept hidden until requested by a user using the concept of layering - blocks of HTML can be defined as existing either over or under other blocks on a page. Microsoft and Netscape plan on different layering support mechanisms. Microsoft plans on using complex style sheets while Netscape will use both Cascaded Style Sheets and the Layer tag. Style sheets are supported by W3C, while the latter was rejected. Still to be resolved are the scripting language interfaces for Style Sheets under HTML. Microsoft's Dynamic HTML Web page contains a whitepaper, overview of the underlying object model, FAQs, and a reference guide.

Mobile Objects/Agents

An important step towards Internet Computing is mobile computations. A mobile object, called an agent when operating on behalf of a user, is a downloadable, executable object that can independently move (code and state) at will. Mobile agents provide a way to think about solving software problems in a networked environment that fits more naturally with the real world. Mobile agents can be used to access and manage information that is distributed over large areas [Dale]. A mobile agent architecture provides the "framework within which mobile agents can move across distributed environments, integrate with local resources and other mobile agents, and communicate the results of their activities back to the user. This framework can then be used to build mobile agents that perform user-driven tasks to fulfill distributed information management goals." Taking this notion further, mobile agents could be used to monitor the network and provide input to QoS and global optimization mechanisms. They could be used during negotiation (with representative agents) to solve constraint satisfaction and optimization problems.

One key research area is providing security against malicious agents (who need access to local resources or can carry a virus) and malicious hosts (who can alter an agents code and state or read private information).

The OMG has an RFP for a Data Interchange Facility and Mobile Agent Facility RFP. "In order to implement mobile agents, three key features need to be supported by ORB: launching and loading of agents on what is traditionally thought of as the client side of the ORB, time asynchronism, and ORB notifying senders and receivers of arrival of packets intended for them. The mobile agent facility proposes these changes." Revised submissions are due June 2, 1997. A joint OMG submission from IBM, Crystalize, GMD FOCUS, and General Magic, Mobile Agent Facility Specification, was submitted April 21, 1997 (Draft 5) and is supported by the Open Group. The 1996 Joint W3C/OMG Workshop Distributed Objects and Mobile Code contains a collection of papers on the topic.

Significant current projects and mobile object/agent technology developments are:

Network/Internet Computing

Dynamically integrating existing computational resources accessible via the Internet into a computing network environment provides a viable alternative to using MPP and supercomputer systems. To arbitrarily deliver and redirect the shared power of the network will require advances in network communications architectures as well as other orthogonal dimensions. The current message-based communication protocol between nodes is insufficient. Critical research directions are:

Protocols

Current Internet transport protocols need to be enhanced to support security and improve performance.

FastCGI

OpenMarket's FastCGI is one open proposal before the W3C that improves the performance of all Internet applications without any of the limitations of CGI and existing server APIs, namely, one process per CGI script and one multithreaded process, respectively. Instead, there is a separate process for each FastCGI program that doesn't die after one request. If it does die, a FastCGI manager automatically restarts it. Two features over CGI are that a FastCGI application can be on a machine different from the server and its functionality is extensible. The FastCGI model combines the safety of a separate process with server software independence, and permits state to be maintained between requests.

HTTP-NG

The progression of the HTTPstandard is HTTP 1.1 -> HTTP 1.2 -> HTTP-NG. A good overview of new HTTP/1.1 functionality and changes from HTTP/1.0 can be found here. A number of implementation issues of HTTP 1.1 need to be resolved before the Proposed Standard moves to Draft Standard status. Current W3C activities can be found here.

HTTP 1.2 supposedly will contain functionality that didn't make it into HTTP 1.1 and address issues like demographic data, features, version management and search facilities.

Most of the ideas in HTTP-NG  are embodied in Simon Spero's specification. W3C is implementing a HTTP-NG proxy server using the Xerox ILU system to investigate feasibility of object technology, and allow for direct comparison with HP's implementation.

The IETF Internet-Draft PEP: an Extension Mechanism for HTTP accommodates extension of HTTP clients and servers by software components.

IPv6

The Internet Protocol (IP) does not provide reliable transmission of messages. The Internet Control Message Protocol and Internet Group Membership Protocol can be used to subvert routing or mount denial-of-service attacks. Protocol encryption would thwart subversive activities, but at the expense of reduced throughput because encrypted data generally cannot be compressed. The cryptographic security mechanism, Encapsulating Security Payload, in IPv6 supports integrity and confidentiality and under certain circumstances authentication. The IP Authentication Header only supports authentication and integrity. Both conform to the Security Architecture of the IP and should be implemented.

Security

If the Internet is to be used to conduct business transactions, mechanisms need to be put in place to protect intellectual property rights and financial transactions. Lack of security has fostered intranets and firewalls creating segments of infrastructure only partially connected to the Internet. Such segmentation impedes the dissemination of information and offloading of client-side programs. Areas where advances in information security mechanisms are needed are: Areas in need of program security mechanisms advances are: The basic security problem of allowing a hostile Java applet/application or ActiveX control to execute in a client's environment needs to be addressed. Security features in the language and transport mechanism are necessary, but not sufficient. Provision of security during program execution ultimately rests with the operating system. The applet/application should be treated like an anonymous user with restricted access privileges to system commands and files. Foolproof mechanisms are needed to extend those privileges dynamically. Current OSes need to be modified to provide such security measures. For example, NT 5.0 will have a guard-everything security scheme. This scheme supports multiple security protocols via the Security Service Provider Interface (SSPI) which is not completely compatible with the IETF Generic Security Services API. SSPI provides a standard way to access distributed security services. Security protocols are implemented by components called Security Service Providers (SSPs). Supported SSPs includes Kerberos. Network protocols, such as HTTP and DCOM, can run on any security service through SSPI. Distributed security services provide user authentication, authorization of user access rights, crytographic checksum for data integrity, and data encryption for data privacy.

The W3C Digital Signature Initiative is addressing the use of digital signature, identity certificate, packing list, and content label technologies to help users decide what code and data to trust on the Web.

A recent NSA/OMG Security Workshop addressed CORBA security, requirements for secure ORBs, the CORBAsecurity service, CORBA security architectures, and alternative models for securing CORBA environments (namely, use of firewalls and SSL).

Services

A number of fundamental services are needed to support optimization decision making, provide a level of contracted quality of service, and reserve network resources: A Mobile Agent Facility is an enabler for Internet Computing. See CORBA-NG and Mobile Objects/Agents above.

Web Performance

Web servers represent potential bottlenecks and a single point-of-failure. Current solutions involve caching proxies and replication of data. However, each solution by itself has inherent problems. For caching, the Web complicates the replacement policy (e.g., factoring the size of the data), determination of document access patterns, determining reload time, and maintaining cache coherency (i.e., keeping cached documents fresh). For replication, it is necessary to maintain consistency between the data stored on the original server and its mirrors. A major challenge is making replication transparent to the client. One recent study at the University of Kaiserslautern [Baentsch] demonstrates the potential advantages of combining the two technologies. No changes are required to browsers or the HTTP protocol. The approach involves a client-side proxy and replicate servers whose existence and location are learned as documents are accessed. One extensible direction is providing application-level QoS over the Internet, e.g., re-routing requests based on previous usage patterns.

More advanced activities are being pursued by the W3C to address open research issues, and make the Web more robust, responsive, and scalable. Some of the key technologies involved include automated, transparent selection of the closest available replica of a service, distributed replication and error recovery, multicast based replication, and cooperative caches, integrating client pull and server push functionalities.

Systems, Projects, and Products

There are a growing number of projects, systems, and products in the area of Web and object integration. In this section we give a brief description of each with emphasis on the architectural approach taken. The systems, projects, and products can be categorized as follows:

Active Platform at Microsoft

The Active Platform is a set of client and server development technologies for building Internet and Intranet applications using a single component model.. It consists of the Active Client, Active Server and ActiveX.

The Active Client is the set of technologies that enables developers to deliver "least common denominator" components or applications that run across multiple operating systems (Windows, Mac, and UNIX) and multiple browsers. The Active Client provides a programming model for client-side computing using HTML 3.2 and Dynamic HTML, scripting via Visual Basic Scripting Edition (VBScript) and JScript, and Java or ActiveX components.

The Active Server is the set of technologies that enables developers to easily build and deploy component-based server applications. It includes the services needed to make component- and Web-based applications run over the network. The Active Server technologies include the distributed component object model (DCOM), Active Server Pages (ASP), Microsoft Transaction Server, message queues, Windows NT Server (directory and security services), Microsoft SQL server, OLE DB, ODBC, and Microsoft Internet Information Server (IIS) 3.0.

ActiveX is a set of technologies that provides cross-platform, component interoperability in a local or networked environment, regardless of the language in which they were created. It enables client- and server-side components to communicate and interact with one another regardless of whether the component is local or remote. ActiveX includes the component object model (COM) to enable communication between client components as well as DCOM to integrate components across the network. Components that run on either the client or server can be developed using the ActiveX SDK, Visual J++, Visual Basic and C++, or Visual Basic Control Creation Edition.

IIS 3.0 is an information delivery and network applications platform that includes a Web server, component-based application development environment (Active Server Pages), integrated full-text searching (Index Server), multimedia streaming (NewShow), and site management extensions (FrontPage 97 Server Extensions). ASPs let one combine HTML, scripts, and reusable ActiveX server components into a Web-based application. Active Server Pages includes native support for both JScript and VBScript, and ActiveX scripting plug-ins for REXX, PERL, and Python, and other CGI-based languages. Additional built-in functionality includes Web access to enterprise databases, application state management components, and a Java VM.

ActiveX at Microsoft

See the Active Group's webpage.

ANSAwebat ANSA Distributed Systems Laboratory (UK)

Category: Web+CORBA

ANSAweb, part of the ANSA Workprogramme, consists of 2 project phases. Phase 1 provides object wrappers for Common Gateway Interface (CGI) services using OMG IDL. This technology demonstrator has been available for public release since June 1995. The code includes an IDL to CGI stub compiler (SC-CGI).

Phase 2 's uses CORBA IIOP as an alternative protocol to HTTP, and object wrapping for integrating Web services and third party services (or legacy applications) as CORBA services using OMG IDL. The code is available in the form of the ANSAweb Distribution Kit.

ANSAWeb provides a strategy for interoperability between the Web and CORBA by HTTP-IIOP gateways -- the I2H gateway converts IIOP requests to HTTP, and H2I converts HTTP requests to IIOP. The H2I gateway allows WWW clients to access CORBA services; the I2H gateway allows CORBA clients to access Web resources. The pair of gateways together behave like an HTTP proxy to the client and server. An IDL mapping of HTTP represents HTTP operations as methods and headers as parameters. An IDL compiler generates the client stubs and server skeletons for the gateways. H2I is both a gateway to IIOP and a full HTTP proxy so a client can access resources from a server that does not have an I2H gateway. A locator service decides when to use IIOP or HTTP. It the locator can find an interface reference to a I2H server-side gateway, IIOP is used; otherwise, the H2I gateway passes the request via HTTP. The interface between H2I and the locator is in IDL provides implementation flexibility.

Arabica at IBM

Category: Web+Java/CORBA

Arabica is an internal name for a collection of technologies providing tools for deploying corporate information systems through the World Wide Web. Arabica includes a set of Java Beans components for:

Arabica, which is based on OpenDoc technology, provides a cross-platform component architecture for developing Java applets and applications. Arabica enables diverse Java applications in complex business environments to interoperate seamlessly. Arabica also provides the means for connecting applications on the Internet to enterprise transaction systems and databases.

VisualAge for Java is an incremental application development environment that enables developers to visually build Java applets and provides visual partitioning tools, enabling users to connect to existing enterprise server data, transactions and applications. The CBToolkit, part of the Component Broker, incorporates VisualAge for C++ and VisualAge for Java, and can generate corresponding Java, C++, and ActiveX** client components. The Component Broker also contains CBConnector which performs workload balancing, operational monitoring, activity logging, troubleshooting and other management functions across distributed networks from a centralized point of control. CBConnector and CBToolkit are full implementations of OMG's CORBA, COS, and IIOP, and provide the infrastructure for developing, deploying, monitoring and administering component-based applications across networks.

Component Broker provides an infrastructure base for IBM's Commerical Shareable Frameworks initiative, a.k.a. project San Fransicso, whose goal is to build a series of reuseable 100% pure Java application business frameworks designed to reduce the complexity, expense, and time-to-market for Independent Software Vendors (ISVs) to build customized multi-platform business applications. The intent is that the shareable frameworks would provide 40% of a typical working application within the supported domains while ISVs would develop the remaining 60% of the application business processes and services on top of the frameworks.

Caffeine at Netscape

Category: Web+Java/CORBA

Caffeine is a complete Java implementation of the CORBA specification, i.e., it is a Java ORB. Its distinguishing feature is that a developer need not learn IDL – IDL is generated from the Java code. Java is used both as an interface definition language and an implementation language. Caffeine includes: 1) a Java2IIOP code generator that produces IIOP-compliant stubs and skeletons from Java interface classes; 2) a Java2IDL preprocessor that produces CORBA IDL from Java code; and 3) a URL-based CORBA naming service. Caffeine is layered on top of VisiBroker for Java and the VisiBroker's Naming Service.

A Java interface is declared to be remote by extending it from the class CORBA.Object which is part of the ORB runtime. The IIOP stubs and skeletons are generated, using Java2IIOP, from the bytecode output by the Java compiler. The resultant IIOP stubs and skeletons are identical to the ones that would be generated by the idl2java compiler.

To make Java objects accessible from other CORBA/IIOP clients written in different languages, they must be registered with the CORBA Interface Repository. This requires CORBA IDL files. The IDL files are generated by Java2IDL which parses the Java code looking for remote interfaces. Finally, the IDL files are loaded into the IR using VisiBroker's utility, IDL2ir.

With Caffeine one can use a variety of naming services: Visigenic/Inprise's SmartAgents, a CORBA COS Naming Service, and a URL-based naming service. The URL Name Service is based on the Resolver Interface which lets a URL be bound to a CORBA object reference and the object reference bound to a URL be obtained. Server objects register themselves with the Resolver, i.e., associate themselves with a URL. Client objects invoke the bind method of a server object via the proxy stub passing the URL; the object reference is returned.

Netscape, in conjunction with Sun and IBM, are developing the Java Foundation Classes (JFC), a comprehensive set of tools for defining the look and feel of Java applications. JFC is the combination of Netscape's Internet Foundation Classes (IFC) and Sun's AWT. JFCs are each built as a JavaBeans component. JFC will be in the next release of JDK.

CORBA Desktop at DSTC

Category: Web+CORBA (specific gateway)

The CORBA Desktop is a tool-set which allows CORBA objects to be invoked from WWW browsers. An HTML-based GUI is generated for a service from its IDL interface. The HTML form invokes a script via CGI which invokes a generic CORBA client. Using DII, the CORBA client invokes the CORBA service. The limitations of the approach are slowness (due to communication and computation overhead) and the lack of type safety (due to the CGI)

CO