topical media & game development

talk show tell print

object-oriented programming

Component technology

Many applications, for example in the area of telecomputing, banking and multimedia (but also in high performance computing and operating systems), require support for distribution and concurrency. Due to their complexity, these applications are likely candidates for an object-oriented approach. However, with regard to their distributed nature, some marriage between object-oriented computing and distributed computing must be realized.

Component technology


Additional keywords and phrases: (D)COM, Java, CORBA, OLE, persistent objects, ODMG, workgroup

slide: Component technology

In this chapter we will study component technology, which combines object-oriented features such as encapsulation and (interface) inheritance with (logical and/or physical) distribution. In reality, component technology is not a clear-cut category but rather, according to  [Szyperski97], a battlefield in action (with (D)COM, CORBA and Java as the main players), from which eventually a winner will arise, or perhaps a merge of technologies. In this chapter, we will explore the forces at work, and in addition we will look at a case study deploying CORBA and Java for the creation of a workgroup application, and the integration of CORBA with an existing framework, hush.

object-oriented programming

Objects versus components


As observed in  [Szyperski97], there is some confusion between the notions of object and component. In this section we will look at the definition of component and compare it with what we know of objects. We will further explore the technology matrix, which classifies a selection of the available (component) technologies. Finally, we will discuss some of the software engineering issues involved in component-oriented development, and do away with some of the myths that surround component technology.


Object orientation has not quite fulfilled its promise with respect to reuse. One of the reasons for this is that objects are generally not as modular as they might appear. Or, in the words of  [
Szyperski97], objects are not a suitable unit of deployment.



  • unit of independent deployment
  • unit of third party composition
  • no persistent state



  • unit of instantiation
  • (persistent) state
  • encapsulation of state and behavior

slide: Definitions

 [Szyperski97] proposes components as a suitable unit of deployment instead, and advocates a component-oriented approach to deliver reusable `off-the-shelf' components for a composing large applications.

Let us look at the definition of software component given in  [Szyperski97]:

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

This definition was the result of an ECOOP96 Workshop on Component-oriented Computing. Notice that the definition itself contains a reusability requirement, in mentioning composition by third parties. The requirements of explicit context dependencies, the absence of inherent state and contractually specified interfaces only strengthen this.

In contrast, an object is not a unit of deployment, but a unit of instantiation. Objects are not used in isolation. Objects, do have state and identity. Deploying an object or a collection of objects, moreover, is often subject to (implicit) assumptions concerning the interaction of objects.

Components as better objects

From the characterization above it might appear that components are just better objects. To some extent this is true, but there are some important differences. First of all, in practice, there is a difference in granularity. Components are usually large grain, such as a text editor or database component. Objects, on the other hand, may be small grain, such as dates or text fields. Secondly, components are opaque, `binary units' of functionality, interchangeable with units that deliver the same functionality. Objects, in contrast, carry a state and may be regarded as the living building blocks of an organic system.

 [Szyperski97] mentions that there is a debate whether inheritance is of relevance for component technology. No doubt, inheritance, although somewhat overrated, is an invaluable mechanism, both interface inheritance, to define hie-rarchies of types, and code reuse or implementation inheritance, to allow for incremental development.

Reconsidering the definitions given, I tend to think of the distinction between components and objects as a distinction between perspectives. From a deployment perspective we need components. From a developer's perspective we might prefer to speak about objects. Unfortunately, matters are not that easy. But we need to take a closer look at the technology to find out why.

The technology matrix

The component technology field is currently dominated by three players: Microsoft (D)COM, OMG CORBA, and (the youngest player) Sun Microsystems Java. When comparing these technologies with respect to attributes such as distribution, mobility, language and platform independence, and reflective capabilities, we see that there are many differences. First of all, notice that component technology does not automatically mean distribution. For example, JavaBeans and Microsoft COM do not support distribution. Secondly, whereas language independence seemed to be of importance in the pre-Java era, that is for (D)COM and CORBA, it is not so for the Java-based solutions. Finally, platform independence is hard to achieve. But, fortunately, it is on the agenda of all three technologies, including (D)COM.

It is worth mentioning that the three major technologies have a rather different origin. Microsoft (D)COM is primarily a desktop technology, with Office as its killer application, whereas CORBA originated from the need to have an enterprise-wide solution for distributed objects. Java is a special case. It started as a Web-based language, but rapidly took position in the desktop and enterprise world as well.

Java distinguishes itself from the other technologies both with respect to mobility and reflection. As a Web-based language, Java allows for downloading code dynamically, that is class descriptions for instantiating new objects. True mobile objects, that is instantiated objects that migrate themselves, are only possible when using a system such as Voyager, or any of the other Java-based agent ORBs. Java also provides a powerful Reflection API, which allows for various kinds of meta-programming, including the creation of new classes. In comparison, meta-programming facilities of the two other technologies are limited to querying the availability and functionality of interfaces, dynamic method invocation and some dynamic typing.

Trends -- interoperability

