Sage advice from Patrick Logan;
Simple dynamic programming languages and simple dynamic coordination languages are winning. Vendors will have to differentiate themselves on something more than wizards that mask complexity.
On the upside, when most every other vendor is hocking snake oil, differentiation from those vendors isn’t hard. On the downside, as Patrick points out, mature products like Apache are the competition.
Of course, there’s always many ways forward. Fair competition being one (build a better Web-server/CMS/router/whatever..), subversion, another. But lots of other possibilities in between.
I’m also reminded of a prediction I made about three years ago;
By the end of 2005, IBM’s content management software division will have absorbed their enterprise software group
Ok, so my timing’s off (as usual), but the message seems even more pertinent after the recent discussions; content management is enterprise integration.
Tags: soa, rest, web, webservices.
Now don’t get me wrong, I do appreciate the bevy of pro – or at least neutral – REST commentary in the recent discussion. But I just can’t get excited about the “moderate” conclusions such as this from Dare Obasanjo;
If you know the target platform of the consumers of your service is going to be .NET or some other platform with rich WS-* support then you should use SOAP/WSDL/WS-*. On the other hand, if you can’t guarantee the target platform of your customers then you should build a Plain Old XML over HTTP (POX/HTTP) or REST web service.
I mean, that looks fine and dandy – as did Don’s conclusions – until you realize that the architectural properties of the resulting system aren’t a factor in the decision.
Oops! This is not progress. This is not principled design.
Tags: soap, soa, rest, webservices.
If you’d have asked me six or seven years ago – when this whole Web services things was kicking off – how things were likely to go with them, I would have said – and indeed, have said many times since – that they would fail to see widespread use on the Internet, as their architecture is only suitable for use under a single adminstrator, i.e. behind a firewall. But if you’d asked me if I would have thought that there’d be this much trouble with basic interoperability of foundational specifications, I would have said, no, I wouldn’t expect that. I mean, despite the architectural shortcomings, the job of developing interoperable specifications, while obviously difficult, wouldn’t be any more difficult because of these shortcomings… would it?
I’ve given this a fair bit of thought recently and concluded that yes, those differences are important. What I don’t know though, is whether they’re important enough to cause the aforementioned WS interop problems. But here’s my working theory on why Web services interop is harder; you can decide for yourself how significant they are.
What I think this boils down to is that interoperability testing of Web based services (not Web services), like any Web deployment, benefits from network effects not available with Web services, primarily due to the use of the uniform interface. So if we’re testing out Web based services, and I write a test client, then that client can be used – as-is – to test all services. You simply don’t get this with Web services, at least past the point where you get the equivalent of the “unknown operation” fault. As a result, there’s a whole lot more testing going on, which should intuitively mean better interop.
Or at least that’s the theory. What do you think?
Update; based on some comments by others, I guess I should qualify this as stating that I understand that there are concrete reasons why bugs exist today. But what I’m talking about above is the meta question of why these bugs continue to persist, despite plenty of time passing in which they could have been resolved (modulo the vendor-interest comment by Steve & Patrick, which I don’t buy because there’s so much activity in SOAP extensions that lock-in at the SOAP level is unnecessary and moreover, shrinks the market by scaring potential customers away).
Tags: soap, rest, web, soa, networkeffects, testing, interoperability, webservices.
Don Box gives us his two cents on a Microsoft-internal “REST vs. SOA(P)” debate;
The following design decisions are orthogonal, even though people often conflate two or more of them:
- Whether one uses SOAP or POX (plain-old-XML).
- Whether or not one publishes an XML schema for their formats.
- Whether or not one generates static language bindings from an XML schema.
- The degree to which one relies on HTTP-specific features. That stated, screw with GET at your peril.
- Whether one adopts a message-centric design approach or a resource-centric design approach.
Some of the decisions (specifically 5) are architectural and sometimes philosophical.
I don’t know about that. Numbers 1, 2, 4, and 5 are architectural, as all impact either the components, connectors, or data of the system. Only number 3 isn’t, since it’s an implementation detail. Number 2 is debateable I suppose, but most Web services based uses of XML schemas I’ve seen involves removing descriptive information from the message in deference to an implicit pointer to a WSDL document (and therefore a schema).
He also added;
If you want to reach both audiences before your competition does, you’ll avoid indulging in religious debates and ship something.
Of course, religious debates should always be avoided. But architectural debates should not, and REST vs. SOA(P) is an architectural debate. Period. If anybody thinks this is a religious debate, you simply haven’t done your homework.
Also of interest, his advice was preceded by this qualifier;
In hopes I never have to address this debate again, […]
Hah, that’s a good one 8-) Resistance is futile. You can’t fight loose coupling, man. It’s infectious. Muhaha!
Tags: soap, rest, microsoft, webservices.