[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] [i021]: update on NO proposal ... and maybe a hint of a proposal
1. More precise assessment of why attaching RMAssertion at
message binding level is not that exciting, at least in the context of i021: - really
we are talking of a policy here that governs RMS and RMD behavior w/r to entire Sequences (per WS-RM Policy
definitions). not to single messages (or message types) as
subjects. E.g. InactivityTimeout, AckIntervals, etc are behavioral properties
of RMD at Sequence granularity at
best, not policies that apply to individual messages (does not
make sense). -
assuming we still attach RMAssertion at message binding with the understanding
that the meaning is like "this message must be sent over via an RMS and a sequence that follows
policy XYZ" that still requires a slew of precautions: prevent
conflict with other RM policies at endpoint level, make sure the client RMS uses
different sequences for sending messages related to different policies, have
the RMS know about which policy applies to which message / operation... etc. Kind of getting more
trouble than we were bargaining for. - I
feel this is rather a kludge for what we really need here: a role-based
assignment of policies. We just want to say that the endpoint will act in the
Destination role w/r to this protocol policy, regardless of the message type -
nothing more. 2. Given the lack of support for roles in
WS-Policy, and assuming there is no reason to always force outbound messages to
follow the same RM policy as inbound messages, then I'd propose the
following: -
get rid
of the RMAssertion container as we know it. -
Replace it
with RMSAssertion and RMDAssertion. Each one of these will be container for assertion
items that concern respectively the behavior of a Source and of a Destination
endpoints, relative to a sequence. -
Then if we
want a policy that only concerns reliability of received messages, we only use RMDAssertion
in the policy. Same if we want to express a policy for the endpoint as a Source
-> use RMSAssertion. -
Note
that does not preclude a more fine-grained attachment than endpoint. -
If we want
to add the client-related assertion items when defining a Destination policy
for an endpoint (like done today within RMAssertion), but just for information
purpose, we can do something like: <wsp:Policy wsu:Id="MyDestinationPolicy" > <wsrmp:RMSAssertion wsp:Usage='Informational'> ... </ wsrmp:RMSAssertion> <wsrmp:RMDAssertion > ... </ wsrmp:RMDAssertion> </wsp:Policy > Opinion? Jacques From: OK, I
thought we had two decent alternatives for i021, but I now believe we have
none... (sigh) See below: 1. First
one I heard is: Attach an RM Assertion to message level in the binding, e.g.
with wsdl:binding/wsdl:operation/wsdl:input as policy subject. At first
that looks good, but: - really
we are talking of a policy here that applies to RMS and RMD behavior, not to
single messages as subjects. E.g. InactivityTimeout, AckIntervals, etc are
behavioral properties of RMD as a QoS provider, not properties that apply to
individual messages. -
assuming we still do that with the understanding that the meaning is like
"this message must be sent over via an RMS that follows policy
XYZ" that still requires a slew of precautions: avoid conflicting RM
policies at endpoint level, make sure the client uses different sequences for
messages related to different policies, have the RMS know about which policy
applies to which message... etc. Kind of getting more trouble than we were
bargaining for. I feel it is rather a cludge for what we really need here: a
role-based assignment of policies. 2. Second
one, is to declare that it is perfectly our right to say that particular policy
assertions (here RMAssertions) per their very nature, only concern messages
that are received by the endpoint to which they are attached. That would not
solve the problem of how to deal with outbound message flow if we want to make
these reliable too. We could "tag" an assertion whether it applies to
the endpoint itself or to clients to the endpoint --> kind of ad-hoc
substitute for a more general missing role mechanism. 3. Other
option: We could also decide to only attach to endpoint the assertions that
relate to Destination if we want to control its RMD behavior only (meaning
inbound messages only), and assertions that relate to Source only if we want to
control its RMS behavior (outbound messages). But a policy that governs a
communication RMS-RMD is now split in two separate parts. The best
way to get this solved is by fixing the policy framework: Otherwise
it sounds like back to the old days when the notion of "role" did not
exist, policies had to be assigned directly to every subjects 1 by 1... (that
is what (1) above is about) Jacques
-----Original
Message----- Yalcinalp,
Umit wrote: > Since
WSDL request/response operations are only mapped to synchronous Response
reliability is much easier to provide if the application For
pragmatic reasons, I see no reason to go beyond specifying a default Tom Rutt
>--umit
-- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]