It is hard to predict the outcome of the `battle of component technologies'. However, one can observe a convergence of technologies, that is bridges between Java and CORBA, CORBA and (D)COM, and Java and (D)COM/ActiveX. Each of these technologies sets a standard for interoperability. So, eventually some new standard may arise that encompasses them all. In the meantime, we may study the strengths of each of these technologies and establish what major challenges lie ahead. For example, Microsoft COM has demonstrated itself in an unescapable way in Microsoft Office. A related technology, OpenDoc, failed to gain a market position, but is nevertheless taken on by the OMG as document-oriented component technology.

An interesting project in this respect is the K-Office project, which aims at developing an Office Application Suite for the Unix/X11 desktop. It is built upon the KDE GUI environment, and employs a CORBA-based component technology, (nick)named KOM, to interconnect (embed and link) the various document components and their associated tools. See .

Component myths

Component software engineering may be characterized as an approach that relies on the availability of reusable `off-the-shelf' components that may be composed into applications. This includes applications for banking, medical services, corporate management, entertainment, etcetera.

Components: myths and reality

if semantical issues can be resolved

development becomes more complex

it affects performance significantly

wrong, it is an evolution from OO and C/S

unknown source

slide: Components: myths and reality

From a market perspective, a successful component-based approach requires interoperability between components from different vendors, and standards with respect to the services components offer. Such standards are necessary to insulate clients (i.e. corporations) from vendor-specific, proprietary solutions. Clearly, on the technology side, this surpasses the mere wiring or plumbing standards that form part of (D)COM, ORBs and JavaRMI. In addition, suitable component standards are required for components to interact, as for example offered by ActiveX, JavaBeans or OpenDoc, as well as general services, as for example defined by the OMG, to manage such systems.

Software engineering perspectives

From a software engineering perspective, we encounter a number of unsolved questions, as phrased in  [Szyperski97]:

  • How to describe the interaction between components?
  • How to manage variety and flexibility?
  • How to guarantee critical system-wide properties?
In addition, we need to deal with the practical aspects of developing component-oriented applications, that is master the distributed (object) technology involved, and manage multi-tier architectures.

And, as indicated in slide myths, do not underestimate the complexities of developing such applications. Given the failure of many OO projects, as described in  [Surviving], component-oriented solutions which involve client/server aspects are not likely to be better off, see  [CS2001]. Another area that needs to be studied is the performance of such systems, see for example  [CorbaPatterns].

Yet, in conclusion, just as object orientation may be regarded as a natural evolution from data-oriented approaches, we may look at component-oriented approaches as a natural evolution from object orientation into the realm of distributed systems.

object-oriented programming

Standards for interoperability


The potential of an object-oriented approach, obviously, lies in the opportunities for reuse, both of code and design. However, reuse requires a common understanding of the basic principles underlying the technology and its application. More particularly, the reuse of code requires (a much more strict) agreement with respect to the components from which an application will be constructed and the language constructs used to implement them. In this section, we will look at the object linking and embedding facilities offered by Microsoft OLE, and the standardization efforts undertaken by the OMG (Object Management Group) directed towards the interoperability of object components. In addition, we will look at the efforts of the ODMG (Object Database Management Group) undertaken to develop a standard for persistent objects.

Object linking and embedding -- COM

Reuse is not necessarily code sharing. In effect, there seems to be a trend towards sharing components at a higher level of granularity, as possibly independent applications. This approach has, for example, been taken by the Microsoft object linking and embedding facility (OLE), which offers support for embedding (a copy) of a component in a (container) component, for including a link to another component, and for storing compound objects. See slide

Object-enabling technology


  • document centered -- text, graphics, reports
  • component software -- standard programmatic interface
  • distributed object systems -- component object model
  • (D)COM


  • linking, embedding, storage


  • IBM SOM/DSOM, Apple OpenDoc

slide: Object-enabling technology -- OLE

The OLE technology, which builds upon (D)COM technology, is characterized by its developers as {\em object-enabling} technology, to contrast it with a more classical language-dependent object-oriented approach relying on inheritance.

The object-linking technology allows the user to maintain a link from one application to another, so that for example a text processor may directly employ the results of a spreadsheet. Moreover, object linking is dynamic and allows any updates in the spreadsheet application to be reflected directly in the outcome of the text processor. In contrast, object embedding works more as the traditional cut and paste techniques in that it results in including only a copy of the material. To be embedded or linked, applications must satisfy a standard programmatic interface. In effect, the interface must provide the facility to request an update of the display of the information contained in the application. In this respect, the OLE technology may be characterized as document-centered.

Object Request Brokers -- CORBA

The ultimate goal of object technology may be phrased as the development of plug-compatible software that allows one to construct a particular application from off-the-shelf components. To achieve this goal, it is necessary to develop standards with respect to object interaction and communication interfaces that support information sharing between distinct components. Such standards are developed by the OMG (the Object Management Group, in which the leading vendors of software systems participate, including Digital Equipment Corporation, Hewlett-Packard Company, HyperDesk Corporation, NCR Corporation, Object Design Inc. and Sunsoft Inc.). The OMG aims at defining standards for information sharing in widely distributed, heterogeneous (multi-vendor) networks to support the reusability and portability of commercially available components, and more generally, to develop the technology and guidelines that allow the interoperability of applications. See slide 11-standards.

Standardization -- system integration


  • information sharing -- technology, policy

Object Management Architecture -- interface standards


  • Object Services
  • Object Request Broker
  • Common Facilities -- file manipulation, print queuing, email
  • Application Objects -- spreadsheets, word processor

