|
A CORBA product may optionally support the "{{mono|http:}}", "{{mono|ftp:}}" and "{{mono|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.
== 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 |archive-url=https://web.archive.org/web/20121203074323/http://www.davidchappell.com/articles/article_Trouble_CORBA.html |archive-date=3 December 2012 |title=Trouble with CORBA |last=Chappel |first=David |date=May 1998 |access-date=15 March 2010 |publisher=davidchappel.com}}</ref>
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,<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|access-date=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}}
;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,<ref name="ACM_fall">{{cite journal |first=Michi |last=Henning |url=http://queue.acm.org/detail.cfm?id=1142044 |title=The Rise and Fall of CORBA |publisher=[[Association for Computing Machinery]] |journal=[[ACM Queue]] |volume=4 |issue=5 |date=30 June 2006 |access-date=15 March 2010}}</ref> 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|date=February 2007}}
: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, [[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 – 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 [[Secure Sockets Layer|SSL]] and can be easily configured to work on a single port. Some ORBS, such as [[TAO (software)|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 ==
| 