|
Complete
We recommend Middleware, as prerequisite reading for this technology description.
An object request broker (ORB) is a
middleware technology that manages
communication and
data exchange between
objects. ORBs promote
interoperability
of distributed object systems because they enable users to build systems by
piecing together objects- from different vendors- that communicate with each
other via the ORB
[Wade 94]. The implementation details of the ORB are
generally not important to developers building
distributed systems. The
developers are only concerned with the object interface details. This form of
information hiding enhances system
maintainability
since the object communication details are hidden from the developers and
isolated in the ORB
[Cobb 95].
ORB technology promotes the goal of object communication across machine, software, and vendor boundaries. The relevant functions of an ORB technology are
- interface definition
- location and possible activation of remote objects
- communication between
clients and object
An object request broker acts as a kind of telephone exchange. It provides a
directory of services and helps establish connections between clients and
these services
[CORBA
96,
Steinke 95]. Figure 21 illustrates some of the key ideas.
Figure 21: Object Request Broker
The ORB must support many functions in order to operate consistently and
effectively, but many of these functions are hidden from the user of the
ORB. It is the responsibility of the ORB to provide the illusion of locality,
in other words, to make it appear as if the object is local to the client,
while in reality it may reside in a different process or machine
[Reddy
95]. Thus the ORB provides a framework for cross-system communication
between
objects. This is the first technical step toward interoperability of object
systems.
The next technical step toward object system interoperability is the
communication of objects across platforms. An ORB allows objects to hide their
implementation details from clients. This can include programming language,
operating system, host hardware, and object location. Each of these can be
thought of as a "transparency,"1 and
different ORB technologies may choose to support different transparencies,
thus extending the benefits of
object orientation across platforms and
communication channels.
There are many ways of implementing the basic ORB concept; for example, ORB
functions can be compiled into clients, can be separate processes, or can be
part of an operating system kernel. These basic design decisions might be
fixed in a single product; or there might be a range of choices left to the ORB
implementer.
There are two major ORB technologies:
An additional, newly-emerging ORB model is
Remote Method Invocation (RMI);
this is specified as part of the
Java
language/virtual machine. RMI allows Java objects to be executed
remotely. This provides ORB-like capabilities as a native extension of
Java
[RMI 97].
A high-level comparison of ORB technologies is available in Table 8. Details are available in the referenced technology descriptions.
Successful adoption of ORB technology requires a careful analysis of the
current and future software architectural needs of the target application and
analysis of how a particular ORB will satisfy those needs
[Abowd
96]. Among
the many things to consider are platform availability, support for various
programming languages, as well as implementation choices and product
performance parameters. After performing this analysis, developers can make
informed decisions in choosing the ORB best suited for their application's
needs.
Table 8: Comparison of ORB Technologies
|
ORB
|
Platform Availability
|
Applicable to
|
Mechanism
|
Implementations
|
COM/
DCOM
|
originally PC platforms, but becoming available on other platforms
|
"PC-centric" distributed systems architecture
|
APIs to proprietary system2
|
one3
|
|
CORBA
|
platform-
independent and interoperability among platforms
|
general distributed
system architecture
|
specification of
distributed object technology
|
many4
|
Java/
RMI
|
wherever Java virtual machine (VM) executes
|
general distributed
system architecture and Web-based
Intranets
|
implementation of distributed object technology
|
various5
|
As shown in
Table 8, there are a number of commercial ORB products
available. ORB products that are not
compliant with either CORBA or OLE also
exist; however, these tend to be vendor-unique solutions that may affect system
interoperability, portability, and maintainability.
Major developments in commercial ORB products are occurring, with life cycles
seemingly lasting only four to six months. In addition, new ORB technology
(Java/RMI) is emerging, and there are signs of potential "mergers" involving
two of the major technologies. The continued trend toward
Intranet- and Internet-based applications is another stimulant in the situation. Whether these commercial directions are fully technically viable and will be accepted by the market is unknown.
Given the current situation and technical uncertainty, potential users of ORB technologies need to determine
- what new features ORB technologies add beyond technologies currently in use in their organizations
- the potential benefits from using these new features
- the key risks involved in adopting the technology as a whole
- how much risk is acceptable to them
One possible path would be to undertake a disciplined and "situated"
technology evaluation. Such an evaluation, as described by Brown and Wallnau,
focuses on evaluating so-called "innovative" technologies and can provide
technical information for adoption that is relative to the current/existing
approaches in use by an organization
[Brown
96,
Wallnau 96]. Such a technology evaluation could include pilot projects focusing on model problems pertinent to the individual organization.
The license costs of the ORB products from the vendors listed above are dependent on the required operating systems and the types of platform. ORB products are available for all major computing platforms and operating systems.
This technology is classified under the following categories. Select a
category for a list of related topics.
|
[Abowd 96]
|
Abowd, Gregory, et al. "Architectural Analysis of ORBs."
Object Magazine 6, 1 (March 1996): 44-51.
|
|
[Brown 96]
|
Brown, A. & Wallnau, K. "A Framework for Evaluating Software Technology."
IEEE Software 13, 5 (September 1996): 39-49.
|
|
[Cobb 95]
|
Cobb, Edward E. "TP Monitors and ORBs: A Superior Client/Server
Alternative."
Object Magazine 4, 9 (February 1995): 57-61.
|
| [CORBA 96] |
The Common Object Request Broker: Architecture and Specification,
Version 2.0. Framingham, MA: Object Management Group, 1996. Also available
[online] WWW
<URL:
http://www.omg.org> (1996).
|
|
[Reddy 95]
|
Reddy, Madhu. "ORBs and ODBMSs: Two Complementary Ways to Distribute
Objects." Object Magazine 5, 3 (June 1995): 24-30.
|
|
[RMI 97]
|
Remote Method Invocation [online]. Available WWW
<URL:
http://java.sun.com/products/jdk/1.1/docs/guide/rmi> (1997).
|
|
[Steinke 95]
|
Steinke, Steve. "Middleware Meets the Network."
LAN: The Network Solutions Magazine 10, 13 (December 1995): 56.
|
|
[Tkach 94]
|
Tkach, Daniel & Puttick, Richard. Object Technology in Application
Development. Redwood City, CA: Benjamin/Cummings Publishing Company, 1994.
|
|
[Wade 94]
|
Wade, Andrew E. "Distributed Client-Server Databases." Object Magazine
4, 1 (April 1994): 47-52.
|
|
[Wallnau 96]
|
Wallnau, Kurt & Wallace, Evan. "A Situated Evaluation of the Object
Management Group's (OMG) Object Management Architecture (OMA),"
168-178.
Proceedings of the OOPSLA'96.
San Jose, CA, October 6-10, 1996. New York, NY: ACM, 1996.
Presentation available [online] FTP.
<URL:
ftp://ftp.sei.cmu.edu/pub/corba/OOPSLA/present> (1996).
|
Kurt Wallnau, SEI
John Foreman, SEI
Ed Morris, SEI
Richard Soley, VP, Chief Technical Officer, Object Management Group
- 25 June 97: modified/updated OLE/COM reference to COM/DCOM; added notes to
Table 8
- 9 April 97: minor edits and reorganization; no meaningful content
changes
- 10 Jan 97 (original): Mike Bray, Lockheed-Martin Ground Systems
1
transparency: making something invisible to the client
2
COM/DCOM specifications have been turned over to the Open Group, but the
outcome of this standardization activity remains unclear.
3
Microsoft maintains the only implementation of PC platforms, and is working
closely with selected vendors to migrate technology to alternate platforms.
4
Examples include ORBIX by IONA Technology, NEO by SunSoft, VisiBroker by
VisiGenic, PowerBroker by Expersoft, SmallTalkBroker by DNS Technologies,
Object Director by Fujitsu, DSOM by IBM, DAIS by ICL, SORBET by Siemens
Nixdorf, and NonStop DOM by Tandem.
5
Implementations of the Java VM have been ported to various platforms.
The Software
Engineering Institute (SEI) is a federally funded research and
development center sponsored by the U.S. Department of Defense
and operated by Carnegie Mellon University.
Copyright
2007
by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/str/descriptions/orb_body.html
Last Modified: 11 January 2007
|
