If you're using MESSAGE style services, then, yes, I would expect the client to be able to handle the change -- no sweat. If you're using RPC, WRAPPED, or DOCUMENT style, I would expect the deserializer to barf. Java's not too good at handling the dynamic introduction of a new element in an object.
Anne
At 12:31 PM 8/26/2003 -0500, you wrote:
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
