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] slightly new i021 proposal


Thanks, Chris.  You agree with....
 
> 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.


but then I argued that this is not a problem.  The server and client, thru some process of policy
comparison, can figure out whether the msg shd be sent reliably or not.
 
Do you agree with this?

All the best, Ashok

 


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Wednesday, March 08, 2006 9:24 AM
To: Ashok Malhotra
Cc: Paul Fremantle; wsrx
Subject: RE: [ws-rx] slightly new i021 proposal


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: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295


"Ashok Malhotra" <ashok.malhotra@oracle.com> 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:paul@wso2.com]
> > 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
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> >
> >
>


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