The component combinator for enterprise applications

Jan. 15, 1998

With the January 1998 issue, JOOP (the Journal of Object-Oriented Programming) inaugurates a new Eiffel column. The opening article is by the column's editor, Bertrand Meyer from ISE.

The subject is one of the important roles of Eiffel: as a component combinator for packaging software elements written with many different languages and tools. Here are some extracts.

Article excerpts

(These are only excerpts; read the magazine for full details.)

The need for a combinator

It looks like the idea of component-based software development has finally captured the industry's attention. This is great news for people who have long been promoting software reusability and object technology; for the first time, reuse has a real chance of succeeding on a broad scale. A chance, not a certainty.

If there is any certainty, it's that no single standard will suffice to develop and distribute reusable components. This is partly a matter of circumstances (each of the big players has high stakes in seeing *its* standard succeed) and partly a matter of technical requirements. Some of the formalisms that may play a substantial role are C, C++, Eiffel, Java, CORBA's Interface Definition Language (IDL), CORBA IIOP, Microsoft's OLE/COM and DCOM, Visual Basic, JavaBeans, HTML and other Web mechanisms.

After years of component drought, shall we have component flood? If so, the risk exists that all those components will be incompatible with each other. Here Eiffel can play a useful role as *component combinator*, enabling various pieces of software, built with various technologies, to lie together as peacefully now as the lion and the lamb will at the end of time.

[...] The role of Eiffel here is less that of an implementation language (except for the components implemented in Eiffel) than of a connecting tool -- the glue between the components.

"Purity" and openness

[...] It is precisely because Eiffel is a "pure" approach to O-O development that it is such a great way to integrate non-O-O stuff. This may at first sound like a paradox, but a moment's reflection shows the validity of the argument: better than a "hybrid" language which keeps elements of another technology such as C, a thoroughly O-O approach can remain simple and easy to learn; and it can concentrate on bringing the architectural benefits of object technology, in particular its power as a combinator for elements of all creeds and persuasions. This power and simplicity enables a better separation of roles between the O-O world and the rest (the "Nixon to China" approach).

We'll talk to anyone

A vast array of interfacing mechanisms supports the use of Eiffel as a component combinator. Here are a few of them.

First, some of the features of an Eiffel class can be *external features* which encapsulate routines written in other languages. You can for example write

	some_operation (argument: INTEGER) is
			external "C"
			end

to indicate that some_operation is actually implemented by a C function. The scheme can be much more sophisticated: you can use macros, specify include files, prescribe type casts for the arguments and results, get the routine from a DLL (Dynamic Link Library).

To use DLLs you can also take advantage of Eiffel library classes (the DESC mechanism) that enable you to create objects representing DLLs and DLL functions, where both the DLL and the functions can be determined at run time.

This use of Eiffel to encapsulate C code has always been an important application of the technology. The head of a large Embedded Eiffel project likes to describe Eiffel as "a CASE tool for C". I am not sure everyone would agree that this is the *only* way to define Eiffel, but it has an element of truth. C will remain, for many years to come, the basic tool for interfacing with hardware and with low-level facilities; this is particularly true in the embedded world. But while C does a good job of implementing short, machine-level functions simply and efficiently, its abstraction mechanisms are notoriously insufficient for large-scale software engineering -- Eiffel's strong point. An excellent marriage.

Almost as important as C, as an external language, is C++. The "external" facilities cover that language too: from Eiffel you can use a C++ class and call its constructors, destructors, member functions, member variables, static members. The result is a close integration between software written in the two languages. An interesting example is the case of "destructors". Here the models are different: Eiffel is garbage-collected, so you don't need to say "delete this object", as you do with a destructor in C++. But a C++ destructor can also serve to clean up resources associated with an object when it is deleted (for example to close the actual file associated with a file object), and this remains useful in a garbage-collected environment. Eiffel offers the `dispose' procedure of the Kernel Library class MEMORY which, when redefined for a particular object, will be applied by the garbage collector when it reclaims that object. Using the C++ interface you can associate with a C++ destructor an Eiffel routine that calls the appropriate `dispose'.

In some cases you will want to use from Eiffel not just a few C++ features but a whole C++ class, to be entirely encapsulated in an Eiffel class which will present a homogeneous interface to the rest of the world. Writing all the external calls manually could be tedious. The "Legacy++" tool removes the tedium. Given a C++ class, it will produce the encapsulation automatically. This is a great way to prepare for reengineering.

Call me any time

All this is from Eiffel to the rest: call-out. As noted above, call-in mechanisms are just as important, enabling the inclusion of advanced elements into existing, possibly large systems. CECIL (The C-Eiffel Call-In Library) covers this need; it enables non-Eiffel software to call all the Eiffel mechanisms, in particular to create objects and apply to them the features of the corresponding classes. So you can use all the power of an Eiffel system or library without ever writing a line of Eiffel.

CECIL comes with a set of mechanisms to establish a correspondence between Eiffel types and C types, to protect objects from the garbage collector (if they are no longer referenced on the Eiffel side but still remembered on the external side), and pass on exceptions, including contract violations, to the external software. This has been crucial in enabling large legacy applications to make progressive use of object technology where it matters most, without breaking the existing structure, and without forcing the legacy side to relinquish control.

Graphical User Interfaces

Graphics and user interfaces is another area where it is crucial to interface smoothly with the market standards. WEL, the Windows Eiffel Library, provides access to the Windows graphical API (Application Programming Interface), made incomparably easier and safer to use thanks to the abstraction mechanisms of Eiffel. The equivalent on the Unix/VMS side is MEL, the Motif Eiffel Library. MEL and WEL are part of EiffelVision, which provides portable, platform-independent graphics.

On Windows, WEL is complemented by the Eiffel Resource Bench, which enables developers to rely on a standard GUI builder such as Microsoft's Developer Studio or Borland's Resource Editor, and generate as output an Eiffel implementation of the interface, relying on calls to WEL facilities.

COM, CORBA, Java, the Web...

Programs increasingly need to communicate with other programs. In the Windows world, OLE/COM is the fundamental "bus" for communication between binaries; OLE/COM support is available to Eiffel applications through the WINE library of Object Tools (authors of Visual Eiffel) and ISE's EiffelCOM's library, built on top of WEL.

The other key communication tool is CORBA; here much has been happening recently, with the release of EiffelCORBA, the Object Request Broker for Eiffel, already in use in the price reporting system being developed for a large Midwest financial institution. As a result of a joint effort between ICL and Eiffel vendors, an official IDL-Eiffel binding has been submitted to the Object Management Group, with good prospects of fast approval.

A number of libraries are also available to support World-Wide Web interaction (plug-ins, HTML generation, CGI form processing).

Java is another technology to which Eiffel is happy to talk. At the time of writing products are already available to embed the Java run-time in Eiffel applications, and several Eiffel-to-Java or Eiffel-to-Java-bytecode generators are in the works.

All this is only part of what Eiffel does to interact with the rest of the world. A shy fellow, you might think at first; but come closer, and you'll discover how eager he is to talk to everyone, and listen.

Reference

The Component Combinator for Enterprise Applications by Bertrand Meyer, in JOOP, volume 10, no. 8, January 1998, pages 5-9.

To other "news stories of the week".