On 08/26/2011 06:36 PM, Christian Schneider wrote: > The problem is that strict versioning and loose coupling do not really > match.
Agreed-on data formats are what makes loose coupling possible. If you publish a data format that you don't follow, you're forcing your clients to use tools which also ignore the format. This is tight coupling, not loose coupling. I do see the benefits of a flexible approach to XML processing for web services. The problem is that nobody has defined that flexible approach, and instead different toolkits are implementing their own form. This is a recipe for disaster. The proper way of handling this would be to define a variation of XML Schema specifically for web services, one which has looser structure rules (such as allowing elements to be added at arbitrary locations). But that hasn't happened and is politically unlikely to ever happen. > I think it is a good idea to give up some strictness to achieve a > looser coupling in services. Btw. by using xsd:any you would do almost > the same > just with a lot more effort. For service stacks that require > validation you can still produce a wsdl with xsd:any if it is really > necessary. Unfortunately, the only way of doing what you describe is by violating the schema definitions. You can do this within a small organization, especially if everyone is using the same tooling for their web services. If you try this in larger environments sooner or later it'll come around and bite you. > > I just looked up the principle I mentioned: > http://en.wikipedia.org/wiki/Jon_Postel#Postel.27s_Law > > This principle is well respected in engineering. Examples mentioned > are E-Mail and digital circuits. I think also the TCP/IP > implementations follow it. This is a well-known principle, but it leads to problems of incompatibility when people don't follow the first part: in essence, "be strict in what you produce". This is exactly the situation we're discussing. > > I tested this in practice and had good experiences with it. The fear > of something breaking in production is not real. Before you put a new > client in production you will test it with the old provider in a test > network. If it breaks you will know before production. The problem would be on the other side - a new provider makes changes, and older clients break. Unless you control all your clients you can't test them for compatibility with a new version of the provider code. - Dennis
