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 define terminology of the parts that language binding consists. For general UNO programming or details about building up a C++ bridge, for example for a specific C++ compiler please read the specific documents.
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, for example 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 (for example when connecting to object models like COM), we use the term of a "language binding" for simplicity. Though, the term "Environment binding" would have been 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, for example 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 (for example IDL long) to its corresponding environment specific type (for example java int). More over, the handling of complex types (for example structs, sequences, any, interfaces) is defined with respective support by a runtime API. If a programming language does not support a specific UNO feature (for example 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 produces 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 environment 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 (for example 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. ($Date: 2007/05/25 14:38:49 $) |