[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Proposal for issue i075 resolution
What Doug D proposed still requires some concrete support in the spec:
" The RM Policy parameters in effect for each Sequence is governed by the endpoint that was used for the <wsrm:CreateSequence> message."
The snag is: the CS message is not associated with any particular endpoint. This is purely an RMS-to-RMD operation, not associated with any "application" message yet, and nothing requires the RMD to be aware of which destination endpoint this sequence is created for. For this to work I suggest an additional (optional) element in CS:
/wsrm:CreateSequence/wsrm:IntendedTo
Of type wsa:EndpointReferenceType.
By
indicating this, the RMS signals to the RMD that it expects messages sent within
this sequence to follow the policy in effect for the intended endpoint. If this
element is absent, an RMD that serves several endpoints with different policies
will make its own decision, communicated by CSR.
Given this, I believe that with the current i075 proposal on the table, we do not have to worry about different policies (meaning different AIs and MaxNumbers) for multiple endpoints.
Consider the following scenario where the same pair of RMS-RMD is shared by different pairs AS endpoint -AD endpoint (AS-AD for short):
Step 1. AS is using RMS to reliably send a request to AD1 endpoint (AD1 for short), associated with RMD. In this scenario AS is not even aware of which policy is supported for AD1 (or it may have learned about it out of band - only use for AS is to make a decision to send or not to AD1).
Step 2. This was the first message for AD1, so RMS is creating a sequence that it will dedicate to messages intended to AD1 only. In the CS, the wsrm:IntendedTo takes the same value as the wsa:To of the (not yet transmitted) app message. The CSR tells the RMS which AI and MaxNumber are in effect for this sequence, per the policy associated with AD1. Then RMS sends the app message to AD1.
Step 3. AS is now sending a message to AD2 also served by the same RMD. The RMS creates a different sequence, intended to AD2. The CSR returns a new pair (AI, MaxNumber) based on AD2 policy.
Step N. Any new message sent by AS will be assigned by RMS to the right sequence, based on its destination endpoint info (AD1 or AD2). So the message is subject to the right policy which may differ from one seq to the other.
So I still suggest that the extension to Section 2.1 (quoted by Giovanni) in the current proposal is unnecessary. Even Paul's latest "recommendation" is.
Jacques
-----Original Message-----
From: Paul
Fremantle [mailto:paul@wso2.com]
Sent: Friday, January 06, 2006 8:45 AM
To: Giovanni Boschi
Cc: Anish Karmarkar;
wsrx
Subject: Re: [ws-rx] Proposal for issue i075
resolution
Giovanni
I agree with what you are saying. I believe that this is in the
domain
of the WS-Policy working group to agree
on.
I also think that there is a danger of us losing track of where
we are.
We changed the wording of the spec to *allow*
the multiple endpoint
scenario, but we did not intend to
define how it works (implementation
specific). It seems
to me it is also up to the providers to ensure that
the
policies match in that scenario. I suggest we simply use this
wording alone:
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.
Paul
Giovanni Boschi wrote:
> 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
>> -----
>>
>>
>
>
>
--
Paul Fremantle
VP/Technology, WSO2 and
OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]