slide: The OMG standardization effort

The OMG proceeds from the assumption that object technology (including encapsulation, polymorphism and inheritance) provides the mechanism necessary for language-, platform- and vendor-independent, system integration. The OMG has proposed an abstract object model and discusses technical and political objectives in the OMA Guide (Object Management Architecture Guide). The architecture specified in OMA provides a generic description of the components that constitute a system and defines the interface standards to which the components must comply. An important aspect of OMA is the interface description language (IDL) that is introduced as a standard to describe object interfaces in a language-independent manner. According to OMA, a system must support a number of Object Services (dealing with the lifecycle of objects, persistence, naming an event notification), and a so-called Object Request Broker (which is an intermediary between the object providing a service and the client requesting a service). Also a system will need, generally, Common Facilities (such as file manipulation and print queuing), and in addition will contain a number of Application Objects (such as a spreadsheet or word-processor) that constitute the proper application. The OMG is primarily concerned with the adoption of technology by the producers and vendors of common facilities and application objects. Its contribution in this respect is the definition of a set of common object services and a standard interface to invoke such services by means of an object request broker. This standard has been adopted in CORBA (the Common Object Request Broker Architecture) which allows for the interaction between an application and distinct object request brokers. The object services envisioned in OMA are intended to deal with objects in a language- and platform-independent manner. See slide 11-services.

Object Services

  • life cycle -- creation and deletion
  • persistence -- management of object storage
  • naming -- mapping names to references
  • event notification -- registration of events


  • transactions, concurrency, relationships, ... ,time

slide: The OMG Object Services

These services encompass the creation and deletion of objects, the management of object storage, the mapping of names to references and the registration of events as triggers for actions. In addition, services will be defined that allow transactions, concurrency, relationships between objects and time-based properties of objects to be specified. To a large extent, such services are provided by individual languages (such as Java, C++ or Smalltalk) with their accompanying libraries and development frameworks. However, the efforts of the OMG are directed towards (the ambitious goal of) providing such services in a generic fashion, independent of a particular language or environment.

Persistent objects -- ODMG

In a similar vein as the OMG, a number of vendors of object database management systems (including SunSoft, Object Design, Ontos, O_{2} Technology, Versant, Objectivity, Hewlett Packard, POET Software, Itasca, Intellitic, Digital Equipment Corporation, Servio, Texas Instruments) have participated in the ODMG (Object Database Management systems Group) to develop a standard for the definition and manipulation of persistent objects. The standards proposal of the ODMG encompasses an object definition language ODL, which is intended as an extension of the OMG/IDL standard, an object manipulation language, OML and an object query language, OQL, that provides SQL-like facilities for the retrieval of information. The advantage of employing an object database system over employing a relational database system is that, in principle, the application programmer may work within a unified type system, encompassing both persistent and transient objects. See slide 11-ODMG.

Persistent objects


  • database extension -- unified type system

Object Definition Language


  • standard types -- objects and literals
  • references -- Ref< T >
  • collections -- List< T > , Bag< T >, Set< T >

Object Manipulation Language


  • create, delete, modify, reference

Object Query Language


  • oql(type& value,const char* query,...)

slide: The ODMG-93 standardization efforts

The extensions to the various languages, which include C++ and Smalltalk, involve the definition of persistent objects, the creation and use of objects and facilities to pose queries concerning their attributes and relations. These extensions are proposed as language-specific bindings for respectively ODL, OML and OQL. The object model proposed by the ODMG supports objects (which may have attributes and methods), literals (which may be considered as primitive values), relationships between objects (including m-n relations), extents (which contain the collection of instances of a particular type), and named objects (to facilitate retrieval). To define objects and literals, the programmer may employ the standard types offered by the language, as well as a number of additional parametrized types to define references and collections. For references the ODMG-93 proposal employs a Ref smart pointer construct. For dealing with collections a number of generic collection classes such as List, Bag and Set must be provided by a standard library. (To provide a binding for Smalltalk, which does not have a type system, type annotations must be employed to define the properties of persistent objects.) The manipulation of persistent objects conforms with the manipulation of ordinary objects as far as attribute access and method invocation are concerned. However, the language-specific OML bindings must take precautions for the creation, deletion and modification of objects. In particular, when employing a reference to a persistent object, the implementation must check whether the referenced object has been modified. The C++ binding for the object query language OQL in the ODMG-93 proposal is quite simple. It consists merely of a function that allows the programmer to pass an extended SQL-like query as a string. The query may contain symbolic variables that are bound in a similar way as allowed by the C printf function. The design principle guiding the ODMG effort has been to promote that the programmer feels that there is one language. However, there are a number of difficulties that arise when defining a particular language binding for the ODMG object model, as for example for C++. See slide 11-binding.

Design principles

object model

  • the programmer feels that there is one language

Language binding


  • objects and literals -- embedded objects are literals
  • relationships -- not directly supported by C++
  • extents -- must be maintained by programmer
  • keys -- simulated by C++ data members

slide: Language binding -- C++ ODL/OML

