Client/Server

Objects from the server side

BaseWorX OSP represents a solid step toward closing the object development gap.

The greatest challenge facing client/server software tool makers these days is making distributed objects as easy to develop as their local, single-machine counterparts. Various key things have to happen before the challenge is met. The most important is that standards must take hold for communication between application-level objects among machines in heterogeneous client/server environments. Almost as importantly, there also must be a cultural dŽtente between client-centric tool makers and their counterparts on the server side.

This month we'll look at a server-centric tool, BaseWorX OSP (Object Services Package) from TCSI Corp. (Berkeley, CA) and see what it can teach the client-centric crowd.

Culture clash
Client-side tool makers (Powersoft is the most prominent example) have rapidly filled wide gaps in the tool offerings from database vendors and other server-side industrial components. CASE tools, for example, provide elegant means of specifying logical models of applications' data and functionality, but they typically offer little help in generating implementations from those models. (Recent CASE tools, however, do a better job of that.) And 4GLs turned out not to be as powerful as everyone had hoped. As client/server became pervasive, user interfaces became more important. Yet, neither CASE tools nor 4GLs offered much help in this area. And whatever those tools didn't do, you essentially had to write in C (or PL/I, etc.).

Meanwhile, the successive ascendancies of relational databases and GUIs have engendered two development techniques -- SQL database programming and point-and-shoot user-interface building -- that Powersoft and others linked together and very quickly exploited. The resulting tools have made developers' lives much easier. But those were developed on the client side; therefore, they ignore such server-side concerns as database design, transaction processing, concurrency control, data integrity, and others. They also do not facilitate the increasingly popular three-tiered client/server model, in which some of the applications' more computationally intensive work is done on the server instead of on the client.

The main reason for the separation between client and server is cultural. Database vendors, as well as makers of CASE tools and transaction monitors, have been utterly out of touch with developments on the client side that resulted from the hegemony of Microsoft Windows and the lesser pervasiveness of the Macintosh and OS/2. The whole idea that development tools could be "polluted" by the sexy, salable characteristics of user applications -- indeed, even operated by users -- has escaped the server-side tool vendors. Client-centric tools, on the other hand, have come from young start-up companies who are eager to grab marketshare by exploiting widely installed platforms in high-profile ways.

Client-side OO tools
Object-oriented, client/server development tools are the next great frontier in the tool field. They represent the most fertile opportunities for cultural dŽtente between client and server tool vendors. Client-side tool vendors' products already extend beyond GUI builders and database-query generators into object-oriented development, through GUI C++ code generators, object-oriented front ends to relational databases, sophisticated Smalltalk environments, and even the inherent object-like characteristics of Powerbuilder-style tools.

Server-side contributions to object development, on the other hand, have mainly been at the level of infrastructure -- software layers that enable object-level communication on top of standards-based networks. The most prominent examples of this necessary object "plumbing" have been Common Object Request Broker (CORBA)-compliant ORB implementations by server hardware vendors and independents like Expersoft (San Diego) and IONA (Dublin, Ireland). But application development tools from the server side have been virtually non-existent, apart from compilers for the Interface Description Language (IDL), which is part of the CORBA standard -- that is, until TCSI's BaseWorX OSP came along.

TCSI, previously known as Teknekron Communications Systems Inc., is a systems integration firm that has done the greater portion of its business building network-management solutions for the telecommunications industry. BaseWorX OSP is part of a suite of tools that TSCI offers.

BaseWorX OSP centers on a language and compiler called MOSC (Managed Object Schema Compiler) that developers use to specify object types. MOSC's syntax, like that of IDL, resembles C++. The language has most of the features that you would expect from an object type-specification language, including methods (called operations) and data attributes included in type definitions and inheritance of superclasses (multiple inheritance in MOSC's case). Their type model also has a few niceties like list constructors and abstract classes -- classes that can be inherited into other class definitions but not instantiated as actual objects. Developers write the actual code for BaseWorX OSP-based operations in C++; objects themselves are stored in a relational database (Sybase, Oracle, Informix, or Ingres).

Get the hint
MOSC has a few interesting wrinkles beyond these relatively conventional object language features. Most notably, developers can give OSP hints about how to manage objects and thereby achieve optimal performance during runtime. These hints are somewhat analogous to "pragmas" in the Ada language or directives to query optimizers in certain implementations of SQL.

