As per my AI from the last con. call, here are the new wordings
assuming that
this proposal is going to be non-normative
Tom & Jacques,
Feel free to pitch in and suggest any changes. I was very colloquial
in my wordings.
----------------------------------------------------------------------------------------------------------
Annotating the Service WSDL with Reliable Messaging capabilities
will be
very useful for the consumer of the Service as it can then leverage
the Reliable
Messaging features correctly & effectively. While there is
on going work and
research on how to specify such capabilities and policies, currently
there is no
one widely accepted open standard which can be embraced right
away. While we
can quickly cook up one such notation in this specification,
it is felt that such
a notation should be defined in a different specification so
that it can be
reused for all policy and capability declarations and not just
Reliable Messaging
capabilities. Also, we don't want to overlay or compete when
those specifications
becomes a widely accepted public standard. Hence, we would like
to propose
a non normative solution to annotate the Service WSDL with Reliable
Messaging
capabilities as an interim solution.
The solution is based on defining a WS Reliable Messaging ServiceConfig
element.
that can be used in the WSDL where ever element extensibility
is permitted such as
at message,input,output,operation,binding,bindingOperation,port,service
levels.
The schema of the element is as follows:
<insert
the schema here>
Vendors can define this element in their proprietary namespace
or define this
element locally in the Service WSDL itself
The element consists of 3 optional sub-elements one each
for the 3 RM agreement
items. All these sub-elements have an attribute by name " usage"
indicating the
requirement of the corresponding RM agreement item. It
could take one of the 2 possible
values: required or optional. A required
value indicates that particular RM agreement
MUST be used for that Web Service invocation. An optional
value indicates that
the Consumer MAY elect to use that RM agreement for this
invocation.
Here is an example with the usage of this element.
<portType name="fooPortType">
<operation name="fooBar">
<tns:ServiceConfig >
<wsrm-guaranteed-delivery usage="{required|optional}">
<!-- List the reply patterns supported by this service. -->
<wsrm:reply-patterns
callback="{boolean}"
poll="{boolean}"
response="{boolean}"
/>
</wsrm-guaranteed-delivery>
<wsrm-duplicate-elimination usage="{required|optional}" />
<wsrm-message-orderingusage="{required|optional}" />
</tns:ServiceConfig>
<input message="fooMessageIn" />
<input message="fooMessageOut>
</operation>
</portType>
--------------------------------------------------------------------------------------------------------------
-Sunil
