NeXT targets the enterprise

With two new products, NeXT tries to make the big breakthrough into the client/server world.

In the music business, "critics' darling" is the slightly sardonic tag for artists who don't sell many albums, even though they are praised regularly in print. The term usually connotes high quality and craftsmanship, but little popular appeal. Is NeXT Inc. (Redwood City, CA), the software industry's equivalent of a critics' darling? Two products they introduced recently, Enterprise Objects Framework and Portable Distributed Objects, are their latest attempts to make the big breakthrough beyond "well-respected" to "market-leading" vendor.

Enterprising objectives
NeXT's new Enterprise Objects (EO) Framework, which shipped last October, addresses mid-'90s realities: Object-oriented software development is now widely popular, yet relational databases vastly dominate as guardians of core corporate data. A few application development products provide object-oriented interfaces to relational data; EO Framework represents the most complete "objectization" of relational data yet.

This tool has an elegant architecture that uses objects from top to bottom. And while the basic principles behind EO Framework's objects-to-relations mapping are not much different from others, EO Framework lets developers build new applications on top of existing relational data. The others develop applications from the ground up, including the design of the database itself.

The most interesting innovation in EO Framework is its use of the Entity-Relationship (E-R) model for automating object-to-relations mapping. Invented by Dr. Peter Chen in the mid-'70s, the E-R model is a way of specifying relational data models by drawing entities, which map to relational table definitions, and relationships between the entities, which map to data integrity constraints, such as foreign keys. An E-R model is like an object model without inheritance and methods: Entities map to object classes, and relationships map to object attributes (instance variables) that are themselves objects.

One of the components of EO Framework, EOModeler, reads an existing relational-database management system (RDBMS) schema and then generates an educated guess E-R model. EO Framework creates standard object classes, including the basic methods and other facilities necessary for the objects to live in the NextStep environment. It's the developer's job to add application-specific methods and variables to the object-class definitions.

EO architecture
So much for the elegant part. The internal architecture of EO Framework that maps the actual objects to data in the RDBMS is somewhat clunkier. It consists of four layers. The top layer is the user interface. Below that, the confusingly named User Interface Layer contains the machinery for managing individual objects in an application. It works by creating two types of auxiliary objects: EOControllers, which are interfaces between objects and their representations in the user interface (for example, an EOController updates an object's state if the user changes a corresponding field on the screen); and EOAssociations, which are links between EOControllers and the actual objects. Those familiar with Smalltalk environments or NextStep itself will recognize this paradigm.

Below the User Interface Layer lies a Data Source Layer that encapsulates the basic operations necessary to insert, delete, update, and query data. The Data Source does this in a way that is optimized for use with relational databases, but can be used with other data sources like spreadsheets, flat files, and so on.

Beneath the Data Source comes the Database Layer, which takes care of transaction management and related issues. The Database Layer also keeps an internal graph of relationships between objects. Once an object is fetched, other objects that have relationships to it are modified so that they point to the new object with a standard Objective-C ID, that is, a simple memory reference. This feature is a vitally important solution to the "impedance mismatch" problem between relations and objects, which results from the fact that a simple "pointer chase" in the object world normally corresponds to a time-consuming join in the underlying relational database. The Database Layer's internal object graph is similar to the pointer cache used in Persistence that solves the same problem (see "Objects and relations unite," July 1993).

The bottom layer of EO Framework is the Adaptor Layer, which provides relational database access. NeXT has Adaptor Layers tuned for Sybase and Oracle, and they provide guidance for implementing adaptors for other relational databases, as well as spreadsheets, flat files, and other data sources. NeXT claims that the development effort involved is not great.

That's a lot of layers, and therein lies the potential drawback of EO Framework -- efficiency. A client machine must do a disproportionate amount of work to access the comparatively small bits of data typically stored in relational systems. (This is nothing new for the object world: One of the reasons for Smalltalk's initial lack of popularity was that it treated everything -- including integers and Boolean values -- as full-fledged objects with the associated overhead.) If the EO Framework client is a reasonably powered RISC workstation, this may not be a problem. But if it's an Intel-powered PC running Windows, the overhead might be excessive.

