Carlos, Nick, and JC,
I believe the whole WSDL issue is
isolated to the binding decisions an implementor decides upon. DSS does not
mandate SOAP or anything else for that matter. I agree that for implementations
using SOAP and Web Services, having WSDLs certainly helps developers. However
you end up getting into very product and toolkit-specific issues with regards to
subtle differences in how differing WSDL-generator toolkits react. We on the EPM
team also release "sample clients" for popular Web Service toolkits. Most
require "tweaking" to get things to work. Invariably things like xs:import
xs:include schemaLocation etc ... work with one and not the
other.
I do not believe
these toolkit-specific issues should not creap into the specification or
TC's published content. What of XML/RPC ? What of REST ? What of other
bindings ? These are the topic of an implementation's "Release Notes" wouldn't
you say ? The same does for the religious rpc vs doc/lit debate. In fact
there are numerous ways to mitigate risk by good xsd / wsdl separartion. Again
that is only a SOAP debate. DSS does not mandate one binding over
another.
Ed
From: Carlos González-Cadenas
[mailto:]
Sent: June 1, 2006 6:39
AM
To: ; 'Nick Pope'; 'Juan Carlos
Cruellas'
Cc: 'DSS TC List'
Subject: [dss] DSS
WSDL
Nick,
JC,
Regarding
the WSDL issue, I want to give you some feedback obtained in the last
months
As you
already know, we have an implementation of DSS Core (CD3 version) and several
other profiles (like timestamping, XAdES and our private ones XSS, Archive and Compound)
running for several big clients here in Spain. At
integration level (people wishing to access the services deployed in our
infrastructures), we have been facing some difficulties mainly due to the
typical misunderstanding: “if there’s no WSDL then there’s no web-service”. I
recommend publishing the WSDL along with the XSD in the TC’s page, as this will impact in a relevant manner in the
degree and speed of adoption of DSS.
In the
interop work, I would consider adding a specific
chapter for WSDL-based integration (we’re doing some work on that for several
platforms, like Java (Axis), .NET and PHP). That is, evaluating how client
technologies handle DSS WSDL.
We need
to address how to handle profiles regarding to their specific WSDLs.
Andreas,
Thanks for
your WSDL file. I’ve been testing it in the last days, and have several
comments
With
XMLBeans 2.1.0, the <xs:import> for the WSDL’s
XSD is not working, and therefore XMLBeans is not
generating classes. Embedding the schema into the <types> section of the
WSDL allows XMLBeans to generate the classes
correctly.
With
Axis 1.4, I was able to generate the classes, but, as you said in your mail,
the code does not compile. Luckily, the errors (changing the order of two
params in the constructors of RequestBaseType and ResponseBaseType) can be fixed very
easily.
With
respect to the style/use for the web-service, I recommend to change rpc/literal (as present in your WSDL) to the one called
“document/literal wrapped”. I have tested the DOC/LIT wrapped approach with
Axis and works perfectly. The attached dss.wsdl
reflects that change to doc/lit wrappedn
Example
of the XML generated with the RPC/LIT (with the operation “verify”). Note
that the “verify” and “verifyRequest” elements are
redundant.
<soap:envelope>
<soap:body>
<verify>
<dss:VerifyRequest>
….
</dss:VerifyRequest>
<verify>
</soap:body>
</soap:envelope>
Example
of the XML generated with the DOC/LIT wrapped. In my opinion the most
natural way to do it.
<soap:envelope>
<soap:body>
<dss:VerifyRequest>
….
</dss:VerifyRequest>
</soap:body>
</soap:envelope>
If anyone needs some help with style/use for webservices, a good article for looking at the differences
between styles/uses for web services can be found
at:
http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/
Kind
regards,
Carlos
Carlos
González-Cadenas
Chief
Security Officer
Diagonal 188-198 Planta
2
08018 Barcelona
tel: 902 303 393
fax: 902 303
394
www.netfocus.es
