In my previous post on this subject I explained that the complexity of web services stems from 4 things:
- Some of the web service standards are simply flawed
- Some of the standards are flawed simply because they’re built on top of other flawed standards
- Some of the standards aren’t standards. There’s too much duplication of functionality amongst competing specifications. Aka, vendor wars
- Web services are complex because technology is complex
The last item was explained in that post. It’s the prior three that I’d like to start addressing now. This won’t be done by simply explaining things away, or by accepting our fate, or even by planting a flag and screaming. Instead, what I’d like to do is deconstruct web services the way they stand today, and reconstruct them from scratch. I want to do this while minimizing the impact on existing web service implementations, but I don’t think that’s entirely possible. At the very least we’ll keep the bath water even as we toss out the baby.
I do not have any of this work in some pre-existing form. I will be creating it here off the top of my head (though it’s been gestating for some time). I also anticipate doing some completely bone-headed things. But this is a living, iterative design, and I will be going back and correcting things as bad ideas become evident. I sincerely hope that others will discover this blog and provide their input into the design. I will be tracking the “new web services” on this page here: http://wanderingbarque.com/ws-reloaded.
In this post I’ll take the first baby step in reconstructing web services; doing something about the name. As a name “web services” is next to meaningless. Or, rather, it has too much meaning; it’s overloaded. Since I envision a message oriented XML-based Internet — ermm — exchange, the new system will be called “Moxie.” And, honestly, I just thought that up while I was typing.
Up next: Thinking about transports.