A position paper submission for the Joint W3C/OMG Workshop on Distributed Objects and Mobile Code June 24-25, 1996, Boston, Massachusetts.
Mark Ryland (markry@microsoft.com)Everyone working on distributed object technology is having the immediate, sustained, and overwhelming intuition that what the Web needs is distributed object technology. Of course, precisely the same thing is happening in dozens of other software and networking disciplines - the Web is hot and everyone is simultaneously afraid that their pet technology is being rendered irrelevant by the Web and certain that whatever they are working on will solve the critical problems facing it.
Since I've been working on distributed object technology I'm entirely convinced that the Web needs distributed object technology. It might even be true: the Web clearly needs stateful servers, marshaling technology, better language integration and programmability, better location transparency, peer-to-peer connections and client call-backs - i.e., "connections" that can be passed around and clients easily becoming servers. Object systems can provide some or all of this and other things that are less obviously needed (or maybe not needed at all).
Perhaps the best thing that can be said for object systems is this: while a sophisticated network programmer with enough time to tune can beat an RPC runtime and associated IDL compiler every time, the bulk of new network protocols and wrapper libraries will be built by the unsophisticated programmer and/or the programmer without enough time. RPC systems - and heck, why not use the most up-to-date RPC systems?; thanks to tweaked programming models they're called "distributed object systems" - RPC systems will be more efficient in all those cases. Object/RPC systems are just perfect, too, for the "chatty" client-interactive-form-to-server-database-style of application that seems to make up about 80% of everything built for the Internet and 95% of everything built for Intranets.
In simple form "objects" might make the Web an even bigger mess than it is today. That's because as defined in its history and typical practice object technology is concerned primarily with building and deploying "applications" - cooperating pieces of code that, if not actually monolithic, are at least scoped within a cooperating group of developers who can, if necessary, deal with change and evolution globally.
But cooperation and global change are impossible in either software mass markets or distributed systems, and even more impossible when the two are combined.
Under mass market/distributed system constraints simple things like the versioning of interfaces become impossible. Even if we can foist an entirely new level of self-discipline on software developers (i.e., "you must check the version number of an interface/object handed to you by anyone else before calling any method or else your code may explode") or even create a software infrastructure where the version number is encoded in the interface reference (so the system handles versioning as a standard part of type-checking), who determines the version number? Since anyone can and will evolve interfaces/components within the system without cooperation (by definition), a sequential numbering scheme makes no sense.
Systems made up of "hardened" objects designed to deal with uncoordinated evolution may properly be termed component systems rather than object systems. Only component systems stand a chance of helping the Web. I won't, however, pedantically stop using the word "object" - just don't be confused!
No one can or should throw away his or her existing investment in clients and servers for the Web. So we find everyone extending things madly around a relatively homogeneous protocol infrastructure. On the server side, things like NeXT's WebObjects and Microsoft's OLE ISAPI for IIS allow server developers to reuse their existing object application infrastructure with URL-based method invocations that spit back HTML to dumb Web clients. And we find on the client Java applets, Netscape Plugins, and Microsoft ActiveX™ Controls extending smart clients without changing dumb servers.
It seems an obvious step to wire together smart clients and smart servers more directly with a common "object-optimized" infrastructure like IIOP or Distributed COM … at the notable cost of hetero-protocols for the first time …
Although … it's not altogether clear if this is "obvious" because it's truly superior or if it's simply self-preserving for those of us who have built alleged "object-optimized" network plumbing. Certainly in principle all "object communication" between any given client and server programming model could be achieved by straightforward enhancements to HTTP. That might even be superior to gateways between incompatible object systems. And let's not kid ourselves that the only necessary object gateways are between COM and "CORBA," that is to say, CORBA as the Platonic (socialist?) ideal floating above competition and market reality. No indeed, CORBA-style ORBs already need gateways to map their disparate value-added features… and things are only going to get "worse" (i.e., better from the perspective of differentiated high-quality products) …
My ad hoc definition of terms: Scripts are pieces of code that can be downloaded to run on putative "client" machines to do work on behalf of (humans running) the server. Agents are pieces of code that can be uploaded to run on putative "server" machines to do work on behalf of (humans running) the client. For ease of concept and deployment, we can think of migrating code as "interpreted", although think broadly: after all, the Intel x86 instruction set is one of the most widely recognized byte code streams in the world today.
Migrating code raises all kinds of interesting issues of security and what not. It is interesting in the total absence of anything resembling a "distributed object system." But again, the intuition of practitioners of the object art is seized with notions of synergy between objects and migrating code. It does seem quite interesting that objects could be passed by reference or by value, depending on bandwidth, security, "remotability", and other considerations. It surely would be handy to pass around even quotidian "scripts/agents" such as (potentially very smart) marshaling code for still-remote worker objects.
Today's object systems don't have enough capabilities to satisfy all the needs of the Web. Of course not - the needs of the Web are just the needs of distributed computing in general, and object systems are relatively immature. Security, you say? what's that?
At a minimum we all need to add a much richer variety of asynchronous features including [vote for your favorite quality of service level here]. But async systems without guaranteed delivery are very hard to program - people seem invariably to build connection-oriented application protocols on top of datagram infrastructure. And async systems with guaranteed delivery either don't really "guarantee" much of anything or else they aren't really async (as anyone on the async@omg.org technical discussion alias can readily attest).
Perhaps to solve the pressing problems of computing modernity we need to return to the dim primeval forests of The Mainframe and to the vast throughput and relative ease of use of its transactioning environments. As a general paradigm for dealing with failure-prone distributed systems and the Unknown Sea of Components, BEGIN TRANSACTION/COMMIT starts to look pretty handy. If every component spanning from desktop to database was transactional - or better yet could be made so transparently - then we could throw away a boatload of error logic that masquerades as application logic, and begin to abolish (or at least ignore) the distinctions between RPCs and message queuing…
But I'm getting ahead of myself. You see, I have this overwhelming intuition that the Web really really needs distributed objects, even in their current primitive forms.