SOA and CORBA compare
In a Gartner article of December 2nd 2002 title “Predicts 2003: SOA is Changing Software”, Row W. Schulte pointed out “SOA is not a new concept. Computer scientists understood its principles by the mid-1980s when distributed computing and remote procedure calls came to market. However, its use during the 1980s and 1990s was limited to leading-edge projects whose architects had the vision, discipline and money to invest in the initial stages of application development, knowing they would later reap SOA’s rewards of scalability, agility and reuse” (Schulte, 2002). This means that Service Oriented Architecture SOA like Common Object Request Broker Architecture CORBA has been in the market for years now.
However, unlike CORBA, SOA did not gain enough momentum in the 1980s and 1990s. This was because most of its supporting underlying technologies like message oriented middleware MOM, web service, Business Process Execution Language for web service BPEL4WS were still immature. Until early 2000 when the IT industry began to accept web services as the main technology for application to application data exchange, that SOA started to live to its promise of loosely coupling and better alignments with business.
One key difference between CORBA and SOA is that CORBA architecture does not have a composite application (although some architects say they can trick it out to include a composite apps) . In SOA the composite application orchestrate the Business process using a process language like BPEL4WS. This integrates the services in the SOA system in a lousely couple manner which makes SOA a very flexible architecture unlike CORBA which is tightly coupled.
| Aspect | CORBA | SOA |
| Protocol | RMI/IIOP | SOAP/HTTP |
| Data model | Object model | SOAP message |
| Client-Server coupling | Tight | Loose |
| Location transparency | Object references | URL |
| Type system | IDL | XML schemas |
| Error handling | IDL exception | SOAP fault |
| Parameter passing | by reference and value | by value |
| State | stateful | Stateless |
| Request semantics | at-most-once | defined by SOAP |
| Runtime composition | DII | UDDI/WSDL |
| Service discovery | CORBA NS, RMI registry | UDDI |
| Language support | with an IDL binding | any language |
| Firewall Traversal | work in progress | Easily, http prt80 |
Another Key advantage of SOA over CORBA is that SOA gives the capility to reuse existing legacy applications assets. In SOA legacy applications API are easily transformed to web service interfaces using the SOA Adapter pattern. Recently, companies have been calling in SOA consulting firms or independent soa consultants to help them in the migration of the legacy applications (COBOL, CICS, C++, etc ) to service assets for reuse in the SOA projects.
Below is the general architecture of CORBA and SOA
