webservices vs CORBA

[Pradeep bhatt]

Hi,
I find that WS is similar to CORBA. Since CORBA has not had much success what abt WS? What does WS offer that is not found in CORBA?
[ December 02, 2003: Message edited by: Pradeep Bhat ]

[somkiat puisungnoen]

I think web service communicate with text message (SOAP , XML Protocol) that can used in all technologies or all language are support web service (Microsoft, Java, Borland) but CORBA is used only in Java, Borland .... not Microsoft (use DCOM). And CORBA is used in intranet (not internet).
I think, Web Service is more flexible than CORBA.

[Lasse Koskela]

Well, if you've ever used CORBA, you'll know that it's pure hell. Furthermore, the whole CORBA scene got standardized too late -- everyone had already burnt their fingers with products following their own flavours of "the standard"...
There's really not that many logical reasons for why CORBA failed. The fact that web services have started with a strong focus on interoperability and standards compliance is probably the best indicator that web services has a chance to achieve what OMG and others failed to achieve with CORBA.

[Lasse Koskela]

Yep. I forgot the firewall-issue... It's absolutely true that CORBA was considered difficult also because the client and server couldn't (in most cases) have a firewall in between. Web services use mostly HTTP which goes flying through the firewalls... Still, the same could've been accomplished with CORBA if only the network administrators would've agreed to open some ports

[Pradeep bhatt]

Still, the same could've been accomplished with CORBA if only the network administrators would've agreed to open some ports

So why didn't they agree on that?

[Matt R. Hansen]

Excellent technologies commonly fail due to the inability of the end user to change how they currently do things. Not many people are interested in trying something new if they have to sit down and think about how it will work. This is one of the reasons that Microsoft has been successful. They try to make things as easy for their users as possible. In my never to be humble opinion, we as programmers should focus a lot more on simplifying what code we expose to other programmers. This is another area where CORBA failed. Configurability is nice (I prefer it), but it isn't what most people want.

[Juan Rolando Prieur-Reza]

I am eager to see if these historical issues are identified among the problems covered in the "Web Services Patterns: Java Edition" by Paul B. Monday.

[Unnsse Khan]

The Department of Defense uses CORBA, and the protocol behind every EJB container is RMI/IIOP, which means that CORBA is now done behind the scenes -invisibly. In M$ world, its known as DCOM / COM+. CORBA is so people can write network software using different languages... Web Services is totally different and has a different purpose...

[Pradeep bhatt]

Web Services is totally different and has a different purpose...

ok..please explain
Webservices is called as Service Oriented Architecture and Can't CORBA be called for SOA as well?
[ December 03, 2003: Message edited by: Pradeep Bhat ]

[hande]

Web services and CORBA looks similar in functionalities. But there is a lot of difference in the implementation
Refer this link for more information.
http://www2002.org/CDROM/alternate/395/

[Lasse Koskela]

"hande",
Congratulations on your first post on the 'ranch. However, you'll need to add a last name into your display name in order to comply with our naming policy.
Thanks.

[Pradeep bhatt]

Is webservices more slower that CORBA because it use XML and HTTP and binary protocol?

[Unnsse Khan]

See, I don't know much about this (to be perfectly honest) but from the best of my knowledge here what I do know:
1. CORBA is basically used to write network software using an ORB. Through an interface called the IDL, one can write code in a language independent manner, such as C++ & Java. Its lies in the realm of distributing computing and the ability to do remote procedure calls (RPCs) is inherent because of the RMI/IIOP protocol that it runs in.
2. Web Services are a similar concept in that its a new form of distributed technology but it is not constrained to network software. SOAP (Simple Object Access Protocol) is simple, not as complex as CORBA and is just a better way for doing RPCs (Remote Procedure Calls)...
Can anyone please help me clarify if I am write or wrong?

[Stan James]

I often call web services (defined (by me) as XML over HTTP, maybe SOAP) the lowest common denominator. Common is important, because nearly any language, OS or framework can do character mode XML over HTTP. Lowest is also important because XML makes for relatively fat payloads and expensive string handling in parsing and building messages and HTTP is not the first choice for fast commnication. I think the unmatched ease and interoperability will win over the performance challenges, tho. The concept is here to stay, fer sure.

[Amer Khan]

Although CORBA,RMI,DCOM work very well in an intranet environment but as already mentioned by Lasse attempting to use these technologies over the Internet present the problem of Firewalls which often block access to the required TCP/IP ports, and also because they are proprietary formats both the client and the server must be running compatible software. Web services operate using the same ports in the firewall allowing server applications to be securely protected while still exposing business functionality via web services. Another plus with WS is the increased ability to distribute systems without relying on a single technology like DCOM,RMI,CORBA because any WS can interact with ,and be used from any technology solution.
I think what makes web services so revolutionary and such a change from previous models is the application of true internet standards.
[ December 03, 2003: Message edited by: Amer Khan ]

[Paul Monday]

No, I didn't cover historical issues in my book <shamelessplug>Web Service Patterns: Java Edition</shamelessplug>
One of my first projects at IBM was to help port the System Object Model (SOM) to OS/400 (I did the Interface Repository port if you're curious). After SOM/400, I went on the the SanFrancisco Project. If you don't remember SOM (did you ever have OS/2 Warp?), it was a CORBA implementation. There are some interesting reasons why, I think, SOM, CORBA, SanFrancisco, and some other technologies do NOT hit the "big time" like Web Services appear to be doing.
I feel like CORBA is complex "out of the box" whereas individuals can start with "basic" Web Services very quickly (you can download Axis, write a "HelloWorld.java" class and be running it as a Web Service in a few minutes). I remember fighting with emitters, multiple inheritance, and so many nuances (especially pointers) with CORBA that it became difficult to deal with.
I also remember the early days of CORBA...it was always amusing that around CORBA 1.0 you could use emitters to generate C or C interfaces.
Once you fall into the "chasm" (as CORBA did and, probably, SanFrancisco and SOM), it is extremely difficult to dig yourself out. Perhaps CORBA is better today than it was...but there were too many horror stories too quickly and Java was able to come in very quickly and disrupt many of the lofty goals of CORBA, and then the quick right hook of XML, and then Web Services and CORBA turns into a niche (albeit important) enterprise solution.
Now, think about CORBA being designed for the enterprise out of the box. I'm always curious if Web Services has an upcoming challenge where its architecture collapses under the weight of some of the things CORBA planned for up front. On the other hand, the beauty of Web Services are really in their simplicity ("Simple" wire protocol and three architectural components (directory, service, client).
Just some pondering to add to the thread :-)

[Pradeep bhatt]

Paul.
The article says that Web Services are not distributed components
http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html

[Paul Monday]

That's a quick way to answer the question :-)
No, Web Services are not "components", they are services. I do feel that a service takes on many of the same characteristics of components though...especially in the theories on interface designs. In fact, services are closer to components than they are to objects (IMHO).