The Free and Open Productivity Suite
Apache OpenOffice 4.1.3 released

Overview: Universal Network Objects (UNO)


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 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.

Connecting Environments

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.

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

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).


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.

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.

Apache Software Foundation

Copyright & License | Privacy | Contact Us | Donate | Thanks

Apache and the Apache feather logo are trademarks of The Apache Software Foundation. OpenOffice, and the seagull logo are registered trademarks of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.