Overall, EO Framework allows developers to access relational data as first-class object citizens in proprietary NextStep -- or eventually OpenStep -- environments. But that doesn't allow NextStep to meet all the requirements of universal enterprise access. As Chuck Musciano pointed out recently (see "OpenStep on the wrong foot," December 1994), OpenStep is not well integrated into environments based on open systems standards. And such integration is, of course, essential in enterprise architectures.

Where PDO fits in
That's where NeXT's Portable Distributed Objects (PDO) comes in. First, the people at NeXT clearly have understood that they need to make their superb object-oriented environment -- and objects developed with it -- truly useful in Unix and other established enterprise-computing environments. Second, NeXT has come to admit that however elegant NextStep is, it cannot compete with the imitators it spawned that are now more popular, such as Microsoft Visual Basic, and which run on commodity software platforms. Nowadays, the new frontier in development tools is the enterprise. While EO Framework works within the currently common paradigm of client/ server with powerful workstations and relational-database servers, it does not cover the more general case of distributed, heterogeneous, multiserver or peer-to-peer applications.

PDO attempts to address both of these concerns. NeXT's existing Distributed Objects (DO) toolset makes objects on NeXT systems available to applications on other NeXT machines by passing messages around a network. In effect, DO acts as another level on the network protocol stack -- one that deals in objects and the messages between them. PDO goes even further by bringing DO to other systems, including common flavors of Unix (now) and other operating environments like Windows, Windows NT, and Novell NetWare (later).

If you're an object enthusiast, a red flag should have just popped up in your head. Doesn't NeXT's strategy with PDOs sound like the Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA) specification for heterogeneous distributed objects? Unfortunately for NeXT, the answer is yes. The company is marketing PDO on the claims they have a solution today and users will be able to migrate to CORBA-based tools and systems tomorrow. Yet, CORBA implementations (Object Request Brokers) are available now, albeit without development tools as good as NeXT's.

NeXT is also trying to influence the CORBA specification so future, compliant ORBs will be compatible with PDO. This seems an unlikely outcome, because this attemp would require OMG to put the CORBA spec through ugly, Twister-like contortions that would really jeopardize the quality of its design. CORBA will clearly be the dominant standard for heterogeneous distributed object-based development, so it need not and should not take such risks.

Market realities
If NeXT had actually incorporated more of the aforementioned heterogeneity into PDO, then it would be well worth considering as an effective heterogeneous distributed-object development tool, that is, at least until standards-based solutions come with better development tools and otherwise overcome their current limitations. But NeXT has addressed such issues only as items on a "future directions" wish list. We are left, once again, with a beautifully elegant system that only really works within its own proprietary environment.

About the authors
Chuck Musciano, in last December's Software Tools column "OpenStep on the wrong foot," hit the nail on the head when he wrote "tremendous effort was expended by talented people to deliver an outstanding product [that] the majority of users probably cannot or will not use." NextStep aficionados, very much like their music-critic counterparts, may bemoan the injustice of it all, but that indeed is the reality of today's marketplace. n

Contributing editor Bill Rosenblatt is director of Publishing Systems at the Times Mirror Co. in the New York City office. Reach him at bill.rosenblatt@sunworld.com.

Bill Rosenblatt is the author of Learning the Korn Shell and a coauthor of Learning Gnu Emacs and Learning the Bash Shell. You can buy these at Amazon.com Books. Select the hyperlinks to learn more about each and Amazon.com.

A list of Bill Rosenblatt's Client/Server columns in SunWorld Online.

If you have problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/asm-02-1995/asm-02-cs.txt.html.
Last updated: 1 February 1995.