ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] Proposal for issue i075 resolution
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Fri, 6 Jan 2006 11:53:38 -0500
For whatever reason there may be a need
for two different endpoints, that share
a single RM persistence/manager, to
expose multiple ways to create RM sequences.
This means that each may need to set
different config options for each - I see no
reason why we should force all endpoints
that may expose a CreateSeq for a shared
sequence to have the same policies.
The one that created the sequence was chosen
for a reason - one of those reasons
could be because the RMS liked its policies better.
Unless the various endpoints are lying
about their policies we have to assume there's
a reason they different - and as such
let the caller choose which policies it wants.
All we need to say is:
The RM Policy parameters in effect for
each Sequence is governed by the endpoint
that was used for the <wsrm:CreateSequence>
message.
-Doug
Paul Fremantle <paul@wso2.com>
01/06/2006 11:44 AM
|
To
| Giovanni Boschi <gboschi@sonicsoftware.com>
|
cc
| Anish Karmarkar <Anish.Karmarkar@oracle.com>,
wsrx <ws-rx@lists.oasis-open.org>
|
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]