Re: Option to Remove Strict Schema Validation
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]
Option to Remove Strict Schema Validation
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
Title: Option to Remove Strict Schema Validation Hi Peter, I strictly use XML Beans as the data-binding for all my contract-first web services in Axis 2, and have actually had quite a few problems due to lack of schema validation. That is, unless we specifically validate the XML Beans DOM and throw an error, Axis 2/XML Beans doesn't validate against the schema. Peter Conrey 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, weve 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 developers control. Has anyone else discovered a solution to this issue, or found a way around it? -- Anthony - Anthony Bull Senior Developer Black Coffee Software Ltd PO Box 10-192 The Terrace Wellington, New Zealand [EMAIL PROTECTED] Ph +64 4 472 8818 Fax +64 4 472 8811 - www.bcsoft.co.nz --- This email may contain confidential or privileged information, and is intended for use only by the addressee, or addressees. If you are not the intended recipient please advise the sender immediately and do not copy, use or disclose the contents to any other person or organisation. Black Coffee Software Ltd accepts no responsibility for viruses received with this email, or to any changes made to the original content. Any views or opinions expressed in this email may be personal to the sender and are not necessarily those of Black Coffee Software Ltd. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
