Content deleted Content added
Bluelinking 5 books for verifiability.) #IABot (v2.1alpha3 |
|||
Line 1:
{{more footnotes|date=February 2009}}
{{Infobox standardref
| title = Common Object Request Broker Architecture
Line 16 ⟶ 17:
| website = {{URL|corba.org/}}
}}
▲{{Use dmy dates|date=July 2011}}
The '''Common Object Request Broker Architecture''' ('''CORBA''') is a [[Standardization|standard]] defined by the [[Object Management Group]] (OMG) designed to facilitate the communication of systems that are deployed on diverse platforms. CORBA enables collaboration between systems on different operating systems, [[programming language]]s, and computing hardware. CORBA uses an object-oriented model although the systems that use the CORBA do not have to be object-oriented. CORBA is an example of the [[distributed object]] paradigm.
Line 23:
CORBA enables communication between software written in different languages and running on different computers. Implementation details from specific operating systems, programming languages, and hardware platforms are all removed from the responsibility of developers who use CORBA. CORBA normalizes the method-call semantics between application objects residing either in the same address-space (application) or in remote address-spaces (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
The CORBA specification dictates there shall be an ORB through which an application would interact with other objects. This is how it is implemented in practice:
Line 45:
| title=History of CORBA
| publisher=[[Object Management Group]]
| accessdate=
| url=http://www.corba.org/history_of_corba.htm
| title=History of CORBA
| publisher=[[Object Management Group]]
| accessdate=4 June 2017
{| class="wikitable"
|-
Line 122:
| title=The CORBA Component Model
| publisher=[[Dr. Dobb's Journal]]
| date=1 September 2004
| accessdate=
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 system|notification]], [[authentication]], [[persistence (computer science)|persistence]] and [[transaction processing]]. 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.
Line 146:
===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
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,
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,
[http://www.omg.org/cgi-bin/doc?formal/98-12-01 The Common Object Request Broker: Architecture and Specification (CORBA 2.3)]
Line 185:
== Problems and criticism ==
While CORBA delivered much in the way code was written and software constructed, it has been the subject of criticism.<ref name="CORBA_trouble">{{cite web |url=http://www.davidchappell.com/articles/article_Trouble_CORBA.html |archiveurl=https://web.archive.org/web/20121203074323/http://www.davidchappell.com/articles/article_Trouble_CORBA.html |archivedate=3 December 2012 |title=Trouble with CORBA |last=Chappel |first=David |date=May 1998 |accessdate=15 March 2010 |publisher=
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.
Line 195:
: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=http://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/smli_tr-94-29.pdf|accessdate=4 November 2013}}</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 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.<ref name="ACM_fall"/> 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.<ref name="CORBA_trouble"/> 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. {{Citation needed|date=November 2017}}
Line 209:
:CORBA (more precisely, [[General Inter-ORB Protocol|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 [[Tunneling protocol|HTTP CONNECT]] method or [[SOCKS]] connections as well. At one time, it was difficult even to force implementations to use a single standard port
== See also ==
Line 219:
;Component-based software technologies
* [[Freedesktop.org]] [[D-Bus]]
* [[GNOME]] [[Bonobo (GNOME)|Bonobo]]
* [[KDE]] [[DCOP]]
* [[KDE]] [[KDE Platform#KParts|KParts]]
* [[Component Object Model]] (COM)
* [[Distributed Component Object Model|DCOM]] (Distributed COM)
* [[Common Language Infrastructure]]
* [[XPCOM]] (Cross Platform Component Object Model)
* [[IBM System Object Model]] SOM and DSOM
* [[Internet Communications Engine]] (ICE)
* [[Java remote method invocation]] (Java RMI)
Line 235:
* [[Remote procedure call]] (RPC)
* [[Windows Communication Foundation]] (WCF)
* [[Software Communications Architecture]] (SCA)
;Language bindings
| |||