RE: [ws-rx] Proposal for issue i075 resolution

[Doug Davis <dug@us.ibm.com>]

Warning: a bit of a ramble...

There are two kinds of policies I think
we need to worry about:
1 - policies that are for the entire
sequence (e.g. expires, oops, DA, oops, AckInterval)
2 - policies that are for a particular
message in the sequence

Starting with #2 - I don't think we
should touch these at all - and right now
we don't. 

For #1 let's look at, what I think,
is a similar situation: an event broker.
Let's say that this event broker can
create Subscription resources as a
result of many different actions - not
just a simple Subscribe().  Or, if you
wish, think of it as there being several
flavors of Subscribe() each with
slightly different semantics or access
control or whatever, but the end result
is that a Subscription resource is created
and each is assigned a set of
rules or policies that govern how it
works and sends out notifications.

Regardless of which version of Subscribe()
is called, there may be a single
back-end subscription manager that can
handle all versions as long as the
right config flags are set on the Subscription
resource.  The fact that the
environment chose to expose multiple
Subscribes is simply an implementation
detail. 

I view this multiple endpoint per RMD
situation the same way.  There may be
lots of ways for a sequence to be created
but the endpoint to which the CreateSeq
is sent is akin to the receiver of the
Subscribe() - its the one that is in charge of creating the
sequence and therefore the one that
controls its policies/config parameters.
Individual message policies (which is
out of scope) may differ between operations
or endpoints but a sequence's config
will remain constant.

One thing we need to remember in all
of this - in order for an RMD to span multiple
endpoint then the environment MUST be
setup to support it.  Which means if you
send a CreateSeq to EP1 and then message
#1 to EP2, EP2 MUST know about the
sequence or it will fault.  This
means that the Sequence is already established and
its configuration is already defined
by EP1.  Nothing in the RM spec talks about changing
those config values based on any message
in the seq - so there is no reason to think that
anything other than the policies defined
by the recipient of the CreateSequence
would be "in effect" for this
Sequence.  The endpoint that created the sequence
set up the parameters regardless of
whether or not this sequence is limited to
just this one endpoint or it is shared/available
to multiple.

-Doug

"Giovanni Boschi" <gboschi@sonicsoftware.com>

01/06/2006 11:19 AM

To	"Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "wsrx" <ws-rx@lists.oasis-open.org>
cc
Subject	RE: [ws-rx] Proposal for issue i075 resolution

Say we have endpoints EP1 and EP2, a sender sends a message to each in
that order, and both messages must be included in the same sequence.
Their respective applicable policies are P1 and P2.  It doesn't really
matter what's in the policies, just assume it's something that matters:
I specifically configured EP1 to use P1 rather than P2, and viceversa,
because it's important for whatever reason.

-----
Section 2.1 add new text to follow line 109:
"When a RM Destination provides RM services for more than one endpoint
it is RECOMMENDED that all the endpoints should have the same values for
RM Policy parameters. If the RM Policies are not the same then the RM
Policy parameters in effect for each Sequence is governed by the
endpoint that was used for the <wsrm:CreateSequence> message."
-----

If I'm reading it right, the proposal says that:

- If I call CreateSequence on EP1, then both P1 and P2 are "in effect"
for EP2
- If I call CreateSequence on EP2, then both P1 and P2 are "in effect"
for EP1

The question of which policies are "in effect" for which entities
is
squarely in the scope of WS-PolicyAttachment; we would now be in the
business of "extending" the WSPA rules in the RM policy spec,
in a way
not at all envisioned by WSPA:  a policy tool would now need to
understand RM in order to tell me which policies apply to which
endpoint.

This doesn't sound right to me.

G.


> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Thursday, December 15, 2005 6:26 PM
> To: wsrx
> Subject: [ws-rx] Proposal for issue i075 resolution
> 
> Matt, PaulF, Jacques and I discussed the ideas that were on the
> whiteboard yesterday (options 1 thru 4) and came up with the following
> proposal to resolve issue i075.
> 
> -----
> Section 2.1 add new text to follow line 109:
> "When a RM Destination provides RM services for more than one
endpoint
> it is RECOMMENDED that all the endpoints should have the same values
for
> RM Policy parameters. If the RM Policies are not the same then the
RM
> Policy parameters in effect for each Sequence is governed by the
> endpoint that was used for the <wsrm:CreateSequence> message."
> -----
> 
> We also propose a new issue, to aid the RMS/RMD/AS/AD in cases where
> policies/WSDL are not advertised, or the RMS is not WSDL/policy aware.
> The advantage of this would be that now we have a mechanism for RMD
to
> specify the RM assertion for the Sequence as opposed to per
port/endpoint.
> 
> New issue (not formated to the new issue template -- will do that
in a
> separate email so that it is easier to track):
> 
> -----
> 1) An RMD is allowed to optionally assert in CSR message the policy
> assertion associated with the Sequence. This policy assertion may
> contain parameter that we have defined in WSRMP and/or extensibility
> elements.
> 
> 2) Similarly, the RMS is allowed to optionally assert in the
wsrm:Offer
> part of the CS message the policy assertion associated with the
Sequence
> in the opposite direction.
> 
> The CSR/CS  message will now be:
> 
> <wsrm:CreateSequenceResponse ...>
>    <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>
>    <wsrm:Expires> xs:duration </wsrm:Expires>
?
>    <wsrm:Accept ...>
>      <wsrm:AcksTo ...> wsa:EndpointReferenceType
</wsrm:AcksTo>
>      ...
>    </wsrm:Accept> ?
>    <wsrmp:RMAssertion ...>... </wsrmp:RMAssertion>?
>    ...
> </wsrm:CreateSequenceResponse>
> 
> <wsrm:CreateSequence ...>
>    <wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo>
>    <wsrm:Expires ...> xs:duration </wsrm:Expires>
?
>    <wsrm:Offer ...>
>      <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>
>      <wsrm:Expires ...> xs:duration </wsrm:Expires>
?
>      <wsrmp:RMAssertion ...>... </wsrmp:RMAssertion>?
>      ...
>    </wsrm:Offer> ?
>    ...
> </wsrm:CreateSequence>
> 
> a) Is it optional for the RMD to include wsrmp:RMAssertion?
> yes
> 
> b) Is the wsrmp:RMAssertion in the CSR definitive?
> yes
> 
> c) Can the wsp:optional attribute be present in the CS/CSR messages
on
> wsrmp:RMAssertion?
> no
> -----
>