|
|
|
|
Common Object Request Broker Architecture
|
| |
|
| |
The Common Object Requesting Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together.
A is a mechanism in software for normalizing the method-call semantics between application objects that reside either in the same address space (application) or remote address space (same host, or remote host on a network).
Discussion
Ask a question about 'Common Object Request Broker Architecture' Start a new discussion about 'Common Object Request Broker Architecture' Answer questions from other users |
Encyclopedia
The Common Object Requesting Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together.
Overview
CORBA is a mechanism in software for normalizing the method-call semantics between application objects that reside either in the same address space (application) or remote address space (same host, or remote host on a network). Version 1.0 was released in October 1991.
CORBA uses an interface definition language (IDL) to specify the interfaces that objects will present to the outside world. CORBA then specifies a “mapping” from IDL to a specific implementation language like C++ or Java. Standard mappings exist for Ada, C, C++, Lisp, Ruby, Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Erlang, and Tcl implemented by object request brokers (ORBs) written for those languages.
The CORBA specification dictates that there shall be an ORB through which the application interacts with other objects. In practice, the application simply initializes the ORB, and accesses an internal Object Adapter which maintains such issues as reference counting, object (& reference) instantiation policies, object lifetime policies, etc. The Object Adapter is used to register instances of the generated code classes. Generated Code Classes are the result of compiling the user IDL code which translates the high-level interface definition into an OS- and language-specific class base for use by the user application. This step is necessary in order to enforce the CORBA semantics and provide a clean user process for interfacing with the CORBA infrastructure.
Some IDL language mappings are "more hostile" than others. For example, due to the very nature of Java, the IDL-Java Mapping is rather straightforward and makes usage of CORBA very simple in a Java application. The C++ mapping is not "trivial" but accounts for all the features of CORBA, e.g. exception handling. The C-mapping is even stranger (since it's not an Object Oriented language) but it does make sense and handles the RPC semantics just fine. (Red Hat Linux delivers with the GNOME UI system, which used to have its IPC built on CORBA, now replaced by DBus)
A "language mapping" requires the developer ("user" in this case) to create some IDL code that represents the interfaces to his objects. Typically, a CORBA implementation comes with a tool called an IDL compiler which converts the user's IDL code into some language-specific generated code. A traditional compiler then compiles the generated code to create the linkable-object files for the application. This diagram illustrates how the generated code is used within the CORBA infrastructure:
This figure illustrates the high-level paradigm for remote interprocess communications using CORBA. Issues not addressed here, but that are accounted-for in the CORBA specification include: data typing, exceptions, network protocol, communication timeouts, etc. For example: Normally the server side has the Portable Object Adapter (POA) that redirects calls either to the local servants or (to balance the load) to the other servers. Also, both server and client parts often have interceptors that are described below. Issues CORBA (and thus this figure) does not address, but that all distributed systems must address: object lifetimes, redundancy/fail-over, naming semantics (beyond a simple name), memory management, dynamic load balancing, separation of model between display/data/control semantics, etc.
In addition to providing users with a language and a platform-neutral remote procedure call specification, CORBA defines commonly needed services such as transactions and security, events, time, and other domain-specific interface models.
OMG trademarks
CORBA, IIOP and OMG are the registered marks of the Object Management Group and should be used with care. However, GIOP is not a registered OMG trademark. Hence in some cases it may be more appropriate just to say that the application uses or implements the GIOP-based architecture.
CORBA Topics
Objects By Reference
This reference is either acquired through a stringified URI string, NameService lookup (similar to DNS), or passed-in as a method parameter during a call.
Object references are lightweight objects matching the interface of the real object (remote or local). Method calls on the reference result in subsequent calls to the ORB and blocking on the thread while waiting for a reply, success or failure. The parameters, return data (if any), and exception data are marshaled internally by the ORB according the local language/OS mapping.
Data By Value
The CORBA Interface Definition Language provides the language/OS-neutral inter-object communication definition. CORBA Objects are passed by reference, while data (integers, doubles, structs, enums, etc) are passed by value. The combination of Objects by reference and data-by-value provides the means to enforce strong data typing while compiling clients and servers, yet preserve the flexibility inherent in the CORBA problem-space.
Objects by Value (OBV)
Apart from remote objects, the CORBA and RMI-IIOP define the concept of the OBV. The code inside the methods of these objects is executed locally by default. If the OBV has been received from the remote side, the needed code must be either a priori known for both sides or dynamically downloaded from the sender. To make this possible, the record, defining OBV, contains the Code Base that is a space separated list of URLs from where this code should be downloaded. The OBV can also have the remote methods.
The OBV's may have fields that are transferred when the OBV is transferred. These fields can be OBV's themselves, forming lists, trees or arbitrary graphs. The OBV's have a class hierarchy, including multiple inheritance and abstract classes.
CORBA Component Model (CCM)
CORBA Component Model (CCM) is an addition to the family of CORBA definitions. It was introduced with CORBA 3 and it describes a standard application framework for CORBA components. Though not dependent on "language independent Enterprise Java Beans (EJB)", it is a more general form of EJB, providing 4 component types instead of the 2 that EJB defines. It provides an abstraction of entities that can provide and accept services through well-defined named interfaces called ports.
The CCM has a component container, where software components can be deployed. The container offers a set of services that the components can use. These services include (but are not limited to) notification, authentication, persistence and transaction management. These are the most-used services any distributed system requires, and, by moving the implementation of these services from the software components to the component container, the complexity of the components is dramatically reduced.
Portable interceptors
Portable interceptors are the "hooks", used by CORBA and RMI-IIOP to mediate the most important functions of the CORBA system. The CORBA standard defines the following types of interceptors:
- IOR interceptors mediate the creation of the new references to the remote objects, presented by the current server.
- Client interceptors usually mediate the remote method calls on the client (caller) side. If the object Servant exists on the same server where the method is invoked, they also mediate the local calls.
- Server interceptors mediate the handling of the remote method calls on the server (handler) side.
The interceptors can attach the specific information to the messages being sent and IORs being created. This information can be later read by the corresponding interceptor on the remote side. Interceptors can also throw forwarding exceptions, redirecting request to another target.
General InterORB Protocol (GIOP)
The GIOP is an abstract protocol by which Object request brokers (ORBs) communicate. Standards associated with the protocol are maintained by the Object Management Group (OMG.).
The GIOP architecture provides several concrete protocols:
- Internet InterORB Protocol (IIOP) — The Internet Inter-Orb Protocol is an implementation of the GIOP for use over an internet, and provides a mapping between GIOP messages and the TCP/IP layer.
- SSL InterORB Protocol (SSLIOP) — SSLIOP is IIOP over SSL, providing encryption and authentication.
- HyperText InterORB Protocol (HTIOP) — HTIOP is IIOP over HTTP, providing transparent proxy bypassing.
- and many more...
Data Distribution Service (DDS)
The Object Management Group (OMG) has a related standard known as the Data Distribution Service (DDS) standard. DDS is a publish-subscribe data distribution model, in contrast to the CORBA remotely-invoked object model.
VMCID (Vendor Minor Codeset ID)
Each standard CORBA exception includes a minor code to designate the subcategory of the
exception. Minor exception codes are of type unsigned long and consist of a 20-bit “Vendor
Minor Codeset ID” (VMCID), which occupies the high order 20 bits, and the minor
code which occupies the low order 12 bits.
Minor codes for the standard exceptions are prefaced by the VMCID assigned to OMG,
defined as the unsigned long constant CORBAOMGVMCID, which has the VMCID
allocated to OMG occupying the high order 20 bits. The minor exception codes
associated with the standard exceptions that are found in Table 3-13 on page 3-58 are
or-ed with OMGVMCID to get the minor code value that is returned in the ex_body
structure (see Section 3.17.1, “Standard Exception Definitions,” on page 3-52 and
Section 3.17.2, “Standard Minor Exception Codes,” on page 3-58).
Within a vendor assigned space, the assignment of values to minor codes is left to the
vendor. Vendors may request allocation of VMCIDs by sending email to tagrequest@omg.org.
The VMCID 0 and 0xfffff are reserved for experimental use. The VMCID OMGVMCID
(Section 3.17.1, “Standard Exception Definitions,” on page 3-52) and 1 through 0xf are
reserved for OMG use.
Corba Location (CorbaLoc)
Corba Location (CorbaLoc) refers to a stringified object reference for a CORBA object that looks similar to a URL.
All CORBA products must support two OMG-defined URLs: "corbaloc:" and "corbaname:". The purpose of these is to provide a human readable/editable way to specify a location where an IOR can be obtained.
An example of corbaloc is shown below:
- corbaloc160.45.110.41:38693/StandardNS/NameServer-POA/_root
A CORBA product may optionally support the "http:", "ftp:" and "file:" formats. The semantics of these is that they provide details of how to download a stringified IOR (or, recursively, download another URL that will eventually provide a stringified IOR). Some ORBs do deliver additional formats which are proprietary for that ORB.
Benefits
CORBA brings to the table many benefits that no other single technology brings in one package. These benefits include language- and OS-independence, freedom from technology-linked implementations, strong data-typing, high level of tunability, and freedom from the details of distributed data transfers.
Language Independence
- CORBA at the outset was designed to free engineers from the hang-ups and limitations of considering their designs based on a particular software language. Currently there are many languages supported by various CORBA providers, the most popular are Java and C++. There are also C-only, SmallTalk, Perl, Ada, Ruby, and Python implementations, just to mention a few.
OS Independence
- CORBA's design is meant to be OS-independent. CORBA is available in Java (OS-independent), as well as natively for Linux/Unix, Windows, Sun, Mac and others.
Freedom from Technologies
- One of the main implicit benefits is that CORBA provides a neutral playing field for engineers to be able to normalize the interfaces between various new and legacy systems. When integrating C/C++, Object Pascal, Java, Fortran, Python, and any other language/OS into a single cohesive system design model, CORBA provides the means to level the field and allow disparate teams to develop systems and unit tests that can later be joined together into a whole system. This does not rule out the need for basic system engineering decisions, such as threading, timing, object lifetime, etc. These issues are part of any system regardless of technology. CORBA allows system elements to be normalized into a single cohesive system model.
- For example, the design of a Multitier architecture is made simple using Java Servlets in the web server and various e time, C++ legacy code can talk to C/Fortran legacy code and Java database code, and can provide data to a web interface.
Strong Data Typing
- CORBA provides flexible data typing, for example an "ANY" datatype. CORBA also enforces tightly coupled datatyping, reducing human errors. In a situation where Name-Value pairs are passed around, it's conceivable that a server provides a number where a string was expected. CORBA Interface Definition Language provides the mechanism to ensure that user-code conforms to method-names, return-, parameter-types, and exceptions.
High Tune-ability
- There are many implementations available (e.g. (Open source C++ and Python implementation)) that have many options for tuning the threading and connection management features. Not all implementations provide the same features. This is up to the implementor.
Freedom From Data Transfer Details
- When handling low-level connection and threading, CORBA provides a high-level of detail in error conditions. This is defined in the CORBA-defined standard exception set and the implementation-specific extended exception set. Through the exceptions, the application can determine if a call failed for reasons such as "Small problem, so try again", "The server is dead" or "The reference doesn't make sense." The general rule is: Not receiving an exception means that the method call completed successfully. This is a very powerful design feature.
Compression
- CORBA marshals its data in a binary form and supports compression. IONA/Remedy IT/Telefonica have worked on an extension to the CORBA standard that delivers compression. This extension is called ZIOP and this is now recommended for adaption.
Problems and criticism
While CORBA promised to deliver much in the way code was written and software constructed, it was much criticized during its history.
Some of its failures were due to the implementations and the process by which CORBA was created as a standard, others reflect problems in the politics and business of implementing a software standard. These problems led to a significant decline in CORBA use and adoption in new projects and areas. The technology is slowly being replaced by Java-centric technologies.
Location transparency
- CORBA's notion of location transparency has been criticized; that is, that objects residing in the same address space and accessible with a simple function call are treated the same as objects residing elsewhere (different processes on the same machine, or different machines). This notion is flawed if one requires all local accesses to be as complicated as the most complex remote scenario. However, CORBA does not place a restriction on the complexity of the calls. Many implementations provide for recursive thread/connection semantics. I.e. Obj A calls Obj B, which in turn calls Obj A back, before returning.
Design and process deficiencies
- The creation of the CORBA standard is also often cited for its process of design by committee. There was no process to arbitrate between conflicting proposals or to decide on the hierarchy of problems to tackle. Thus the standard was created by taking a union of the features in all proposals with no regard to their coherence. This made the specification very complex, prohibitively expensive to implement entirely and often ambiguous.
- A design committee composed largely of vendors of the standard implementation, created a disincentive to make a comprehensive standard. This was because standards and interoperability increased competition and eased customers' movement between alternative implementations. This led to much political fighting within the committee, and frequent releases of revisions of the CORBA standard that were impossible to use without proprietary extensions.
Problems with implementations
- Through its history, CORBA was plagued by shortcomings of its implementations. Often there were few implementations matching all of the critical elements of the specification, and existing implementations were incomplete or inadequate. As there were no requirements to provide a reference implementation, members were free to propose features which were never tested for usefulness or implementability. Implementations were further hindered by the general tendency of the standard to be verbose, and the common practice of compromising by adopting the sum of all submitted proposals, which often created APIs that were incoherent and difficult to use, even if the individual proposals were perfectly reasonable.
- Working implementations of CORBA have been very difficult to acquire in the past, but are now much easier to find. The SUN Java SDK comes with CORBA already. Some poorly designed implementations have been found to be complex, slow, incompatible and incomplete. Commercial versions can be very expensive. This changed significantly as commercial-, hobbyist-, and government-funded high quality free implementations became available.
Firewalls
- CORBA (more precisely, IIOP) uses raw TCP/IP connections in order to transmit data. However, if the client is behind a very restrictive firewall/transparent proxy server environment that only allows HTTP connections to the outside through port 80, communication may be impossible, unless the proxy server in question allows the HTTP CONNECT method or SOCKS connections as well. At one time, it was difficult even to force implementations to use a single standard port — they tended to pick multiple random ports instead. As of today, current ORBs do have these deficiencies. Due to such difficulties, some users have made increasing use of web services instead of CORBA. These communicate using XML/SOAP via port 80, which is normally left open or filtered through a HTTP proxy inside the organization, for web browsing via HTTP. Recent CORBA implementations, though, support SSL and can be easily configured to work on a single port. Most of the popular open source ORBS, such as TAO and JacORB also support bidirectional GIOP, which gives CORBA the advantage of being able to use callback communication rather than the polling approach characteristic of web service implementations. Also, more CORBA-friendly firewalls are now commercially available.
See also
Further reading
- .
- Robert Orfali: The Essential Client/Server Survival Guide, John Wiley & Sons, ISBN 0-471-15325-7
- Robert Orfali, Dan Harkey, Jeri Edwards: The Essential Distributed Objects Survival Guide, John Wiley & Sons, ISBN 0-471-12993-3
- Robert Orfali, Dan Harkey: Client/Server Programming with JAVA and CORBA, John Wiley & Sons, ISBN 0-471-24578-X
- Dirk Slama, Jason Garbis, Perry Russell: Enterprise CORBA, Prentice Hall, ISBN 0-13-083963-9
- Michi Henning, Steve Vinoski: Advanced CORBA Programming with C++, Addison-Wesley, ISBN 0-201-37927-9
- Axel Korthaus, Martin Schader, Markus Aleksy: , Springer, ISBN 3-540-24173-6
- Fintan Bolton: Pure Corba, Sams Publishing, ISBN 0-672-31812-1
- Jon Siegel: CORBA 3 - Fundamentals and Programming, John Wiley & Sons, ISBN 0-471-29518-3
- Ron Zahavi: Enterprise Application Integration with CORBA: Component and Web-Based Solutions, John Wiley & Sons, ISBN 0-471-32720-4
- Bret Hartman, Konstantin Beznosov, Steve Vinoski, Donald Flinn: Enterprise Security with EJB and CORBA, John Wiley & Sons, ISBN 0-471-40131-5
- Thomas J. Mowbray, Ron Zahavi: The Essential Corba: System Integration Using Distributed Objects, John Wiley & Sons, ISBN 0-471-10611-9
- Michael Rosen, David Curtis: Integrating CORBA and COM Applications, John Wiley & Sons, ISBN 0-471-19827-7
- Gerald Brose, Andreas Vogel, Keith Duddy: Java Programming with CORBA, John Wiley & Sons, ISBN 0-471-37681-7
- John Schettino, Robin S. Hohman, Liz O'Hara: CORBA For Dummies, Hungry Minds, ISBN 0-7645-0308-1
- Jeremy L. Rosenberger: Teach Yourself CORBA in 14 Days, Sams Publishing, ISBN 0-672-31208-5
- Jon Siegel: Quick CORBA 3, John Wiley & Sons, ISBN 0-471-38935-8
- Thomas J. Mowbray, Raphael C. Malveau: CORBA Design Patterns, John Wiley & Sons, ISBN 0-471-15882-8
- Robert Orfali, Dan Harkey, Jeri Edwards: Instant CORBA, John Wiley & Sons, ISBN 0-471-18333-4
- Paul Harmon, William Morrissey: The Object Technology Casebook, John Wiley & Sons, ISBN 0-471-14717-6
- Michi Henning: , in: ACM Queue, Volume 4, Issue 5 (June 2006).
External links
|
| |
|
|
