RE: [ws-rx] i075: a proposal

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

Title: RE: [ws-rx] i075: a proposal

If we do not define anything within the RMAssertion then, from our perspective, there can be no conflicting policies. If some other individual or group defines, by extension, either attributes or child elements of the RMAssertion then it is up to them to define what happens if and when these attributes or elements "conflict".

 

For example someone could define an extension child element of RMAssertion named "UseUniqueSequence". The presence of this element means that the RMS/RMD should negotiate a unique sequence for the corresponding endpoint. It is the nature of this extension that it can't possibly conflict with similarly extended policies attached to other endpoints so the author of such an extenstion would not, in this case, be required to address the "policies conflict for same sequence" issue.

 

What I'm saying is that, unless we put something in the RMAssertion that can conflict across a sequence, we don't have to say anything (more accurately can't say anything) about how to resolve such possible conflicts.

 

We may want to add a meta-note to the exposition of the RMAsserstion extensions points saying that "putting something here may create a situation in which multiple, sequence-specific policies conflict" and "sorry we can't help you with this".

 

- g

---

From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Thursday, January 19, 2006 12:00 PM
To: 'Anish Karmarkar'
Cc: Doug Davis; 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
>