Note to self; avoid using an HTTP header named “Status” in Webware, since apparently it’s reserved for holding the in-memory equivalent of the response code.
Ack.
What’s the best Python Web app framework, or should I just go back to Jython and javax.servlet?
One of the nice things about being a critic of the current approach to Web services, is that the infighting amoungst the players had a chilling effect on standardization efforts, which made my job – of keeping the W3C as free from this stuff as possible – easier. Unfortunately, today, everybody seems to have come together for the worst spec of them all; WS-Addressing is now a W3C submission.
SOAP, I liked very much, just not how people were/are using it.
WSDL, I didn’t like because of the bad practice it encouraged, but I felt that it might have a role to play.
But this monstrosity actively causes harm by not using URIs as EPRs. That part of the spec has no redeeming qualities, except that it represents an attempt on behalf of the authors to Do The Right Thing regarding addressing (i.e. standardize it). Unfortunately, those authors fail to recognize that we’ve already got a perfectly good identification spec.
Update; P.S. yes, I understand than an EPR has a mandatory wsa:Address, but that doesn’t change anything, as any identifying information in the SOAP envelope is necessarily in conflict with the HTTP Request-URI. One endpoint per message, please.
Sean highlights Reinout van Rees’s Zen moment
Awesome, another recruit!
I just want to add that I think it’s important to recognize that “getting it” requires a Zen moment. For everybody I know who came from a CORBA/DCOM-like distributed systems background, but now understands the Web, serious mental model rewiring occurred. If you haven’t had that rewiring, you don’t (yet) get the Web.
The original impetus behind XML, at least as far as I was concerned back in 1996, was a way to exchange data between programs so that a program could become a service for another program. I saw this as a very simple idea. Send me a message of type A and I’ll agree to send back messages of types B, C, or D depending on your A. If the message is a simle query, send it as a URL with a query string. In the services world, this has become XML over HTTP much more than so called “web services” with their huge and complex panoply of SOAP specs and standards.
Wow! I actually had a weblog entry written, that questioned whether Adam’s transition away from a Web services company, and towards a Web company, might have had something to do with him “seeing the light” regarding REST vs. SOA. I decided not to post it because it was pure conjecture. But it seems my gut feel was partly right. However, he also adds;
Why? Because it is easy and quick.
Which is true, but not a very satisfying answer I’d say. Why is it easy and quick? Anyhow, I’m sure Adam will have lots of time to mull that question over in his work at Google. I look forward to seeing what cool stuff he comes up with there.
Sean discovers WS-MessageDelivery which triggers him to display a level of frustration that I didn’t expect to see, but that I’m happy about. We need more integration gurus to raise their hands and ask “Hello, what the $%@! are you people doing?!”, in the hope that those building this architecture may stop to take the time to think about what they’ve created and give it the principled architectural examination it requires. Sean writes;
You started at the wrong end of the pipe. SOAP always was and always will be and API-centric worldview. That is not the future. That is the past. Re-implemented badly. Sometimes I wonder. I really do.
I disagree that SOAP requires an API-centric worldview – I battled against enormous odds to ensure SOAP 1.2 didn’t – but I certainly agree that this is how Web services proponents and specs are using the SOAP specs.
On the other hand, to their credit, Web services promoters are trying to distance themselves from APIs. The problem is that they think they’ve done this with “document oriented SOAP” by removing the operation from the message. Unfortunately though, in their architecture, the operation is still in effect, it’s just hidden from the message which actually makes things worse than RPC (in case you wondered if that was possible!).
What Web services need is an architecture based purely on document exchange, not some RPC/document bastard. Luckily, one is readily available.