A Capsule History of Active Webs
The runaway success of the Web's HTML display language made everyone in the software community stop and take note. What was so exciting about this new technology? Was it the markup language itself? Couldn't be! HTML is just a stripped down version (DTD) of SGML, which has been around for a while. Was it the concept of a remote screen interface language? No, X terminals and the X protocol have been around for years. Could it be the HTTP protocol for transmitting HTML? Let's hope not. HTTP is basically a broken FTP, and that's been around for decades.

No, it was simplicity and integration. Pure and simple. Although it was never intended that actual people write HTML code, they can; it's that easy. Lots of people are doing it, even though there is a large variety of HTML generators and editors on the market. It also offers (and here's the good part): instant integration among resources anywhere on the Internet via a small number of well-understood and well-supported protocols (SMTP for electronic mail, FTP for file transfer, TELNET/TN3270 for interactive login as well as the new HTTP for hypertext transmission), all without you having to remember to type TYPE I' to your file transfer software (after downloading it in the wrong mode the first time - remember those days)?

But it wasn't -- well, dare I say it? -- it wasn't enough. Here we have a perfect, simple-to-set-up client/server link (or peer-to-peer, I don't care which paradigm you prefer), and essentially all we're using it for is dead text. Not enough. The answer, of course was CGI, the Common Gateway Interface for connecting World Wide Web servers to new or existing "legacy" applications for runtime computation of the HTML to be sent back to the client. And while CGI isn't exactly an easy gateway to configure or use, it can be done.

Analogous to CGI, but on the client side, was the CCI, which tried to fill a similar role within web browsers. It never did, though. Why? A simple lack of portability and security. There are a lot more clients than servers in the web world, and portability is much more important there. So is security; users of the web do not want to make it easier for some twelve-year-old hacker to crash their machines!

Java became the primary answer to this quandary. With a straightforward portability model (based on a virtual machine architecture) and a clear security story (through a novel use of compile-time and run-time type safety), Java fits the bill for portable, secure, downloadable code. Note that Java is not the only way to achieve such functionality (also called "mobile code". See http://www.w3.org/pub/WWW/OOP/9606_Workshop/ for this year's entry in a series of joint World Wide Web Consortium/ Object Management Group workshops on this topic). But a combination of technology and marketing have made it the current hot topic. And it defines a complete, portable virtual machine so you could even code secure, portable COBOL instead if you pleased, or RPG! Think of the possibilities!

We're done, right? Sure, if you really don't mind retraining your entire staff and rewriting your entire code base, and waiting for all of your software suppliers to do the same. Furthermore, the proliferation of programming languages and operating systems wasn't always for competitive reasons; sometimes COBOL is the right tool for the job. Don't plan to see all languages but Java simply fade away any time soon.

Enter Distributed Objects
Not surprisingly, another segment of the universe has been dealing with precisely these issues for some time. Distributed object computing (DOC) addresses the need for systems integration in heterogeneous environments in a straightforward way, using the power of object technology's key concepts as enablers. Encapsulation provides a way to hide local implementations of interfaces ("classes") providing safety for implementors; polymorphism hides the details of implementation promoting portability and maintainability; and inheritance allows developers to stand on the shoulders of those who have gone before (rather than just stepping on their toes).

The Common Object Request Broker Architecture (CORBA) provides a cross-language, cross-operating system, cross-platform, cross-application method for describing services and making use of those services. Modelling applications as objects interacting in a network (with CORBA hiding all of the details of the network and service access) has allowed major organizations such as the United Kingdom Customs Department, Boeing, Motorola, John Deere & Co., J. P. Morgan and Wells Fargo Bank to build robust, distributed applications to support their everyday operations.

The cornerstone of CORBA is an Interface Definition Language (OMG IDL) for describing services (Figure 1 shows an example). This simple language is essentially an inter-language integration platform; you still write your programs in whatever language you like (C, C++, FORTRAN, COBOL, Ada, Smalltalk, whatever you or your managers prefer. Unambiguous mappings from OMG IDL to these implementation languages allow integration of systems written in different languages, even if they are executing on different machines. And a common communications protocol (which can similarly be layered on any transmission medium, with the Internet's TCP/IP preferred) ensures interoperability across wide gulfs within or between organizations.

In fact, CORBA itself is part of a larger architecture, called the Object Management Architecture (OMA), which includes layered services (called CORBAservices) running the gamut from lifecycle management, events and naming services to transaction management, concurrency control and security (See Figure 2). Further services for wide application domains (CORBAfacilities) as well as specific application domains, CORBAdomains, including such domains as financial systems, telecommunications, healthcare provision, manufacturing, transportation, etc., are also outlined.

However, this brings us to a quandary. Should we build distributed systems on a robust, multi-language base (with attendant steep learning curves), or on a simple, easily accessible but limited base (world wide webs)? The answer, naturally, is both. Future History of the Web and Distributed Object Computing The current situation, despite important early work (see a few examples at http://iiop.ansa.co.uk:8080/~jade/, http://webstar.cerc.wvu.edu/, http://corbanet.dstc.edu.au and http://www.digicool.com/&127;releases/ilurequester/) is two unconnected worlds (See Figure 3). Though they use the same wide transmission media, especially the Internet, the Web world and the CORBA world, noted as a "sea of objects" in the figures, are not strongly connected.

This won't last long. Already standardized service interfaces (the key strength of the CORBA specification) have been added to the most popular freeware web server (see http://www.apache.org and http://www.digicool.com/
releases/ilurequester/). This allows webmasters to integrate their web services easily with new and existing applications, even distributed applications, without resorting to proprietary interfaces such as Netscape's and Microsoft's competing NSAPI and ISAPI. Finally CGI is dead. Why bother when you can connect these two growing worlds directly and easily, and manage the resulting application suite from a single point? Figure 4 outlines that first tentative step. The sea of objects, including databases and business objects that represent the real systems in your enterprise, are connected into the web server, which presents those services with an HTML front-end.

The next step is even more exciting. Why should the fun be limited to the server you happen to be connected to? Shouldn't your browser be able to contact and use the services available on the network directly? Already some browsers do just that. One approach is to add a new type of connection, to go with the well-known HTTP:, FTP:, MAILTO:, etc. Some people think the IIOP: or CORBA: connection, is an appropriate way to represent browsers connecting directly to that same "sea of objects." Do you want to browse the pages of a Web 'zine? Great. Do you even want to get some work done too (i.e., earn your pay, check inventory for the customer's request)? Have your browser directly connect to the database which maintains that information. This option is shown in Figure 5.

Enter the Dragon
The problem with this approach, of course, is that it requires "fat" browsers. In particular, it's yet another type of service to be directly supported by all browsers. And that "all" part is important; the value of the World Wide Web today is due mostly to the ubiquity of this easy-to-use front end, the web browser. Piling more and more functionality into what used to be a simple function doesn't seem to be such a great idea. It's just a front end, after all; why should I have to upgrade it every few months?

The solution is Java. Java, as a dynamic, mobile object solution, gives us a way to dynamically update any Java-enabled browser to support this kind of functionality. In fact, given Java's object-oriented nature, and current lack of distributed computing capabilities, it's a natural fit. Given a Java mapping for OMG IDL, and a Java implementation of the CORBA IIOP, any Java-enabled browser on the Internet (or any internal internet, or intranet) can access resources via a non-proprietary, widely supported infrastructure. And with the OMG-specified standard gateway between CORBA and Microsoft's COM architecture, developed with the support of Microsoft and all CORBA vendors, direct access from browsers running on non-Windows platforms suddenly have access not only to the entire enterprise, but to all of the network desktop services as well.

This approach, shown in Figure 6, is the future of the World Wide Web, integrating all of the new and legacy enterprise data already out there. And several companies are already making it a reality. For more information, check out: http://www.sun. com/sunsoft/neo/
external/neo-joe.html, http://www.pomoco.com/
bwhome.html and http://www.usa.iona.com/
www/Orbix/ OrbixWeb/index.html.

Conclusion
Well, that was a whirlwind tour of the way to build client/server systems and the coming integration of web technology with distributed objects. This article could only give you a taste; I hope you'll track the URL's above as well as check http://www.omg.org for more information about the OMG and the CORBA specification. These two exciting technologies are perfectly matched, providing the robustness of distributed objects with the simplicity of the web. It's worth a look.

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Figure 6