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?
Congrats Rael!! Well deserved.
(
link) [
Mark Baker’s Bookmarks]
I went to high-school with Hans, and had a big crush on his sister Denise. Though he was a year ahead of me, we were always hanging out in the computer room together with the other jean-jacket wearing geeks.
(
link) [
Mark Baker’s Bookmarks]
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.
A vision of things to come; personal servers, event servers, REST, RDF, …
(
link) [
Mark Baker’s Bookmarks]
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.
A good one from Bill Grosso on what the year 2009 will bring, including a couple of bang-on comments about the Web/Web-arch
(
link) [
Mark Baker’s Bookmarks]
Adam writes;
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.
“It’s pretty clear to me that the RDF data model is simpler”. See, there is hope for BEA.
(
link) [
Mark Baker’s Bookmarks]
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.