Hi Jon,
I'm in the same situation, in that I have a number of
existing web services in production, and there's a road-map to slowly
improve/update the web services over a given time. However, I obviously
want to apply some versioning, so that the migration doesn't break old
clients, but still allows new ones to be deployed and tested.
My current guesstimate on doing this is to:
1) I use the approach, schema first, then java. Hence, I am applying
version numbers to the schemas. These version numbers in turn are shown
in the wsdl, as wsdl types.
2) I use spring in my backend. Hence, when I have to deploy some new
functionality, I normally create a new interface, which translates into
a new endpoint.
So, should my clients wish to use the old endpoint with the old xsd
schema version, they can. Otherwise, they are made aware of the new
endpoint with the new schema (with updated version number). To be
honest, I'm not sure if this is the best way to do it, so am all ears to
hear how others are doing it?
Best,
Conor
________________________________
From: Poulton, Jonathan [mailto:[EMAIL PROTECTED]
Sent: Thursday, 7 June 2007 12:11 AM
To: [email protected]
Subject: [xfire-user] Server versioning
Hi there,
I have a generic question about client vs. server versioning I was
hoping one of you might have some experience with.
Say we have 1 set of services providing a services to a number of
different clients. As the services undergo development the object model
changes, as new fields are added or altered. With each new services
version the clients need to have a choice; they can continue to use the
"old" service, or they can immediately switch to using the new service
via their existing clients. I was wondering if this scenario was
possible with xfire, and if so if there were any pitfalls I should be
aware of. It would be useful to hear from anyone who has had problems
with client/server versioning, and the approach they took to solving the
issue.
Thanks
Jon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email (including any attached files) is for the intended
recipient(s) only. If you received this email by mistake, please,
as a courtesy, tell the sender, then delete this email.
The views and opinions are the originator's and do not necessarily
reflect those of the Queensland Studies Authority. All reasonable
precautions have been taken to ensure that this email contained no
viruses at the time it was sent.