One hint is a way of specifying memory-management characteristics. You can specify that an object class is sticky, meaning that objects of that class will never be swapped out of main memory, or LRU, which means OSP will choose objects of that class for swapping out of main memory, when necessary, according to those that have been least recently used. If you expect a particular class to have many instances, and it's not critical that they be quickly accessible in memory, then you can conserve RAM by telling MOSC to use LRU memory management for that class. Conversely, if you expect your class will have a small number of instances, or that those objects must be accessible instantaneously, then you should use sticky memory management for that class.

The other important hint in MOSC is the operation kind specifier. You can use key words in operation definitions to tell OSP what effect an operation will have on an object. Operations of the kinds creator and deleter are similar to C++ constructors and destructors, respectively. They specify that the operation will create a new instance of the class or delete an existing one. The modifier kind is like a write flag. It tells OSP that the operation will potentially change the state of the object. Selector operations, on the other hand, don't affect object state, and controller operations are for time-critical tasks, such as alarms or emergency cancels, which merit preempting other operations.

Operation kinds help the system manage concurrency control better, thereby increasing transaction throughput. For example, assume two processes call operations on the same object at the same time. If both operations are selectors, then the system knows the operations will not interfere with one another, and therefore can be executed concurrently. If one is a modifier and the other is a selector, concurrent execution is still possible. But if one of the operations is a deleter, then it will interfere with any other operation and thus must be blocked until all other operations on the object complete their tasks. Overall, if you know certain combinations of operations can safely execute simultaneously, then you can let them do so and increase throughput. Conventional concurrency control systems can't get that sort of knowledge about objects and operations, so (all else being equal) they do not perform as well.

These hint features are OSP's way around a tough problem in object management systems: How can you specify what the behavior of an object actually should be when the system is in operation? It would be great if an object manager could read the definition of an object type in a conventional language, such as C++, and learn things about the type that help it manage objects of that type better. For instance, it would be great if an object manager could determine whether two operations on an object will get in each other's way when executed simultaneously, or whether an object's behavior is close enough to be used in a situation where another type of object is normally expected. As an example of the latter, how, in general, can you tell at runtime whether it's meaningful to perform an add operation on two objects of different types?

Unfortunately, there is no general way of deriving runtime object-type behavior from C++ (or similar) code. To do it right, you would have to specify object types' behavior in some sort of separate, mathematically rigorous notation -- presumably with lots of Greek letters and other symbols -- that a program could read, interpret, and draw interesting conclusions. Such notations exist in academia, but they have never made it into the real world because they are very difficult to learn and require a disproportionate amount of extra programming work to use effectively.

Fortunately for developers, the engineers at TCSI have managed to distill all that down to a small, manageable set of key words in their object-definition language to represent those aspects of object-type behavior that really make a difference in system performance, particularly from the perspectives of memory use and transaction throughput. Some of the terms they use may not be quite appropriate, like LRU for memory management, since they are implementation details and not descriptions of object behavior and thereby break the sacred principle of data abstraction. But the features are undeniably useful.

Meeting of the minds
TCSI has some very innovative features in BaseWorX OSP because they have enough real experience implementing industrial-strength distributed object-based systems to know what the important issues are on the server side. And they have the theoretical knowledge to resolve those issues. BaseWorX includes several more innovative features, including a clean way of partitioning middle-tier application code among multiple servers. Client-side vendors like Powersoft just don't have this kind of sensitivity to server-side issues.

However, BaseWorX OSP lacks the front-end power and ease-of-use that have made Powersoft's Powerbuilder, Gupta's SQLWindows, and others into very big hits. BaseWorX OSP's user-interface package, for example, is based on an old-style language, ˆ la Telesoft's TeleUSE, rather than on point-and-click functionality. And its client software runs only on X Windows (Motif), not on Microsoft Windows, Macintosh, or OS/2. Another problem is BaseWorX OSP's object model is proprietary. It's unclear how TCSI can make the model comply with standards like CORBA while retaining some of its unique features.

It is evident, because client/server communication via objects is more complex than communication via SQL and relational data, successful distributed-object development tools require a higher degree of interaction between server-side and client-side concerns. Right now, two distinct types of tool vendors are delivering useful features on each side separately. Tighter cooperation between GUI tool vendors and the TCSIs of the world will be necessary before truly good distributed-object development tools become available.

About the author
Contributing editor Bill Rosenblatt is director of Publishing Systems in the New York City office of the Times Mirror Co. 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-05-1995/asm-05-client.html.
Last updated: 1 May 1995.