Ashok,
+1
and especially:
> If a server attaches <RM optional = 'true'>
to an output message
> it says that the message may or may not be transmitted reliably.
> The client may or may not be prepared to accept the message reliably.
which I think confirms that what I was
trying to convey with my proposal is consistent with
your understanding of the semantics
of wsp:Optional.
Cheers,
Christopher Ferris
STSM, Software Group Standards Strategy
email:
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
"Ashok Malhotra" <>
wrote on 03/07/2006 10:11:22 PM:
> Paul:
> Thank you for trying to ferret out the confusion.
>
> My understanding of wsp:optional is a bit different and I
> don't think we need to define our own optional semantics.
>
> If you attach wsp:optional = 'true' to an output message
> you are saying that that message may or may not be transmitted
> reliably. In WS-Policy terms this means that there will
> be a policy option created that will transmit that message reliably
> and an option created that will not transmit the message reliably.
> Both policy options are equally valid and which option is chosen
> depends on what the client and server agree on.
>
> If a server attaches <RM optional = 'true'> to an output message
> it says that the message may or may not be transmitted reliably.
> The client may or may not be prepared to accept the message reliably.
> There needs to be communication between the client and server to
> determine whether the message is transmitted reliably or not.
> This may take the form of policy intersection or negotiation.
> But at the end of it the server and the client will agree on whether
> the message shd be transmitted reliably or not.
>
>
> All the best, Ashok
>
>
> > -----Original Message-----
> > From: Paul Fremantle [mailto:]
> > Sent: Tuesday, March 07, 2006 9:36 AM
> > To: wsrx
> > Subject: [ws-rx] slightly new i021 proposal
> >
> > Firstly, before anyone (or Umit) ticks me off, this is not MY
> > proposal.
> > It is in effect an amalgam of previous proposals.
> >
> > Secondly, the intent of this proposal is to effectively take
> > the previous proposal from Sanjay, amended by Chris, and make
> > one key change. The change is for us to define our own model
> > of what "optional"
> > means. The reason is that I think that if we have the
> > wsp:Optional marker on output messages it has an unintended
> > consequence that it implies the Service Client can and should
> > support RM.
> >
> > I see this policy being used in the following ways.
> >
> > 1) simply mark a whole endpoint optional. RM can be used on
> > either path or not without problems
> > 2) mark a whole endpoint non-optional. RM must be used on all
> > interactions.
> > 3) mark the endpoint optional and certain messages with
> > optional markers. This is a way expressing a preference that
> > these messages are delivered reliably. For example, mark all
> > input messages optionally reliable.
> > 4) mark the endpoint optional and certain messages
> > non-optional. This expresses that these specific messages
> > MUST be delivered reliably. One valid approach to this is to
> > deliver all messages reliably.
> >
> > Paul
> >
> > Based on WSRMP WD06/CD3
> >
> >
> >
> > In section 2.2 change:
> >
> >
> >
> > Replace Line 101 with :
> >
> >
> >
> > <wsrmp:RMAssertion [optional="true"]? ... >
> >
> >
> >
> > Replace lines 108-111 with
> >
> > /wsrmp:RMAssertion/@wsrmp:optional="true"
> >
> > The behavior indicated by the assertion is optional - that
> > WS-ReliableMessaging MAY or MAY NOT be used. The attachment
> > of an assertion marked optional does not imply that either
> > the service client or service provider implements either or
> > both an RMD or an RMS, and if no sequence is available, the
> > interaction SHOULD continue unreliably.
> >
> >
> >
> > Replace the entire content of section 2.3 (Assertion
> > Attachment) in the WS-RM Policy specification with the following:
> >
> >
> >
> > The RM policy assertion is allowed to have the following
> > Policy Subjects
> > [WS-PolicyAttachment]:
> >
> >
> >
> > Endpoint Policy Subject
> >
> > Message Policy Subject
> >
> >
> >
> > WS-PolicyAttachment defines a set of WSDL/1.1 [WSDL 1.1]
> > policy attachment points for each of the above Policy
> > Subjects. Since an RM policy assertion specifies a concrete
> > behavior, it MUST NOT be attached to the abstract WSDL policy
> > attachment points.
> >
> >
> >
> > The following is the list of WSDL/1.1 elements whose scope
> > contains the Policy Subjects allowed for an RM policy
> > assertion but which MUST NOT have RM policy assertions attached:
> >
> >
> >
> > wsdl:message
> >
> > wsdl:portType/wsdl:operation/wsdl:input
> >
> > wsdl:portType/wsdl:operation/wsdl:output
> >
> > wsdl:portType/wsdl:operation/wsdl:fault
> >
> > wsdl:portType
> >
> >
> >
> > The following is the list of WSDL/1.1 elements whose scope
> > contains the Policy Subjects allowed for an RM policy
> > assertion and which MAY have RM policy assertions attached:
> >
> > wsdl:port
> >
> > wsdl:binding
> >
> > wsdl:binding/wsdl:operation/wsdl:input
> >
> > wsdl:binding/wsdl:operation/wsdl:output
> >
> > wsdl:binding/wsdl:operation/wsdl:fault
> >
> >
> >
> > If an RM policy assertion is attached to any of:
> >
> >
> >
> > * wsdl:binding/wsdl:operation/wsdl:input
> >
> > * wsdl:binding/wsdl:operation/wsdl:output
> >
> > * wsdl:binding/wsdl:operation/wsdl:fault
> >
> >
> >
> > then an RM policy assertion, specifying optional=true MUST be
> > attached to the corresponding wsdl:binding or wsdl:port,
> > indicating that the endpoint supports WS-RM. Any messages,
> > regardless of whether they have an attached Message Policy
> > Subject RM policy assertion, MAY be sent to that endpoint
> > using WS-RM. Additionally, the receiving endpoint MUST NOT
> > reject any message belonging to a Sequence, simply because
> > there was no Message Policy Subject RM policy assertion
> > attached to that message.
> >
> >
> >
> > If the RM policy assertion appears in a policy expression
> > attached to a wsdl:binding as well as to the individual
> > wsdl:binding level message
> > definitions(wsdl:binding/wsdl:operation/wsdl:input,
> > wsdl:binding/wsdl:operation/wsdl:output,
> > wsdl:binding/wsdl:operation/wsdl:fault), any parameters or
> > extensibility elements in the former MUST be used and the
> > latter ignored.
> >
> >
> >
> > If the RM policy assertion appears in a policy expression
> > attached to a wsdl:port as well as to the other allowed
> > WSDL/1.1 elements, any parameters or extensibility elements
> > in the former MUST be used and the latter ignored.
> >
> >
> >
> > --
> >
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://feeds.feedburner.com/bloglines/pzf
> >
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> >
> >
>
