The latest version of ADB no longer imposes the limitations described in the documentation. It offers pretty comprehensive support for XML Schema now.
Anne On Tue, Sep 2, 2008 at 2:53 PM, Peter Conrey <[EMAIL PROTECTED]> wrote: > I have been developing web services and web service clients in a large > corporate environment for several years now. We employed several Perl web > services (using SOAP::Lite) to feed both Java-based web clients (using Axis > 1) and .NET clients in other departments. While the architecture works very > well, we've run into a very frustrating scenario that limits our ability to > respond quickly to change requests. Whenever we need to add data to a web > service (say, a new field to a customer profile object), we have to > completely re-deploy any Java application that uses that service/object, > even if that new field is not relevant to the application. > > When we discovered that Axis 2 provided a means of turning off strict schema > validation, we were excited to covert our code. However, according to the > Axis documentation, the only client format that supports the "-Eosv" option > is ADB, which also carries the following limitation: > > "It is not meant to be a full schema binding application, and has > difficulty with structures such as XML Schema element extensions and > restrictions." > > --http://ws.apache.org/axis2/1_4/userguide-creatingclients.html#createclients > > Unfortunately, we use both extensions and restrictions in our schema, as > they best define our data structure. How difficult would it be to add the > "Eosv" option (or equivalent) to all data binding formats? As much as I > hate to tout Microsoft, .NET has no such limitation, so adding information > to serialized objects has no effect on .NET clients. While this may not be > the "correct" behavior from a strict standards-based perspective, from a > practical, enterprise perspective, it is unacceptable to have to rebuild > 8-10 client applications just to support a change required only by one or > two, especially when one of the unaffected applications is beyond the > service developer's control. > > Has anyone else discovered a solution to this issue, or found a way around > it? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
