incubator-ooo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r799361 [8/8] - in /websites/staging/ooo-site/trunk/content/udk/common: ./ man/ man/concept/ man/draft/ man/draft/scripting/ man/draft/scripting/DesignDoc/ man/images/ man/spec/ man/tasks/ man/tutorial/
Date Sun, 27 Nov 2011 22:52:03 GMT
Added: websites/staging/ooo-site/trunk/content/udk/common/man/uno.html
==============================================================================
--- websites/staging/ooo-site/trunk/content/udk/common/man/uno.html (added)
+++ websites/staging/ooo-site/trunk/content/udk/common/man/uno.html Sun Nov 27 22:51:54 2011
@@ -0,0 +1,251 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+<head>
+<link href="/css/ooo.css" rel="stylesheet" type="text/css">
+
+<title></title>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+
+</head>
+
+<body>
+  <div id="banner">
+    <div id="bannerleft"><a alt="Apache OpenOffice.org (incubating)" href="/">
+      <img id="ooo-logo alt="Apache OpenOffice.org (Incubating)" src="/images/ooo-logo.png"/></a></div>
+    <div id="bannerright"><a alt="Apache Incubator" href="http://incubator.apache.org">
+      <img id="asf-logo" alt="Apache Incubator" src="/images/apache-incubator-logo.png"/></a></div>
+   <div id="bannercenter"><br/>(incubating)&nbsp;|&nbsp;The Free and
Open Productivity Suite</div>
+  </div>
+  <div id="clear"></div>
+  
+  <div id="content">
+  
+    
+    
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0 BGCOLOR="#666699"
+    summary=header>
+	<TR>
+		<TD>
+			<H1> Overview: Universal Network Objects (UNO) </H1>
+		</TD>
+	</TR>
+</TABLE>
+
+<h2> Overview </h2>
+
+			<P>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. 
+			</P>
+			<P>The <A HREF="#applications">StarOffice and Sun ONE Webtop</A>
+			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. 
+			</P>
+			<P>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. 
+			</P>
+			<P>UNO is freely available (it is distributed under the LGPL
+			license) and currently supports Java, C and C++ (on windows, Linux,
+			and Solaris). A bridge for COM OLE Automation already exists. 
+			</P>
+			<P>UNO is developed by the OpenOffice.org community including the Sun
+			Microsystems development labs.<!-- ******************************************************
+* TECHNICAL DETAILS
+******************************************************
+ -->
+						</P>
+<h2><a name="tech_details"></A> Some technical details </h2>
+
+<P>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. 
+			</P>
+			<P STYLE="margin-bottom: 0cm">Each component lives in a <STRONG>U</STRONG>no
+			<STRONG>R</STRONG>untime <STRONG>E</STRONG>nvironment (<STRONG>URE</STRONG>).
+			A URE is identified by the implementation language (e.g., C++,
+			Java, <SPAN LANG="en-US">Perl</SPAN>, ...) 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. 
+			</P>
+
+<center><img src="images/component_environments.gif" name="Grafik1" align=middle
width=511 height=294 border=0 alt="Connecting Environments"/></center>
+
+			<P>In general, calls are bridged through a single <EM>dispatch</EM>
+			method. This method is, in general, easy to implement for 
+			interprocess bridges or bridges to interpreting languages. There
+			is <STRONG>no generated code</STRONG> for stubs or<SPAN LANG="en-US">
+			proxies. </SPAN>All necessary conversions are done by the generic
+			dispatch method. The information about the method signature is
+			retrieved dynamically from a <STRONG>type library</STRONG>. 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. 
+			</P>
+			<P>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 <STRONG>global reference counting</STRONG>.
+			<STRONG>Exceptions</STRONG> are used for error handling. 
+			</P>
+			<P>UNO guarantees <STRONG>object identity</STRONG>, <STRONG>thread
+			identity</STRONG>, and the <STRONG>sequence of calls</STRONG>. 
+			</P>
+			<UL>
+				<li>object identity<br/>
+				Two interfaces' references can be compared for equality. UNO
+				guarantees, that the result is correct, no matter whether the
+				result is true or false. 
+
+				<li>thread identity<br/>
+				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.).
+
+				<li>sequence of calls<br/>
+				UNO allows declaring a method oneway
+				(or asynchron). Multiple, oneway calls are guaranteed to be
+				executed in the same sequence as they were called. 
+
+			</UL>
+			<P>A sequence of oneway calls can be<SPAN LANG="en-US">
+			transferred </SPAN>and executed extremely fast via an interprocess
+			connection. The UNO interprocess protocol is optimized for low
+			bandwidth connections. 
+			</P>
+			<P>Have a look a this document, <A HREF="concept/unointro.html">Uno Intro</A>,
+			for further technical information.<!-- **************************************************************************
+* A P P L I C A T I O N S   B U I L T   O N   U N O
+**************************************************************************
+ -->
+						</P>
+
+<h2><a name="applications"></a> Applications built on UNO </h2>
+
+<P>This chapter discusses some actual use cases of UNO and the benefits
+the applications derived from UNO.</P>
+
+<h3>StarOffice (or OpenOffice.org)</h3>
+
+			<P>StarOffice is a fully featured office productivity suite. 
+			</P>
+			<P>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, 
+			<A HREF="uno_the_idea.html">Uno the Idea</A>, for a more complete explanation.

