r local disk or everything on the server; you need to choose dynamically which data would be better stored locally for quicker access. Systems like Marimba's Castanet are pointing to the way to do that.
Another thing we won't do is ignore the integrity of connections that we currently have; being arbitrarily dumped from a Web site while you're in the middle of a banking transaction will just not be acceptable. There's an urgent need to learn lessons from the transaction processing technology used by automatic bank tellers and other mainframe applications.
But
if we were to sum up this new direction for software in one phrase, it would have to be "Components everywhere." Note that word
components
rather than the word
objects
. Behind this change of terminology lies a profound technical shift. In its earlier incarnations, object-orientation was purely a programming discipline, which delivered its benefits to programmers directly (for example, easy code reuse through inheritance) but only indirectly to end users. Unlike a C++ class library that you must compile into a program before you can use it, a component is a ready-to-run package of code that gets dynamically loaded and linked into your system to extend its functionality. ActiveX controls and Java applets are components in this sense. Components share many of the characteristics of objects, particularly the need to hide their internal workings behind a well-defined interface, that is, a set of access methods.
Perhaps less obvious is the shift that
everywhere
signals -- to distri
buting components. Cuno Pfister, managing director of Oberon Microsystems, in Zurich, sums it up this way: "Distributed objects are attractive because they promise complete local/remote transparency. You can develop software for local use first and then later partition it onto several machines. Components are often equated with distributed objects, but while both share important properties, such as the necessity of clearly separating interface from implementation, components make sense even where distribution doesn't. Componentware is the mature way of constructing software systems, such that markets in ready-made components can emerge. Components need to be sufficiently independent that they can be developed, sold, and installed independently, and yet they need to be interoperable so that they can leverage each other's functionality. In other mature engineering disciplines, a component approach is now a matter of course, but in software engineering the dust hasn't settled yet."
We are moving beyond the
stage where components are just user-interface widgets or cutesy dancing heads. Their real import is that you can reuse them to form new "applications" without having to recompile anything.
The four main component models -- ActiveX, Java, OpenDoc, Netscape's LiveConnect -- are not plug-compatible, but there's progress toward making them all work together. For example, the forthcoming Java Beans API will allow components written in Java to execute inside ActiveX and OpenDoc containers, while Netscape has pledged to build ActiveX support into its future browsers. It won't be long before you'll be able to mix Java and ActiveX components in the same palette in a development tool like Borland's Latte.
While this kind of component-based, lightweight distributed computing is ideally suited to systems based on desktop PCs and low-bandwidth networks, there will always be applications, such as database search engines, that require large objects too big to shuffle around the network and must be executed in
place on the servers they inhabit. Hence you'll still need both fully distributed objects and remote method calls. The key to the future will be to combine these two different styles of distribution in the most effective way possible, downloading what is easily moved and remotely calling what is not. Fortunately the standards that will make this possible are being hammered out right now.
SunSoft's Java version 1.1 introduces some strategically crucial new features for communication with remote objects. Java Remote Method Invocation (RMI) will enable client-side applets to drive server-side Java applications and vice versa, the way the VR viewer does in my toy
store example
. Java Database Connectivity (JDBC) will provide a standard API into SQL databases; and Object Serialization converts Java objects to and from data streams, so you can move data across the network as easily as code.
Equally significant is the Object Management Group's late 1996 release of the specifications
for General Interoperable ORB Protocol (GIOP) and Internet Interoperable ORB Protocol (IIOP). These protocols specify the message formats and data structures for communicating between Object Request Brokers (ORBs) that conform to the Common Object Request Broker (CORBA) 2 standard. An ORB is a software engine that allows objects from different vendors on different platforms to call each other's methods by translating between their different object models, processor endianisms, or whatever.
Already there are ORBs , like Visigenic's Black Widow and Iona's OrbixWeb, that enable Java applets to talk to distributed objects on any CORBA-compliant ORB. Black Widow automatically generates both client and server side Java code from interface definition language (IDL) interface descriptions, and the resulting applets provide bidirectional access between any Java-enabled browser and CORBA objects on a remote system. (IDL is the abstract language used to specify object interfaces under CORBA and Microsoft's Common
Object Model, or COM.)
Both Netscape and Oracle have adopted IIOP as the basis of their network computer architecture. Microsoft remains coolly detached from CORBA and has placed its own Distributed COM (DCOM) distributed object technology in the public domain to promote it as an alternative, but compliant ORBs will be able to absorb DCOM objects just as well as any other.
Repositories of All Wisdom
Before it can become a reality, "components everywhere" needs to deal with a very large fact of life, namely that almost all the most important data in the world, from census records to telephone directories to corporate business information, is stored not in objects but as rows in relational databases, or even in old COBOL-based flat-file systems. That's why my Toys 'N Stuff
example employs
a three-tier structure, where the stock control data is kept in the same database system it has been in for the last decade, and a middle tier of software accesses it via
SQL. At the moment there's a veritable flood of products, like Microsoft's ActiveX Database Object, dbWeb, Internet Database Connector (IDC), and SQL Server Web Assistant that let you link your Web site to legacy databases and generate HTML pages on-the-fly to display the data.
While an HTML representation is a good place to start, eventually we will want databases to return proper objects. Those who have the luxury of starting from scratch, like Time-Warner with its Pathfinder site, can employ a fully OO database (essentially a repository of persistent objects with executable methods) like Object Design's ObjectStore as a back end, but anyone who has legacy data needs some kind of compromise formula. Proponents of pure object databases have been bickering with the relational database establishment for several years, but now such compromise looks within reach. A great strength of relational databases, over and above their ubiquity, is that they make it easy to accelerate queries using multiple processor
s because they retrieve data in logical sets rather than one record at a time. Their weakness is that they cannot easily handle complex multimedia objects like video and compound documents. The pros and cons of object databases are the reverse, so there should be complementarity.
Hybrid object-relational databases are now gaining support from all the leading database vendors, including Oracle, Sybase, and IBM. There are various ways you can meld object and relational databases together, including object wrappers, class libraries, and mapping toolsets.
A wrapper is an object containing a query in SQL (or some other data manipulation language) that accesses a relational database and bundles the retrieved data into the form of an object; the downside is that the wrapper will need to be rewritten whenever the database structure changes, and it may degrade performance, too. By employing a class library that separates interface from implementation, you can avoid this rewriting problem. Products like DBt
ools++, from Rogue Wave Software, and SQL Objects++ 2.0, from Objects++ Software, are typical, and future CORBA-compliant systems will use such libraries.
Mapping toolsets are programs that take an object model and a relational database schema and generate a layer of mapping code that converts data automatically between the two. While wrappers and libraries can normally make only "table=type" mappings (i.e., each row of the relational table becomes one object), a mapping tool can perform arbitrarily complex translations that go beyond data relationships and add value to the retrieved data. Examples of such tools include Persistence, from Persistence Software, and Object Integration Server, from Ontos.
Some object-relational database products like IBM's DB2, Informix's Illustra, and UniSQL's UniSQL/X extend a conventional RDBMS by adding support for user-defined types and functions, large and composite objects, and multiple inheritance.
There's no knowing yet which of these hybrid technologie
s will triumph, but whichever it is, a big part of its job will be to support transaction processing (TP). A real on-line economy cannot tolerate the haphazard way most of us currently experience the Internet, where you attempt to log on, maybe you succeed (or not), maybe you get thrown off without warning after 5 minutes. The mainframe world has been using TP for years to protect the sort of transaction you make when you draw money from a cashpoint machine, where it would be disastrous to lose contact after your account has been debited but before you've got the money. TP is a whole design philosophy for client/server systems in which a transaction becomes a contract temporarily binding a client to one or more servers, while imposing the disciplines of atomic updates, committal, and roll-back to undo unwanted actions should the transaction fail. When a transaction ends, all the parties involved must agree that it either succeeded or failed.
TP monitors are control programs that manage transactions from
the point of origin, typically on the client, managing their routing, load-balancing, and restarting after failure. Mainframe TP monitors have evolved within a model of few huge servers supporting thousands of clients each, but a component-oriented future will mean many more but smaller servers, with far more complex connectivity. Future TP monitors will need to be very smart indeed, able to support long-lived transactions that cross many different servers and can spawn nested subtransactions (with a parent-child hierarchy of committals.)
Microsoft's forthcoming Transaction Server already shows a subtle evolution of the TP monitor. TS doesn't have all the features of, say, CICS, but it strikes out in some newer directions. For example, Transaction Server will help distributed applications reliably connect with remote objects, even when no transaction is being performed.
Perhaps the most suitable place for a TP monitor will eventually be right inside your Web browser. Future browsers may need to e
xpand their functions from merely rendering HTML pages to becoming general network resource managers that can knit together remote resources of various kinds (e.g., e-mail, database queries, directory searches, calls through ORBs) and assure the integrity of transactions involving such multiple sources. Keeping the TP code at browser level rather than OS level would make sense, since you will often want to make less secure and more lightweight connections without incurring its overhead. Traditionally building TP monitors has been a very difficult software engineering task, but that could change now that Microsoft has its own COM-based TP tool in the Distributed Transaction Coordinator, which is intended to open up transaction processing the way that ODBC has done for database access. The CORBA standard also defines transactions as part of its ORB Services, and they should be supported by most ORBs.
As networks become fatter, proper use of this technology will become key. "Much more control will be requi
red for a future ATM-based broadband communications network," predicts Dr. Andy Hopper, director of research, Olivetti & Oracle Research Laboratory (Cambridge, U.K.). "What will need controlling will be the end points (i.e., browsers and servers) and the data streams themselves. A promising way of doing this is to provide a CORBA-compliant interface to the network. Because CORBA is also available for use with most computer operating systems, this would allow the whole telecomm system to be orchestrated in a consistent way. Present Web browser technology cannot exploit the richness of such a high-speed network, and by introducing CORBA and appropriate quality-of-service control to the end-point software, better and fancier use of resources will become possible -- for example, live video and audio streams as part of the user interface."
Think Small and Think Net
One thing is now certain: Software will get smaller, more modular, and more network-oriented. That said, the future of sof
tware that I've outlined here is subtly different from the road maps that the major software vendors were following even a year ago. We were promised distributed OSes that would let you construct applications consisting of communicating objects running on many different machines. That hasn't happened yet, and maybe it never will. What has intervened is the notion that in most cases it's easier to just move the software to where it is needed -- the downloadable component. This idea was sparked off by Sun's Java language, originally developed for use in TV set-top boxes rather than PCs, and it's been fanned into flame by the popularity of the Web. All the preparation that's gone into distributed objects is not wasted, though, as components use essentially the same technology of compound documents, embedding, and containers. The result should be better, more manageable software, easier maintenance and cheaper computing, and a new level of transparency in network communication.
The only thing that might hol
d up the spread of "components everywhere" is the lack of sufficient Internet backbone bandwidth to satisfy all the new demand that will be created, and that factor is beyond the control of all but the largest telecom companies. In the meantime, having to treat bandwidth as a scarce resource will favor the small and the clever, which is no bad thing.
Where to Find
Digital Equipment
Maynard, MA
Phone: 508-493-5111
Internet:
http://www.digital.com
The Component Enterprise
