Option to Remove Strict Schema Validation

[Peter Conrey <pf...@hotmail.com>]

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#createclient
s

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?

Re: Option to Remove Strict Schema Validation

[Anne Thomas Manes <at...@gmail.com>]

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 <pf...@hotmail.com> 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org