[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] WS-I.org basic profile
Yes, our match is good (but the advice is rather limited). See <ak> below.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 24 October 2002 18:50
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] WS-I.org basic profile
Thanks for this summary, Andre. I had the same general impressions from a
first pass; namely that we match quite well. Relative to your comments:
- SOAPAction being optional: I think we had introduced this in order to
make one of the web stacks work ... do you remember which one?
<ak> Was it for JAXRPC when request names had a Request ending?
In this case it also helped the .NET stack but, at worst, a Web Service
C# attribute has to be added.</ak>
- cookie support: We currently allow Producer to say they require cookie
support of the Consumer and then require Consumers choosing to use such a
Producer to provide such support. The profile says the Producer must work
without this support, but often this just means that state is always lost
and so the End-User can't do anything interesting. The service end-point
works, but it certainly isn't useful. I think we are refining the profile
in a manner that increases usability.
<ak> Our refHandle is an application-level session management function.
Not doing anything useful, if no cookies are returned, would be compliant
at best. Possibly, doInitEnvironment=false producers could try to do
better ...</ak>
- void returns allowed: Some web stacks are broken here ... we have changed
all void returns to returning an Extension element.
- dual bindings: These are allowed, but require unique port elements to
define their soap:address.
- certificate authority: What would the value of a WSRP certificate
authority be (relative to HTTPS, that is)?
<ak> Just noted the possibility (consumer authentication) but then
Web server certificates don't really give you that much if you read the
fine print.</ak>
- attachments: Has anyone been looking at the evolution of the attachment
specs?
<ak> Fault handling seemed to be another area of incompatibility.</ak>
<ak> Apologies for the corrupted format of my posting. Line breaks from
the latter 2/3 seem to have been removed. </ak>
Andre Kramer
<andre.kramer@eu. To:
wsrp-wsia@lists.oasis-open.org
citrix.com> cc:
Subject: [wsrp-wsia]
WS-I.org basic profile
10/24/2002 01:18
PM
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?
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC