Steve:
> What I
believe you were trying to say is that there is no
association with an Application Destination,
> i.e. the endpoint to which the
message should be delivered.
Right. The CS is of course "associated"
(intende to) the RMD endpoint. Only in our i075 case, the RMD endpoint is distinct
from AD endpoint(s), which means the RMD has no indication about which AD instance
was "motivating" this new sequence, just by looking at the CS
contents.
>... So how can you possibly send a
CSReq to an RMD if CSReq isn't sent reliably?
I take that as a challenge to the proposal
currently on the table, not to the point I am trying to make.
My quick answer would be: all the operations
for creating, closing, terminating sequences have the same status: they are not
sent "reliably", nor are their responses. However, that is not such
a serious issue: by nature, they can be repeated without trouble. An RMS can
always repeat a CS if it did not get the previous CSR, until it gets the CSR. In
the worst case, unused sequences would be created in RMD. The response message
is then a way to provide "some" reliability to these operations
(which is the subject of i078 for Termination).
Regards,
Jacques
From: Winkler, Steve [mailto:steve.winkler@sap.com]
Sent: Friday, January 06, 2006
12:18 PM
To: Jacques
Durand; Paul Fremantle; Giovanni Boschi
Cc: Anish Karmarkar; wsrx
Subject: RE: [ws-rx] Proposal for
issue i075 resolution
Hi Jacques,
Though I think I understand what you're
saying, you may want to be more precise. You state
"The snag is: the CS
message is not associated with any particular endpoint."
Which isn't quite true. The CS
message is targetted at the RMD, which by definition, is an endpoint.
Kind of (see below). What I believe you were trying to say is
that there is no association with an Application Destination, i.e.
the endpoint to which the message should be delivered.
This brings me to a potential new
issue. The RMD is currently defined in the context of a message that is
sent reliably, however, a sequence needs to be established in order to send a
message reliably. So how can you possibly send a CSReq to an RMD if CSReq
isn't sent reliably?
We may need to work on these
definitions...
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Friday, Jan 06, 2006 12:02
PM
To: 'Paul Fremantle'; Giovanni
Boschi
Cc: Anish Karmarkar; wsrx
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