[wsrp-wsia] WS-I.org basic profile

[Andre Kramer <andre.kramer@eu.citrix.com>]

WS-I.org published their basic profile recently:
http://xml.coverpages.org/ni2002-10-18-c.html
http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm
Having not been exposed to this before, I read this with WSRP in mind and
made some notes. (Informational only / no warranty / usual disclaimers).

regards,
Andre
-----------------
On namespaces: 

They use http://www.w3.org/1999/XMLSchema and
http://www.w3.org/1999/XMLSchema-instance. Don't see need to stop using 2001
for WSRP wsdl.

On style = literal:

<cite>
For interoperability, literal XML is preferred
</cite> 

Good.

and later:

<cite>
R2706 A DESCRIPTION MUST use the value of "literal" for the use attribute in
the SOAP Binding description.
R2707 If a DESCRIPTION does not specify the use attribute in the SOAP
Binding description, the value of the use attribute SHALL default to the
value "literal".
For interoperability the profile prohibits the use of different encodings
including the SOAP encoding.
</cite>

even better.

On SOAPAction: it's optional.

I notice our binding wsdl has SOAPActions="http://tempuri.org/...";. This
should be fixed. Setting to "" may require an attribute to be set on .NET
Web Service.

On Attachments:

<cite>
Editors' note:The Working Group is currently considering whether to include
an attachments mechanism in the Basic Profile; if so, it should be
referenced here, and it may impact current requirements (e.g., allowed
bindings in WSDL, allowed Content-Type values in HTTP).
</cite>
On use of http session management:
<cite>
R1120 INSTANCEs MAY attempt to use the HTTP state mechanism ("cookies").
R1121 INSTANCES MUST NOT require support for cookies in order to function
correctly.
R1122 If INSTANCEs use the HTTP state mechanism, they SHOULD conform to that
described in RFC2965.
HTTP cookies are a useful tool for improving the efficiency of a service
(e.g., through session management). However, cookie support in clients is
not mandated by RFC2965, and therefore cannot be required for successful
operation; it should only be used as an optimization or hint.
</cite>
So WSRP with initEnvironment() and even without (since 0.8 mandates cookies
be returned if set) does not conform. Suggest we could allow cookies in the
no initEnvironment() case to be optional (hints). Producer meta data: {
usesCookies=true, requiresCookies=false }.
On import: We seem to follow the wsdl "import" rules but no mention of
nested imports.
On types: nothing about having to have types be qualified.
<cite>
Use of wsdl:message elements with zero parts is permitted in both RPC and
Document styles to permit operations that can send or receive MESSAGEs with
empty SOAP Bodies. This case is explicitly permitted by the Basic Profile.
</cite>
We saw problems with void returns for xrpcc ...
On soap faults: need to add faults to wsdl first!
On UDDI:
<cite>
UDDI description is optional for Web service instances. By no means do all
usage scenarios require the kind of metadata and discovery UDDI provides,
but where such capability is needed, UDDI is the sanctioned mechanism.
</cite>
Could be read as UDDI over getService/EntityDescription() for Meta Data. [No
idea why things like the replication schema get a mention. Strange that the
UDDI.org best practice for WSDL is not referenced, except for later editors'
note.]
Iff we adopt UDDI and publish entities to it the advice to parallel all meta
data seems sound. We could use tModels for the producer flags and it may be
a good idea to make the producer offered entity handle/name equal to the
service name in UDDI.
On security:
<cite>
R5000 An INSTANCE MAY require the use of HTTPS.
R5001 If an INSTANCE requires the use of HTTPS, the location attribute of
the soap:address element in its wsdl:port description MUST be a URI whose
scheme is "https"; otherwise it MUST be a URI whose scheme is "http".
R5010 INSTANCEs MAY require the use of HTTPS with mutual authentication.
</cite>
Can't have dual bindings for HTTP/HTTPS as soap:address must be set to one.
<cite>
R5100 If an INSTANCE requires use of basic HTTPS, the choice of acceptable
certificate authorities for the instance's certificate is a private
agreement between the consumer and the instance.
R5110 If an INSTANCE requires the use of HTTPS with mutual authentication,
the choice of acceptable certificate authorities for the consumer's
certificate is a private agreement between the consumer and the instance.
</cite>
Posibility of  providing a certfication authority for WSRP?