Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/uno_the_idea.html
URL:
http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/uno_the_idea.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/uno_the_idea.html
(added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/uno_the_idea.html Sun
Nov 27 22:49:46 2011
@@ -0,0 +1,262 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html;
charset=windows-1252"/>
+ <TITLE>The Idea of Universal Network Object Technology (UNO)</TITLE>
+ <META NAME="GENERATOR" CONTENT="StarOffice 6.0 (Win32)"/>
+ <META NAME="CREATED" CONTENT="20001010;19410735"/>
+ <META NAME="CHANGEDBY" CONTENT="Hans-Peter Burow"/>
+ <META NAME="CHANGED" CONTENT="20020122;10012841"/>
+ <META NAME="CLASSIFICATION" CONTENT="The Idea of Universal Network
Object Technology (UNO)"/>
+ <META NAME="KEYWORDS" CONTENT="UNO"/>
+<style type="text/css">
+<!--
+h1 { text-align:center; margin-top: 0.2cm; text-decoration: none; color:
#ffffff; font-size: 6; margin-top: 0.2cm}
+h2 { margin-top: 0.2cm; margin-bottom=0.1cm; color: #ffffff; background-color:
#666699 }
+li {margin-bottom: 0.2cm;}
+dl {margin-bottom: 0.2cm;}
+dd {margin-bottom: 0.2cm;}
+dt {margin-bottom: 0.2cm;}
+-->
+</style>
+</HEAD>
+<body>
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0 bgcolor=#666699
summary=header>
+ <TR>
+ <td>
+ <h1> The Idea of Universal Network Object Technology
</h1>
+ </td><td>
+ <a href="http://www.openoffice.org/";><img
src="../../images/open_office_org_logo.gif" name="Grafik1" alt="OpenOffice"
align=right width=109 height=54 border=0/></a>
+ </TD>
+ </TR>
+</TABLE>
+
+<h2> Contents </h2>
+
+<blockquote>
+ <P><A HREF="#Introduction">Introduction</A><br/>
+ <A HREF="#General_solution">General solution</A><br/>
+ <A HREF="#The_Idea">The Idea</A><br/>
+ <A HREF="#Why_our_own_object_model">Why our own object
model?</A>
+ </P>
+</blockquote>
+
+<h2><a name="Introduction"></a> Introduction </h2>
+
+<p>Before explaining the concepts behind UNO, some
+ problems that occurred in a C++ based, openoffice.org
development
+ effort, need to be presented.</P>
+
+<ol>
+<LI>There are a number of base projects (Tools, Streams, Visual Class Library,
+ Framework, etc.) The higher projects, such as
the word processor, calc, etc., use the
+ classes of these base projects. After a change
of some of these classes,
+ for example, a new member or virtual method is
added, the entire office suite
+ needs to be rebuilt. This takes two days, if no
problems occur.
+
+<LI>The API of the base project, with a few exceptions, is not well documented.
+The base projects grow with the requirements of the higher projects.
+
+<LI>The projects dependencies are complicated and difficult to understand.
+Before making changes to an API we need to know, exactly, which projects are
+affected.
+
+<LI>StarOffice has a complex build environment.
+ This made it very difficult for third parties to write components
+ which could be integrated into the office suite.
+
+<LI>StarOffice components could not be used outside of StarOffice.
+
+<LI>There was a requirement to integrate components from other object models
+like CORBA, COM/DCOM, or Java into StarOffice. In addition, it was desirable
+to have StarOffice components be first class components in other component
+models.
+ </OL>
+
+<h2><a name="General_solution"></a> General solution </h2>
+
+<P>There is a general approach to solve the above
+ problems; therefore, the question of “why should
we use UNO”, will
+ be answered in this section.</P>
+
+<ol>
+
+<LI>There is a mechanism which enables a new method to be added to
+ an existing class: this is done with interface
technology. Only
+ interfaces are exposed to other projects. To
add a new method, you
+ only have to add a new interface. So, new
methods can be added to an
+ existing old class, and then the other projects
can use these new
+ features. There is a migration path to the new
API.
+
+<LI>Use of an IDL-language to describe our interfaces
+ and the functionality of components. To do this
on an abstract
+ level, normally, the documentation is better
and the API is not
+ implementation dependent.
+
+<LI>To reduce the build dependencies of a specific
+ component only interfaces are used to
communicate with other
+ components and the base libraries. In this
case, the dependencies
+ are flat.
+
+<LI>Provide infrastructure to add components to a existing product or to the
+system.
+
+<LI>Reduce the dependencies of components, if possible.
+
+<LI>To communicate between different component models we have to create a
+bridge from UNO to the other component model.
+
+</OL>
+ <P>Here is why we are not using an existing component
model: First,
+ we cannot use Java Beans because it is not abstract, it
is only
+ usable in Java itself. Second, CORBA wouldn't be the
right choice
+ because there exists no specification for binary
compatibility in
+ one process and the communication between two
components must be
+ handled through the IIOP protocol. Third, COM/DCOM does
not support
+ exception handling, which is necessary to integrate
smoothly into
+ languages with native exception handling, such as C++,
Java, etc.</P>
+
+<h2><a name="The_Idea"></a> The Idea </h2>
+
+ <P>First, we need to distinguish the difference between
the
+ Universal Component Environment (UCE) and UNO. UCE
defines an
+ environment in which components can be embedded and
defines the
+ API which must be supported by a component. The points
5 and 6, above, are
+ solved with this technology. So, the UCE is on top of
UNO. The
+ construction of the UCE is documented in <A
HREF="empty.html">uce.html.</A></P>
+
+ <H4>The ideas of UNO are as follows:</H4>
+
+ <OL>
+ <LI>A binary specification of the memory layout
of the IDL
+ types. This specification is machine dependent,
so it can be
+ implemented directly, in many languages.
+
+ <LI>Each object lives in an environment.
Objects share this
+ environment with other objects, which are
compatible. This means
+ the same compiler version, the same java
virtual machine or something
+ else. <!-- rh: The preceding sentence is not
clear --> The only access to an object from another environment is to
+ generate a proxy in your own environment. This
can be
+ accomplished by a bridge.
+
+ <LI>To reduce the number of bridges, we define
one environment
+ called the Binary UNO Environment. It is
recommended to provide a
+ bridge to this environment. If you want to
access an object, normally,
+ you have two bridges. The first, from your
environment to the
+ Binary UNO Environment, and the second, from
the Binary UNO
+ Environment to the destination environment. For
every new
+ environment it is only necessary to implement
one bridge.<br/>
+ You
+ can implement bridges between any two
environments, but do this
+ only for performance reasons.
+
+ <LI>Provide a UNO runtime library which
organizes access to
+ the bridges and the environments. With the UNO
runtime library, it is
+ simple to access an object from another
environment, presuming
+ that the bridges are installed.
+
+ <LI>The important concept is, that all calls to
an object in
+ the Binary UNO Environment are dispatched
through one function.
+ This is the Dynamic Dispatch Function. All
calls contain a full
+ description of the method, which means: method
name, argument
+ types, return type, exceptions, and additional
information.<br/>
+ It
+ is very simple to create a bridge to an
interpreter, remote, or an
+ environment which has a well specified API to
call object methods,
+ for example, Java.
+ </OL>
+
+<h2> How does this ideas solve the problems? </h2>
+
+ <P>I explain the special solution with UNO and use the
stated
+ points from the general solution.</P>
+ <OL>
+ <LI>UNO has one base interface called
+ <A
HREF="http://api.openoffice.org/common/ref/com/sun/star/uno/XInterface.html";><I>com.sun.star.uno.XInterface</I></A>.
+ This interface provides a method called
<I>queryInterface</I>.
+ With this method you can get other interfaces.
In this way, it is
+ possible to extend an existing class. In UNO
terminology, we speak
+ of components instead of classes. Look into the
document
+ <A HREF="../empty.html">xinterface.html</A> for
detailed
+ information about
<I>com.sun.star.uno.XInterface.</I>
+
+<LI>An UNO IDL compiler is provided. The language is similar
+ to CORBA's IDL. An extension of our language
was a special tag
+ called <I>service</I>. In a service, you can
specify the
+ interfaces, properties, and the interaction
between the interfaces
+ of a component.
+
+ <LI>We implement components in UNO only with
dependencies to
+ interfaces, or to our base libraries, VOS, SAL,
and OSL. We generate
+ the declaration files in the project of the
component itself; so
+ there are only dependencies to the base
libraries, the binary
+ type repository, and the tool that generates
the declarations.
+
+ <LI>The Universal Component Environment
provides an API to get
+ the dependencies from a component. This
solution is documented
+ in the <A HREF="empty.html">UCE</A> document.
+
+ <LI><p>The other solutions are nice to have,
but this is the
+ fundamental solution done in UNO. First, the <A
HREF="../reference/Cppu/index.html">UNO
+ runtime library</A> provides access to the
environment in which
+ the component is written (e.g.,
<I>uno_getEnvironment(..., “msci”,
+ 0 )</I>). A component <B>need not </B>know it's
environment until
+ it is accessed from another environment. Next,
the UNO runtime
+ library provides access to the <A
HREF="bridge.html">bridge</A>
+ between two environments (e.g.,
<I>uno_getMapping(..., “msci”,
+ “java”)</I>). So from the user
side, it is very simple
+ and normally this is done in a loader like a
shared library
+ loader. The loader is part of the Universal
Component
+ Environment.</p>
+
+<p>On the other side, there is the implementation of
+ the bridge between two environments. The bridge
should create a
+ stub very efficiently, and the transformation
of the calls from one environment
+ to another must be fast. To save disk space and
avoid
+ the administration of marshaling code, the
bridge creates stub
+ objects only from a type repository. The type
repository contains
+ all type information that is necessary. For
example, these are the
+ methods of an interfaces, the members of
structures, and so on.
+ The access to the type repository is also
provided by the UNO
+ runtime library.</p>
+The point that makes the transformation
+ between two environment fast is the binary UNO
specification. The
+ transformation, from one environment to the
binary UNO
+ specification and to the target environment,
should be fast. There
+ are two other ways to speed up the
transformation: First, if two
+ components lie in the same environment, the
communication between
+ them is direct (e.g., a virtual method call in
c++) and no
+ translation is necessary. Second, you can
provide a direct bridge
+ between two environments, so the transformation
to the binary UNO
+ specification is avoided.
+ </OL>
+
+<h2><A NAME="Why_our_own_object_model"></A> Why our own object model? </h2>
+
+ <P>The main reason is that the other object models
don't provide
+ the full functionality. The COM/DCOM model does not
provide
+ exception handling.</p>
+
+<p>CORBA is normally used for remote communication and there is no local
+standard API between objects.</p>
+
+<p>Java RMI is only useful in a Java environment. So we
+ can't use an existing standard to implement the object
model we
+ want to use. But if you look at our object model, then
you see
+ that we use the IIOP protocol in the remote case, and
we use
+ reference counting like COM to determine the lifetime
of the
+ interfaces.</P>
+
+<table width=100% bgcolor=#666699 summary=footer>
+ <TR>
+ <TD>
+<FONT COLOR="#ffffff">Author:
+ <A HREF="mailto:[email protected]";><FONT
COLOR="#ffffff">Jörg
+ Budischewski</FONT></A> ($Date: 2004/12/05 13:27:08
$)<br/><I>Copyright
+ 2002 Sun Microsystems, Inc., 901 San Antonio Road, Palo
Alto, CA
+ 94303 USA.</I></FONT>
+ </TD>
+ </TR>
+</TABLE>
+</BODY>
+</HTML>
Propchange:
incubator/ooo/ooo-site/trunk/content/udk/common/man/uno_the_idea.html
------------------------------------------------------------------------------
svn:eol-style = native
