CORBA VS Webservices

Question

Why WebServices took advantage over CORBA ?

Artillery

Googling "CORBA vs web services" brings up a whole bunch of useful results. – Killerdiller

Answer 1

While initially CORBA may have been thought to provide what web services provide today, I think I agree that it seems that for this application CORBA has "lost".

However, as an RPC technology that is supported on a wide array of platforms (embedded), works and is tested well from native (C++), and can be used to implement pretty performant data transfer scenarios, I do think that CORBA still has an important niche. It's just got nothing to to with "the web".

To directly refer to the question: I like to think that CORBA "lost" because, unlike WebServices, it is not targeted at The Web as it is used today -- As in: Tunneling everything through port 80, running apps 60% in the browser and 40% in a webserver, etc.

Goforth

Answer 2

I suspect everything started from the firewall issues: CORBA requests are binary, multiple random ports are required for the normal work so CORBA requests and responses used to be blocked by firewalls when these first appeared. HTTP and FTP also use phantom ports, but these protocols were in much more wider use so immediately was obvious that firewalls must be configured to allow them. As a result, developers cannot rely on possibility to have CORBA connection between the server and end user PC and need to use some more firewall friendly approach.

Firewalls appear much less an issue in communication between the specialized servers than can use separate networks, IP/MAC filtering, specialized firewalls and the like. I think CORBA, same as JDBC, are still used to communicate data between servers.

It may also be a factor that CORBA messages use aligned fields (to match boundary alignments as they are used in C/C++ data structures). Derived protocols (like Google Protocol buffers) do not send unnecessary bytes just for alignment. Hence they messages are compact and these protocols may be preferred when binary messages and fast pre-generated message parsers are desired. Protocol buffers that appear for me rather similar to CORBA by design (IDL-like compiler, stubs and servants, binary messages, language interoperability) is really far from decline, being internally used in many Google services.

While CORBA framework is complex, a "properly done" web service stack is also not exactly trivial, so I do not think that the complexity of the standard has been an issue. Similarly, while the original OMG specification documents may appear horrible, the similar SOAP/WDSL specifications are equally complex, probably it is difficult to document a standard in an easy to read way.

CORBA protocols are not proprietary, they have been implemented in Free software many times, including JacORB and also GNU/Classpath implementations (well, now OpenJDK is also Free).

Nestornestorian

Answer 3

I don't think it's a stretch to say that web services have won out in the marketplace. CORBA is a niche at best, and a small one at that.

Web services:

• Simpler, although WS-* can add weight and complexity
• Use HTTP as wire protocol instead of proprietary
• Can tunnel through port 80 in firewall
• Services aren't as complete

CORBA:

• Requires ORB to operate
• Proprietary vendors or open source
• May use HTTP, but also use proprietary protocols
• Provide services like naming, directory, transaction, security, etc.

Delaryd

I don't think it's an either/or decision between the two. I think the OP could benefit from looking at a lot of different middleware options, including but not limited to REST, AMQP and the many proprietary technologies out there. Also "simpler" is subjective. For me, CORBA IDL can be a lot easier to deal with than XML schema, but that's just me. – Chrysalis

Are you still using CORBA, Brian? Which ORB? Agreed, easier is a subjective thing. – Delaryd

No, I'm not using CORBA anymore, but I was heavily involved in it for a good 10+ years. – Chrysalis

Answer 4

CORBA lost primarily because of two things:

1) lack of good development/testing tools or IDE-plugins 2) See (1) again

Metheglin