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

[XML-SIG] WSDL library ?


> > So can HTTP and SMTP, using extension headers.
>> 
>> You don't like the invention of SOAP but you accept an invention of new
>> HTTP headers? :)    (01)

I don't have a problem with the invention of SOAP.  Just that I think SOAP is 
too big and hariry an invention for just this small purpose.    (02)


> >  BEEP doesn't even need extensions, I think.
>> 
>> Beep solves different problems, it's HTTP-NG, really; a plea in the
>> night that we avoid crappy substrates like HTTP.    (03)

Of course.  But my argument is that no more is needed.  We can use good old 
GIOP with CDR, XDR or other established RPC systems when we need RPC, and save 
BEEP for the rich messaging payloads that I think is SOAP's only legitimate 
niche.    (04)


> > >       - SOAP with Attachments
>> > 
>> > I thought you were listing reasons for liking SOAP.  I'm unable to interpret
>> > this as such.
>> 
>> id/ref and the CID scheme; perhaps more accurate: "it makes SwA
>> possible."
>> 
>> > >       - Ability to send XML
>> > 
>> > 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.
>> 
>> XML embedded in XML is a general XML problem.  You can't send XML in
>> XML-RPC unless you stringify it.  If I've already got a message decoder,
>> why force the price of re-encapsulation.    (05)

Agreed, but then hopw is SOAP better than XML-RPC for the purpose?  You need 
to escape/encode in either case.    (06)


> > And anyway, why can't anything else send XML?
>> 
>> See above.
>> 
>> > 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.
>> 
>> And since Corba doesn't have pointers, that person would be wrong.    (07)

SOAP doesn't have pointers either.  It has a hack where you can state a value 
once and give it an arbitrary ID, and then use that ID elsewhere.  There is no 
guarantee that this represents any reliable state on the server side, so it's 
not a pointer, but a gimmick.    (08)


> > 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?
>> 
>> Ahh, that's a different question.  Are there equivalent tools? 
>> Certainly. Is that really the key problem?  It seems like your position
>> is:
>> 	If it's simple use XML-RPC; if it's not, use Corba
>> Is that fair?  If so, then what about all those DCOM and pure-RPC and
>> java-RMI folks?    (09)

Mostly politics.  The only thing complex about CORBA, properly implemented, is 
setting up the ORB package.  XML-RPC does save this, since so many languages 
come with XML-RPC libs built in.    (010)

Therefore, I like the formula you suggest    (011)

"If it's simple use XML-RPC; if it's not, use Corba"    (012)


> > And why can't you send hrefs using any other mechanism?
>> 
>> Sure, if you can define a datatype that is "aliasable."  But I was
>> trying to show what I liked about SOAP that wasn't in other things, not
>> what I liked that could be created elsewhere.    (013)

I have no idea what you mean with all this about pointers and aliases.  Can 
you just give an example?  Pick any real-world scenario.  Show me how CORBA 
cannot do what SOAP can with regard to this pointers/aliases magic.    (014)


> > >       - reasonable size to implement
>> > 
>> > Having looked really closely at ZSI, SOAP.py, SOAPy, and our own coupel of
>> > attempts to implement, I am astounded at this claim.
>> 
>> I guess we come at it from different viewpoints.  I wrote a C++ BER
>> library for LDAP; it took 2000 lines.  A full DER package such as
>> openssl's ASN1 module is 18K lines. The core SOAP part of ZSI (TC*.py,
>> parse.py, writer.py) is 2K lines.  DCE RPC was like 25K lines.
>> 
>> > * SOAP interoperability is a myth, as I can painfully attest
>> 
>> Disagree, as I can attest. :)  Come join us in the soapbuilders mailing
>> list (at yahoogroups).    (015)

I'd rather be pull off my toenails one by one and eat them.  :-)    (016)

If you have to join a mailing list to see SOAP interop, it's just as bad as I 
think.  I just downloaded tools, followed instructions, and watched everything 
fail.  This is using well-published and trivial Web services listed at 
XMethods.    (017)

Not to point fingers, but the very first Web service I tried with ZSI failed 
to work with a Delphi-based service: the silly Captain Haddick thingie.    (018)

Sad, I'd say.  I've had immeasurably more luck with CORBA, without having to 
join mailing lists.    (019)


> > Funny thing is that Clay Shirky makes a completely different set of points from my own, and still manages to roast WS quite handily
>> 
>> Yes, I quite enjoy Clay's writing.  SOAP != web services.
>> 
>> And IIOP is a crappy protocol that only came into existence because Sun
>> said DCE protocol over my dead body and IBM, fearing DCOM, caved in.  If
>> it were so great, RMI would've gone along quietly. :)    (020)

The best thing about the Internet is that everyone has a raw, pulsating 
opinion, eh?    (021)

Cheers.    (022)


-- 
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    (023)