HI, Yesterday I boought my first book of Web Services and was to understand what a web srvice is. What I understad is, a web service is used to get services form an application sitting somewhere on the network writen in a different language than the application taking the service. i.e an application written in Java running on a windows machine can make use of services written in C++ running on a Unix box. Corba also dose the same, am I right ? Then why Web Services. I aplogise if this is a baseless question, but I am confused over it
... Or, if you just want the quick summary: CORBA is a binary mechanism for remote process communication. It's fairly light weight, but is easily blocked by firewalls and other security mechanisms. SOAP is a text mechanism for remote process communication. It's heavier than CORBA, but can be transmitted via HTTP, FTP, mail, or other suitable channels, so it's less likely to run into security blocks. There are other considerations as well, but these are probably the most significant.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.
Originally posted by Tim Holloway: It's heavier than CORBA...
Well, we should keep in mind that even though the wire protocol is heavier (XML encoding explodes the message size), the needed software infrastructure for communicating with SOAP is much lighter than a CORBA compliant ORB on each side. Remember that CORBA is not just RPC, there are also a slew of services implemented by the ORB provider.
Also nice to think about is the exchangeability of WebServices. When you're using CORBA, it can happen, that CORBA stubs aren't as exchangeble between other that Java en C++ applications as they say they should be. XML Webservices are so open. It is easy to build options in for example your own programminglanguage to support webservices. The XML format is way too open to compare with CORBA I think. Regards, Mark Monster
Originally posted by M.K.A. Monster: Also nice to think about is the exchangeability of WebServices. When you're using CORBA, it can happen, that CORBA stubs aren't as exchangeble between other that Java en C++ applications as they say they should be. XML Webservices are so open. It is easy to build options in for example your own programminglanguage to support webservices. The XML format is way too open to compare with CORBA I think. Regards, Mark Monster
Agreed - Web Services started out by being seen as "CORBA using XML" and people would often compare it to other RPC technologies which went before: Java RMI, etc. But then people realised that when doing RPC, you often have to pass objects around, and although SOAP included some encoding rules for data, the object-passing and platform-neutral aspects of SOAP were difficult to reconcile. [i.e. it's easy to say "anyone can consume this message because it's XML" - but if it's a serialized Java class in the SOAP payload, good luck consuming that using .NET]. So - the thinking has shifted more to Document-based SOAP [as opposed to SOAP RPC]. This isn't so much "RPC between applications", as "email between applications". This fits nicer with the loosely-coupled and platform-neutral requirements. And it means that ancestors of SOAP maybe aren't CORBA and RMI, but are EDIFACT and ANSI/X12 [i.e. EDI data enveloping standards]. Also, the "Literal" (as opposed to encoded) style for a SOAP body suits document-based SOAP better than SOAP RPC (where objects are frequently passed and must be encoded). It's interesting to note that .NET does document/literal SOAP by default, while AXIS uses RPC/encoded as default [both can do either, but you have to tweak your code to change the SOAP style]. The story isn't as simple as "SOAP is a new way to do RPC" - it could be "SOAP is a new way to do EDI". [showing my background here - I used to work for an EDI Value-Added Network and I can see the value of XML for EDI]. Hope this helps -Mark. Mark O'Neill CTO, Vordel