has observed for quite sometime that Web service toolkits
need to do a better job helping developers deal with change. Most
toolkits provide little help with Web service versioning and most
generated clients are brittle in the face of change. Sam wants to
see more support for the intrinsic extensibility of XML surfaced
through toolkits. In the absence of that, it will be hard to build
systems that will work at Internet scale. A large part of the value
of the Web came from the fact that you can deploy clients and servers
independently with a high degree of success. Web services should work
the same way (as I described here).
Versioning is one of the things you gain if you build Web services that
are loosely-coupled. Many people claim that the use of XML makes things
inherently loosely-coupled. This is true to some degree - clients and servers
do not have to know how the code at the other end of the wire is implemented.
However, Web services and their clients may still be tightly-coupled in terms
of the data they send and receive. Most Web services today focus on an RPC
programming model. If you build distributed applications around method callstacks,
they will almost certainly be tightly-coupled because, in general, it is hard to
version behavior. It is a lot easier to version data, which is one of the reasons
I think of Web services in terms of messages, not RPC calls.
expressed his disagreement with Sam's position. He wants
to know exactly what data to expect, so he can generate optimized parsers and
serializers to increase performance. I don't understand why XSD cannot be used to
solve this problem. XSD can be used to define as tightly closed or openly extensible
a message format as you desire. If toolkits went further with their support for XSD's extensibility
features, then proponents of loose-coupling would be happy. If some services choose
never to use those features, proponents of tighter coupling would be happy. I believe all
Sam is looking for is more sophisticated XSD support in the next generation of tools.