RE: [ws-rx] i075: a proposal

[Doug Davis <dug@us.ibm.com>]

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
>