Web + Object Integration



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 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 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.


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


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.


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.


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.


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:


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

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.

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.

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.


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*.


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.


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.


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.


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.


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).


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.]


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:


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.


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.


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:


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


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.


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.


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.


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).


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)

CORBA Desktop is part of the Distributed System's Desktop in which arbitrary services can be invoked in a distributed system without prior knowledge of their existence and their interface specifications.


Category: Web+Java/CORBA

CORBAnet is an illustration vehicle sponsored by the OMG and developed and maintained by the Australian research organization Distributed Systems Technology Centre (DSTC) to both demonstrate interoperability between ORBs from various vendors using the Internet Inter-ORB Protocol (IIOP) and the potential use of CORBA over the WWW. CORBAnet links together the hardware, operating software, object request brokers, and associated products from key CORBA vendors. CORBAnet also serves as a testbed for CORBAservices and CORBAfacilities.

To access CORBAnet hyperlink to http://corbanet.dstc.edu.au. The CORBAnet application is a meeting booking system that allows users to book a room and staff for a meeting.

CorbaWeb/CorbaScript at HP Labs (Ph.D. Thesis)

Category: Web+CORBA

The CorbaWeb environment is a generic gateway between HTTP servers and CORBA objects which makes it possible for Web clients to navigate through CORBA object links using dynamically generated URLs for each object. CorbaWeb receives the user's actions through a Web Server CGI program and translates them into scripts for the CorbaScript component which invokes a CORBA/application object, and returns a HTML document containing the requested results.

