Sunil:
A few
comments, which I don't see critical, but even if we keep the
annotation
as you
propose, we need to explicitly state which of the following semantics it
has:
- It
should be possible to express that only input messages are concerned by the RM
features
even when attaching a service config annotation
at service / port / op level, (i.e. without having to
"override" at message level, in order to exclude the output
message.)
E.g.
scope="input", (future versions will handle: scope="output",
scope="input-ouput")
-
The annotation you propose is not always about capability: in some cases
the RM features *must* be used
by the
client. In other words, the annotation may have different
meaning
for
each side. Consider the following cases, each gives the annotation a different
meaning:
1.
server capability (this is your service config I think): WS supports this RM
feature if client asks for using it.
Attribute: clientuse="possible".
2.
client requirement: client must use the feature, because the WS implementation
assumes it does
for a
proper WS behavior (e.g. ordering required, when using repeatedly
a monitoring operation)
Attribute: clientuse="required".
3.
server requirement: E.g. WS1 is a deployed pay-per-use WS, which will respond to
users via requests
issued
to users. The user then has to implement a "response" WSDL,
describing a service WS2 that
supports these requests. So we may want to specify in the WSDL 2 that
the WS implementation or
deployment MUST support the RM feature, because the client (here
the deployed WS1) will use it.
Attribute: serveruse="required" (or clientuse="possible"?)
Beyond
this, it becomes user-specific (e.g. according to an SLA) and would require more
advanced
policies or agreements attached to user ID.
Jacques
-----Original Message-----
From: Sunil Kunisetty
[mailto:]
Sent: Tuesday, January 20, 2004
2:57 PM
To:
Subject: Re: [wsrm]
[REL-49]proposal for REL-49
Here is my AI
from the last F2F to simply the proposal for REL-49.
Salient points are:
A non-normative proposal for annotating Service WSDL with WSRM
capabilities
Based on WSDL extensibility element concept.
Defines only one extensible schema element (ServiceConfig)
This element could be used at any of the following WSDL levels:
message/input/output/operation/binding/bindingOperation/port/service
This service element could be used inside any vendor specific policy
elements or directly.
Example of a
<ServiceConfig> usage inside the operation 'foorBar'.
<portType name="fooPortType">
<operation
name="fooBar">
<wsrm:ServiceConfig xmlns:wsrm="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"
>
<wsrm-guaranteed-delivery>
<!-- List the reply patterns supported by this service.
-->
<wsrm:reply-patterns
callback="{boolean}"
poll="{boolean}"
response="{boolean}"
/>
</wsrm-guaranteed-delivery>
<wsrm-duplicate-elimination/>
<wsrm-message-ordering />
</wsrm:ServiceConfig>
<input message="fooMessageIn" />
<input message="fooMessageOut>
</operation>
</portType>
Schema for such an element would
be:
<xsd:element name="ServiceConfig"
type="wsrm:ServiceConfigType" />
<!-- ServiceConfig WSDL Extensible Element Type
-->
<xsd:complexType
name="ServiceConfigType">
<xsd:complexContent>
<xsd:extension base="wsrm:RmBaseType">
<xsd:sequence>
<xsd:element
name="wsrm-guaranteed-delivery"
type="wsrm:wsrm-guaranteed-delivery-type" minOccurs="0"/>
<xsd:element
name="wsrm-duplicate-elimination" type="wsrm:EmptyType"
minOccurs="0"/>
<xsd:element name="wsrm-message-order" type="wsrm:EmptyType"
minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType
name="wsrm-guaranteed-delivery-type">
<xsd:complexContent>
<xsd:extension base="wsrm:EmptyType">
<xsd:sequence>
<xsd:element name="reply-patterns"
type="wsrm:reply-patterns-type" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="reply-patterns-type">
<xsd:complexContent>
<xsd:extension base="wsrm:EmptyType">
<xsd:attribute name="callback"
type="xsd:boolean" use="optional"/>
<xsd:attribute name="poll"
type="xsd:boolean" use="optional"/>
<xsd:attribute name="response"
type="xsd:boolean" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
-Sunil
