Overview: Universal Network Objects (UNO)

Overview

UNO is a component model that offers inter-operability between different programming languages, different objects models, different machine architectures, and different processes; either in a LAN or via the Internet.

The StarOffice and Sun ONE Webtop products have proven the usability of UNO in complex real world applications. Developers that want to use, extend, or modify the functionality of one of the products will do this using UNO.

UNO is not limited to the above applications. The base libraries of UNO are independent of StarOffice and can be used as a framework for other applications.

UNO is freely available (it is distributed under ALv2) and currently supports Java, C and C++ (on windows, Linux, and Solaris). A bridge for COM OLE Automation already exists.

UNO is developed by the OpenOffice.org community including the Sun Microsystems development labs.

Some technical details

UNO is interface based, as are COM and CORBA. Components implement interfaces compliant to their interface specification. Multiple components communicate only via their interfaces. This allows implementing one component in a different language or to move an implementation to another machine, without modifying the other's components. This gives you huge flexibility and preserves earlier invested efforts.

Each component lives in a Uno Runtime Environment (URE). A URE is identified by the implementation language (e.g., C++, Java, Perl, ...) and the current process. There is no performance overhead for components, that are instantiated within the same URE, e.g., in C++, a call from component A to B is just a virtual call. The calls between components from different UREs are bridged by UNO.

In general, calls are bridged through a single dispatch method. This method is, in general, easy to implement for interprocess bridges or bridges to interpreting languages. There is no generated code for stubs or proxies. All necessary conversions are done by the generic dispatch method. The information about the method signature is retrieved dynamically from a type library. This type library is reused by every bridge, so only the number of entries in the type library grows with a growing number of types. This reduces build time and memory consumption at runtime; nevertheless, bridging is as fast as generated code.

UNO-interfaces are specified in IDL. All UNO-interfaces must be derived from a superinterface, that offers acquire, release, and a queryInterface method (comparable to COM). The lifetime of UNO-objects is controlled by global reference counting. Exceptions are used for error handling.

UNO guarantees object identity, thread identity, and the sequence of calls.

• object identity
  Two interfaces' references can be compared for equality. UNO guarantees, that the result is correct, no matter whether the result is true or false.
• thread identity
  In UNO every thread is named by a globally unique thread identifier. A thread leaving the process via an interprocess bridge is identified when entering the process, again, some callstack levels higher. The same thread will execute the new call thus guaranteeing that any thread dependent resources stay the same (such as thread local storage, lock of mutexes, etc.).
• sequence of calls
  UNO allows declaring a method oneway (or asynchron). Multiple, oneway calls are guaranteed to be executed in the same sequence as they were called.

A sequence of oneway calls can be transferred and executed extremely fast via an interprocess connection. The UNO interprocess protocol is optimized for low bandwidth connections.

Have a look a this document, Uno Intro, for further technical information.

Applications built on UNO

This chapter discusses some actual use cases of UNO and the benefits the applications derived from UNO.

StarOffice (or OpenOffice.org)

StarOffice is a fully featured office productivity suite.

StarOffice mainly uses the C++ -in-process functionality of UNO. Before UNO, the StarOffice development suffered very much from incompatible changes (e.g., adding a new virtual method or a new member to a class) in one of the base libraries. This forced a complete rebuild of the product, which roughly consumed 2 days and was done only once a week. These incompatible updates were be reduced considerably by using UNO, and as a result the whole work became more efficient. Please have a look at this document, Uno the Idea, for a more complete explanation.

Java components in StarOffice (e.g., the pgp-integration) use the Java-C++ bridge to access the StarOffice API. External developers can easily integrate their desired functionality in StarOffice using this bridge.

External developers can use the UNO-interprocess bridge to access StarOffice-API from a different process for remote office control.

Sun ONE Webtop

Sun ONE Webtop is a highly distributed application. It provides a fully featured office productivity suite via the Internet. Office documents can be accessed via various clients (WebBrowser-Plugins, PDAs, HTML-Clients, etc.).

UNO is used in the communication between the WebBrowser-Plugin and the office application server. All outputdevice-calls (e.g., DrawRect, DrawLine, and SetColor) necessary to paint a scene are transmitted via the Internet connection (the necessary performance is reached by declaring those calls oneway).

UNO is used to bridge between Java Server Pages (running within the webserver) and the Universal Content Broker (a C++ process that is responsible for data access).

UNO, COM, CORBA, and Java RMI

It is often asked, why a new component model (UNO) has been developed, instead of using already existing ones (such as COM/DCOM, CORBA, or Java RMI). The main reason is that the other object models don't provide the functionality needed for applications such as StarOffice or Sun ONE Webtop.

• COM/DCOM does not allow for use of exceptions, which is of eminent important for advanced error handling.

• CORBA is only a standard for remote communication, there is only very poor support for in process communication (IIOP in process), which is too slow for most applications. See also the CORBA-UNO comparison document

• Java RMI is only useful within a Java environment, but there is a need for a technology for bridging between different languages.

Additionally, the code generation needed, e.g., in COM or CORBA, results in huge libraries if there are many types. For each new bridge, new generated glue code would be necessary, which becomes too difficult to handle.

Author: Jörg Budischewski ($Date: 2004/12/05 12:54:40 $) Copyright 2002 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.