Anish,
I don't necessarily disagree with these
requirements.
However, as I indicated in my previous
notes, and during the discussion on
last week's call, It isn't clear to
me that every RM enabled endpoint will have
the capacity to apply the RM semantics
on a message-by-message basis.
There are certain situations, such as
a gateway, that may not have access to the
WSDL/policy to determine which messages
should be included in an RM
Sequence. Further more, even if the
WSDL/policy WERE available, there may be
considerable overhead involved in having
to parse the messages (in the
gateway scenario) to determine if they
match those messages which have
been annotated as needing to be sent
reliably.
In such cases where a source endpoint
is just on/off for all messages that
pass though, I think that the corresponding
destination endpoint should NOT
reject messages that are sent reliably
yet are not indicated as being required
to be sent reliably in the WSDL/policy.
Thus, adding to my proposed addendum
to Sanjay's proposal:
If an RM policy assertion is
attached to any of:
wsdl:binding/wsdl:operation/wsdl:input
wsdl:binding/wsdl:operation/wsdl:output
wsdl:binding/wsdl:operation/wsdl:faultthen
an RM policy assertion, specifying wsp:Optional=true MUST be attached to
the corresponding wsdl:binding or wsdl:port, indicating that the endpoint
supports WS-RM. Any messages, regardless of whether they have an attached
Message Policy Subject RM policy assertion, MAY be sent to that endpoint
using WS-RM. Additionally, the receiving endpoint MUST NOT reject any message
belonging to a Sequence, simply because there was no Message Policy Subject
RM policy assertion attached to that message.
I would offer the following explanation/rationale:
There might be certain RM implementations
that are incapable of applying RM QoS semantics on a per-message basis.
In order
to ensure the broadest interoperability,
when an endpoint decorates its WSDL with RM policy assertions using Message
Policy Subject,
it must also be prepared to accept that
all messages sent to that endpoint might be sent within the context of
an RM Sequence, regardless
of whether the corresponding wsdl:input,
wsdl:output or wsdl:fault had an attached RM policy assertion.
Rather than turn away messages that
were unnecessarily sent with RM semantics, the receiving endpoint described
by the WSDL
must accept these messages.
By attaching an RM policy assertion
that specifies wsp:Optional="true" to the corresponding endpoint
that has attached RM policy
assertions at the Message Policy Subject
level, the endpoint is describing the above constraint in policy.
Cheers,
Christopher Ferris
STSM, Software Group Standards Strategy
email:
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
Anish Karmarkar <>
wrote on 03/09/2006 08:01:12 AM:
> I took an action during last week's concall to send requirements for
> what I see as the desired semantics for issue i021. Sorry for being
late
> but I'm on vacation till 17th march (my regrets for the next 2 concalls).
>
> Requirements:
>
> 1) Provide the capability to specify in WSDL that a particular message
> (input, output, or fault) MUST be sent reliably within a WSRM Sequence.
>
> 2) Provide the capability to specify in WSDL that a particular message
> (input, output, or fault) MAY be sent using WSRM. The means that it
is
> the sender's choice (and not the receiver's) whether the message is
sent
> reliably or not.
>
> 3) Provide the capability to specify in a WSDL binding/port that all
> messages sent using that binding/port MUST be sent reliably
within a
> WSRM Sequence (but not in the same Sequence). This potentially could
be
> syntactic sugar based on how the capability in (1) is provided.
>
> 4) Provide the capability to specify in a WSDL binding/port that all
> messages sent using that binding/port MAY be sent reliably within
a
> WSRM Sequence (but not in the same Sequence). The means that it is
the
> sender's choice (and not the receiver's) whether the message is sent
> reliably or not. This potentially could be syntactic sugar based on
how
> the capability in (2) is provided.
>
> 5) The capability in (1) and (2) should not impose onerous constrains
on
> other messages within the same portType/Binding/Port wrt reliability.
> For example, one should have the ability to specify that a particular
> in-message MUST be sent reliably without requiring any reliability
> constrains on the out-message (supported or required).
>
> Consider a port which is a purchase order service providing 'submitPO'
> and 'getStatus' operations. The submitPO operation is reliable, secure
> and transacted operation which returns a PO number. Both the in and
out
> messages for submitPO are sent reliably. The getStatus operations
> requires the PO number and returns a status (pending, approved) --
this
> is not a secure, reliable or a transacted operation. The capabilities
> provided in (1) - (4) above should not force the port to support
> reliability for the getStatus operation.
>
> -Anish
> --
>
>
>
