aspose file tools*
The moose likes Web Services and the fly likes Why Web Services ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "Why Web Services ?" Watch "Why Web Services ?" New topic
Author

Why Web Services ?

Javed Sardar
Ranch Hand

Joined: Sep 10, 2002
Posts: 33
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

Joined: Jul 13, 2001
Posts: 3150
Two good links to explain this
http://www2002.org/CDROM/alternate/395/
http://www.xs4all.nl/~irmen/comp/CORBA%20vs%20SOAP.html


Spritle Software Blogs
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16145
    
  21

... 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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Javed Sardar
Ranch Hand

Joined: Sep 10, 2002
Posts: 33
Thanks you very much guys.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
M.K.A. Monster
Ranch Hand

Joined: May 02, 2002
Posts: 130
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

Joined: Feb 26, 2003
Posts: 5
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why Web Services ?