Chris, you said ...
> 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.
This is the contentious requirement. You want the
spec to cover situations where
one of the participants does not adhere to the spec or does
not have enough information
to follow the spec. I don't think this is
reasonable.
All the best, Ashok
From: Christopher B Ferris
[mailto:]
Sent: Thursday, March 09, 2006 8:24
AM
To: Anish Karmarkar
Cc: wsrx
Subject: Re:
[ws-rx] issue i021 requirements
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:fault
then 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
> --
>
>
>