A browser invokes CorbaWeb with HTML forms exactly as it would for a CGI application. The HTTP server passes certain requests to a CORBA client which runs as a module within the Web server. The CORBA client interacts with CORBA gateways which in turn interact with IDL wrappers of data sources. Installing a new gateway object is a matter of starting it from the command line; it registers itself with the CORBA name server, and becomes visible to the CORBA client and thereby accessible to the Web server. Server side includes embed ORB invocations into an HTML document. The message to CORBA is encoded in a URL (e.g., http://www.someBank.com/orb/customers/teller references a service called "teller"). The CORBA client invokes the gateway's invoke() operation on the URL encoded data, similar to the CORBA DII and Dynamic Skeleton specifications, which decodes the URL and invokes the object wrapper which implements a service. If the decoded data includes a tag identifying the originator of the request, any output from the object wrapper is encoded as HTML by the gateway and returns it to the CORBA client which passes it back to the browser. In this scheme, there is a separation of service and presentation logic in that the object wrapper delivers the service and the gateway deals with presentation issues (decoding input and rendering output as HTML).

DCE-Web at OSF

One of the major offerings of the DCE Web project is the WanD (Web and DCE) Server.

GemStone/J at GemStone

See the GemStone/J and CORBA whitepaper.


Catyegory: Web+Java

HORB is a Java ORB that is not compatible with CORBA. It supports communication only between Java objects. Remote method invocation follows the standard ORB paradigm: a client stub routine (proxy for the server object) transmits the invocation via the ORB to a skeleton routine on the server. HORB uses its own on-the-wire format for Java objects, but supports multiple inter-object communication protocols via the Inter-Object Communication Interface (IOCI). Client stubs and server skeletons are generated directly from the Java source; there is no separate IDL. The HORB compiler is a preprocessor that generates Java source and calls the standard Java compiler to compile it. The HORB application language is Java without any extensions. The HORB client runtime is a set of Java classes; the HORB server runtime is a Java stand-alone application. Performance analysis shows that HORB is 2-3 times faster than Java RMI.

ILU System at Xerox PARC

Category: Web+Java/CORBA

The InterLanguage Unification (ILU) System, through its Interface Specification Language (ISL) or the OMG Interface Definition Language (IDL), permits object-oriented interfaces between units of program structure, called modules, to be defined and documented. An interface specifies object types, other types, constants, exported methods, and exceptions that another module would use to communicate with it. ILU tools produce stubs for particular programming languages from the interface descriptions. These stubs can bind to, call, and be called from other stubs generated from the same interface description. To create a program, stubs are linked with application modules, ILU runtime support for the target language, and the ILU kernel library. Modules can be part of the same memory image or different memory images on different machines. A particular module might be part of several different memory images at the same time. ILU does all the translating and communicating necessary to use all these kinds of modules in a single program.

ILU 2.0 supports bindings for many languages used to implement modules, namely, ANSI C, C++, Modula-3, Common Lisp, Python, and Java. It also supports OMG's Internet InterOrb Protocol (IIOP) which allows ILU to communicate with other ORB systems. ILU can be used to build multi-lingual object-oriented libraries, implement distributed systems, and write CORBA services or clients. It is being used in several Digital Library research efforts such as the Stanford Digital Library and in the W3C implementation of the next-generation of HTTP (HTTP-NG).

Jylu is a complete Java implementation of the ILU runtime kernel and Java language binding.

Infospheres Project at Caltech

See the DOMC 96 accepted position paper.

Jade at APM Limited (depreciated)

Category: Web+Java/CORBA

Jade is a CORBA 2.0 IIOP communications engine written entirely in Java. The Jade "ORBlet" can be automatically downloaded into a web browser thereby providing Web users with access to CORBA services via the Internet. Enterprise service providers offer their on-line services to their customers through Web based, downloadable user interfaces implemented as a Java applet. The applet talks to its CORBA-based server using the Jade ORBlet.

JavaBeans at Sun

Category: Component Architecture

JavaBeans is a set of Java component APIs which allows developers to write portable Java applets and applications from reusable components that can interoperate with other Java applets and applications, as well as with other existing document-sharing/component models via bridges, such as HTML-based frameworks (e.g., Netscape Navigator and JavaScript), LiveConnect, OpenDoc, ActiveX/OLE/COM, and CORBA. IBM and Apple are working on bridge technology that would enable OpenDoc and JavaBeans to work together in MacOS, OS/2, UNIX, and NextStep environments. SunSoft's JavaBean's–ActiveX bridge allows JavaBean components to be embedded and run in legacy ActiveX containers. Application-building tools, such as IBM's VisualAge, SunSoft's Java WorkShop, Symantec's Visual Café, and Inprise's JBuilder allow developers to graphically compose Java components and applications.

Beans can interact with several distributed computing approaches. Beans can use Java's Remote Method Invocation (RMI), CORBA IDL interfaces and IIOP, or JDBC and a database protocol for remote object access.

Java Beans provides a composite mechanism by which a Bean can publish its functionality, i.e., the properties, events, and methods the Bean it supports. The first mechanism is a low-level mechanism called reflection. By conforming to naming conventions (design patterns) for properties (named attributes), events, and methods, any Java Bean-based tool can read from a Java Bean's .class file what properties, methods, and events are available in it. The second mechanism is called introspection. A Java Bean's capabilities can be dynamically read through a BeanInfo class and several descriptor class types, which contains all the properties, events, and methods used inside a Java Bean. The composite mechanism for analyzing Beans is the Introspector Class that understands both design patterns and standard interfaces. The Introspector class searches for a BeanInfo class and if found uses the explicit information; otherwise, it uses the low-level Java Core Reflection API to deduce the implicit information. In either mechanism, there is no system registry to update and no separate Java Bean repository.

Enterprise JavaBeans extends the JavaBeans component model to provide a object-oriented transactional environment to build scalable business applications for manufacturing, financial, inventory management, shipping and payroll, and data processing as reusable server components. The draft specification for Enterprise JavaBeans will be available in summer 1997. Enterprise JavaBeans is part of the Java Platform for the Enterprise.

Jigsaw Server at W3C†

Jigsaw is a complete HTTP server written in Java. It main purposes are to test and demonstrate new HTTP 1.1 features and provide a basis for experimentation with server software (e..g., mobile code).

Server-side entities (directories, files etc.) are defined as resources, objects with methods that define behavior and attributes that capture state. Resource objects are a way of extending the server's functionality, and they replace CGI. All defined attributes must to be registered with an AttributeRegistry. An example of a resource is HTTPResources which has overloadable methods to handle the different kinds of HTTP requests (get, put etc.) and a set of attributes to define content-type, content-encoding, the MIME type of the resource etc. Other typical kinds of resources include FileResources, DirectoryResources, CgiResources, etc. New resources are defined in the typical OO manner by subclassing from the one of the appropriate pre-existing resource classes.

Resources can be created by either directly defining the resource object, or by wrapping an existing file system entity (file/directory) into a Jigsaw resource. For the latter to be done automatically, Jigsaw maintains a mapping between the Resource type and the underlying file name as part of the resource factory. One can also programatically create resources corresponding to entities in the filesystem without using the auto-wrapping capability. The programmatic approach is more versatile, e.g., it can allow many-to-many relationships between resources and file system entities, allow a resource name to be independent of the location of the file it is mapped to, etc.

Each running server has an associated resource factory. The resource factory allows the association of existing files and directories in the file system with resource types. It also allows resources to dynamically create/manipulate other resources. For example, a DirectoryResource can dynamically call the resource factory to create FileResource objects on-demand in response to HTTP get requests.

Comparing resources to CGI:

†The description of Jigsaw is mostly adapted from Venu Vasudevan's technical note IAS Experiments with the Jigsaw HTTP Server.

JTF-ATD Architecture (password protected)

At a DARPA review, Lee Erman (Teknowledge) presented the Web Server (OMG document internet/96-01-04), which serves structured webs of interdependent ideas and services, and provides easy access and editing. Version 1 (password protected), completed in 1995, provides command and control schema objects embedded in nodes, persistence, subclassable web/nodes, triggers, and a WS gateway to HTTP and WWW browsers. Version 2 (96) will provide distributed collaborative access over variable communications, replication of nodes/webs for performance over WAN, concurrent multiuser access, access control and locking, and versioning. Version 3 (97) will adapt to variable-bandwidth communications. The generic version is called WebMan.

The Web Server project is part of the JTF-ATD reference architecture for command and control (C2). Many DARPA military projects have adopted this architecture or are extending it for use in domains such as modeling and simulation. In the architecture, various military task force commander domain-oriented collections of applications called "anchor desks" (e.g., planning, logistics, weather, others) depend on an infrastructure of services described in IDL and implemented in C++. Collections of services (called servers) provide capabilities for maintaining communications in a bandwidth-limited environment, access to heterogeneous data sources, web management, map creation, display and manipulation, plan management, situation assessment, etc. A C2 schema (several thousand object classes) is described in IDL and represents the description of shared command and control entities.

The JTF-ATD project is using Iona Orbix and GOTS (government off-the-shelf) CORBA product, CORBUS, developed by MITRE. Both are being integrated and others may be considered later. A dedicated Iona representative in their Boston office is supporting the project as problems are encountered as this is one of the largest Orbix development projects currently in progress.

The JTF-ATD Web Server project has defined a number of structured web types for plans, situations, maps, and models, but arbitrary webs can be constructed on-the-fly. The Web Server is actually a set of IDL and C++ libraries that are compiled into other servers and applications which inherit data structures and methods for creating, accessing and managing webs. Webs represent arbitrary graphs consisting of specialized node and link components which can be named, typed and navigated bi-directionally (from any node/web to any other node/web connected by a link). The Web Server does not have any knowledge of the internal contents of nodes as it is the responsibility of the servers and applications to extend the general data structures and methods contained in the Web Server for capabilities such as display, evaluation or manipulation of contents. Web Server webs and nodes are not WWW objects directly, but can be published in HTML or other representations that can be accessed by WWW browsers through the Web Server WWW Gateway. Military requirements for the Web Server include security, robustness, reliability, and replication of webs and their constituent collections of nodes and links in a bandwidth-adaptive manner. Webs and nodes are versionable to help provide consistency among different views of information and what-iffing. Monitors can be set on any specified nodes and webs to detect specific kinds of changes and triggers start particular actions based on the changes detected. There is a web editing tool (the Webber) which can operate on the specialized JTF-ATD webs or WWW webs, using a point-and-click GUI for establishing and editing links between any nodes and webs to form larger webs. The JTF-ATD project is using CORBA 1.2 services and implementing others as needed until these are addressed by CORBA 2.0 (or later) compliant products. JTF-ATD developers found it necessary to divide the collection of object class definitions into broad, high-level classes defined in IDL, and more specific, fine-grained classes defined in C++ due to IDL compiler limitations in the Sun Solaris and HP/UX environments at around 2000 classes.

While the webs which the Web Server manages are not directly WWW compatible, a bidirectional gateway between the JTF-ATD and WWW environments has been implemented to allow conversion of webs in either direction. Version 1.0 was recently released within DARPA and DoD and access to the prototype software and documentation can be requested by contacting Lee Erman at Teknowledge (lerman@teknowledge.com, (415) 424-0500 x 422).

Joe/NEO at Sun†

Category: Web+Java/CORBA

Joe is primarily a client-side Java ORB that enables the networking of Java client/server applications for the Internet and Intranet. Joe links client Java applets with NEO server objects via NEO's CORBA 2.0 ORB. Joe is automatically downloaded along with the Java applets into a desktop Web browser unless it is permanently installed on the client machine. Joe establishes and manages connections between local Java objects and remote CORBA objects using IIOP. Joe also includes an IDL-to-Java compiler that generates associated Java classes from interface definitions of CORBA objects, and supports remote callback so Java applets can receive asynchronous event notification from remote objects and so Internet users can access secured remote services behind firewalls. Joe is bundled with NEO, Sun's CORBA-based networked object environment for Solaris. NEO contains development tools, system administration tools, and transparent networking to create, modify, customize and maintain applications offered as shared services (business objects). NEO also supports ActiveX/OLE/COM interoperability and access to legacy data stored in different types of databases.

Joe is based on Sun's Spring-Java IDL system.

† In mid-November 1997, Sun announced it will discontinue its Neo ORB, transfer some of its basic functionality into Solaris (namely the CORBA-class libraries and IIOP), and partner with third-party ORB vendors Iona Technologies, BEA Systems, and Visigenic/Inprise Software.

Netscape ONE

Category: Web+Everything

Netscape ONE (Open Network Environment) is a framework for building interoperable Internet applications that uses OMG's CORBA/IIOP as the basis for its distributed object model. By integrating Visigenic/Inprise's VisiBroker, a Java-based, CORBA/IIOP-compliant ORB, into its client and server software products, client and server objects can interconnect and communicate as if they were part of the same application. Using CORBA interfaces, IIOP allows enterprises to access legacy applications as well as build new network-centric applications.

To aid developers in building Web-based distributed applications, Netscape ONE also includes an IIOP-compliant infrastructure that transparently supports distributed method invocation for Java classes, including Netscape's IIOP-compliant Internet Foundation Classes (IF), a common set of Java classes, components, and APIs, and JavaScript. It also supports HTML, Java, communication and collaboration protocols (HTTP, NINTH, SM TP, I MAP4, POP3), and a broad set of standard, scalable security services (SSL 3.0 and X.509v3). (For a complete list with brief descriptions of key Netscape ONE technologies, see here.) Figure 1 depicts the Netscape ONE application architecture.

Netscape ONE Application Architecture

Figure 1: Netscape ONE Application Architecture
(taken from Netscape ONE whitepaper)

A typical Netscape ONE application consists of a client component and one or more server components that interact with the client through a set of common interfaces. Within the Web page container, the client component, Netscape ONE supports three different component execution environments: Java, JavaScript, and native-code components (plug-ins). Java and JavaScript components are platform-independent and can run on either the client or server side. Client and server plug-ins are accessed through platform-independent APIs, namely, the Client Plug-in API and the Server Plug-in API, respectively. The latter can be used to gain access to the major databases. LiveConnect provides a common object and messaging model allowing the three kinds of components to seamlessly interact and transparently access Netscape ONE services; they are treated as member objects of the containing Web page. LiveConnect is built on top of Netscape's Java Runtime Interface, which maps platform-specific object models to the LiveConnect object model. This makes it possible for any Java applet to use native methods. IIOP provides a distributed messaging system through which Netscape ONE applications can interact with other network-centric programs and any CORBA 2.0-compliant enterprise application, such as business objects, EDI, and transaction services. Any network-centric application can be make available as a service using IIOP. The IFC provides Netscape ONE components with a common set of platform-independent objects, APIs, and services required to build and deploy network-centric applications. It consists of controls to build GUIs, frameworks for concurrent, object persistence, and resource localization, and services for messaging, security, and networking.

There are nearly 60 development tools developers can use to develop Netscape ONE applications. The tools fall into three categories. First is Core Component Development Tools used to develop Java applets, plug-ins, CGI scripts, and multimedia elements such as graphics, sounds, animations, and visualizations. Second is Application Building and Integration Tools used to build web pages and web sites using HTML and JavaScript, as well as connect with databases and legacy systems. Third is Web Site Deployment and Management Tools for managing assets and links, and measuring site performance and usage.

Network Computing Architecture (NCA) at Oracle

Category: Web+Everything

Oracle's multi-tiered Network Computing Architecture™ (cf. whitepaper and FAQs) provides a unifying framework that combines client/server, Web/Internet, and distributed object computing technologies into a common computing model based on the open and de facto standards CORBA 2.0 (which include IIOP for object interoperability and IDL for language-neutral interfaces) and HTTP/HTML (which includes TCP/IP). In addition, Java is used to provide programmability, portability and extensibility and ActiveX/COM clients are supported through open COM/CORBA interoperability specifications. NCA allows component-based, network-centric applications to be developed and deployed, and for client devices, mainframes, Web servers, database servers, legacy systems, Internet and Intranets, and distributed object software to work together.

The key architectural components of the NCA (see Figure 2) are:

Network Computing Architecture

Figure 2: Network Computing Architecture
(taken from Oracle's NCA whitepaper)

Cartridges are containers for objects or software components that plug into the client (e.g., browser), application server, or backend database server to provide extensible functionality through open, standards-based interfaces. Cartridges enable existing Client/Server and legacy applications to run in Web environments. They can be written in Visual Basic, PL/SQL, C/C++, JavaScript or Java with an IDL mapping. Cartridges have access to numerous cartridge services, including CORBA services, as well as clients and servers via the ICX software bus.

The Universal Application Server (see Figure 3) includes a Web Request Broker for managing HTTP connectivity and a Connectivity Broker for managing multiple protocol connectivity to other services such as gateways to legacy messaging and transactions services and gateways to X.400 (email) and X.500 (directory services). The Web Request Broker provides the services of the ORB to Web cartridges which enable users to maintain a constant connection between a client, application server and database server. It supports dynamic load balancing of processes. The Connectivity Broker handles existing client/server and special purpose mechanisms.

Universal Application Server

Figure 3: Universal Application Server
(taken from Oracle's NCA whitepaper)

The Universal Server (see Figure 4) has an embedded IIOP protocol enabling it to host CORBA objects as well as enable data cartridges to talk to other cartridges across distributed architectures.

Universal Server

Figure 4: Universal Server
(taken from Oracle's NCA whitepaper)

A COM/CORBA bridging mechanism will enable ActiveX/COM clients to access other CORBA/Java cartridges through IIOP. Through ICX, ActiveX/COM clients will also be able to access ORB services provided by the Universal Application Server. In addition, NCA will provide the ability for a Java applet running within a COM application to communicate with an ActiveX control.

The NCA will support Java integration into CORBA/IIOP through a joint CORBA RFP with Sun Microsystems.

Oracle's Project Apollo is a business-to-consumer Internet merchant server built on top the NCA and plugs into the Web Request Broker as an application cartridge.

Open Blueprint at IBM

Category: Web+Everything

Open Blueprint is IBM's architectural framework for heterogeneous, distributed, network computing. The Open Blueprint structure provides support for the development, execution, and management of distributed, network applications. It supports HyperText Transfer Protocol (HTTP), Web Browser, Java, DCE, CORBA and CORBA services as well as expanded security, directory and network service functions. It also supports collaboration, intelligent agents and their management, enhanced systems management, internationalization of software and mobile computing functions.

The Open Blueprint structure (see Figure 5) views a system as part of a distributed network and the network as if it were a single system, i.e., everything is viewed as a single system image. As seen in the figure, there are 6 sets of component services: Network Services, Distributed System Services, Applicaton Enabling Services, Systems Management, Local Operating System Services, and Development tools. The building blocks in the figure contain multiple product-independent components implemented by various products on different system platforms. The Open Blueprint structure does not describe packaging of the implementations, but provides software principles and guidelines, defines the desired functions, and specifies important boundaries, interfaces, and technical attributes. Components can be combined to form infrastructure building blocks that can support different computing styles, such as two-tier, three tier, and N-tier client/server or network computing, and support for specific technologies and products.

Open Blueprint structure

Figure 5: Open Blueprint Structure
(taken from IBM's Whatis Webpage)

A network of systems function as a unit connected by a communications network. Services on each system manage resources cooperatively across the network. All services are accessible by all applications from each platform even though all services are not on all platforms. Each node in the network is viewed as following the Open Blueprint structure.

The Distributed System Services consist of Communication Services, Object Management Services, and Distribution Services. The Communication Services supports 4 communication modesl: X/Open's Common Programming Interface for Communications (CPI-C), RPC, Messaging and Queuing, and HTTP. The Object Management Services include the Distributed SOM ORB, and the Life Cycle, Externalization, and Collections basic object services. The ORB is an implementation of OMG's CORBA and supports objects written in C++, SmallTalk, and Java. The Distribution Services enable a single system view of the network.

The Application/Workgroup Services supports compound documents and intelligent agents. The key compound document technology is OpenDoc. Intelligent agents are composed from the 5 sub-components of the Intelligent Agent resource manager: adapters, engines, knowledge used by the engines, libraries that provide knowledge persistent across agent activations, and tools for user interaction. The Application/Workgroup Services also includes the Java Virtual Machine that provides a platform independent execution environment for Java programs.

Orbix/OrbixWeb at Iona

Category: Web+Java/CORBA

Iona has two ORB products. The C++ ORB, called Orbix, runs on over 20 OSes including UNIX, Windows 95/NT, MAC, OpenVMS, and MVS. These ORBs supports both IIOP and the proprietary Orbix protocol. Orbix is fully compliant with the CORBA 2.0 specification. The Java ORB, called OrbixWeb, is a lightweight client-side implementation of Orbix.

The Orbix architecture supports CORBA/COM integration. Orbix Desktop for Windows is the integration vehicle. COM-based distributed Windows applications can transparently access and distribute CORBA services while CORBA services can transparently access COM objects on Windows. Four integration models are supported: COM client - CORBA server, CORBA client - COM server, client and server in COM, and client and server in CORBA. An Orbix Wizard generates the proper code in each case for the developer.

Orbix server objects may be written in C++ or Java. The OrbixWeb IDL compiler will be fully compatible with the IDL-to-Java mapping when it becomes a standard.

ORB Plus at HP (deprecated)

Category: Web+CORBA

ORB Plus is a fully threaded, scaleable implementation of OMG's CORBA/IIOP 2.0. It includes CORBA Connect, Enterprise Wizards, and the new services Trader Service, Transaction Service, and Security APIs. ORB Plus supports full two-way COM/CORBA interoperability via CORBA Connect. CORBA Connect provides real-time transparent conversion between the OLE, COM and CORBA object systems. It is is fully compliant with the OMG's COM-CORBA Interworking Specification. The package also include a JIT compiler and GUI object browser. Enterprise Wizards for Microsoft Developer Studio and Visual C++ assists developers creating C++ applications using ActiveX clients and COSS1 method invocations. It consists of the Server Wizard which generates server skeletons based on IDL files and user input, and the Insertion Wizards generates code to modify environment variables, and access the Naming Service, LifeCylce Service, and Events Service.

Future releases will include CORBA Components for developing applications with web browser front-ends. The HP CorbaWeb component allows the use of simple HTML forms programming to access CORBA servers; it includes a customized version of the Apache HTTP server. The Java ORB is a fully CORBA 2.0 compliant ORB implementation in Java for developing distributed Internet applications.

SOMobjects at IBM

The SOMobjects is IBM's implementation of the CORBA standard; the product is referred to as SOMobjects. The toolkit contains SOM (System Object Model), an object-structured protocol that allows applications to access and use distributed objects implemented in different languages. SOM consists of a IDL compiler, a runtime to define classes at runtime and invoke methods on objects, a CORBA ORB, and a collection of object services. The latest version, SOM 3.0, is CORBA 2.0 compliant, includes many OMG services (Life Cycle, Security, Transaction and Naming), uses a naming service to locate and instantiate specialized factory objects, and conform with the OMG Persistence specification. SOM is an integral part of OpenDoc, providing its underlying CORBA-compliant object bus. SOM also provides the object infrastructure on which the OS/2 Workplace Shell is built.

SOM extends CORBA with a Metaclass Framework that allows components to be dynamically created from existing components. It also allows components to be customized by inserting system behavior into binary object classes. This permits an object factory to combine a component's binaries with extended binaries that provide support for security, transactions, and concurrency.In addition, an object can inherit from a before-after metaclass, so each method invocation on an object can be preceded by a before method, and the end of execution of each method can be followed by a call to an after method. This is useful for pre/post processing, acquiring/releasing locks, logging information, or calling a security or licensing server.

Microsoft's DCOM is nearly the same thing as DSOM. They both allow objects to be created that other programs and objects can operate on in a binary-standard manner. Both Microsoft and IBM use these object facilities to write OS controls. Developers can use the same controls and easily modify their behavior.

Stanford Digital Library Project

Native library services (Lycos, Web Crawler, Alta Vista, Oracle's ConText document summary tool, converters, Knight-Ridder Dialog Information Service, Stanford online catalog) use an experimental Digital Library Interoperability Protocol (DLIOP) that allows CORBA clients to interact with Library Service Proxies (CORBA objects) by wrapping each native library service in its own IDL wrapper. The implementation platform is Xerox PARC's ILU, a free implementation of a CORBA superset. Most of the code is developed in the interpreted, object-oriented language Python. For the project, a number of generic base services were developed (Common Object Services) in order for the objects to function in a distributed network environment, in particular, a naming service, event communication services, event channel administration services, life cycle services, object property service, and a factory service.

The project also uses agent technology for managing multiple payment mechanisms and for information finding (collaborative filtering and distributed gathering). An adaptive agent learns to browse the Internet on behalf of the user based on user feedback on the usefulness of previously retrieved pages.

Tcl/Tk Project at Sun Microsystems Laboratories/Scriptics

Category: ?

WebTk is an HTML Authoring Tool (editor/browser) written in Tcl and Tk using an Tcl/Tk HTML library making it easy for Tcl applications to be Web-aware. Sun Labs is adding microscripting support with Tcl so the pages can contain mixtures of HTML and Tcl/TK scripts. These scripts can be executed on the server using CGI to fill in variable parts of the page or on the client using the Netscape plug-in when the page is displayed.

Tcl Browser Plug-in for Netscape Navigator that runs Tcl/Tk applets.

Tcl/Tk documents referencing Safe-Tcl and presentation foils on the Tcl/Tk Project.

See the Scripting whitepaper.

TeleMed at LANL

TeleMed is a distributed, object-based, collaborative health-care environment system that presents a unified view to a virtual patient record. The actual data may exist locally or remotely, but this is transparent to the user. Where processing occurs is also transparent; CPU intensive calculations are performed on a remote supercomputer.

The TeleMed system is built on Orbix's implementation of OMG's CORBA. It makes liberal use of inheritance so using OLE/COM that does not support inheritance would be difficult. The Orbix ORB has been integrated with ObjectStore , a commercial object oriented database from Object Design, to maintain persistence of the TeleMed objects (i.e., patient records). These objects are kept in distributed object repositories. CORBA 2.0 is used to represent and access repository objects. The interface to a repository is published in CORBA IDL and it can be mapped to programming language bindings suitable for individual clients.

Future work include the use of components and features of OpenDoc to implement Telemed's GUI and Graphic Patient Record.

Visual JavaScript at Netscape

Category: Web+Java/CORBA

Visual JavaScript is a visual development tool that enables enterprise developers to build dynamic Java-based applications that are platform independent and run across the Intranet and Internet. Using the point-and-click user interface, developers drag and drop prebuilt software components from the Component Palette onto Web pages. Components can be HTML form elements, JavaScript components, and/or JavaBeans components. Using the Inspector and Connection Builder features, developers can customize the application behavior of these components by visually setting properties and making connections between them. The JavaScript debugger is used to check completed applications. Components can be built using Symantec Visual Café for Java, Inprise's JBuilder, or Netscape's Component Developers Toolkit and added to the Component Palette.

Visual JavaScript enables an application to leverage the services of the Netscape SuiteSpot family of server software and CORBA services accessible via the Internet InterORB Protocol (IIOP) using the Visigenic/Inprise ORB built into the Netscape browser. SuiteSpot services include Netscape LiveWire database connectivity services from Netscape Enterprise Server, messaging services from Netscape Messaging Server, and directory services such as executing Lightweight Directory Access Protocol (LDAP) directory queries from Netscape Directory Server.

VisiBroker at Visigenic/Inprise

Category: Web+Java/CORBA

Visigenic has two versions of their CORBA 2.0 ORB: VisiBroker for Java (formerly PostModern's BlackWidow) and VisiBroker for C++. VisiBroker includes a IDL-to-Java compiler and a IDL-to-C++ compiler and an ORB runtime. VisiBroker is an agent-based architecture. Consequently VisiBroker offers object replication, fault tolerance, object migration, and load balancing. VisiBroker for Java also includes a secure bridge for accessing servers behind firewalls, is multi-threaded so multiple object requests can be handled by a single process, and uses IIOP as it only communication mechanism.

Visigenic/Inprise's VisiBridge is a software bridge that enables communication between COM/DCOM objects and CORBA objects. Applications built with ActiveX controls, Visual Basic applications or OLE-enabled applications can interoperate with CORBA-based server systems. The bridge software turns CORBA IDL interfaces into ActiveX controls. The resulting ActiveX Control objects, which contain CORBA client stubs representing the CORBA objects, are then embedded in client-side applications. Runtime client software passes requests from ActiveX controls to CORBA objects via IIOP.

The VisiBroker Gatekeeper enables an application object outside the enterprise firewall to access objects running on machines behind the firewall. The Gatekeeper supports HTTP tunneling, i.e., IIOP messages are encapsulated in HTTP so they can be passed through firewalls.

VisiBroker fully supports the fault-tolerant CORBA Naming Service for C++ and Java. Multiple naming services running in the same network can locate each other and automatically partition the namespace among themselves. This allows objects on different servers to be replicated and the load balanced. If a server goes down, VisiBroker automatically re-routes client calls to a replica. VisiBroker also supports a URL-based naming service. When a client requests an object services using a URL, the CORBA object reference is extracted from the file specified by the URL and used to bind to that object.

VisiBroker also fully supports the CORBA Event Service for C++ and Java. Using a supplier-consumer models, supplier objects can notify any number of consumer objects via an event channel the occurrence of a subscribed event.

A Java-to-IIOP translator utility can infer the IDL object inter-faces and automatically create the object stubs and skeletons. Java developers can use CORBA without having to learn IDL.

The VisiBroker IDL compiler will be fully compliant with the CORBA binding for Java when it becomes available from OMG.

VisiBroker has been incorporated into Netscape's Communicator browser. This enables Netscape ONE applications to access CORBA services and IIOP-compliant enterprise applications.

Web* (depricated)

Category: Web+CORBA

Web* defines a model to access CORBA services by a WWW browser. Web* is a server-side generic CGI script that accesses a set of layout pages, one at a time, which are HTML documents with embedded Tcl scripts. Web* extracts the HTML and sends it to the client, and interprets all the Tcl scripts and sends the results to the client. The Tcl scripts are written in TclDII, an extension of the Tcl language, which allows the dynamic invocation of CORBA services using DII and the Orbix ORB. Web* also retains client state from each WWW interaction thereby creating the illusion the client is in engaged in session-based transactions. The state information is captured as a collection of Tcl variables, which are transmitted to the clients as embedded hyperlinks in generated layout pages.

Web Broker at DEC/BEA

Category: Web+CORBA

DEC uses its implementation of CORBA, ObjectBroker, to provide WWW users direct access to transactional information. All transactions go through the Web Broker, a common access point between the Web and DEC's internal application network. Running under HTTPD as a "cgi-bin" program, the Web Broker translates user's data provided in an HTML form to a generic ObjectBroker object. Using the completed object, ObjectBroker invokes the remote method to service the user's request. On the application server, the Object Wrapper Layer extracts the parameters from the passed object and formats it correctly for the Application Wrapper layer which invokes the application. The method's results are returned in a similar reverse pattern. The Web Broker merges the method's results returned by the Object Wrapper Layer with a Meta-HTML and outputs it to the user.

The ObjectBroker Desktop Connection (DTC) makes corporate business applications and services accessible to Window applications. With DTC, ActiveX applications can access ObjectBroker’s CORBA servers anywhere on the network or intranet.

W3Objects at University of Newcastle upon Tyne

Category: Web+CORBA (specific gateway)

In the W3Objects model, standard Web resources (HTML documents, GIF images, PostScript files, audio files, and the like) are transformed from file-based resources into objects called W3Objects. That is, into encapsulated resources possessing internal state and well-defined behaviors. The motivating notion is that the current Web can be viewed as an object-based system with a single class of object – all objects are accessed via the HTTP daemon. By changing to an object-oriented paradigm, specialized access can be achieved through the use of inheritance. W3Objects are responsible for managing their own security, persistence, and concurrency control. These common capabilities are made available to derived application classes from system base classes. The W3Object model provides a flexible and extensible way of building Web applications with Web resources encapsulated as objects with well-defined interfaces. Inter-object communication (peer-to-peer) is used though out W3Objects to support functionality such as referential integrity and caching.

A W3Objects server supports multiple protocols by which client objects can access server objects. When using HTTP, the URL binds to the server object and the permitted object operations are defined by the HTTP protocol. Or, the RPC protocol can be used to pass operation invocations to a client-stub generated from a description of the server object interface. W3Objects uses C++ as the interface definition language, although CORBA IDL and ILU ISL can be used.

W3Objects can also be accessed though a gateway, implemented as a plug-in module for an extensible Web server, such as Apache. URLs beginning with /w3o/ are passed by the server to the gateway; the remainder of the URL identifies the requested service and its parameters. Using a Name Server, the appropriate HTTP method is invoked on the requested service.

WebObjects at NeXt/Apple†

Category: Web+CORBA, Web+OLE/DCOM

A HTTP servers talks to a WebObject (WO) application via a single generic WOAdaptor which is a CGI script. The WOAdaptor mediates between the HTTP server and the application. The application to be invoked is obtained from the URL to the WOAdaptor. For example, in the HelloWorld URL - "http://localhost/cgi-bin/WebObjects/Examples/HelloWorld", the part up to "WebObjects" is the URL for the WOAdaptor. The WOAdaptor uses the rest of the URL to find the application, and if necessary invoke it. WO is object model independent. It can interoperate with OLE-based applications and communicate with CORBA 2.0 objects.

An application is a HTTP event loop. An applications consists of multiple components, each of which generates a one page object (dynamic HTML content) of the application dialogue. Components consist of a HTML template, a script declarations file and a script file:

Standard HTML is augmented with a few different elements to denote dynamic content. Webscript, the WO scripting language, is an interpreted subset of Objective-C. Webscript buffers the action programmer from both HTML and HTTP. There is no potential that the same script could be reused for a different markup language and different protocol.

WO has a notion of sessions, and applications can consist of multiple sessions. Data can persist between sessions either by being in Webscript "session" variables (like C++ static data members) or by being stored on the component page. One can do rudimentary load balancing in WO. WOadaptor reads configuration files before launching applications. These configuration files can have machine preferences for application launches.

WebObjects Pro layers on WebObjects, and talks to OLE/COM and CORBA objects on the backend. WebObjects Enterprise layers on the other two, and connects the Web to databases and legacy mainframes. No backend ORB integration is referenced. Netscape and NeXT have an intranet alliance where WebObjects serves as the application development environment, talking to SuiteSpot (server side) and Navigator Gold (Client side).

† The description of NeXt/Apple's WebObjects is an adaptation of Venu Vasudevan's application note WebObjects.



CORBA and CORBA-related books can be found here.

D. Chappel. Understanding ActiveX and OLE: A Guide for Developers and Managers, Microsoft Press 1996, ISBN 1-57231-216-5.

R. Orfali, D. Harkey, and J. Edwards. The Essential Distributed Objects Survival Guide, Wiley (1996), ISBN 0471-12993-3.

R. Orfali and D. Harkey. Client/Server Programming with Java and CORBA, Wiley (1997), ISBN 0471-16351-1.

R. Orfali, D. Harkey and J. Edwards. Instant CORBA, Wiley (1997), ISBN 0-471-18333-4.

G. Pfister. In Search of Clusters: The Coming Battle in Lowly Parallel Computing, Prentice Hall PTR (1995), ISBN 0-13-437625-0.


Dr. Dobb's Sourcebook, January/February 1997 - Distributed Objects (feature articles on CorbaWeb, Hector, and W3Objects)


G. Almási and V. Jagannathan, Integrating the WWW and CORBA-based Environments, http://webstar.cerc.wvu.edu/www4/www4.html (depreciated)

G. Almási. A. Suvaiala, I. Muslea, C. Cascaval, T. David, and V. Jagannathan, Web* - A Technology to Make Information Available on the Web,
http://webstar.cerc.wvu.edu/webice.ps (depricated)

Apple, The WebObject's Developer's Guide,

M. Baentsch, L. Baum, G. Molter, S. Rothkugel, and P.Sturm, Enhancing the Web's Infrastructure: From Caching to Replication, IEEE Internet Computing, 1,2 (March-April 1997), 18-27.

A. Beitz, R. Iannella, A. Vogel, and Z. Yang, Integrating WWW and Middleware, http://www.dstc.edu.au/AU/staff/andreas-vogel/papers/ausweb95/ausweb95.html

K. Brockschmidt, What OLE Is Really About, (Microsoft whitepaper)

T. J. Brando, Comparing DCE and CORBA,

D. Chappell, DCE and Objects,
http://www.chappellassoc.com/DCEobj.htm (deprecated)

P. E. Chung, Y. Huang, S. Yajnik, D. Liang, J. C. Shih, C.-Y. Wang, and Y. M. Wang,
"DCOM and CORBA Side by Side, Step By Step, and Layer by Layer" (Sept. 1997).

J. Dale, A Mobile Agent Architecture to Support Distributed Resource Information Management, Ph.D Thesis (January 1997).
http://www.mmrg.ecs.soton.ac.uk/publications/archive/dale1997b/ (IEEE Internet Computing paper with David De Roure)

M. Dolgicer and P. Fischer, DCOM, ActiveX and Corba Must Live Together, Application Development Trends (April 1997).

G. Eddon and H. Eddon, Understanding the Java/COM Integration Model, Microsoft Interactive Developer (April 1997), 57-68.

S. Fowler, Issues on Integrating Objects on the Web,

E. Hastings and D.Kumar, Providing Customers Information Using the WEB and CORBA: Integrating Transactions, Objects, and the Web, http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/hastings/hastings.html

HotWired article, Steve Jobs: The Next Insanely Great Thing [Web+Objects],

IBM, Overview of SOM, AIXpert (August 95),

IBM, Introduction to SOMobjects,

IBM, Open Blueprint Technical Overview,

D. Ingham, M. Little, St. Caughey, S. Shrivastava, W3Objects: Bringing Object-Oriented Technology to the Web

D. Ingham, W3Objects: A Distributed Object-Oriented Web Server (position paper),
Object-oriented Web Servers and Data Modeling Workshop, Sixth International World Wide Web Conference, Santa Clara, CA (April 1997).

IBM, Introduction to the Open Blueprint: A Guide to Distributed Computing, 3rd Edition (December 1996).

IBM, Open Blueprint Technical Overview, 3rd Edition (December 1996).

Iona, OrbixWeb Programming Guide V2.0,

Iona, OrbixWeb Reference Guide V2.0,

B. Janssen and M. Spreitzer, ILU Reference Manual,

JavaSoft whitepaper, JavaBeans: A Component Architecture for Java,

JavaSoft, JavaBeans 1.0 API Specification,

J. R. Kiniry and K. Mani Chandy, Leveraging the World Wide Web for the Worldwide Component Network,

D. Larner, Migrating the Web Toward Distributed Objects, World Wide Web Journal, 1,4 (Fall 1996),

F. Manola, D. Georgakopoulos, S. Heiler, B. Hurwitz, G. Mitchell, and F. Nayeri, "Supporting Cooperation in Enterprise-Scale Distributed Object Systems," In Papazoglou and Schlageter (eds.), Cooperative Information Systems: Current Trends & Directions, Academic Press (1997).

P. Merle, C. Gransart, J. Geib, CorbaWeb: A Generic Object Navigator,

P. Merle, C. Gransart, J. Geib, CorbaWeb: A WWW and CORBA Worlds Integration,

Microsoft whitepaper, WhatOLE is Really About,

Microsoft paper, The Component Object Model: Technical Overview,

Netscape whitepaper, The Netscape ONE Development Environment Vision And Product Roadmap,

NeXt whitepaper, Bridging Mainframe to Web with WebObjects,
http://www.next.com/WebObjects/Mainframe_Brief.html (deprecated)

OMG paper, Comparing ActiveX and CORBA/IIOP,

Oracle whitepaper, Network Computing Architecture,

A. Paepcke, S. S. Cousins, H. Garcia-Molina, S. Hassan, S. Ketchpel, M. Röscheisen, and T. Winograd, Towards Interoperability in Digital Libraries: Overview and Selected Highlights of the Stanford Digital Librrary Project, IEEE Computer (May 1996).

J. Pasquale, Towards Internet Computing, ACM Computing Surveys 28(4es) (December 1996),
http://www.acm.org/pubs/citations/journals/surveys/1996-28-4es/a215-pasquale/ (members only)

O. Rees, N. Edwards, M. Madsen, M. Beasley, and A. McClenaghan,, A Web of Distributed Objects,

R. Resnick, Bringing Distributed Objects to the WWW, http://www.interlog.com/~resnick/javacorb.html

B. Schimpf, Securing Web Access with DCE,

M. Shoffner, JavaBeans vs. ActiveX,
http://www.javaworld.com/javaworld/jw-02-1997/jw-02-activex-beans.html (Part 1)
M. Hughes, JavaBeans and ActiveX go Head to Head,
http://www.javaworld.com/javaworld/jw-03-1997/jw-03-avb-tech.html (Part 2)

H. Satoshi, HORB: Distributed Execution of Java Programs,

S. Vinoski, CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments, to appear in IEEE Communications Magazine, Vol. 14, No.2, February 1997,

Visigenic/Inprise, Distributed Object Computing in the Internet Age (whitepaper),

W3C, Jigsaw: An object oriented server (whitepaper),

J. Weiss, A. Johnson, J. Kiniry. Distributed Computing: Java, CORBA,and DCE, Open Software Foundation Research Institute,
(provides a good comparison of the three technologies) http://www.osf.org/mall/web/SW-java/corba.htm (Open Group Members only)


TU Vienna, Distributed Object Computing with CORBA

TU Vienna, Java Resources


There have been a number of workshops and papers devoted to this subject. In particular, we refer the reader to the papers present at recent workshops:

This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.

© Copyright 1996, 1997, 1998 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information on this page.

Status:  this report contains a daunting amount of material assembled first by Craig Thompson, then by Gil Hansen.  The report was never finished but was useful to get some handle on the broad range of technical approaches that exist in the area of Web and object integration.

Last Modified: August 16, 2000 by sjf. Send comments to thompson@objs.com

Back to Internet Tool Survey - Back to OBJS homepage