Object Request Brokers (ORBs), as defined by the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) specification, provide the mechanisms by which objects transparently make requests and receive responses. The HyperText Transfer Protocol (HTTP) is a generic stateless object-oriented protocol, and is based on a request/response paradigm. The similarities offer an opportunity to interoperate between CORBA-based systems and the World Wide Web.

Due to the growing success of Web-based corporate applications-or intranets, corporate WANs that use Internet protocols-Object Technology, championed by the OMG, has lately stirred renewed interest in the role of the enabling technology for enhanced distributed business applications. Prompted by these converging trends, the OMG has exchanged membership with the Internet Society, and is holding, for the first time this year, joint conference and exhibition events. Conversely the recent International World Wide Web Conferences held in Boston, last December, and Paris, last May, offered a growing crop of results from research work in the area of inter-linking ORBs and the Internet.

The motivations for investigating further the opportunity for interoperability are two-fold: overcome some of the technical limitations of the Web infrastructure for the new generation of business applications, and bring forward the benefits of using distributed objects to this new transport vehicle. The expected benefits of the Web infrastructure are precisely the ones that, according to recent studies from the Standish Group and Forrester Research, the traditional client/server architecture failed to deliver : an improved way of managing business systems, truly open architecture, and lower cost of ownership. The current interest in so-called "thin-clients", Web browsers running on standard PCs or even lower-cost dedicated hardware-NCs, network computers, promoted by the like of Oracle, IBM, and Apple Computer-as a simple unique front-ends to both corporate applications and the Internet is a direct consequence of these findings in corporate organisations.

Closer scrutiny of the Web standards, however, clarify the limits and scope of the HTTP protocols that can be attributed back to a number of early design decisions that have not scaled up to cope with the demand of the new generation of business applications:

• Over the past couple of years, the Web client and Web server applications are tending to become larger monolithic applications, despite the thin-client banner most of the vendors are rallying to. Proprietary extension mechanisms for both clients and servers are flourishing. Besides being often incompatible and vying for developers' mindshare, these mechanisms are increasing the weight of clients and servers, and making it globally more difficult to optimise performance and manage applications.
  
• The Web is originally document-centric, and although a larger share of desktop business applications are now thought as document-centric, its protocols still provide little support for connecting interactive services.
  

On the other hand, some of the provable benefits of using distributed objects, and more especifically ORBs, are:

• Ease of programming : the existence of a common object model, and an lingua franca in the form of the Interface Definition Language (IDL) simplify the task of writing distributed applications, or integrating various pieces of the information system together.
  
• Extensibility and manageability : object technology is primarily designed for making it easy to add, replace or customise pieces of the business applications. In a later stage, when the object architecture is properly in place, additional benefits stem from re-using objects throughout the development and deployment processes.
  
• Systems integration : object technology is adept at breathing a new life into "legacy" systems by making it easier to link the old pieces with the new ones.
  

The strategy for combining the economic benefits of both approaches must be one of an evolutionary, rather than revolutionary, nature. A strategy for full interoperability should enable the benefits of the new technology without losing the use of the older resources. The following sections provide an overview of the available and usable technology for interoperability, and explain whether these approaches are complementary of competing.

1. HTTP via CORBA. When considering distributed applications it is useful to separate the services layer from the transport layer. The services layer is concerned with the way the services are described and made available to the client applications that use them. The transport layer is concerned with the implementation of the actual protocols for transmitting data and information over the network linking clients and servers.

The following table provide a simplified comparison of the services and transport layers in both approaches:

	Web	CORBA
Services	HTML	IDL
Transport	HTTP	ORB, IIOP

As IDL and ORBs are perfectly suited for connecting interacting services with fairly general mechanisms, a first idea is to define an IDL mapping of HTTP that promotes interoperability. CORBA technology is used to develop clients that can use resources from the Web and servers that can provide resources to the Web. In this view HTTP is a set of methods, with specific arguments and results, and the goal is to build gateways converting between HTTP representations and CORBA representations. The result is a way of carrying HTTP requests and responses over a CORBA-based system : HTTP via CORBA.

This strategy is best exemplified by the ANSA work programme, at Architecture Projects Management Ltd., under which various gateways have been developped. The first result of this research work is a proxy-based gateway mechanism. Interoperability is simply provided by two basic gateways : one forwarding IIOP request to HTTP, and the other one forwarding HTTP requests to IIOP. When several routes HTTP, and IIOP, are available to route requests the HTTP-to-IIOP gateway relies on a separate service, the "locator" to find the available routes and servers. Defining the locator as a separate service, a design which is encouraged by the ORB architecture, makes it easy to encapsulate and experiment with different directory and access mechanisms for attaching to servers.

A second result of the approach is to produce "native-IIOP" Web browsers and Web servers. These native-IIOP browsers and servers use IIOP as their native protocols : the HTTP-IIOP is bundled in the client while the IIOP-HTTP is bundled in the server. Although this seems to illustrate further the tendency to create heavier client applications by adding further weight to the Web browser, it provides the additional flexibility and manageability of distributed objects that still escape the current Web infrastructure. In particular a native-IIOP thin-client could run an application composed of fully interactive objects located on various machines to match, and possibly dynamically at run-time, the available processing, storage, and communication resources.