Doug:
We do not seem to have the same premises
in mind when talking about this, so let me try to clarify:
> The CS _is_ associated with an endpoint - its the
endpoint that the CS is sent to :-)
> What that endpoint/EPR is is not defined by the
spec nor should it be. It could be the same EPR as one of the app
messages, it could be some common broker or it could be some 3rd party (RM manager)
endpoint.
So you assume that the CS could be sent to
an AD EPR, like any application message. I always assumed that a CS and other
sequence operation messages, are sent to the RMD endpoint, whatever it is. In
some cases this is the same endpoint as the application behind. But in i075 use
cases, it can be distinct. Are we saying that in such cases, unlike for
application messages, the RMD would "block" the CS to make sure it
never reaches the endpoint it was technically sent to?
In that case, sure the RMD would have a
clue about which policy to apply - but it is rather odd to send a CS to
another endpoint than an RM manager, which is the actual consumer of all operations
on sequences.
> I don't think the spec should say anything about
how the RMS or AS chooses a sequence - which is the direction I think your
examine leads.
No. I am only indicating a way the RMS can
convey in the CS which destination endpoint should be associated with the new sequence
(regardless of who decides to create this sequence), when the RMS is given this
opportunity. Sending the CS to this destination endpoint as you seem to suggest
is just another way to do the same thing - sure it does not use a new
element (though relies on wsa headers that must be understood by RMD?) but our
developers clearly dislike the trick....
Always sending the CS and other sequence
ops to the RMD endpoint (in the same way as CSR are always sent back to the RMS
endpoint and not an AS endpoint behind) is another way to keep things simple...
Am I at least restating the options
correctly?
Thanks,
Jacques
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Friday, January 06, 2006
12:25 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposal for
issue i075 resolution
Jacques,
I'm not sure I really understand this so I don't see why we need this. The
Sequence might not ever be associated with application messages. Imagine
the case where a sequence is used as a long-lived thing between two servers (or
brokers) and all apps use the same sequence. The sequence can be
established long before (and independent of) any app message being sent.
The
CS _is_ associated with an endpoint - its the endpoint that the CS is sent to :-)
What that endpoint/EPR is is not defined by the spec nor should
it be. It could be the same EPR as one of the app messages, it could be
some common broker or it could be some 3rd party (RM manager) endpoint. That's
an implementation detail and if that's an issue then its there whether or not a
sequence spans multiple endpoints. Ultimately, once the RMS figures out
where to send the CS (even in the single endpoint case), its that endpoint's policy
that should govern the sequence - I don't see why it needs to be any more
complicated than that.
w.r.t.
you example - I don't think the spec should say anything about how the RMS or
AS chooses a sequence - which is the direction I think your examine leads. Its
very possible that even between two endpoints/EPRs there could be multiple
sequences being used - this is all application dependent and IMO should remain
out of scope.
thanks,
-Doug
Jacques
Durand
<JDurand@us.fujitsu.com>
01/06/2006 03:02 PM
|
To
|
"'Paul Fremantle'"
<paul@wso2.com>, 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
|
|
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