"A well-designed object can manage itself just fine, thank you very much, and attempts to control it from the outside may well destroy its usefulness in a large-scale business system."

"The question now is not whether to buy a DBMS that supports objects but when to buy it and from whom."

Adaptivity

In today's fast paced business climate, the keys to maintaining a competitive edge lie in the ability to create adaptive software. Adaptivity allows existing software to evolve along with rapidly evolving business needs. Object technology is uniquely suited to building adaptive software. The rest of this book validates this claim.

These are the fundamentals of object technology: encapsulation of procedures and data, polymorphism, and inheritance hierarchies.

Simula

Some historical perspective: Simula was the first language to introduce many of the features of objects; as a simulation language used to model objects in the real world, Simula naturally packaged objects together with their methods to achieve encapsulation. Simula also introduced the concept of classes as templates for objects. And Simula provided for inheritance hierarchies.

The author supplies drawings that clearly depict encapsulation, messages between objects, classes as templates for objects, and inheritance hierarchies. These drawings, artistic but simple, are excellent examples of what Edward Tufte has praised in his well-known book Visual Explanations. They provide visual cues which quickly allow the reader to understand otherwise abstract concepts.

Objects and Cells

The analogy drawn between objects and human cells is very accurate. The human cell encapsulates it's internal complexity behind a cell membrane. Cells communicate by sending chemical 'messages', each of which is uniquely coded to elicit a particular response from a cell when it penetrates the cell's membrane. Similar to the cell membrane, an object's interface hides the object's internal complexity from the outside world. Communication with the object is achieved by sending preestablished messages through the interface.

Class or Interface?

Polymorphism greatly simplifies the programmer's task because a single message signature may be applied to a family of objects, each of which may be fundamentally different from the other, but the result will nevertheless be the same. The example provided, determining the value of a financial instrument, demonstrates the simplicity of calling one interface independent of the underlying mechanism used to actually calculate the value. The calculation may in fact be very different for a stock, a bond, or an option.

Polymorphism may be provided through inheritance in a class hierarchy. However, the author clearly points out the limitations of polymorphism within class hierarchies. What if the objects have distinctly different characteristics and therefore don't fit into a class hierarchy, but nonetheless share the requirement for a common interface?

For example, both products and supplies may require the services of a shipping department. Since Product and Supply are intrinsically different object types, how do you choose the type of an object which may be submitted to the Shipping interface? The answer lies in providing each with a Shipment interface which abstracts the essential quality relevant to the Shipping interface. The Shipment interface may have methods such as getWeight() and getAddress(); it is the responsibility of Product and Supply to provide the correct implementations for these methods.

The Component Revolution

The era of hand-crafting programs may very well be nearing an end. If the author's analogy between hand-crafting code for each new problem and the state of manufacturing prior to the Industrial Revolution is correct, we are at the verge of transitioning to the assembly of programs from standardized components. COM, CORBA and Java Beans components all lead to significant reuse at the component level and, therefore, potentially dramatic increases in programmer productivity.

Object Databases

Dr. Taylor does an outstanding job of describing the advanced concepts of object databases, even to readers who may be completely unfamiliar with this topic.

Oftentimes there is a need to persist objects for later reuse. Conventional databases are largely unsuited for effectively storing complex objects. Objects introduce the following complexities that are mismatched to relational databases: most objects are a composite of other objects, objects provide inheritance, objects frequently have rich data types such as video and audio, and objects contain methods. Relational databases don't provide a support infrastructure optimized for these features.

While some DBMS vendors provide solutions which map objects to relational tables, the author compares this to taking apart a car to put it in your garage. He describes the need to perform transformations as introducing a 'semantic gap' between software developers and database designers. The noted author Mary E. S. Loomis (Object Databases, The Essentials) refers to these solutions as 'vaulting' the walls between software disciplines.

