[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Date | Thread | Author

[XML-SIG] WSDL library ?


OK.  Quick answers because, like Paul, I don't have a lot of time to repeat 
what I've written before in this and other forums, as well as in articles.    (01)

> > Pretty scary when I'd be more comfortable pointing people to a hack like 
>> > XML-RPC than I would be pointing people to SOAP.
>> 
>> 
>> What's wrong with SOAP?  I like it because:
>> 	- Supports more than just sender-receiver; e.g., intermediates.    (02)

So can HTTP and SMTP, using extension headers.  BEEP doesn't even need 
extensions, I think.    (03)

> 	- SOAP with Attachments    (04)

I thought you were listing reasons for liking SOAP.  I'm unable to interpret 
this as such.    (05)

> 	- Ability to send XML    (06)

Anything can send XML.  And SOAP/RPC is very lexically brittle for sending XML
 has serious problems sending XML.  For instance, if the embedded XML has an 
XML decl, you have to escape things.    (07)

And anyway, why can't anything else send XML?    (08)

> 	- Richer data types    (09)

This is not an absolute statement.  A CORBA person would tell you that given 
structs, ANYs, object-by-value, etc., CORBA is every bit as rich in data types 
as SOAP/RPC.    (010)

Can you give a concrete example of a task that SOAP's data typs made more 
possible than if you'd used other RPC mechanisms?    (011)

> 	- href/id handles pointer aliasing    (012)

Only if you're delivering the entire object being pointed to anyway.  I hardly 
see what this buys you over CORBA OBV.    (013)

> 	- href allows (transparent!) refs to network data    (014)

And why can't you send hrefs using any other mechanism?    (015)

> 	- extensible architecture (header elements)    (016)

HTTP and SMTP are also extensible.  SOAP does have the advantage that 
extensions can have hierarchical structure.  This is one of the few true 
advantages I've been able to admit for SOAP.  But guess what?  BEEP has the 
same advantage.    (017)

> 	- reasonable size to implement    (018)

Having looked really closely at ZSI, SOAP.py, SOAPy, and our own coupel of 
attempts to implement, I am astounded at this claim.    (019)


> > Good riddance.
>> 
>> 
>> Why?  What do you not like about it?    (020)

* Most importantly, it has nothing whatsoever to contribute to RPC except for 
hierarchically extensible headers
* SOAP interoperability is a myth, as I can painfully attest
* It conflates transport and payload details
* SOAP data types consist of hack after hack, with the biggest hack being the 
multi-reference values you seem to like so much
* It is wicked inefficient (5-6x the network traffic, several times the 
latency and about 100 times the marshalling/unmarshalling expense when 
compared to OmniORB/Python, in my low-fidelity observation)    (021)


Funny thing is that Clay Shirky makes a completely different set of points from my own, and still manages to roast WS quite handily    (022)

http://www.xml.com/pub/a/2001/10/03/webservices.html    (023)


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management    (024)