Embedded objects which are defined in C++ as object data members, must be taken as literals in the ODMG object model, whereas embedded references to objects are to be taken as objects. Relationships are not directly supported in C++. In the ODMG-93 proposal, the programmer is required to employ an explicit data structure for updating and traversing a relation. Extents, which contain the collection of instances of a type, must explicitly be maintained by the programmer. Extents may conveniently be stored in a collection that is associated with a static data member of the class. Keys, which are needed for efficient retrieval, must be simulated by C++ data members. Support for indexing and retrieval by key requires additional compiler support, for which no provision is made in the ODMG-93 proposal. Other problems that arise in defining a binding to C++ involve the naming of objects, the restriction that C++ allows for only one implementation of a particular type and the duality between arrays and pointers.


Both the OMG and ODMG standardization efforts aim at the portability of software. The ODMG proposal not only entails the portability of design and source code, but also includes object code, in the form of persistent objects. The ODMG-93 proposal is inadequate due, partially, to the self-imposed restrictions with respect to the compiler support required.

C++ODL/OML binding -- future

  • no distinction between persistent and transient objects
  • better integration of the query sublanguage

Modifications to C++

  • overloading dot (access operator), r/l values, ...

Standardization efforts -- de facto market share


slide: Future standardization efforts

The future C++ODL/OML binding will probably no longer distinguish between references to persistent and transient objects, and will provide a better integration of the query language OQL. To realize these goals, however, extended compiler support is needed and perhaps also modifications of C++ to allow the incorporation of code for integrity checking. It is worth noting that there are a number of additional efforts at defining a standard object model. See slide 11-efforts. The ODMG proposal is explicitly meant as a superset of the object model proposed by the OMG, in order to become what they aptly phrase as a standard enforced by a de facto market share.

object-oriented programming

The Java platform -- technology innovation

Java is the newest wave of technology. It offers a distributed object-oriented platform for the development of Web-aware applications. However, as with any wave of technology, we must ask ourselves whether it really does provide an answer to our questions. And, in the line of  [Lewis97], we may well ask ourselves what the original question was in the first place.


  • Internet applications -- the dial-tone of the Internet
  • Software engineering -- long-term maintenance
  • Language design -- semantic compromises
  • System development -- lightweight clients, heavyweight servers
  • Computer science -- towards declarative, verifiable technology
  • IT (in) business -- standards for business objects and processes
  • Global village -- virtual world technology

slide: Perspectives

Whether Java does answer answer our needs for technological innovation is a matter of perspective. The question whether Java will provide an economically viable solution to corporate IT needs can not be answered at this stage. Yet, Java frameworks are being developed. See section San-Francisco.

In this section, we will look at the Java platform from the perspectives listed in slide Perspectives. The rhetoric in these reflections must not be misunderstood as dismissing Java, but as a way to get hold of the issues that play a role in adopting the Java technology, or any of the competing technologies, for business-critical applications.

Internet applications

Java was introduced in 1995 at the WWW3 Conference in Darmstadt as `the dial-tone of the Internet', with applets as its killer application. The dial-tone, because Java is platform-neutral and network-aware. In practice, applets form only a small part of Java applications. Together with the Beans component technology and RMI, Java seems to be an ideal platform for companies that wish to employ the Internet and the Web for commercial applications. However, most developers have no idea how to adopt the Java platform without sacrificing their investment in legacy applications, such as a corporate database. The question is whether there is a migration strategy. In comparison, OMG CORBA seems to have better answers in this respect, although combinations of RMI and JNI (the Java Native Interface) have also been suggested as a technical solution.

Software engineering

 [Lewis97] argues that within two decades we will have Java legacy problems similar to the legacy maintenance problems we have now. Software development with Java is not an issue. There are excellent tools, there is a large amount of good documentation, and there are loads of APIs. In general, software development with Java seems to be easier than, for example, with C++. However, long-term maintenance is a different question altogether. The answer to this question depends on standardization, and issues such as language and platform independence. We must consider that Java is a programming technology, and a good one in this respect, and not an integration technology such as CORBA, for which the specification of domain-independent and domain-specific standards, including services and facilities, is the primary issue.

Language design

Java may be regarded as a second-generation third-generation programming language. Complex as this may sound, it is meant to express that Java is an object-oriented imperative language that shows the influence of many of its predecessors, the minimality of Pascal, threads, the flavor of C++. Personally, I am somewhat bothered by the semantic compromises in Java. For example, the equality operator for strings does, against all expectations, not test for string equality but for reference equality. Threads is another issue. Why only a keyword synchronized and not an Ada-like select? See, for example,  [Petitpierre98]. Java has been developed in great haste. For example, assertion (like Eiffel) seem to have been omitted simply because the implementation was buggy at the time of a delivery deadline.

System development

The Java virtual machine is a good idea. It can be realized on any platform, including computers of all sorts and a variety of gadgets. Java is easy to learn and there are many tools. However, a survey entitled `Are Java Tools ready for Prime Time' indicated that all tools still needed improvements.

Now back to the reality of software development. Many Internet applications are written in script languages. Perl for server-side scripting and Javascript on the client-side. Given the efficiency problems of Java (which are a consequence of the virtual machine approach) and the long download times for applets, Java runs the risk of being too light for heavy-duty servers and too heavy for lightweight clients.

Computer science

Java has been adopted by many universities as the first programming language, and students like it. That is a good thing, although I am worried to see C++ disappear from the curriculum.

