OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Title: 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
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]