Dave,
> Some new bits.
>
> I finally got to the bottom of the controversy over WSDLs and SOAP 1.1.
>
> SOAP w/o an IDL is 404 Not Found all over again.
I don't think so, no. At least not under the covers. Perhaps superficially.
> So you call a procedure and it's not there or its interface changed and your
> script fails.
That's certainly the case for RPC. But I believe the HTTP/URI equivalent
is 501 (and sometimes 405), not 404. 501 is "not implemented". It's what I
get if I do a "FOOBAR /resource.html". It means that my web server doesn't
know what the "FOOBAR" method means, the same as if I did an RPC "foobar()"
to a program that didn't have a foobar method. That's very different than
404 which means that the server knows what you're asking it to do, but that
it doesn't know about the "thing" you want to do it to.
It's another example of how the HTTP contract is stronger than a
generic "RPC" contract, because HTTP already has the methods
defined, where "just RPC" doesn't (until you define them, and get
everybody else to agree). This can't be negotiated at runtime
because no negotiation semantics are defined for any RPC protocol
that I know about. Some RPC folk like to claim that dynamic invocation
mechanisms solve this problem. They don't. All they do is allow those
in denial to pretend that the problem would be different if only the error
occured at runtime rather than compile time.
> What does an IDL do to prevent such an outage, or to help you debug an
> outage that a script error wouldn't?
Nothing. Yet another reason why HTTP is better than RPC.
> Of course in this debate I'm taking the side of linkrot. It's our friend,
> it's what makes this stuff implementable, and keeps the gorillas from
> swamping and crushing The Little Folk.
Linkrot, good.
MB
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:13:43 PDT