Lecture 04: CORBA: Overview and Lessons Learned
History
- Effort started in about 1991
- Organized by the Object Management Group (OMG.org)
- Consortium of a large number of vendors
- Last Major Revision 2002
- Peak of Interest was about 1999
- Produced many specifications (30?) covering a range of topics
- I was peripherally involved at its early stages
- Many current criticisms were obvious even then
Problem Areas
- Service Proliferation
- API versus On-the-wire
- Programming language standards
- Distribution Transparency
- Synchronous versus Asynchronous
- Standardization Process
Sources
- "The Rise and Fall of CORBA", ACM Queue 4(5) - June 2006 by Michi Henning, ZeroC
- Response by Dion Picco, IONA
- "Why CORBA doesn't cut it"
- "Why CORBA still doesn't cut it"
Services
- The OMG created a large number of generic services via standardized interfaces
- Collection (sets, iterators, etc.)
- Query (over collections of objects)
- Concurrency (locking)
- Transaction (as described by Ken last Tuesday)
- Life Cycle (create, delete, copy, move objects)
- Licensing
- Events (channel oriented == multicast == RSS)
- Event Domains (collections of event channels)
- Notification (non-channel because channels didn't work out so well)
- Notification/JMS (attempt to make the notification service compatible with the Java messaging service)
- Naming (locate objects)
- Trading Object (offering and discovery of instances of services of particular types)
- Lightweight (simplified naming, events, time)
- Externalization (serialization)
- Persistence (of objects on a storage system)
- Relationships (independent linking together two or more objects)
- Properties (independent attachment of attributes to objects)
- Services (cont.)
- Security (grab bag of security issues)
- Telecom Logs (just a distributed logging service)
- Time
Problem: Service Proliferation
- Service standards were developed independently with no initial attempt at compatibility
- Service overkill
- Do we really need relationship and properties services?
- Three flavors of events?
- Never clear when to quit
- Java suffers from the same problem
Problem: API versus On-the-Wire
- API Approach
- Specify the form of the interfaces to the distribution mechanism and hide the internals
- Examples: CORBA 1.0, Java RMI
- On-the-wire (Protocol) approach
- Specify the detailed format of messages that get transmitted and the state machine of the protocol
- Examples: XML-RPC, SOAP
- API only works in a homogeneous environment (such as Java)
- CORBA 1 failure led to CORBA 2, which (grudgingly) provided a std protocol
Programming Languages
- CORBA standard specified the interfaces/embedding of CORBA into programming languages
- Laudable goal: to make programs more portable
- Big Problem: mismatches between the language and the CORBA Model (IDL). E.g.,
- Inheritance
- Type system mismatches
- Exception handling mismatches
- Transparency (more later)
Distribution Transparency
- CORBA had as a goal to make the location of objects invisible to programs
- Within same process versus distributed
- Almost impossible because of
- No shared memory (pointers)
- Latency
Partial failures
- Error handling is complex in distributed systems
- CORBA language specs became quite twisted trying to achieve this kind of transparency
- Pointer problem:
- Transparency required ability to have pointers to distributed objects on an equal footing with local objects
- Forced painful use of heavyweight pointer objects and wrappers in e.g. C++
Synchronous versussynchronous
- RPC is inherently synchronous
- Client requests and blocks
- Server replies and blocks for next request
- Partly a transparency issue
- Local procedures and remote should act the same
- But there is a desire to provide more concurrency
=> Altering the RPC semantics to be asynchronous
- CORBA started as synchronous and later added asynchrony
Standardization Process
- No Reference Implementations
- Multiple Proposals for a given service
- Merge instead of shoot-out
- No controls on who could participate
- No coordination between standards
Conclusion
- In its early years, the CORBA process was a case of Standards Out of Control
- But despite the critique, it finally works and has a reasonable size niche market
- Part of the Sun Java JDK, for example
- But it ceased being of interest to the research community five or more years ago
