OpenOffice UNO Language Binding : What is it about?


Contents


Introduction

Definitions:


Introduction


The objective of this document is to get a general notion of a UNO language binding and mainly defines terminology of what parts a language binding consist. General UNO programming or details about building up a C++ bridge, e.g. for a specific C++ compiler is not described here.
A UNO language binding is simply said the infrastructure enabling communication between UNO components from different language or runtime environments. More over a language binding not only let components, e.g. written with different programming languages, to interoperate, it also provides the UNO programming environment for a specific language/ environment. Despite the fact that a language binding may not only connect different programming languages (e.g., when connecting to object models like COM), we keep the term of a "language binding" for simplicity. Though, the term "Environment binding" would be more general.
The following section presents several definitions of what parts a UNO language binding consists. Some parts are optional, though.

Definitions


UNO Runtime Environment (URE). A UNO component runs in an environment which serves as the platform to run components (UNO Runtime Environment). A language binding connects two environments for interoperation.
The runtime prerequisites for components in an environment may be different, e.g. a java component needs a java virtual machine, a COM component the COM libraries. An environment need not denote a specific programming language to interoperate with, it can even be a language independent object model like COM.

Language Specification and Glue Code. The language specification defines the mapping of any UNO type (e.g., IDL long) to its corresponding environment specific type (e.g., java int). More over, the handling of complex types (e.g., structs, sequences, any, interfaces) is defined with respective support by a runtime API. If a programming language does not support a specific UNO feature (e.g., no "direct"/ convenient exception support), additional glue code (part of the runtime API) has to be defined balancing out these weaknesses.

Code Generator. The language specification defines the representation of UNO IDL types.
A code generator prodcues the appropriate programming language constructs as defined in the language specification. It commonly reads from a binary type library and writes out files for each type.

UNO Bridge. A bridge is the core instance connecting two environments.
A bridge is bidirectional in the way that it can map interfaces from one anvironment to another and vice versa, thus providing two unidirectional mappings.

    Mapping. Mapping an interface involves in depth knowledge of both environments to emulate arbitrary interfaces.
    Calls on an emulated interface are delegated (including marshalling) via the bridge and lead to a method invocation on the target interface. Any return values, out parameters or exceptions have to be converted to the calling environment. For this task the complementary mapping is needed, thus both mappings of a bridge are tied closely together.

    Environment/ Engine Access. The bridge needs runtime environment access, for interpreting environments also access to the executing engine (e.g., java, javascript).
    The bridge connecting to the environment commonly needs engine access, too.

UNO Component Loader. The UNO component loader loads a UNO component implemented for a specific UNO runtime environment.
Besides loading the component and preparing the runtime environment (like scripting engine access), this process eventually includes raising an appropriate bridge to connect to the environment.
When loading a component, the component may define own types it needs to execute. These types may be introduced to the runtime by the component dynamically at startup or those types have been merged to a central binary typelib file prior to application execution (which has been most commonly used for now).

Bootstrapping. The bootstrapping process starts up the UNO core system up to the point that components can be loaded and executed.
Components are dependent on each other. For loading components you most commonly need to have a component loader component from scratch. This is the first problem: You need to load it manually. Among other things it is necessary to have a type system providing type information used in components. The latter issue may includes typelib files to be known. So this process requires inside implementation knowledge of the initial components, despite the fact that you normally need not know how a service is implemented. As a result of the bootstrapping process, it is possible to raise further components without knowing any implementation details.
It is not intended to define a general bootstrap process here, if this is possible at all. Although, we will present a default scheme applications using the C++ implementations of base services from code module stoc. It is part of the UNO language binding to provide a mechanism to bootstrap an initial UNO system in a specific UNO runtime environment.

Initial Object. First object provided by a UNO runtime environment.
This may be necessary in inter-process communication, if the component loader needs to have a "special" initial object like a service manager. The language binding has to define the initial communication protocol to get the initial object.


Author: Daniel Bölzle. Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.