Managing backward compatibility in web services api

[John Eapen <j1...@gmail.com>]

I would imagine this to be a common problem, so looking for best
practices/information which can help manage this issue regarding providing
Web Services api which are backward compatible through wsdl modifications.

Let's say the initial product/application was version 1 and later there were
upgrades to api resulting in product version 2 and so on..
It will be nice if the client api's  using version 1 wsdl can also work with
version 2 wsdl.

To add to this,

a. I am not quite sure if changing the xml/wsdl namespace is an good
solution.

b. Does using xsd:any and xsd:anyType help ? Are they ws-I complaint ?

Appreciate any help.

Thanks
-John

Re: Managing backward compatibility in web services api

[John Eapen <j1...@gmail.com>]

 I guess, I was not clear enough while specifying the context of "backward
compatibility".

 Its *not* w.r.t. axis versions ( axis1 and axis2 ).

 Its more of the applications we develop and as the application is enhanced
the wsdl's/xsd's and service implementation of the api's may change as well.
 In this context, the client is now forced to upgrade to the new wsdl's
everytime the corresponding service impl changes. This may not be desirable.

 Some of the suggestions which I read about are using loosely defined web
services, use of  xsd:any and xsd:anyType etc.

 I am looking for other practical suggestions.

 Thanks
    John

   PS: I found this pretty good blog discussing WSDL Versioning and gives a
very good example of what I am talking about.
         http://christo4ferris.blogspot.com/2004_11_01_archive.html


On Thu, Apr 17, 2008 at 1:30 AM, Upul Godage <up...@gmail.com> wrote:

> This article may be helpful.
> http://wso2.org/library/2611
> In this case it talks about using the same endpoint for an Axis 1 and an
> Axis2 client requests.  From outside it is the same endpoint. It uses a tool
> like Apache Synapse or WSO2 ESB to do content based routing to find the
> proper endpoint.
>
> Upul
>
>
>
> On Thu, Apr 17, 2008 at 12:49 PM, John Eapen <j1...@gmail.com> wrote:
>
> >
> > I would imagine this to be a common problem, so looking for best
> > practices/information which can help manage this issue regarding providing
> > Web Services api which are backward compatible through wsdl modifications.
> >
> > Let's say the initial product/application was version 1 and later there
> > were upgrades to api resulting in product version 2 and so on..
> > It will be nice if the client api's  using version 1 wsdl can also work
> > with version 2 wsdl.
> >
> > To add to this,
> >
> > a. I am not quite sure if changing the xml/wsdl namespace is an good
> > solution.
> >
> > b. Does using xsd:any and xsd:anyType help ? Are they ws-I complaint ?
> >
> > Appreciate any help.
> >
> > Thanks
> > -John
> >
> >
>

Re: Managing backward compatibility in web services api

[Upul Godage <up...@gmail.com>]

This article may be helpful.
http://wso2.org/library/2611
In this case it talks about using the same endpoint for an Axis 1 and an
Axis2 client requests.  From outside it is the same endpoint. It uses a tool
like Apache Synapse or WSO2 ESB to do content based routing to find the
proper endpoint.

Upul


On Thu, Apr 17, 2008 at 12:49 PM, John Eapen <j1...@gmail.com> wrote:

>
> I would imagine this to be a common problem, so looking for best
> practices/information which can help manage this issue regarding providing
> Web Services api which are backward compatible through wsdl modifications.
>
> Let's say the initial product/application was version 1 and later there
> were upgrades to api resulting in product version 2 and so on..
> It will be nice if the client api's  using version 1 wsdl can also work
> with version 2 wsdl.
>
> To add to this,
>
> a. I am not quite sure if changing the xml/wsdl namespace is an good
> solution.
>
> b. Does using xsd:any and xsd:anyType help ? Are they ws-I complaint ?
>
> Appreciate any help.
>
> Thanks
> -John
>
>