> A lot of it depends on the semantics of the interface. How relevant is > this removed attribute to the existing client applications? Can you > generate a default value for the attribute for these existing clients > and still have it work?
Yes, this is exactly the case. The particular attribute is deprecated. In fact, the server now takes its value from a local datasource. I can go through the @deprecated cycle but with long times between production releases it could be literally months before the attribute actually gets out of the code. > > One of the easiest ways to make this work is to intercept incoming > requests, and if the request contains the now-removed attribute, > transform it using XSLT so that it conforms to the new interface. > Likewise, response messages also must be intercepted and transformed to > the format the client is expecting. Clever. > > If the semantics of the interface have changed so much that it doesn't > work, then you need to create a different service -- and then either you > must continue to support both versions, or you need to tell your old > clients to upgrade. Of course. If this were a critical piece of information I would create a new DTO heirarchy and a new service method. > > Anne > > -----Original Message----- > From: James CE Johnson [mailto:[EMAIL PROTECTED] > Sent: Monday, October 25, 2004 8:41 AM > To: [EMAIL PROTECTED] > Subject: How do I safely evolve data structures? > > Lets say I have defined a Customer data object, done the java2wsdl2java > dance and now I'm using the generated Customer object in my Axis client > and server. > > Time passes and I need to remove an attribute from Customer... If I > remove the attribute and redeploy my Axis server calls from an older > client (e.g. - one which still has the now-removed attribute) will fail. > > Is there a way to evolve my server independently of the client? Or is > this just a bad idea?