In terms of research, what Java offers is not really new. Personally, I am somewhat disappointed that the attention is focused on another third-generation language, whereas to my mind, we should have a declarative programming technology on our research agendas, a technology that supports the development of reliable and verifiable software. Nevertheless, Java appears to be an excellent platform for Web-related research.

IT (in) business

Java is being adopted rapidly. It is nevertheless hard to establish to what extent this involves mission-critical applications or pilot projects. After all, at the time of writing, Java is still cutting-edge technology. And common wisdom has it not to use cutting-edge technology for strategic projects, see  [Surviving].

An example of a business application framework is the IBM San Francisco framework, discussed in section San Francisco, which offers generic solutions for the realization of business processes, such as order management and quality control. Nevertheless, crucial issues in this area do not seem to concern technology per se, but rather the standardization of such notions as business objects, business processes and, of course, business logic. This is also an area of active OMG interest.

Global village

On the Internet we see an increasing number of virtual communities deploying 3D technology for rendering worlds and their inhabitants. Imagine a virtual stockmarket. Decisions must be taken quickly. There is an overload of information, from a variety of sources. Stock prices, political tensions, market trends, all these must be monitored continuously. In critical situations, direct actions must be possible. A nice playground for virtual worlds technology. Is the Java platform ripe for this? It might, given the Java3D and JavaVRML97 efforts. And what about the knowledge management?


In summary, Java is a promising platform, with a wealth of APIs for the development of a variety of applications. At this stage there might be problems of efficiency and problems due to the instability and immaturity of the APIs offered. However, as indicated, there are a number of issues that surpass the reach of the Java platform since they do not depend on technical solutions only. The most important issues, I would say, concern the standardization of (domain-specific) business objects and processes, and the migration problems due to the inescapable existence of legacy applications.

object-oriented programming

An Internet-based workgroup application

The goal of the project described in this section was to develop a prototype for an Internet-based workgroup architecture using CORBA technology. CORBA provides a means for developing distributed object applications, while the Internet provides a standard and widely accessible network infrastructure. Users should not need special client software to use the system, other than a Java-enabled browser such as Netscape.

slide: Object model

The object model guiding the implementation is depicted in \sliref{object-model}. The most important notion in our system is that of an agent, which is defined as a representative of a user which can perform simple operations on the user's behalf, such as sending messages to and making appointments with other agents.

Each user participating is represented by a personal agent, which has an agenda and a message queue. Each agenda consists of several appointments. A workgroup has a membership list consisting of zero or more agents present in the system. An agent can be a member of zero or more workgroups. Possible operations on agents are sending messages to and making appointments with other agents, subscribing to a workgroup, making an appointment with a workgroup or sending a message to all workgroup members.

All interaction of the user with the system is done via Java applets, which combine a graphical user interface with Internet access and CORBA functionality. The server is implemented in C++. We used Visigenic's (formerly PostModern Computing) CORBA 2.0-compliant product ORBeline to implement the server and BlackWidow from the same vendor to implement the Java clients. The server can run on most UNIX platforms, as well as on Windows NT, while the Java applets, running on top of a Java Virtual Machine, can theoretically run on every platform that Java supports. In addition, a C++ browser/monitor was developed that can be used to interrogate agents and workgroups and to monitor message flows.

The Java client applets are first transferred to the client by the HTTP server using a web page and then contact the object server through IIOP, the Internet Inter-ORB Protocol. The client applets run in Netscape or HotJava and contain the CORBA client communications software as well as the client application code. The object server can reside on a different machine than the Web server and is running an IIOP gatekeeper, for instance on {\sc tcp} port 15000, that is part of the ORB. All further communication is done through this gatekeeper.


During the development of a simple workgroup application using CORBA, we experienced a number of limitations inherent to the CORBA architecture.

The most important problem we faced was the distinction between clients and servers, where distributed objects can only reside on a server. If a client wants to make its objects available to other programs, it should be configured as a server as well, with an ORB running on the same host. This causes problems regarding overhead and licensing and is not a feasible situation for the distribution of (Java) clients over the Internet. The same architecture limitation prevents servers from notifying clients using callbacks. This feature makes it impossible for clients to pass distributed object references back to the server, forcing them to work with other identification mechanisms such as object IDs or human-readable strings.

Other minor problems we observed concern the lack of support for existing non-CORBA objects in a distributed environment. Possible solutions are converting existing classes to CORBA and making their interface available through IDL, or to write CORBA object wrappers around these objects.

Finally, not all parts of a CORBA system are compatible among ORBs at the source-code level. This problem should, however, be alleviated with the Portable Object Adapter (POA).

object-oriented programming

Crush -- extending hush with CORBA

This section describes how the hush toolkit has been extended with CORBA functionality. The nickname for this effort was crush. The major problem that arises when extending a given toolkit or framework, such as hush, with CORBA IDL interfaces and classes to implement these interfaces is to provide for a seamless integration of the already existing code with the CORBA-based extensions. In crush we have included facilities for object creation and access, as well as client-side adaptors for the hush CORBA objects, to resolve the type clash between the original hush class hierarchy and the hush CORBA object classes.

Extending a framework with CORBA

  • the legacy problem -- granularity of wrappers
  • object creation and access -- factories and tables
  • client-side adaptors -- to fit within native type system
  • events versus objects -- natural interfaces

