<prognostication-mode accuracy="questionable">
I was reading this post today about the Microsoft AJAX Library, and something struck me: the [ScriptService] attribute makes this is a new web service toolkit. "Duh", you're saying. But the interesting thing about this one is that it's a toolkit that .NET web service authors probably can't ignore. Up until now, I've been getting the message from most of my clients that the only web service client they really care about is .NET. That sort of begs the question of "Then why use web services at all?" but that's perhaps a topic for another time.
At any rate, given how software from Microsoft is usually received by developers in the Windows world, I suspect that people will be forced to consider the AJAX Library when designing their .NET web services. And granted it's written by the same company, but I'll be completely stunned if the two stacks are completely isomorphic. Hell, it's hard enough to get the .NET stack to talk to itself across XML serialization sometimes.
I think this constraint is going to be fundamentally positive. It's generally true that the second client is much harder to write than the third, as the number of generalizations you have to introduce decreases. So if people start testing against two different clients (even if they are both from Microsoft) then it'll be that much easier when it comes time to integrate with Java, or Ruby, or whatever the hell comes next. Which is (at least one of) the point(s) of doing Web Services.
Should be interesting. At the very least, it looks like I should devote some time to playing with [ScriptService] to find out what the limitations are.
</prognostication-mode>
No comments:
Post a Comment