Re: [dss] DSS WSDL

For internal inter-op testing amongst ourselves ... sure. Releasing "samples" along with the core ... possibly. Definitively stating within the DSS core that this WSDL is the core's WSDL ... I am not so comfortable. BTW rpc vs doc/lit lifts its head right into the WSDL as you know.

Ed

----- Original Message ----
From: Carlos González-Cadenas <gonzalezcarlos@netfocus.es>
To: ed.shallow@rogers.com
Cc: DSS TC List <dss@lists.oasis-open.org>
Sent: Thursday, June 1, 2006 9:31:44 AM
Subject: RE: [dss] DSS WSDL

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
gonzalezcarlos@netfocus.es
www.netfocus.es

De: Edward Shallow [mailto:ed.shallow@rogers.com]
Enviado el: jueves, 01 de junio de 2006 14:24
Para: gonzalezcarlos@netfocus.es ; kuehne@klup.de; '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.

From: Carlos González-Cadenas [mailto: gonzalezcarlos@netfocus.es ]
Sent: June 1, 2006 6:39 AM
To: kuehne@klup.de; '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>

<dss:VerifyRequest>

….

</dss:VerifyRequest>

</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
gonzalezcarlos@netfocus.es
www.netfocus.es

dss message