See more Common Object Request Broker Architecture articles on AOD.

Powered by
TTSReader
Share this page on
Article provided by Wikipedia


Main article: "General Inter-ORB Protocol

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, including:

  1. Internet InterORB Protocol (IIOP) – The Internet Inter-Orb Protocol is an implementation of the GIOP for use over the "Internet, and provides a mapping between GIOP messages and the "TCP/IP layer.
  2. SSL InterORB Protocol (SSLIOP) – SSLIOP is IIOP over "SSL, providing "encryption and "authentication.
  3. HyperText InterORB Protocol (HTIOP) – HTIOP is IIOP over "HTTP, providing transparent proxy bypassing.
  4. Zipped IOP (ZIOP) – A zipped version of GIOP that reduces the bandwidth usage.

VMCID (Vendor Minor Codeset ID)[edit]

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 proper 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 CORBA::OMGVMCID, 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. A list of currently assigned VMCIDs can be found on the OMG website at: http://www.omg.org/cgi-bin/doc?vendor-tags

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.

The Common Object Request Broker: Architecture and Specification (CORBA 2.3)

Corba Location (CorbaLoc)[edit]

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 and editable way to specify a location where an IOR can be obtained.

An example of corbaloc is shown below:

corbaloc::160.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[edit]

CORBA's 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 was designed to free engineers from limitations of coupling their designs to a particular software language. Currently there are many languages supported by various CORBA providers, the most popular being Java and C++. There are also C++11, 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, Solaris, OS X, OpenVMS, HPUX, Android, LynxOS, VxWorks, ThreadX, INTEGRITY, 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 or 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 CORBA servers containing the business logic and wrapping the database accesses. This allows the implementations of the business logic to change, while the interface changes would need to be handled as in any other technology. For example, a database wrapped by a server can have its database schema change for the sake of improved disk usage or performance (or even whole-scale database vendor change), without affecting the external interfaces. At the same time, C++ legacy code can talk to C/Fortran legacy code and Java database code, and can provide data to a web interface.
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 is 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 tunability
Many implementations (e.g. ORBexpress (Ada, C++, and Java implementation)[3] and OmniORB (open source C++ and Python implementation))[4] have options for tuning the threading and connection management features. Not all ORB implementations provide the same features.
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 does not 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, and "Telefónica have worked on an extension to the CORBA standard that delivers compression. This extension is called ZIOP and this is now a formal OMG standard.

Problems and criticism[edit]

While CORBA delivered much in the way code was written and software constructed, it has been the subject of criticism.[5]

Much of the criticism of CORBA stems from poor implementations of the standard and not deficiencies of the standard itself. Some of the failures of the standard itself were due to the process by which the CORBA specification was created and the compromises inherent in the politics and business of writing a common standard sourced by many competing implementors.

Initial implementation incompatibilities
The initial specifications of CORBA defined only the IDL, not the on-the-wire format. This meant that source-code compatibility was the best that was available for several years. With CORBA 2 and later this issue was resolved.
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 is a fundamental design flaw,[6] as it makes all object access as complex as the most complex case (i.e., remote network call with a wide class of failures that are not possible in local calls). It also hides the inescapable differences between the two classes, making it impossible for applications to select an appropriate use strategy (that is, a call with 1"µs latency and guaranteed return will be used very differently from a call with 1s latency with possible transport failure, in which the delivery status is potentially unknown and might take 30s to time out).
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.[7] This made the specification complex, expensive to implement entirely, and often ambiguous.
A design committee composed of a mixture of implementation vendors and customers created a diverse set of interests. This diversity made difficult a cohesive standard. 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 some ORB implementors ensured were difficult to use without proprietary extensions.[5] Less ethical CORBA vendors encouraged customer lock-in and achieved strong short-term results. Over time the ORB vendors that encourage portability took over market share.
Problems with implementations
Through its history, CORBA has been plagued by shortcomings in poor ORB implementations. Unfortunately many of the papers criticizing CORBA as a standard are simply criticisms of a particularly bad CORBA ORB implementation.
CORBA is a comprehensive standard with many features. Few implementations attempt to implement all of the specifications,[7] and initial 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.["citation needed]
Robust 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 built-in. Some poorly designed implementations have been found to be complex, slow, incompatible and incomplete. Robust commercial versions began to appear but for significant cost. As good quality free implementations became available the bad commercial implementations died quickly.
Firewalls
CORBA (more precisely, "GIOP) is not tied to any particular communications transport. A specialization of GIOP is the Internet Inter-ORB Protocol or IIOP. IIOP uses raw "TCP/IP connections in order to transmit data.
If the client is behind a very restrictive firewall or "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. Some ORBS, such as "TAO, omniORB 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, most modern firewalls support GIOP & IIOP and are thus CORBA-friendly firewalls.

See also[edit]

CORBA
Software engineering
Component-based software technologies
Language bindings

References[edit]

  1. ^ "History of CORBA". "Object Management Group. Retrieved 2017-03-12. 
  2. ^ "The CORBA Component Model". "Dr. Dobb's Journal. 2004-09-01. Retrieved 2017-03-13. 
  3. ^ "ORBexpress : Real-time CORBA ORB". 
  4. ^ "omniORB : Free CORBA ORB". sourceforge.net. Retrieved 9 January 2014. 
  5. ^ a b Chappel, David (May 1998). "Trouble with CORBA". www.davidchappel.com. Archived from the original on 3 Dec 2012. Retrieved 15 March 2010. 
  6. ^ Waldo, Jim; Geoff Wyant; Ann Wollrath; Sam Kendall (November 1994). "A Note on Distributed Computing" (PDF). Sun Microsystem Laboratories. Retrieved 4 November 2013. 
  7. ^ a b Henning, Michi (30 June 2006). "The Rise and Fall of CORBA". "ACM Queue. "Association for Computing Machinery. 4 (5). Retrieved 15 March 2010. 

Further reading[edit]

External links[edit]

) )