You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by hu...@jpmorgan.com on 2002/03/11 22:48:49 UTC
Change management of web service input/output models???
What is the best way to deal with changes in the input and/or output model
of a web service?
Any references to general change management solutions are appreciated.
In my case, there are n different groups implementing a SOAP service. If a
new field is added to the input model all groups must simultaneously
upgrade the input model definition (otherwise deserialization will fail
once the model is changed in the client). Generally, however, the change
will simply be the addition of a new field, not modifying or removing an
existing field. Given this, a good solution is to allow legacy services to
simply ignore the new field. This will allow the interested service
implementor to recognize the new field while the other groups ignore it
until they are ready to upgrade the input model.
One solution is to subclass or create my own BeanSerializer which drops a
field it doesn't recognize during deserialization (currently the Apache
BeanSerializer will fail). I thought this was a good idea until I tried to
find someone else who has done the same thing. I couldn't, which makes me
think this may not be a good idea.
Another is to flatten the input model to a Map such that all input models
are just name/value pairs. I don't like this because the input model must
be flattened.
Lastly, I could add a new service accepting the new input model. This
would require UDDI wrapper code in the client to direct the request to the
appropriate version of the service.
Any experiences or suggestions welcome.
Thanks,
Shawn.
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
RE: Change management of web service input/output models???
Posted by graham glass <gr...@mindspring.com>.
hi shawn,
GLUE works just like you describe, and ignores extra fields that
it doesn't recognise (both when reading and writing according to
the WSDL/XML schema).
cheers,
graham
-----Original Message-----
From: hughes_shawn@jpmorgan.com [mailto:hughes_shawn@jpmorgan.com]
Sent: Monday, March 11, 2002 3:49 PM
To: soap-user@xml.apache.org
Subject: Change management of web service input/output models???
What is the best way to deal with changes in the input and/or output model
of a web service?
Any references to general change management solutions are appreciated.
In my case, there are n different groups implementing a SOAP service. If a
new field is added to the input model all groups must simultaneously
upgrade the input model definition (otherwise deserialization will fail
once the model is changed in the client). Generally, however, the change
will simply be the addition of a new field, not modifying or removing an
existing field. Given this, a good solution is to allow legacy services to
simply ignore the new field. This will allow the interested service
implementor to recognize the new field while the other groups ignore it
until they are ready to upgrade the input model.
One solution is to subclass or create my own BeanSerializer which drops a
field it doesn't recognize during deserialization (currently the Apache
BeanSerializer will fail). I thought this was a good idea until I tried to
find someone else who has done the same thing. I couldn't, which makes me
think this may not be a good idea.
Another is to flatten the input model to a Map such that all input models
are just name/value pairs. I don't like this because the input model must
be flattened.
Lastly, I could add a new service accepting the new input model. This
would require UDDI wrapper code in the client to direct the request to the
appropriate version of the service.
Any experiences or suggestions welcome.
Thanks,
Shawn.
This communication is for informational purposes only. It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
RE: Change management of web service input/output models???
Posted by graham glass <gr...@mindspring.com>.
hi shawn,
GLUE works just like you describe, and ignores extra fields that
it doesn't recognise (both when reading and writing according to
the WSDL/XML schema).
cheers,
graham
-----Original Message-----
From: hughes_shawn@jpmorgan.com [mailto:hughes_shawn@jpmorgan.com]
Sent: Monday, March 11, 2002 3:49 PM
To: soap-user@xml.apache.org
Subject: Change management of web service input/output models???
What is the best way to deal with changes in the input and/or output model
of a web service?
Any references to general change management solutions are appreciated.
In my case, there are n different groups implementing a SOAP service. If a
new field is added to the input model all groups must simultaneously
upgrade the input model definition (otherwise deserialization will fail
once the model is changed in the client). Generally, however, the change
will simply be the addition of a new field, not modifying or removing an
existing field. Given this, a good solution is to allow legacy services to
simply ignore the new field. This will allow the interested service
implementor to recognize the new field while the other groups ignore it
until they are ready to upgrade the input model.
One solution is to subclass or create my own BeanSerializer which drops a
field it doesn't recognize during deserialization (currently the Apache
BeanSerializer will fail). I thought this was a good idea until I tried to
find someone else who has done the same thing. I couldn't, which makes me
think this may not be a good idea.
Another is to flatten the input model to a Map such that all input models
are just name/value pairs. I don't like this because the input model must
be flattened.
Lastly, I could add a new service accepting the new input model. This
would require UDDI wrapper code in the client to direct the request to the
appropriate version of the service.
Any experiences or suggestions welcome.
Thanks,
Shawn.
This communication is for informational purposes only. It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.