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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> >
> >
>
