Jon Udell
The NextStep 3.0 development system came with DBKit, a data-access layer that you could easily wire to data-aware user-interface controls. Next hoped this would become its own version of ODBC (Open Database Connectivity). By offering drivers, or database adapters, for Sybase and Oracle, the company hoped third-party NextStep developers would create more adapters and write the database applications that would exploit them. For the most part, that didn't happen.
"Now we're admitting that we were wrong," says Rick Jackson, director of product marketing for Next. DBKit's ODBC-like layered architecture didn't really exploit the power of an object system like NextStep. The forthcoming Enterprise Objects Framework, announced at the NextStep Expo in June, aims to fix that.
The new approach focuses on building objects that abstract data and the business logic that governs the use of that data. The Enterprise Objects Framework connects abstract data indirectly to real sources of data--initially SQL back ends, but potentially OODB (object-oriented database) engines as well. Developers who construct abstract models will, of course, have to consult closely with the database administrators who own the storage engines.
The Enterprise Objects Framework also connects abstract business logic indirectly to applications screens. Consider, for example, the problem-escalation logic that's bound up in a typical customer-service application. Expressed as a business object, that logic becomes a corporate asset that's not hard-wired to any client application. It can even appear as a network service that, using Next's Portable Distributed Objects, could run on a non-NextStep system, such as HP-UX.
"Corporate clients told us they needed to decouple business logic from applications
in this way," says product manager Felix Lin. It's an attractive idea, and one that Next hopes will showcase the maturity of its object technology just as some of those corporate clients begin kicking Taligent's tires.