Ed,
In
my opinion the WSDL work to be produced inside the committee (if any) should be
aligned to the binding protocols in chapter 6.
By
now, only SOAP and HTTP (you can also call this one REST) are included. It’s
clear that you can imagine DSS messages transported over many transport
bindings (you are free to create any other WSDL apart from the TC’s one with the bindings you prefer), but I’m
sure that these two protocols present by now in chapter 6 were not chosen
randomly.
So
for me, what protocols to include in chapter 6 and the WSDL are different
stories (IMHO you want to translate to the WSDL what you have covered in
chapter 6, as a misalignment between the two would be quite difficult to
explain).
The
“religious” debate RPC/DOC (SOAP-based) was a lower level,
implementation detail thing, only trying to make some suggestions on the “actual”
draft WSDL, and totally independent from the debate about what transport
bindings should appear in DSS chapter 6. This is another completely different
story.
As
for the “tweaking”, obviously I agree, but, IMHO, is a question of
best-effort. Publishing a standardized descriptor of the service helps more
than not doing it (at last, you can ignore it and keep on going with the XSD
only). Code generators for WSDL and XSD are constantly improving, and developers
are comfortable with these tools (in many cases, like .NET, you don’t even
need to generate anything, it’s transparent to the developer). Many of
them will refuse generating the messages “by hand”, and will ask
you for a WSDL to generate appropriate stubs (yes, I know that there are also
data-binding generators based on XSD, but they're much less frequent).
The
interop thing is only an idea, but at last, we can
rely on final users to do that ““interop””.
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
De: Edward Shallow
[mailto:]
Enviado el: jueves, 01 de junio de
2006 14:24
Para: ;
; 'Nick Pope'; 'Juan Carlos Cruellas'
CC: 'DSS TC List'
Asunto: RE: [dss] DSS WSDL
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
