Distributed object enterprise views were converging nicely in the early
1990s, until the Web came along. Tim Berners-Lee had succeeded in
modularizing systems, making information truly accessible to the masses
by combining universal thin clients with flexible back-end servers, with
interaction through a gateway with third-tier applications such as
databases.
In the late 1990s, the question remains as to how to use the best of
both the Object and Web worlds when developing applications. Object
Services and Consulting, Inc., is investigating the scaling of ORBlike
object service architectures (for behaviors such as persistence,
transactions, and so on) to the Web (for behaviors such as firewall
security and document caching, as well as rich structuring) by using
intermediary architectures [1]. They are also exploring data models
that converge the benefits of emerging Web structuring mechanisms and
distributed object service architectures [2].
Ultimately, the Holy Grail of application development using "Components
Plus Internet" can be realized in many different ways, including:
1. By putting ORBs behind the gateway of a Web server's back-end.
2. By using Java; that is, by downloading an applet in the Web
browser as an ORB client that can communicate directly with ORBs.
3. By placing middleware between ORB clients and HTTP clients.
4. By using HTTP-NG, a binary distributed object protocol designed
for use with the Web, CORBA, and DCOM [3].
5. By using MIME typing with OMG's IDL, with the ORB as the server,
and Web browser-clients connecting.
6. By composing active proxies that act on behalf of Web and ORB
clients and servers as needed [4].
7. By composing data from different sites using data fusion (for
example, collating information using WIDL [5]).
8. By performing compound transactions with ORBs and Web servers.
In prototyping an annotation service [6] and a personal network weather
service [7], OBJS developed an intermediary architecture that exploits
the benefits of both ORBs and the Web [8]. Web engines provide
universal clients and global access to rich data streams; ORBs furnish
object services and open the door to enterprise computing. In
integrated, hybrid systems, these roles are leveraged and the workload
balanced.
Fundamentally, is a Web server all that different from an ORB? Perhaps.
HTTP as a protocol makes provisions for error recovery, latency,
platform heterogeneity, cross cultural issues, caching, and security,
for a specific type of application (the transport of documents), whereas
ORBs have a generic object architecture that allows for the selection of
services piecemeal as needed.
The Web has focused on providing a rich typing system, whereas ORBs have
focused on providing a rich set of APIs. To that end, the Web is useful
for describing DATA aspects (as opposed to operations), whereas CORBA
focuses on PROCEDURAL aspects (as opposed to types). This is manifested
in the Web's document-centric nature -- and in CORBA's loss of its
compound document architecture.
It is also manifested in the Web's approach to heterogeneity: a single
common type indirection system, MIME, allowing new data types to be
added to the system as needed. By contrast, ORBs define data types
strongly, so that the IDLs know exactly what is going to hit them.
MIME is one example of how the Web was adopted using a strategy of
incremental deployment, starting with file system semantics and building
up from there. As a result, the Web in its nascent stage has not yet
deployed "services" (in the traditional "object" sense), but they are
forthcoming shortly (WebDAV for versioning, XML for querying, and so
on).
One limitation of HTTP is that although in theory HTTP can be run for
communication in both directions (through proxies), in practice HTTP 1.x
must be initiated by a client, so two peers would need two open
channels (that is, two HTTP pipes). IIOP has hooks for avoiding this
through back and forth polling.
On the other hand, the Web has several strengths:
1. Caching - a bag of bits and an URL can live anywhere
2. Error processing
3. Proxies - a gateway is part of the Web architecture
4. Type system - Web data types are loose (MIME but no PEP)
but rich (human-readable) and dynamically discoverable
5. Scaling - synchronous point-point, distributed group services
6. Directory services - DNS, but no traders
These strengths could be applied to CORBA, adding real attributes to
CORBA interfaces. Perhaps some combination of Object and Web
technologies may ultimately prove useful (for example, IDL for interface
specifications and XML for data exchange and storage). The Web might
assimilate CORBA, and CORBA might assimilate the Web, and HTTP-NG might
do both. And although Web technology as commecially available is
insufficient presently for many object developers' needs, it is, as
Marty Tenenbaum of CommerceNet would say, simple enough that a fifth
grader can use it.
For now, we continue to attempt to understand the commonalities and the
differences of ORBs and the Web in our application analyses and designs.
As of January 1998, CORBA remains a generic framework for developing many
applications, whereas the Web is a generic framework that HAS deployed
many applications.
[1] http://www.objs.com/workshops/ws9801/papers/paper102.html
[2] http://www.objs.com/OSA/wom.htm
[3] http://www.parc.xerox.com/istl/projects/http-ng/
[4] http://www.objs.com/workshops/ws9801/papers/paper102.html
[5] http://www.w3.org/Submission/1997/15/Overview.html
[6] http://www.objs.com/OSA/OSA-annotations.html
[7] http://www.objs.com/OSA/OSA-network-weather.html
[8] http://www.objs.com/OSA/OSA-intermediary-architecture.html
----
adam@cs.caltech.edu
Forget REUSE. Just aim for USE.
-- Marty Tenenbaum, CommerceNet