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