slide: Extending a framework with CORBA

Extending a given framework with CORBA is not as straightforward as it may seem. First of all, one has to decide which interfaces may become public, that is may be exported as IDL interfaces. Secondly, one has to decide how object references become known to clients, and what rights clients have to create objects within a particular server. The most important problem, however, concerns the type clash between the CORBA classes implementing the IDL interfaces and the `native' class hierarchy offered by the framework itself.

The legacy problem -- integrating CORBA

CORBA technology is well suited to develop distributed applications. For new projects, the restrictions imposed by CORBA can be taken into consideration from the start. For projects that carry the legacy of existing code, a decision must be made to what extent the CORBA functionality is integrated with the legacy code. On one side of the spectrum, CORBA technology can be used simply for wrapping the legacy code. For example a database may be embedded in a CORBA server, without affecting the database itself. However, for an object-oriented framework such as hush such a solution is not very satisfying. Instead, one would like to have the basic interfaces of hush available to develop distributed components of arbitrary granularity.

Object creation and access

The CORBA Naming Service may be used to provide access to an object residing somewhere on a server. Alternatively, the server may export a reference to a factory object that allows the client to create objects within the server.

For giving access to objects within a particular hush component, we have provided dots (distributed object tables) for both hush and the widgets components. Using the dot the client can access an object of a given type by the name it is given by the server. The object must already exist in the server.

In case clients are allowed to create objects within the server, a factory is provided for creating hush or widget objects.

Client-side adaptors

The intermediary between clients and servers in a CORBA-based system are the CORBA IDL classes generated by the idl compiler from the IDL interfaces. These classes (using the C++ language binding) inherit directly from the CORBA::Object class and hence do not fit within the given class hierarchy.

To allow clients the use of CORBA IDL classes wherever one of the original hush classes is expected, client-side adaptors have been provided for each of the hush or widgets IDL classes. An additional advantage of client-side adaptors is that they allow for overcoming the `weaknesses' of IDL with respect to overloading member functions, parametrized types and operator definitions.

Typically, client-side adaptors have their corresponding hush class as a base class and simply delegate method invocations to the CORBA object they encapsulate.

Events versus object method invocation

Since GUI components are in some way typically event-driven, one may be inclined to limit the communication between such components to exchanging events. The CORBA Event Service would suffice for such communications.

