blob: 66d33d065cda00c8f7b498d5bf4357b8f95a9276 (
plain) (
tree)
|
|
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">
<chapter>
<header>
<copyright>
<year>1999</year><year>2013</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</legalnotice>
<title>The Orber Application</title>
<prepared></prepared>
<docno></docno>
<date>1998-10-05</date>
<rev></rev>
<file>ch_orber_kernel.xml</file>
</header>
<section>
<title>ORB Kernel and IIOP </title>
<p>This chapter gives a brief overview of the ORB and its relation
to objects in a distributed environment and the usage of Domains
in Orber.
Also Internet-Inter ORB Protocol (<term id="IIOP"><termdef>Internet-Inter ORB Protocol</termdef></term>) is discussed and how this
protocol facilitates communication between ORBs to
allow the accessory of persistent server objects in Erlang. </p>
</section>
<section>
<title>The Object Request Broker (ORB)</title>
<p>An ORB kernel can be best described as the middle-ware, which
creates relationships between clients and servers, but is
defined by its interfaces. This allows transparency for the
user, as they do not have to be aware of where the requested
object is located. Thus, the programmer can work with any other
platform provided that an IDL mapping and interfaces exist.
</p>
<p>The IDL mapping which is described in a later chapter is the
translator between other platforms, and languages. However, it
is the ORB, which provides objects with a structure by which
they can communicate with other objects.
</p>
<p>ORBs intercept and direct messages from one object, pass this
message using IIOP to another ORB, which then directs the
message to the indicated object.
</p>
<p>An ORB is the base on which interfaces, communication stubs
and mapping can be built to enable communication between
objects. Orber uses <term id="domains"><termdef>A domain allows a more efficient communication protocol to be used between objects not on the same node without the need of an ORB</termdef></term>to group objects of different nodes
</p>
<p>How the ORB provides communication is shown very simply in figure 1 below: </p>
<marker id="theORB"></marker>
<image file="theORB.gif">
<icaption>
Figure 1: How the Object Request Broker works.</icaption>
</image>
<p>The domain in Orber gives an extra aspect to the distributed object
environment as each domain has one ORB, but it is distributed over
a number of object in different nodes. The domain binds objects on
nodes more closely than distributed objects in different domains. The
advantage of a domain is that a faster communication exists between
nodes and objects of the same domain. An internal communication protocol
(other than IIOP) allows a
more efficient communication between these objects. </p>
<note>
<p>Unlike objects, domains can only have one name
so that no communication ambiguities exist between domains.</p>
</note>
</section>
<section>
<title>Internet Inter-Object Protocol (IIOP)</title>
<p>IIOP is a communication protocol developed by the OMG to
facilitate communication in a distributed object-oriented
environment.
</p>
<p>Figure 2 below demonstrates how IIOP works between objects:</p>
<marker id="iiop"></marker>
<image file="iiop.gif">
<icaption>
Figure 2: IIOP communication between domains and objects.</icaption>
</image>
<note>
<p>Within the Orber domains the objects communicate without
using the IIOP. However, the user is unaware of the difference in protocols, as this difference is not visible. </p>
</note>
</section>
</chapter>
|