+			</P>
+			<P>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<SPAN LANG="en-US">
+			functionality </SPAN>in StarOffice using this bridge. 
+			</P>
+			<P>External developers can use the UNO-interprocess bridge to
+			access StarOffice-API from a different process for remote office
+			control. 
+			</P>
+
+<h3>Sun ONE Webtop</h3>
+
+			<P>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.).</P>
+			<P>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).</P>
+			<P>UNO is used to bridge between <STRONG>Java Server Pages</STRONG>
+			(running within the webserver) and the Universal Content Broker (a
+			C++ process that is responsible for data access).<!-- ******************************************************
+* OTHER COMPONENT MODELS
+******************************************************
+ -->
+						</P>
+
+<h2><a name="other_models"></a> UNO, COM, CORBA, and Java RMI </h2>
+
+			<P>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. 
+			</P>
+			<UL>
+				<LI><P STYLE="margin-bottom: 0cm">COM/DCOM does not allow for use
+				of exceptions, which is of eminent important for advanced error
+				handling. 
+				</P>
+				<LI><P STYLE="margin-bottom: 0cm">CORBA is only a standard for
+				remote communication, there is only very poor support for in
+				process<SPAN LANG="en-US"> communication </SPAN>(IIOP in
+				process), which is too slow for most applications. See also the 
+				<A HREF="comparison_uno_corba.html">CORBA-UNO comparison document</A>
+								</P>
+				<LI><P>Java RMI is only useful within a Java environment, but there
+				is a need for a technology for bridging between different
+				languages. 
+				</P>
+			</UL>
+			<P>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. 
+			</P>
+
+<table summary=footer width=100% bgcolor=#666699>
+	<TR>
+		<td>
+			<FONT COLOR="#ffffff"><SPAN LANG="en-US">Author</SPAN>: <A HREF="mailto:joerg.budischewski@sun.com"><FONT
COLOR="#ffffff">J&ouml;rg
+			Budischewski</FONT></A> ($Date: 2004/12/05 12:54:40 $)<br/><i>Copyright
+			2002 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA
+			94303 USA.</i></font>
+		</TD>
+	</TR>
+</TABLE>
+</BODY>
+</HTML>
+
+  </div>
+
+  <div id="footera">
+    <div id="poweredbya">
+      <p><img src="/images/feather-small.gif"/><br/>Powered by the Apache
CMS.</p>
+    </div>
+    <div id="copyrighta">
+      <p>
+	Apache "OpenOffice.org" is an effort undergoing incubation at The Apache Software Foundation
(ASF), sponsored by the Apache Incubator.
+	Incubation is required of all newly accepted projects until a further review indicates that
the infrastructure, communications, and
+	decision making process	have stabilized in a manner consistent with other successful ASF
projects. While incubation status is
+	not necessarily a reflection of the completeness or stability of the code, it does indicate
that the project has
+	yet to be fully endorsed by the ASF.</p>
+      <p>
+	<a href="/contact.html">Contact Us</a> |
+	<a href="/terms.html">Terms of Use</a>
+	<br />Apache and the Apache feather logos are trademarks of The Apache Software Foundation.
+	<br />OpenOffice.org and the seagull logo are registered trademarks of The Apache
Software Foundation.
+	<br />Other names appearing on the site may be trademarks of their respective owners.
+      </p>
+    </div>
+  </div>
+
+</body>
+</html>

