Hi Guys,
I am trying to get an idea on the state of "runtime XMLSchema validation on
SOAP messages" in the SOAP toolkit industry.
Currently I am using Apache Axis 1.4 WSDL2Java to generate client agent
code.
Some SOAP agent clients being used.
.NET
gSOAP
NuSOAP
Apache Axis
Apache Axis2
etc...
I have 'heard' that .NET does XML Schema validation on SOAP messages ?
Would it be fair to say, that there are very few SOAP Agent applications
that do XMLSchema validation on the SOAP request and SOAP response messages.
=================================================================
April 2005
An extract from a W3C Workshop on XML Schema 1.0 Specification User
Experiences document
"One acute pain point for developers is in mapping XML Schema constructs to
programming languages.
One interesting observation is that few web service implementers employ W3C
XML Schema validation processors.
Many users "validate" SOAP messages using only inherent SOAP processing
mechanisms, possibly with some uncoordinated help from type serializers."
=================================================================
Sep 2003
http://www-128.ibm.com/developerworks/webservices/library/ws-castor/
Apache Axis is one of the most popular Web services toolkits out there.
Axis supports both RPC and Document-style services, and so it would seem to
be the right starting point for a Document-style service.
As with any Document-style service, you still have the task of handling the
incoming XML data somehow.
Axis includes a handy tool to help solve this arduous task, called
WSDL2Java.
WSDL2Java can generate both code stubs for the client and server for your
methods, and actual beans to model your data from the model defined in the
XML-Schema.
WSDL2Java will then populate these beans automatically from the XML.
This process in general is called data binding, and it's one of the
mainstays of the movement behind XML-Schema.
WSDL2Java can be a little quirky, but in general it helps get things
rolling.
Clearly a tool like this is very useful to have, but unfortunately it is not
the end-all for client stub generation -- it faces some real issues:
* WSDL2Java suffers from the common trap most technologies in the
space have fallen into, which is playing catch-up with schema support.
Writing a tool that can correctly and completely handle the highly complex
XML-Schema standard is no small task. It alone represents an effort
potentially as difficult as Axis itself. WSDL2Java is noticeably lacking in
this area, having buggy or incomplete support for many XML-Schema features.
Examples of this are support for attribute groups and choice groups, but
these are of course changing, as work on WSDL2Java continues. The point,
however, is that writing and maintaining such a complex piece of code isn't
the area that Axis is concentrating on, and WSDL2Java will likely
continually be playing a game of catch-up to meet the functionality of
stand-alone data-binding solutions.
* Another problem, related to the first, is that the code that
WSDL2Java generates lacks XML validation capability. When you begin to work
with XML documents, validation is important, and the XML-Schemas allow
validation to occur automatically. However, WSDL2Java doesn't have a
facility to do this.
* The interface to serialization to and from strings is not intuitive.
If you are using WSDL2Java's data binding code for your XML objects, chances
are, you'll need to encode or decode the objects back to an XML string at
some point. While this is possible with WSDL2Java's generated objects, it's
not an easy task. A large framework has to be set up, and it can cause a lot
of headaches, for what seems to be a simple task.
=================================================================
regards
> Alick Buckley
>
> LANSA Research and Development
> LANSA Pty Ltd
>
> Phone: +61289070243
>
> http://www.lansa.com
> mailto:[EMAIL PROTECTED]
>
>
>
>
