1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
<?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>
The contents of this file are subject to the Erlang Public License,
Version 1.1, (the "License"); you may not use this file except in
compliance with the License. You should have received a copy of the
Erlang Public License along with this software. If not, it can be
retrieved online at http://www.erlang.org/.
Software distributed under the License is distributed on an "AS IS"
basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
the License for the specific language governing rights and limitations
under the License.
</legalnotice>
<title>Introduction to Orber</title>
<prepared>Megan Lynch</prepared>
<docno></docno>
<date>1998-09-21</date>
<rev></rev>
<file>ch_introduction.xml</file>
</header>
<section>
<title>Overview</title>
<p>The Orber application is a CORBA compliant Object Request Brokers
(ORB), which provides CORBA functionality in an Erlang
environment. Essentially, the ORB channels communication or
transactions between nodes in a
heterogeneous environment.
</p>
<p><term id="CORBA"><termdef>Common Object Request Broker Architecture is a common communication standard developed by the OMG (Object Management Group)</termdef></term>(Common Object Request Broker
Architecture) provides an interface definition language allowing
efficient system integration and also supplies standard
specifications for some services.
</p>
<p>The Orber application contains the following parts:</p>
<list type="bulleted">
<item>
<p>ORB kernel and IIOP support</p>
</item>
<item>
<p>Interface Repository</p>
</item>
<item>
<p>Interface Definition Language Mapping for Erlang</p>
</item>
<item>
<p>CosNaming Service</p>
</item>
</list>
<section>
<title>Benefits</title>
<p>Orber provides CORBA functionality in an Erlang environment that enables:
</p>
<list type="bulleted">
<item>
<p><em>Platform interoperability and transparency</em></p>
<p>Orber enables communication between
OTP applications or Erlang environment applications and
other platforms; for example, Windows NT, Solaris
etc, allowing platform transparency. This is especially helpful in situations where there
are many users with different platforms. For example,
booking airline tickets would require the airline database
and hundreds of travel agents (who may not have the same
platform) to book seats on flights. </p>
</item>
<item>
<p><em>Application level interoperability and transparency</em></p>
<p>As Orber is a CORBA compliant application, its purpose is
to provide interoperability and transparency on the application
level.
Orber simplifies the distributed system software by defining the
environment as objects, which in effect, views
everything as identical regardless of programming
languages. <br></br>
Previously, time-consuming programming was
required to facilitate communication between different languages.
However, with CORBA compliant Orber the Application
Programmer is relieved of this task. This makes
communication on an application level relatively transparent to the user.</p>
</item>
</list>
</section>
<section>
<title>Purpose and Dependencies</title>
<p>The system architecture and OTP dependencies of Orber are illustrated in figure 1 below:</p>
<marker id="dependent"></marker>
<image file="dependent.gif">
<icaption>
Figure 1: Orber Dependencies and Structure.</icaption>
</image>
<p>Orber is dependent on Mnesia (see the Mnesia
documentation) - an Erlang database management application
used to store object information.</p>
<note>
<p>Although Orber does not have a run-time
application dependency to IC (an <term id="IDL"><termdef>Interface Definition Language - IDL is the OMG specified interface definition language, used to define the CORBA object interfaces.</termdef></term>compiler for
Erlang), it is necessary when building
services and applications. See the IC documentation for
further details.</p>
</note>
<marker id="orbs"></marker>
<image file="orbs.gif">
<icaption>
Figure 2: ORB interface between Java and Erlang Environment Nodes.</icaption>
</image>
<p>This simplified illustration in figure 2 demonstrates how Orber can facilitate communication in a heterogeneous environment. The Erlang Nodes running
OTP and the other Node running applications written in Java can
communicate via an <term id="ORB"><termdef>Object Request Broker - ORB open software bus architecture specified by the OMG which allows object components to communicate in a heterogeneous environment.</termdef></term>(Object Request Broker). Using
Orber means that CORBA functions can be used to achieve this
communication.
</p>
<p>For example, if one of the above nodes requests an object, it does not
need to know if that object is located on the same, or
different, Erlang or Java nodes. The ORB will channel the
information creating platform and application transparency for
the user.
</p>
</section>
<section>
<title>Prerequisites</title>
<p>To fully understand the concepts presented in the
documentation, it is recommended that the user is familiar
with distributed programming and CORBA (Common Object Request
Broker Architecture).
</p>
<p>Recommended reading includes <em>Open Telecom Platform Documentation Set</em> and <em>Concurrent Programming in Erlang</em>.
</p>
</section>
</section>
</chapter>
|
