Florian, I actually posted a similar message to the group not too long ago -- you can likely find it in an archive -- as a matter of fact, here's the text:
--------------------------- All, We've recently added a new member to an object being returned in our response payload. Basically we've added a simple type to a complex type that clients are used to consuming. We've appropriately updated our WSDL and I've updated our custom serializer to return the new member. My question is this -- should existing clients that have generated stubs prior to the addition of the new member play nicely? I would expect the introduction of a new element (especially a simple type wrapped up in a known complex type) to have little effect on existing stubs but it seems like at best you'd wind up with indeterminable results. From what I can tell -- Axis client tools choke if the payload changes even at the most trivial level, .NET tools manage to ignore the introduced element. I'm not saying either platform is right or wrong -- I just hate the idea of having to get partners to regen stubs because of the addition of a new member if they don't need access to that member. Certainly, the purist in me says "introduce a new service" -- but the practical side of me says that client tools should ignore elements that they weren't originally made aware of. Thoughts? Cory --------------------------- Perhaps I've changed my tune, but it's now my personal opinion that unless you're using a document style service -- you really shouldn't be changing your service's interface unless you have some sweet change management policy in place wherein all clients are notified of pending changes. Even if you have that policy in place, I think some leeway has to be given for migration time, e.g., revision your service so that you can cycle them in/out. For example: Endpoint of original service: http://www.foo.com/services/foo/01 (to be phased out at a given time). Endpoint of new service: http://www.foo.com/services/foo/02 I don't think anyone is really exploring this topic, it seems to me that the consensus is that you put up a definition and it remains static over time. In my line of business, requirements changes weekly which leads to a plethora of issues when attempting to get functionality out over a web services channel. We're exploring that internally now and if any good comes of it, I'll let you/the list know. Cory -----Original Message----- From: Florian Lindauer [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 09, 2003 11:40 AM To: [EMAIL PROTECTED] Subject: Web Services and backwards compatibility Currently we reflect on in how far changing a web service's interface can be done keeping it backwards compatible, i.e. do not break running clients. This sure is a broad topic, and if anyone can point me to articles, discussions etc on this.. Going a bit more concrete, I think there should not be a problem if you add a new operation, for example. But adding a new data field in a bean class (part of some response) is a problem, at least for a client using Axis-generated client-stubs: org.xml.sax.SAXException: Invalid element in <BeanClass> - <newElement> Any chances that this problem will be fixed in future releases? (a .NET client using an old proxy-dll did not seem to have a problem here, ignoring the new field) How do other frameworks react on this? What are other typical pitfalls, what should one keep in mind when changing the interface of a web service? What can be considered "safe", and what should be avoided? But then, you probably cannot avoid a lot of things in reality.. Thanks for any help/ideas. -- Florian Lindauer