Nevertheless, in our opinion events should be used in a very restricted manner. Events tend to break the `crisp' object interfaces that are one of the benefits of an object-oriented approach to design.

For the hush CORBA extensions, we have chosen for retaining the original hush object interfaces. Note however that the IDL interfaces are somewhat more abstract than the corresponding C++ interfaces. Nevertheless, the event interface is part of the hush module. Together with the dispatch function of the handler interface incoming events resulting from user actions may be dispatched directly to remote components.


The IDL interfaces reflect to a large extent the functionality of the original hush and widgets interfaces. In this section a partial listing of the interfaces will be given. In comparison with the corresponding C++/Java classes, the IDL interfaces are much more abstract in the sense that many member functions required for the actual implementation of the hush framework may be omitted.

The hush module

The hush module contains interfaces corresponding to the basic hush classes, handler, event, kit, widget and item, as well as the auxiliary classes for iterators and containers.

  interface handler { 
event dispatch( in event data ); };

slide: handler

The handler interface provides only a method for dispatching events. It may be extended in the future though. In hush almost every class is derived from handler. This is directly reflected in the hush IDL interfaces.

  interface event : handler { 
attribute long type; attribute long x; attribute long y; };

slide: event

The event interface offers attributes to determine the type of event and its location. Also the event interface will very likely be extended in the future, to allow for a greater variety of events.

  interface kit : handler { 
void source(in string file); void eval(in string command); string result(); widget root(); };

slide: kit

In hush, a kit provides an interface to some embedded interpreter, such as a Tcl interpreter or a logic engine. The kit also gives access to the underlying window environment; in particular it may be asked to provide a reference to the root window.

  interface widget : handler { 
string path(); void eval( in string cmd ); void configure( in string options ); void pack( in string options ); };

slide: widget

A widget is a user interface gadget. The widget interface collects the functions that all these gadgets have in common.

  interface item : handler { 
void move( in long x, in long y ); };

slide: item

An item is obtained when creating a graphical object for a canvas. Subsequently, the item reference suffices to manipulate such objects. Also the item interface will very likely be extended in the future.

Iterators and lists

As an alternative for CORBA arrays and sequences, the hush module offers interfaces for iterators and containers.

  interface iterator { 
Object next(); };

slide: iterator

From a client's perspective, an iterator is a data generator. To deal with typed iterators, the hush C++ library offers template client-side adaptor classes encapsulating the untyped CORBA iterators.

  interface container { 
long length(); Object first(); Object next(); Object current(); iterator walk(); };

slide: container

The container interface offers access to the hush list class. It offers functions for cursor-based list traversal as well as the walk function that may be used to obtain an iterator.

Factories and distributed object tables

To obtain references to objects, clients may use either factory object or distributed object tables.

  interface factory { 
hush::kit kit(in string name); hush::event event(in long type); };

slide: factory

The factory interface allows only for creating a kit and for creating an event. Note that handler objects may not be created directly.

  interface dot {  
hush::kit kit(in string name); hush::container container(in string name); hush::iterator iterator(in string name); hush::factory hush(in string name); };

slide: dot

Apart from giving access to a hush factory, the dot interface allows for getting access to a kit, a container and an iterator. When obtaining references through a dot object, these objects are assumed to exist within the server.

The widgets module

The widgets module provides the actual user interface gadgets for hush. Below we have included only the (partial) interfaces for a canvas and a message widget.

  module widgets {
  interface canvas : hush::widget { 
canvas create( in hush::widget anc, in string path ); hush::item circle( in long x, in long y, in long radius, in string options ); // other items ... }; interface message : hush::widget {
message create( in hush::widget anc, in string path ); void text(in string txt); }; interface factory : hush::factory {
widgets::canvas canvas(in string name, in string options); widgets::message message(in string name, in string options); }; interface dot : hush::dot {
widgets::canvas canvas(in string name); widgets::message message(in string name); widgets::factory widgets(in string name); }; };

slide: module widgets

Note that each widget type has a method create, with which an actual widget of that type can be created. In effect this means that each widget object may act as a factory for widget objects of that type. (The server may however refuse to create such objects!) In addition to the specific gadget interfaces, the widgets module provides a factory and dot interface, extending the respective hush interfaces.


The hush CORBA extensions may be used in a number of ways. For example, the client does not need to be linked with hush when only the server side is given a graphical user interface. In the case that also the client has a graphical user interface, the client side may dispatch incoming events to the server, as illustrated in the canvas example. The communication between server and clients can be arbitrarily complex. The final example shows how to employ iterators and containers to give clients accesses to collections of information.

A remote interpreter kit

This example uses a remote kit. It shows how to get access to a message widget and a kit via a dot (which is a distributed object table). The client access the kit and the message widget by using a name (hello for the message widget and tk for the kit). The client can send Tcl/Tk interpreter commands to the kit.


      hush::dot*      hush;      // (distributed) object tables
      widgets::dot*   widgets;   // widgets contains hush
      hush::kit* tk;             // remote kit object
      widgets::message* banner;
      try {
          hush = widgets = widgets::dot::_bind (SERVER, argv[1]);
          tk = hush->kit("tk");
          banner = widgets->message("hello"); // must exist
      } catch (...) {
           cerr << "Unexpected exception ..." << endl;
           return -1;
      while (1) {
  	char text = readtext(); // from stdin
  	banner->text( text );  // display text

slide: A tk client

This fragment shows how a distributed object table is obtained via the bind function. From this table, the client obtains a kit and a message area. Queries are read in from standard input, displayed in the message area and evaluated. Queries may be arbitrary Tcl/Tk commands. In this way the client may even construct a complete user interface through Tk commands.


  class application : public session {
  application(int argc, char* argv[]) : session(argc,argv,"hello") {
  void corba();
  int main() {
      message* m = new hello(".hello"); 
      corba(); // make yourself available as a server
      return OK;

slide: The tk server

The server is realized as a standard hush program, except for the call to corba (for which the code is given below). Note that the calls to declare for both the kit and message objects is needed to make these objects accessible via the dot.

  void application::corba() {
  widgets::dot* dw = new widgets_dot_srv(); // create dot for widgets
  try {
   CORBA::Orbix.registerIOCallback(it_orbix_fd_open, FD_OPEN_CALLBACK);
   CORBA::Orbix.registerIOCallback(it_orbix_fd_close, FD_CLOSE_CALLBACK);
  catch (...) {
       cout << "apparently something went wrong" << endl;

slide: A tk application

In application::corba() a distributed object table is created. This object is exported as a server by a call to Orbix.impl_is_ready(SERVER,0), where SERVER is a macro defining the name of the server. Calling registerIOCallback is needed to merge the (Orbix) CORBA server event loop with the window event loop for hush.

Evaluating logical queries

With a few minor changes, the client program can be adapted for accessing a logical query evaluator.


      try {
          tk = hush->kit("bp");       // A kit for BinProlog
      catch(...) {
          cout << "An exception ... " << endl;
      while (1) {
          char* text = readtext();
          char* q = 0;
          while ( (q = tk->result()) )
                  cout << "Result: " << q << endl;

slide: Evaluating logical queries

This fragment show how to obtain a kit for BinProlog and consult a facts database. Since queries may produce multiple answers the client must iterate over the term resulting from the query.

A remote canvas

This example shows how a client canvas can be used to draw on a remote canvas.

  class draw_clt : public canvas {  
public: void plug(widgets::canvas* x) { draw = x; } int operator()() { hush::event* e = hush->event(_event->type()); cerr << "Getting event " << e->type() << endl; e->x(_event->x()+10); e->y(_event->y()+10); hush::event::_duplicate(e); // CORBA 2.0 hush::event* res = draw->dispatch(e); return canvas::operator()(); } draw_clt(const widget* w, char* path ) : canvas(w,path) { configure("-background white"); geometry(200,100); self()->bind(this); dragging = 0; } draw_clt(char* path ) : canvas(path) { configure("-background white"); geometry(200,100); self()->bind(this); dragging = 0; } void press( event& ) { dragging = 1; } void motion( event& e) { if (dragging) { self()->circle(e.x(),e.y(),2,"-fill black"); draw->circle(e.x(),e.y(),3,"-fill yellow"); } } void release( event& ) { dragging = 0; } protected: int dragging; widgets::canvas* draw; };

slide: A (remote) canvas client

This fragment shows the implementation of a canvas which is simultaneously the client side of a remote canvas. The method plug allows for declaring the remote canvas, which is accessed via the instance variable draw in both the operator method and the motion method (when dragging). In the operator method an event is created which is dispatched to the remote canvas. Note that this is possible since a canvas is a handler. In the motion method, a large yellow dot is drawn on the remote canvas, whereas the local canvas draws a black dot. Combined, the actions on the remote canvas result in drawing parallel yellow and black dots.

  class draw_srv : public canvas { 
public: draw_srv( const widget* w, char* path ) : canvas(w,path) { geometry(200,100); self()->bind(this); dragging = 0; } void press( event& ) { dragging = 1; } void motion( event& e) { if (dragging) circle(e.x(),e.y(),10,"-fill black"); } void release( event& ) { dragging = 0; } protected: int dragging; };

slide: A canvas server

The canvas implementation on the server side straightforwardly implements a hush canvas. It is embedded in a CORBA server when an object reference is given to it via the distributed object table.

Moving items

This example is similar to the canvas example, but shows some additional features, such as how to manipulate a list of items.


      list* rlist =  new list;
      item* it = draw->circle(40,40,10,"-fill yellow");
      hush::item* rit = new item_srv(it);
      it = draw->circle(30,30,10,"-fill red");
      rit = new item_srv(it);
      hush::container* rx = new list_srv(rlist);
      list::declare("items",rx); // store server
      iter* riter = rlist->walk();

slide: Moving items

The fragment above illustrates the creation of a list of items. In addition it shows how to obtain an iterator and how the iterator may be declared to make it accessible via the distributed object table.


From a design point of view, the hush framework proved to be sufficiently abstract to allow for recapturing its design by means of IDL interfaces. Lacking in the current realization of crush though, are proper exceptions to indicate possible error conditions.

This work shows how to integrate CORBA functionality with an already existing framework. In particular the need for client-side adaptors for resolving the type clash between the `native' classes and the CORBA IDL classes has been amply demonstrated. Enriching hush with CORBA makes crush a potential competitor of Fresco, the CORBA based GUI toolkit derived from the Interviews library.

