Common Object Request Broker Architecture: Difference between revisions

Revision as of 05:44, 28 July 2025

Latest revision as of 06:58, 28 July 2025

(4 intermediate revisions by one other user not shown)

Line 3:

{{More footnotes needed|date=February 2009}}

{{how-to|date=April 2023}}

{{full citations needed|date=July 2025}}

}}

{{Use dmy dates|date=December 2019}}

Line 182 ⟶ 183:

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===

; 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===

; 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===

; 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 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.<br> For example, the design of a [[multitier architecture]] is made simple using [[Java Servlet]]s 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===

; Data-typing: CORBA provides flexible data typing, for example an "ANY" datatype. CORBA also enforces tightly coupled data typing, 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===

; High tunability: Many implementations (e.g. ORBexpress (Ada, C++, and Java implementation)<ref>{{cite web |title=ORBexpress: An Overview |url=https://www.ois.com/index.php/communications-middleware/}}</ref> and OmniORB (open source C++ and Python implementation))<ref>{{cite web |title=omniORB: Free CORBA ORB |url=https://omniorb.sourceforge.io/ |access-date=10 October 2024}}</ref> have options for tuning the threading and connection management features. Not all ORB implementations provide the same features.

===Freedom from data-transfer details===

; 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===

; Compression: CORBA marshals its data in a binary form and supports compression. IONA, Remedy IT, and [[Telefonica|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==

Line 205 ⟶ 213:

===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,<ref>{{cite journal |last=Waldo |first=Jim |author2=Geoff Wyant |author3=Ann Wollrath |author4=Sam Kendall |title=A Note on Distributed Computing |journal=Sun Microsystem Laboratories |date=November 1994 |url=https://sites.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/smli_tr-94-29.pdf |access-date=10 October 2024 |url-status=live |archive-url=https://ghostarchive.org/archive/20221010/http://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/smli_tr-94-29.pdf |archive-date=2022-10-10}}</ref>{{Failed verification|date=November 2017}} 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 {{val|1&nbsp;[[|ul=μs]]}} latency and guaranteed return will be used very differently from a call with {{val|1&nbsp;|u=s}} latency with possible transport failure, in which the delivery status is potentially unknown and might take {{val|30&nbsp;|u=s}} to time out).

===Design and process deficiencies===

Line 225 ⟶ 233:

==See also==

{{Too many see alsos|date=July 2025}}

===Software engineering===

* {{annotated link|Component-based software engineering}}

Line 255 ⟶ 263:

* {{annotated link|SOAP}}

* {{annotated link|Internet Communications Engine}}

===Language bindings===

Line 269 ⟶ 276:

==References==

* {{cite web |title=CORBA |work=Current |series=Specification |publisher=[[Object Management Group|OMG]] |url=https://www.omg.org/spec/CORBA/}}

{{Reflist}}

==Further reading==

* {{cite web |title=CORBA |work=Current |series=Specification |publisher=[[Object Management Group|OMG]] |url=https://www.omg.org/spec/CORBA/}}

* {{cite book |last=Bolton |first=Fintan |title=Pure Corba |year=2001 |publisher=Sams Publishing |isbn=0-672-31812-1 |url=https://archive.org/details/purecorba00fint |url-access=registration}}

* {{cite book |last1=Brose |first1=Gerald |last2=Vogel |first2=Andreas |last3=Duddy |first3=Keith |title=Java Programming with CORBA |date=25 January 2001 |publisher=John Wiley & Sons |isbn=0-471-37681-7}}