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