Added: websites/staging/ooo-site/trunk/content/udk/common/man/uno_components.html
==============================================================================
--- websites/staging/ooo-site/trunk/content/udk/common/man/uno_components.html (added)
+++ websites/staging/ooo-site/trunk/content/udk/common/man/uno_components.html Sun Nov 27
22:51:54 2011
@@ -0,0 +1,49 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+<head>
+<link href="/css/ooo.css" rel="stylesheet" type="text/css">
+
+<title></title>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+
+</head>
+
+<body>
+  <div id="banner">
+    <div id="bannerleft"><a alt="Apache OpenOffice.org (incubating)" href="/">
+      <img id="ooo-logo alt="Apache OpenOffice.org (Incubating)" src="/images/ooo-logo.png"/></a></div>
+    <div id="bannerright"><a alt="Apache Incubator" href="http://incubator.apache.org">
+      <img id="asf-logo" alt="Apache Incubator" src="/images/apache-incubator-logo.png"/></a></div>
+   <div id="bannercenter"><br/>(incubating)&nbsp;|&nbsp;The Free and
Open Productivity Suite</div>
+  </div>
+  <div id="clear"></div>
+  
+  <div id="content">
+  
+    
+    
+  </div>
+
+  <div id="footera">
+    <div id="poweredbya">
+      <p><img src="/images/feather-small.gif"/><br/>Powered by the Apache
CMS.</p>
+    </div>
+    <div id="copyrighta">
+      <p>
+	Apache "OpenOffice.org" is an effort undergoing incubation at The Apache Software Foundation
(ASF), sponsored by the Apache Incubator.
+	Incubation is required of all newly accepted projects until a further review indicates that
the infrastructure, communications, and
+	decision making process	have stabilized in a manner consistent with other successful ASF
projects. While incubation status is
+	not necessarily a reflection of the completeness or stability of the code, it does indicate
that the project has
+	yet to be fully endorsed by the ASF.</p>
+      <p>
+	<a href="/contact.html">Contact Us</a> |
+	<a href="/terms.html">Terms of Use</a>
+	<br />Apache and the Apache feather logos are trademarks of The Apache Software Foundation.
+	<br />OpenOffice.org and the seagull logo are registered trademarks of The Apache
Software Foundation.
+	<br />Other names appearing on the site may be trademarks of their respective owners.
+      </p>
+    </div>
+  </div>
+
+</body>
+</html>

Added: websites/staging/ooo-site/trunk/content/udk/common/man/uno_the_idea.html
==============================================================================
--- websites/staging/ooo-site/trunk/content/udk/common/man/uno_the_idea.html (added)
+++ websites/staging/ooo-site/trunk/content/udk/common/man/uno_the_idea.html Sun Nov 27 22:51:54
2011
@@ -0,0 +1,289 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+<head>
+<link href="/css/ooo.css" rel="stylesheet" type="text/css">
+
+<title></title>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+
+</head>
+
+<body>
+  <div id="banner">
+    <div id="bannerleft"><a alt="Apache OpenOffice.org (incubating)" href="/">
+      <img id="ooo-logo alt="Apache OpenOffice.org (Incubating)" src="/images/ooo-logo.png"/></a></div>
+    <div id="bannerright"><a alt="Apache Incubator" href="http://incubator.apache.org">
+      <img id="asf-logo" alt="Apache Incubator" src="/images/apache-incubator-logo.png"/></a></div>
+   <div id="bannercenter"><br/>(incubating)&nbsp;|&nbsp;The Free and
Open Productivity Suite</div>
+  </div>
+  <div id="clear"></div>
+  
+  <div id="content">
+  
+    
+    
+<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 &ldquo;why should we use UNO&rdquo;, 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(..., &ldquo;msci&rdquo;,
+				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(..., &ldquo;msci&rdquo;,
+				&ldquo;java&rdquo;)</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:joerg.budischewski@sun.com"><FONT COLOR="#ffffff">J&ouml;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>
+
+  </div>
+
+  <div id="footera">
+    <div id="poweredbya">
+      <p><img src="/images/feather-small.gif"/><br/>Powered by the Apache
CMS.</p>
+    </div>
+    <div id="copyrighta">
+      <p>
+	Apache "OpenOffice.org" is an effort undergoing incubation at The Apache Software Foundation
(ASF), sponsored by the Apache Incubator.
+	Incubation is required of all newly accepted projects until a further review indicates that
the infrastructure, communications, and
+	decision making process	have stabilized in a manner consistent with other successful ASF
projects. While incubation status is
+	not necessarily a reflection of the completeness or stability of the code, it does indicate
that the project has
+	yet to be fully endorsed by the ASF.</p>
+      <p>
+	<a href="/contact.html">Contact Us</a> |
+	<a href="/terms.html">Terms of Use</a>
+	<br />Apache and the Apache feather logos are trademarks of The Apache Software Foundation.
+	<br />OpenOffice.org and the seagull logo are registered trademarks of The Apache
Software Foundation.
+	<br />Other names appearing on the site may be trademarks of their respective owners.
+      </p>
+    </div>
+  </div>
+
+</body>
+</html>



Mime
View raw message