|
ADVANCED
We recommend
Object Request Broker,
as prerequisite reading for this technology description.
The Common Object Request Broker Architecture (CORBA) is a
specification
of a standard architecture for object request brokers
(ORBs)
(see Object Request Broker).
A standard architecture allows vendors to develop ORB products that support
application
portability
and
interoperability
across different programming languages, hardware platforms, operating systems, and ORB implementations:
"Using a CORBA-compliant ORB, a client can transparently invoke a
method on a server object, which can be on the same machine or across a
network. The ORB intercepts the call, and is responsible for finding an object
that can implement the request, passing it the parameters, invoking its
method, and returning the results of the invocation. The client does not have
to be aware of where the object is located, its programming language, its
operating system or any other aspects that are not part of an object's
interface"
[OMG 96].
The "vision" behind CORBA is that distributed systems are conceived and
implemented as distributed objects. The interfaces to these objects are
described in a high-level, architecture-neutral specification language that
also supports object-oriented design abstraction. When combined with the
Object Management Architecture
(see Technical Detail),
CORBA can result in distributed systems that can be rapidly developed, and can
reap the benefits that result from using high-level building blocks provided
by CORBA, such as
maintainability
and
adaptability.
The CORBA specification was developed by the
Object Management Group (OMG), an
industry group with over six hundred member companies representing computer
manufacturers, independent software vendors, and a variety of government and
academic organizations
[OMG 96].
Thus, CORBA specifies an industry/consortium standard, not a "formal" standard in the IEEE/ANSI/ISO sense of the term. The OMG was established in 1988, and the initial CORBA specification emerged in 1992. Since then, the CORBA specification has undergone significant revision, with the latest major revision (CORBA v2.0) released in July 1996.
CORBA ORBs are middleware mechanisms
(see Middleware),
as are all ORBs. CORBA can be thought of as a generalization of remote procedure call (RPC) that includes a number of refinements of RPC, including:
CORBA and the Object Management Architecture. It is
impossible to understand CORBA without appreciating its role in the Object
Management Architecture (OMA), shown in Figure 2. The
OMA is itself a specification (actually, a collection of related
specifications) that defines a broad range of services for building
distributed applications. The OMA goes far beyond RPC in scope and
complexity. The distinction between CORBA and the OMA is an important one
because many services one might expect to find in a middleware product such as
CORBA (e.g., naming, transaction, and asynchronous event management services)
are actually specified as services in the OMA. For reference, the OMA
reference architecture encompasses both the ORB and remote service/object
depicted in
Figure 21, Middleware.
Figure 2: Object Management Architecture
OMA services are partitioned into three categories: CORBAServices, CORBAFacilities, and ApplicationObjects. The ORB (whose details are specified by CORBA) is a communication infrastructure through which applications access these services, and through which objects interact with each other. CORBAServices, CORBAFacilities, and ApplicationObjects define different categories of objects in the OMA; these objects (more accurately object types) define a range of functionality needed to support the development of distributed software systems.
- CORBAServices are considered fundamental to building non-trivial distributed applications. These services currently include asynchronous event management, transactions, persistence, externalization, concurrency, naming, relationships, and lifecycle. Table 1 summarizes the purpose of each of these services.
- CORBAFacilities may be useful for distributed applications in some settings, but are not considered as universally applicable as CORBAServices. These "facilities" include: user interface, information management, system management, task management, and a variety of "vertical market" facilities in domains such as manufacturing, distributed simulation, and accounting.
- Application Objects provide services that are particular to an application or class of applications. These are not (currently) a topic for standardization within the OMA, but are usually included in the OMA reference model for completeness, i.e., objects are either application-specific, support common facilities, or are basic services.
Table 1: Overview of CORBA Services
CORBA in detail. Figure 3 depicts most of the basic components and interfaces defined by CORBA. This figure is an expansion of the ORB component of the OMA depicted in Figure 2.
Figure 3: Structure of CORBA Interfaces
One element (not depicted in Figure 2) that is crucial
to the understanding of CORBA is the interface definition language (IDL)
processor. All objects are defined in CORBA (actually, in the OMA) using
IDL. IDL is an object-oriented interface definition formalism that has some
syntactic similarities with C++. Unlike C++, IDL can only define interfaces;
it is not possible to specify behavior in IDL. Language mappings are defined
from IDL to C, C++,
Ada95, and Smalltalk80.
An important point to note is that CORBA specifies that clients and object implementations can be written in different programming languages and execute on different computer hardware architectures and different operating systems, and that clients and object implementations can not detect any of these details about each other. Put another way, the IDL interface completely defines the interface between clients and objects; all other details about objects (such as their implementation language and location) can be made "transparent."
Table 2 summarizes the components of CORBA and their functional role.
Table 2: Components of the CORBA Specification
Compliance. As noted, CORBA is a specification, not an implementation. Therefore, the question of compliance is important: How does a consumer know if a product is CORBA-compliant, and, if so, what does that mean? CORBA compliance is defined by the OMG:
"The minimum required for a CORBA-compliant system is adherence to
the specifications in CORBA Core and one mapping"
[CORBA 96]
where "mapping" refers to a mapping from IDL to a programming language (C, C++
or Smalltalk80;
Ada95 is specified but has not been formally adopted by the OMG at the time of this writing). The CORBA Core (not the same as the ORB Core denoted in Figure 3 and Table 2) is defined for compliance as including the following:
Significantly, the CORBA Core does not include CORBA
interoperability, nor does it include interworking, the term used to describe
how CORBA is intended to work with Microsoft's COM
(see Component Object Model (COM), DCOM, and
Related Capabilities).
A separate but related point is that CORBA ORBs need not provide implementations of any OMA services.
There are as yet no defined test suites for assessing CORBA compliance. Users must evaluate vendor claims on face value, and assess the likelihood of vendor compliance based upon a variety of imponderables, such as the role played by the vendor in the OMG; vendor market share; and press releases and testimonials. Hands-on evaluation of ORB products is an absolute necessity. However, given the lack of a predefined compliance test suite, the complexity of the CORBA specification (see next topic), and the variability of vendor implementation choices, even this will be inadequate to fully assess "compliance."
Although not concerned with compliance testing in a formal sense, one
organization has developed an operational testbed for demonstrating ORB
interoperability
[CORBANet 96]. It is conceivable that other similar centers may be developed that address different aspects of CORBA (e.g., real time, security), or that do formal compliance testing. However, no such centers exist at the time of this writing.
Complexity. CORBA is a complex specification, and considerable effort may be required to develop expertise in its use. A number of factors compound the inherent complexity of the CORBA specification.
- While CORBA defines a standard, there is great latitude in many of the implementation details- ORBs developed by different vendors may have significantly different features and capabilities. Thus, users must learn a specification, the way vendors implement the specification, and their value-added features (which are often necessary to make a CORBA product usable).
- While CORBA makes the development of distributed applications easier than with previous technologies, this ease of use may be deceptive: The difficult issues involved in designing robust distributed systems still remain (e.g., performance prediction and analysis, failure mode analysis, consistency and caching, and security).
- Facility with CORBA may require deep expertise in related technologies,
such as distributed systems design, distributed and multi-threaded programming
and debugging; inter-networking; object-oriented design, analysis, and
programming. In particular, expertise in object-oriented technology may
require a substantial change in engineering practice, with all the technology
transition issues that implies
(see
The Technology Adoption Challenge).
Stability. CORBA (and the OMA) represent a classical model of distributed
computing, despite the addition of object-oriented abstraction. Recent
advances in distributed computing have altered the landscape CORBA occupies.
Specifically, the recent emergence of mobile objects via Java
(see Java), and the connection of Java with "web browser" technologies has muddied the waters concerning the role of CORBA in future distributed systems. CORBA vendors are responding by supporting the development of "ORBlets", i.e., Java applets that invoke the services of remote CORBA objects. However, recent additions to Java support remote object invocation directly in a native Java form. The upshot is that, at the time of this writing, there is great instability in the distributed object technology marketplace.
Industry standards such as CORBA have the advantage of flexibility in response to changes in market conditions and technology advances (in comparison, formal standards bodies move much more slowly). On the other hand, changes to the CORBA specifications- while technically justified- have resulted in unstable ORB implementations. For example, CORBA v2.0, released in July 1995 with revisions in July 1996, introduced features to support interoperation among different vendor ORBs. These features are not yet universally available in all CORBA ORBs, and those ORBs that implement these features do so in uneven ways. Although the situation regarding interoperation among CORBA ORBs is improving, instability of implementations is the price paid for flexibility and evolvability of specification.
The OMA is also evolving, and different aspects are at different maturity levels. For instance, CORBAFacilities defines more of a framework for desired services than a specification suitable for implementation. The more fundamental CORBAServices, while better defined, are not rigorously defined; a potential consequence is that different vendor implementations of these services may differ widely both in performance and in semantics. The consequence is particularly troubling in light of the new interoperability features; prior to inter-ORB interoperability the lack of uniformity among CORBAServices implementations would not have been an issue.
A large and growing number of implementations of CORBA are available in the
marketplace, including implementations from most major computer manufacturers
and independent software vendors.
See Object Request Broker
for a listing of available CORBA-compliant ORBs. CORBA ORBs are also being developed by university research and development projects, for example Stanford's Fresco, XeroxPARC's ILU, Cornell's Electra, and others.
At the same time, it must be noted that not all CORBA ORBs are equally mature,
nor has the OMA sufficiently matured to support the vision that lies behind
CORBA (see Purpose and Origin). While CORBA and OMA
products are maturing and are being used in increasingly complex and demanding
situations, the specifications and product implementations are not entirely
stable. This is in no small way a result of the dynamism of distributed object
technology and middleware in general and is no particular fault of the
OMG. Fortunately techniques exist for evaluating technology in the face of
such dynamism
[Wallace 96,
Brown 96].
Costs and limitations include the following:
Dependencies include the following:
Alternatives include the following:
Complementary technologies include the following:
This technology is classified under the following categories. Select a
category for a list of related topics.
| [Baker 94] |
Baker, S. "CORBA Implementation Issues."
IEEE Colloquium on Distributed Object Management Digest 1994 7
(January 1994): 24-25.
|
| [Brando 96] |
Brando, T. "Comparing CORBA & DCE."
Object Magazine 6, 1 (March 1996): 52-7.
|
| [Brown 96] |
Brown, A. & Wallnau, K. "A Framework for Evaluating Software Technology."
IEEE Software 13, 5 (September 1996): 39-49.
|
| [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).
|
| [CORBANet 96] |
Distributed Software Technology Center Home Page [online]. Available WWW
<URL:
http://corbanet.dstc.edu.au> (1996).
|
| [Deng 95] |
Deng, R.H., et al.
"Integrating Security in CORBA-Based Object Architectures," 50-61.
Proceedings of the 1995 IEEE Symposium on Security and Privacy.
Oakland, CA, May 8-10, 1995. Los Alamitos, CA: IEEE Computer Society Press,
1995.
|
|
[Foody 96]
|
Foody, M.A. "OLE and COM vs. CORBA." UNIX Review 14, 4. (April 1996):
43-45.
|
|
[Jell 95]
|
Jell, T. & Stal, M. "Comparing, Contrasting, and Interweaving CORBA and
OLE," 140-144.
Object Expo Europe 1995. London, UK, September 25-29, 1995.
Newdigate, UK: SIGS Conferences, 1995.
|
|
[Kain 94]
|
Kain, J.B. "An Overview of OMG's CORBA," 131-134.
Proceedings of OBJECT EXPO `94.
New York, NY, June 6-10, 1994. New York, NY: SIGS Publications, 1994.
|
|
[Mowbray 93]
|
Mowbray, T.J. & Brando, T. "Interoperability and CORBA-Based Open
Systems." Object Magazine 3, 3 (September/October 1993): 50-4.
|
|
[OMG 96]
|
Object Management Group home page [online]. Available WWW
<URL:
http://www.omg.org> (1996).
|
|
[Roy 95]
|
Roy, Mark & Ewald, Alan. "Distributed Object Interoperability."
Object Magazine 5, 1 (March/April 1995): 18.
|
|
[Steinke 95]
|
Steinke, Steve. "Middleware Meets the Network."
LAN: The Network Solutions Magazine 10, 13 (December 1995): 56.
|
|
[Tibbets 95]
|
Tibbets, Fred. "CORBA: A Common Touch for Distributed Applications."
Data Comm Magazine 24, 7 (May 1995): 71-75.
|
|
[Wallace 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).
|
|
[Watson 96]
|
Watson, A. "The OMG After CORBA 2."
Object Magazine 6, 1 (March 1996): 58-60.
|
Kurt Wallnau, SEI
Dave Carney, SEI
Ed Morris, SEI
10 Jan 97 (original)
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
2008
by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/str/descriptions/corba_body.html
Last Modified: 24 July 2008
|