In true object databases, composite objects are persisted by providing fast navigational links between the components which are stored. Because these navigational links are implemented as direct references, complex objects are retrieved expeditiously; in contrast, RDBMS's require complex joins in order to establish similar types of relationships.

For an OODBMS, there is no master schema; therefore, variations on relationships between components are easily supported. This facilitates alternative structures without disrupting previously established relationships.

Support for inheritance in true object databases facilitates reuse of base classes in the database. The example provided is the need for additional information in non-U.S. addresses (township, parish, canton). This may be provided by subclassing the base class for address and adding the additional information in the subclass. The OODBMS handles this through direct references from the subclass for foreign address to the base class for address. In contrast, an RDBMS solution would be to add the additional fields to an existing table, which is wasteful of space, or to create joins between tables, which is cumbersome to maintain.

Hybrid solutions such as using an OODBMS and an RDBMS together in an hierarchical fashion are briefly described. One fascinating development to recently appear commercially are RDBMS's with built in Java virtual machines and tight integration between Java objects and the database through the use of the emerging SQLJ standard. Oracle 8i is an example of this new category of database. It would be interesting to see how Dr. Taylor views this development from the perspective of hybrid object and relational database solutions.

Object Engines

Dr. Taylor really becomes unusually prescient when discussing object engines, which he claims are the future of enterprise computing. Why prescient? Because an object engine is essentially what is just now emerging as the application server: a hosting environment for distributed software components which are shared across applications. CORBA and the emerging Enterprise Java Beans standards rule the day here. It seems that Dr. Taylor's familiarity with object databases enabled him to predict this new trend.

Distributed Objects

With the advent of object request brokers, objects may be located anywhere within the network. A proxy allows clients to find objects in the network without worrying if they are local or remote. This is called location transparency. What does this achieve? For one, objects can be located close to the resources that they need to perform their job, rather than being close to the clients that use them.

Rules

Rules form the third part of the trilogy of object attributes: methods, data, and rules. The motivation for utilizing rules is to separate logic which is subject to frequent change due to changing real-world requirements from the portion of objects which is more static. Rules are implemented by special-purpose, high-level scripting languages or tools. Presumably, it is much easier to change a script than it is to change code. Thus, rules further promote the author's global vision of software adaptivity.

One problem with the author's depiction of rules encapsulation within objects is that it would appear that rules can be hidden within the object to which they apply. However, in practice these rules will usually apply to multiple objects at the same time. For instance, a rule for processing a bank loan application may need to access both personal data (age, marital status) and credit information (example: person.age < 25 and credit.debt > 20,000).

It is satisfying to note that products have begun to appear on the market that fully implement the integration of rules with objects. One particular example is the Neuron Data Advisor 2 product which allows rules to directly call methods on the objects with which they integrate. The product fully integrates with Java objects as well as with objects which implement CORBA and COM interfaces.

Agents

Agents are really cool. The author is showing us a vision of the future, when mobile software objects zip freely around the network in the process of performing their tasks. Agents take distributed objects and rules to their logical conclusion - the agents are intelligent enough to perform on their own. This vision is already taking place: witness products like Sun's Jini and Voyager from ObjectSpace.

Conclusion

Dr. Taylor fulfills his promise to provide us with a vision of how software adaptivity can be attained through the use of object technology by providing three salient examples in the conclusion of his book.

In the first example, long distance dialing plans are rapidly implemented by enforcing a common, generic interface for all products and defining a dialing plan through the composition of product objects which support this interface.

In the second example, a loan object is created which is self-monitoring. By encapsulating a relatively small number of rules in the loan object, the complexity of determining which loans have become problems is simplified significantly.

Finally, in a distillation of many of the strategies described throughout the book, a supply chain distribution model is proposed based on classes for vehicles and shipments which are sufficiently intelligent to manage themselves in a just-in-time market economy.

We highly recommend this book. Proof that the author's vision is unfolding today: the Internet economy is rapidly evolving through the wide-scale deployment of Java and CORBA based distributed computing infrastructures.