WS-I released the first draft of the Basic Profile today. I don’t know how they manage to write so much about something that isn’t necessary; you wouldn’t need profiles if interoperability were well defined. It seems to be purely a political move to bundle specs together so that the technology doesn’t look like it could be easily marginalized (though it can).
I mean, really, why on earth does anybody need to specify the possible HTTP response codes to be used, when HTTP clients can already deal with all of them (even if only to fallback to x00)?
And cookies for state management? Puh-leeze! Cookies are a hack, and only make any kind of sense when you’re dealing with an installed base (browsers) that support them. Remove the browser, and you could do state management properly, on the client (and only on the client) instead of the server. This is Distributed Systems 101 stuff here, sheesh.
Sigh. It disappoints me to think of all the time and money the industry is wasting on this.
Sam writes that Glen Daniels has added HTTP GET support to Axis. Good job! Though I think my suggestion was cleaner, lined up well (semantically) with how other methods are invoked, and didn’t require that odd hack which suggests that a GET request is not a request message(!). Oh well. Thanks, Glen.
A message I sent to www-ws-arch this past summer seems to be making the rounds again. I don’t think I ever mentioned it in my weblog, so here ya go. Looks like it was mentioned on xml-dev, so perhaps that’s why. Er, and I forgot that I mentioned it in my “Playing Checkers with a Chess Set” blog too. Duh.
BTW, 10 kudos to whomever finds the “flaw” in the argument I made in that message. It’s not a fatal flaw, of course, but it does hilight the late binding issue, which I didn’t introduce in it (for fear of losing the simplicity of the point I was trying to make).
Update; the flaw is that when you get to the get/GET part, the message no longer means “get stock quote”, it just means “get a representation of what’s identified by this URI”. You find out if it’s a stock quote after you invoke GET. That’s late binding.
Presumably a virus/worm/whatever had a hand in a
message forwarded to the
Web Services Architecture WG mailing list today. Interesting, it appears as though
Scott Dietzen, CTO at
BEA, has moved on to Microsoft. Ow, that’s gotta hurt. 8-)
Who knows though, this could be a fake, since the message headers look weird; the message-id is from bea.com, despite the From header indicating microsoft.com. Shrug/chuckle.
Update; the archived content of the message has been removed, presumably per
W3C archive editing policy.
But you can still see the From and Message-Id headers.
Just came up with this. I’ll have to use it someplace. It’s a bit too brash for my .sig unfortunately, especially for WS-Arch emails. 8-)
Update; just whipped together a
blog at my
O’Reilly weblog.
It’s good to see
Edwin
agreeing with
Steve Vinoski
about how distributed systems are not as simple as
just exposing object APIs through SOAP.
I especially like this bit; “We should think of it as email for business applications”. Yes! But email is fairly limited; we can do better than just “add this message to that mailbox”. What if we extended email with the ability to retrieve messages, replace existing messages, plus other operations on messages and mailboxes? If you squint a little, that’s what the Web is.
I should probably have done this long ago for the record, but there’s no better time than the present. This was prompted by a
couple of
comments I’ve seen recently saying “Web services are here to stay!”. Bzzt!
Web services will be considered an utter failure by the industry by the end of 2004.
The end game will be interesting to watch, that’s for sure. Some companies will emerge as the real thought leaders, and others will likely be left insisting that Web services are the right way to do things. Then again, it’s possible that Microsoft and IBM spin doctors may just absorb REST; “We’ve been saying that all along!”. Either way, none of the specs associated with Web services will be in use on the Internet by then, except perhaps SOAP, DIME, and WS-Routing. But I’d have to bet against those too, unfortunately, because they’re going to get caught up in the backlash.
I’ve seen the phrase “Service Oriented Architecture” (SOA) thrown about by
so
many
people recently, and every time I see it, I cringe. As near as I can tell, it’s being used by Web services folks to mean simply “a service available over the Internet”, which AFAIK includes email, FTP, the Web, IRC. Really, what distributed system is not about services?
If marketing buzzwords are going to make it into technical discussion, please make sure they’re not no-ops.
Ken Arnold gives a wonderful interview on distributed computing and the inherrent problems associated with it. Brilliantly done, modulo a slightly confusing answer about state; he seems to also be confusing application and session state, in part at least. I can’t imagine developing a system without object state, since for most systems it’s a requirement that state is held persistently. The most important issue is application/session state; keep it in one place if you can, preferably on the client if you need to scale.
He also misses what I believe to be the principle difference between computing at Internet-scale versus the smaller-scale. Then again, a lot of people miss this. Awesome interview though.
There are two kinds of people; those that believe that XML-RPC was SOAP‘s predecessor, and those that believe that PEP was.