object-oriented programming


object-oriented programming

This chapter has given an overview of component technology. It discussed standards for interoperability, including (D)COM, CORBA and Java. It gave an example application using both Java and CORBA, and discussed the issues involved in extending an existing library with CORBA.

Objects versus components


  • definitions -- components
  • the technology matrix
  • component myths -- (r)evolution

slide: Section 6.1: Objects versus components

In section 1, we looked at some definitions of components to clarify how component technology differs from object technology. A brief overview of existing technology was given and an attempt was made to demystify component-based development.

Standards for interoperability


slide: Section 6.2: Standards for interoperability

In section 2 we looked in somewhat more detail at component technologies that, each in their own way, set a standard for interoperability.

The Java platform


  • a matter of perspectives

slide: Section 6.3: The Java platform

In section 3, we discussed the Java platform from a variety of perspectives, as listed in slide 6-3. We weighted the pros and cons of Java from each of these perspectives, and concluded that Java is a promising platform.

An Internet-based workgroup application


  • agent, workgroup, agenda, appointment
  • CORBA server, Java applets

slide: Section 6.4: An Internet-based workgroup application

In section 4, we looked at the outline of a simple workgroup application, that allows for creating appointments mediated by agents that act as a representative of a user. The workgroup illustrates the use of Java applets and CORBA servers.

Crush -- extending hush with CORBA


  • factories -- (distributed) object tables
  • server wrappers -- remote objects
  • client-side adaptors -- transparent typing

slide: Section 6.5: Crush -- extending hush with CORBA

Finally, in section 5, we discussed the issues involved in extending a framework such as hush with CORBA. Apart from the definition of interfaces and server wrappers, we defined client-side adaptors to attain a transparent integration of CORBA object handles and the types native to the framework.

object-oriented programming


  1. Give a definition of the notion of components. How is this related to a definition of objects? Explain the difference between these definitions.
  2. What actual component technologies can you think of? How would you compare them?
  3. Describe Microsoft (D)COM, OMG CORBA, ODMG Persistent Objects. Is there any relation between these standards?
  4. Discuss the Java platform. What perspectives can you think of? Discuss pros and cons.
  5. Describe the architecture of an Internet-based workgroup application. What technology would you use?
  6. What issues may arise in extending a given library or framework with CORBA? Can you think of any solutions?

slide: Questions

object-oriented programming

Further reading

I recommend  [Szyperski97], both as an introduction to component-technology, and as a reference for more advanced readers. For an introduction to CORBA, you may read  [Siegel96]. A readable account of the ODMG standard is given in  [Cattell94]. For more information on Java, again, visit . For information on (D)COM, look at . Learning how to program CORBA applications is probably best learned from the manuals that come with your CORBA distribution. For an evaluation of object store management and naming schemes see  [Persistent].

(C) Æliens 04/09/2009

You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.