Distributed Objects on the Web
Comparing CORBA and DCOM
By Fernando Martinez-Campos
As the Internet infrastructure matures, the original simplicity of the HTTP protocol is also its Achilles heel. Because it's a generic request-response protocol, HTTP's main drawbacks are its statelessness and its inefficiency in establishing new connections for each request. Many schemes have been devised to overcome these problems: using cookies that pass state context back and forth; keeping browser-session IDs in hidden fields on HTML pages; and keeping state at the server with a transaction-processing monitor like Microsoft Transaction Server, TOP END, Tuxedo, or CICS. HTTP also suffers from other problems like its character-oriented method of passing parameters across programs. (See "
Online".)
The next generation of the Web, which will be driven by electronic-commerce applications, must be able to issue asynchronous requests and will require richer mechanisms for passing parameters of integers, structures, and other data types. The Web community, led by W3C and Xerox PARC, is addressing the problem of distributed object computing on the Web with HTTP-NG. However, the two currently prevailing component architectures are CORBA, which is promoted by a consortium of companies collectively known as the Object Management Group, and Microsoft's DCOM. This article examines both architectures, and shows how each approach addresses the shortcomings of HTTP.
A CORBA Primer
Before the advent of the Web, the Object Management Group defined the Common Object Request Broker Architecture, a standard for a distributed-system infrastructure that would allow objects to interact with each other in a distributed-computing environment.
