← Prev in month ← Prev in thread
Next in thread → Next in month →

REFURBISHED ISSUE: i021

From
Jacques Durand <>
Date
2005-09-23T23:36:08+00:00
ID
Thread
REFURBISHED ISSUE: i021
i021 freshened a bit:

 

Description:

Last sentence of Section 2
in RM-Policy spec says that an RM policy MUST apply to all messages in a
binding (when associated to binding). That means applying equally (same timing
parameters, etc.) to both in and out messages of an operation of type
request-response. However, clearly the DA requirements are different for each
endpoint (Client and WS), and so are the performance requirements and
capabilities regarding the protocol. For example, a WS may need ExactlyOnce for
incoming messages, and consequently implement the protocol along with its
receiving functions (sending Acks), but not willing to implement the RM sending
functions (resending mechanism...) - or at least not with the same
parameter values - if the responses need not be reliable. In addition,
when deployed in a WS-I-compliant (Basic Profile) environment, a reliable Response
has to be sent over an HTTP response. The RMS behavior (which is now the sender
of the Response) would need to implement a much more constrained and context-dependent
resending mechanism, as response messages can only be resent as responses to
request resendings.

                                                                               

Justification:

Enforcing same protocol
policies for inbound and outbound messages may create unnecessary burden to a
WS endpoint for which RMD-only functions are sufficient. In addition, the
resending behavior for synchronous responses being more constrained, cannot
obey the same parameters. 

 

Proposal:

A couple of proposal
directions (either / or):

1. Assert somehow that RM
policy assertions are "oriented" by default, i.e. only apply to all
"in" messages from a Client to a WS endpoint unless specified
otherwise.

2. Attach policy assertions
at message level if needed (or provide means to override at message level, e.g.
attach a "void" policy to an out message, if no reliability needed
here.)
← Prev in month ← Prev in thread
Next in thread → Next in month →