• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why Web Services ?

 
Javed Sardar
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Balaji Loganathan
author and deputy
Bartender
Posts: 3150
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18277
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... 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.
 
Javed Sardar
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks you very much guys.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
M.K.A. Monster
Ranch Hand
Posts: 130
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Mark O'Neill
Author
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic