Although I'm not enthusiastic about
the idea of a CS "intended" to an endpoint for which it has no
meaning,
I can go with the proposal currently on
the table.
Jacques
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Thursday, January 19, 2006
12:51 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i075: a
proposal
Jacques,
the wording change is ok but I don't think the RM spec should be making any
statements about what's behind (or not behind) the RMD. So saying the RMD must
prevent the CS from reaching some other destination is an implementation detail.
If its not supposed to get there then a fault will be generated, but
either way its none of the RM spec's concern how the RMD/AD chooses to manage
the incoming messages.
-Doug
Jacques
Durand
<JDurand@us.fujitsu.com>
01/19/2006 03:00 PM
|
To
|
"'Anish Karmarkar'"
<Anish.Karmarkar@oracle.com>
|
cc
|
Doug Davis/Raleigh/IBM@IBMUS,
ws-rx@lists.oasis-open.org
|
Subject
|
RE: [ws-rx] i075: a proposal
|
|
Not sure what the
latest about this.
Regardless of how hollow the policy assertion becomes, it seems we still have
potential policies associated *somehow* to services endpoints, that could
be different from one to the other.
So the
latest proposal currently on the table is still relevant:
>
After line 485 in [1]:
> The RM Policy parameters in effect for each Sequence is governed by the
> endpoint
> that was used for the <wsrm:CreateSequence> message.
Comments:
- "used for" is a little vague. How about " ...endpoint to which
the <wsrm:CreateSequence> message was destined."
- add a requirement: "When the CS is destined to an endpoint beyond the
RMD, the RMD must prevent it to reach this destination."
Jacques
-----Original
Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
Sent: Thursday, January 12, 2006 12:35 PM
To: Jacques Durand
Cc: Doug Davis; ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] i075: a proposal
Jacques Durand wrote:
> Anish:
>
> Do we really need to keep this "static advertising" within scope
of this
> specification?
In that
case, we should change the RM assertion (modulo the resolution
of issues around AI and MaxMessageNumber) to:
<wsrmp:RMAssertion
[wsp:Optional="true"]? ... >
<wsrmp:AcknowledgementInterval
Milliseconds="xs:unsignedLong" ... /> ?
<wsrmp:MaxMessageNumber Number="xs:unsignedLong" ... />
?
</wsrmp:RMAssertion>
Note that
the "..." from the previous pseudo-schema is removed. I.e., no
extensibility point. The RMAssertion would essentially say whether RM is
required/supported (depending on the value of wsp:Optional).
If we do
that, the issue of RM policy/parameters conflicting across WSDL
ports/endpoints does not arise.
... and
if you want to use extensibility, just use the one in CSR message.
-Anish
--
> We
know that some out of band communication is certainly expected for
> publishing DAs, etc, which is now considered out of scope. We could
> expect a client to learn about parameters the same way.
>
> Also the static advertising we are talking about here is about protocol
> parameters that some implementations may want to change from one
> sequence to the other, based on various factors (CPU load,
> negotiation...) that may have little to do with the service definition.
> It is unclear what semantics a presence in WSDL would have - mostly
> advisory as you say.
>
> That is why I'd propose to discuss new issue "proposed-03" asap,
before
> i075.
>
> - Jacques
>
>
>
> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Thursday, January 12, 2006 11:35 AM
> To: Doug Davis
> Cc: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] i075: a proposal
>
> I mostly agree with the statement below.
>
> But I think there is an issue with the idea of attaching RM policy
> parameters to WSDL endpoint given the resolution of issue i010 -- which
> states that both RMS and RMDs can span multiple endpoints (EPRs) and/or
> multiple WSDL endpoint/ports.
>
> The fundamental unit/scope in WSRM is the Sequence and RM policy
> assertion parameters should be associated with the Sequence rather than
> a WSDL port/endpoint (I know that there is a possibility that we may end
> up with zero RM policy parameters in the WSRM policy doc, but given the
> extensibility within the assertion, there may be parameters specified
> that are not defined by the WSRM policy document). Which is why, I think
> it makes sense to include such parameters in the CreateSeqenceResponse
> rather than in the WSDL. But there is certainly a need to advertise the
> policy assertion/parameter through WSDL so that it is statically (before
> creating the Sequence) available. But I view such WSDL attachment (RM
> policy parameters, not the assertion itself) as advisory rather than
> definitive. I think anything present in the CreateSeqenceResponse is
> definitive. I.e., parameters in the CSR trumps parameters in the WSDL.
>
> -Anish
> --
>
> Doug Davis wrote:
> >
> > I thought Umit had proposed this but I couldn't find the email,
sorry if
> > its a dup, but just to make sure there's a formal proposal out
there, I
> > believe all we need to do for issue 075 is to add this text:
> >
> > After line 485 in [1]:
> > The RM Policy parameters in effect for each Sequence is
governed by the
> > endpoint
> > that was used for the <wsrm:CreateSequence> message.
> >
> > [1]
> >
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15177/wsrm-1.1-spec-cd-01.pdf
>
> >
> >
> > -Doug
>