Babel was conceived, designed, and built to solve a problem; namely, to make scientific software libraries equally accessible from all of the standard languages. Hence, its goal is language interoperability. The vision goes far beyond calling BLAS1 implemented in fortran 77 from a C program. At its heart, Babel lets programmers use their tool of choice in developing complete applications using components implemented in one or more distinct programming languages.
For instance, let us say that an application scientist is running a sophisticated C++ code from a Python scripting environment. This can already be easily accomplished with technologies like SWIG. Now let’s say that the simulation is showing some erratic behavior and the application scientist wants to extend the ConvergenceCheck class to also report some information to a log file. Let’s also assume that this application scientist doesn’t want to write a new C++ class much less rewrite the current application. What this individual wants to do is derive and utilize a new class in Python from the C++ ConvergenceCheck class. Thus, the C++ simulation code will now have to invoke a method on a class implemented in Python, which then dispatches back to the C++ base class after doing its additional logging. In Babel, this situation is normal and expected. In SWIG, one must use special settings to enable the director feature to have this level of flexibility, which increases the code size and complexity. Figure 2.1 shows a high level view of what Babel’s solution looks like. The developers write the application in Python, the library in C++, and the extended ConvergenceCheck in Python. All the glue code is generated by running Babel on a SIDL file.
Figure 2.2 lists many of the primary languages that are of interest to scientific simulation software developers and users. The good news is that there is a path from each language to every other; meaning that calling from one to another is possible. However, the technologies to get from one language to another vary widely, are fraught with pitfalls, and may require calling through a completely different language.
Babel works by providing the technology to define and support the multi-language interoperation of a common subset of functionality through programming language-neutral interface specifications. See Fig. 2.3 to see a graphical representation of the supported languages. It is important to note that this common functionality subset is far from a lowest common denominator solution in that Babel actually adds functionality when it is lacking in the host language.
In order to support multi-language interoperability, Babel relies on the specification of interfaces in the Scientific Interface Definition Language (SIDL) (pronounced “SIGH-dull”). SIDL is similar to COM and CORBA IDLs, but was designed with an emphasis on scientific computing. Specifically, SIDL supports dynamic multi-dimensional arrays and has built-in complex numbers. SIDL also supports interface contracts, which define properties that must hold true during execution — before and/or after method invocation — when contract enforcement is enabled. It will acquire a set of directives to aid in the description of massively parallel distributed objects.
When it comes to deciding what programming idioms to support across all languages and which ones to reject, SIDL strikes a careful balance between minimalism and completeness. It is not a lowest common denominator solution. SIDL is minimal to keep the learning curve as low as possible. It is complete so developers do not feel constrained in how to express their solutions.
SIDL is object-oriented. Its object model closely resembles that of Java and Objective C. In this model there is single inheritance of implementation and multiple inheritance of interfaces. It supports the typical notions of virtual, static, and final methods. SIDL also provides a basic set of features by defining and implementing the basic types for interfaces, classes and exceptions. All types implicitly inherit from these basic types.
The most important concept to grasp about SIDL is that SIDL only defines a public interface that other programs may use to access your code. As a result, all methods defined as part of a SIDL file are public; if you do not want a method to be globally usable, simply do not define it in your SIDL file. Furthermore, all object and class data is implicitly private. There is no way to declare or define data in a SIDL file. Instead, any data required for your code should be declared in the implementation language files. This way, the languages that use your code through Babel may create your objects and pass them around just like any normal piece of data, but they may only access the data through the provided interface.
SIDL also has a complete set of fundamental data types, from booleans to double precision complex numbers. It also supports more sophisticated types such as enumerations, strings, objects, and dynamic multi-dimensional arrays.
SIDL is still a work in progress. Of particular research interest are directives that will be added for parallel distributed object interaction and features to specify computational quality of service semantics associated with the interfaces.
Babel has two types of customers: developer and user. The developer implements a library that will be used by one or more users, and the user uses libraries via their Babel generated interfaces. Babel provides value to developers by making their software accessible to a larger customer base because their software can be used from more different programming languages. Users, on the other hand, may not care or even know that they are interacting with a library through Babel. Babel provides value to users by making more software accessible to them.
Babel provides some features that benefits user and developer alike. The most important aspect to note here is that all Babel objects are reference counted. This feature is critical to encapsulate the memory allocation library (e. g. C’s malloc/free or C++’s new/delete) used in the implementation of the object. Users never need concern themselves with when to free up a resource, they only declare when they’re done with their reference to that resource. Developers are free to use different memory allocation subsystems in different parts of their code if need be.
Babel also provides a consistent type system. This is particularly important when you want to make object-oriented libraries written in C++, Python or Java accessible in procedural languages like fortran 77, Fortran 90/95 and C. Babel maps the object-oriented concepts like inheritance, polymorphism and object identity into all supported languages.
Interface contracts , which identify conditions that must hold at the interface boundary, can be used to improve the quality of software for both developers and users. Interface contracts consist of precondition, postcondition, and/or invariant clauses belonging to the interface, not the underlying implementation(s). Precondition clauses consist of assertions on properties which must hold prior to method execution. Postcondition clauses contain assertions which must hold upon method completion. Invariant clauses apply before and after method execution. Consequently, in addition to providing useful documentation, SIDL interface contracts are enforceable. So developers can enable contract enforcement as an aid to testing and debugging. Users can enable full or partial contract enforcement during deployment to gain confidence in unfamiliar software.
The language interoperability problem is a large one, and though the Babel tools address much of it, there is still a lot that is beyond the scope of our tool. Babel is at its heart a code generator and a runtime library. Consequently, the following features are currently limitations of the Babel tool kit:
Despite the aforementioned limitations, Babel does facilitate the development of language interoperable software. However, issues of robust packaging, building, and deployment of language interoperable software still loom on the horizon.
Babel consists of a set of tools intended to facilitate language interoperability in the scientific computing community. Using interfaces for libraries or components specified in Scientific Interface Definition Language (SIDL) files, Babel can generate corresponding XML representations as well as the source code for the corresponding stubs, intermediate object representations, and implementation skeletons. The generated source code then becomes the foundation for the glue code used for language interoperability between callers of libraries and components.
In addition to providing generated code automatically handling mapping fundamental data type parameters between different languages, Babel has built-in support for complex numbers and multi-dimensional arrays. Additional benefits include object reference counting to facilitate memory management.
Optional SIDL interface contract features are also provided. Interface contracts aid in improving the quality of software. Contracts added to interfaces document constraints and can be used to enhance testing. When enabled at runtime, contracts can also be used to help users gain confidence in unfamiliar software.
Finally, Babel’s primary goal is to facilitate the development of language interoperable libraries and components. Hence, support for reverse engineering is not provided. Given that Babel has been developed by a research team, there are also limitations associated with shared library and programming language-specific compiler interoperability support that have been looked into but probably will not be addressed in the foreseeable future. Regardless, Babel has proved to be useful to its stakeholders to the point that it is becoming an integral part of the Common Component Architecture (CCA). Refer to papers and presentations on our web site for more information.
The remainder of this document is separated into two parts: foundations and supported language bindings. Part I is devoted to describing the SIDL and the Babel tools. It starts with a tutorial to gently introduce the reader to the development of glue code from both the implementation (or server) and user (or client) sides. The following chapter introduces SIDL and Babel basics. Finally, a chapter on advanced topics, such as linking options, is provided.
Part II describes the language bindings currently supported by Babel. Most of the bindings are programming languages. In which case, most have both client- and server-side bindings. However, Babel also supports textual language backends. At this time, Extensible Markup Language (XML), Hypertext Markup Language (HTML) and Scientific Interface Definition Language (SIDL) are the only textual backends.
Appendices are included to provide more information on topics such as acronyms, the SIDL Grammar, and SIDL XML. In addition, sections are included that provide advice and tips on troubleshooting.
