RE: [ws-rx] i021 proposal

[Doug Davis <dug@us.ibm.com>]

Since you left it just sitting out there...
I'll bite  :-)  which parts of the issue do you
feel strongly about?

If the semantics were left a bit ambiguous
(like most policy assertions) and just
said something like "the messages
are sent using RM" or even better "the
message may be sent using RM" would
that work?  I still like the idea of letting
the sender decide if they want to use
RM or not and letting the receiver simply
indicate that it can support it.  So,
for replies the receiver can indicate it by
exposing the policy in its wsdl (if
available) or by including it in the replyTo EPR.

So, overall, I'd prefer if the assertion
simply stated that RM is supported
(I guess it can be tagged as required
too using the optional attribute).

thanks,
-Doug

"Ashok Malhotra" <ashok.malhotra@oracle.com>

02/15/2006 12:22 PM

To	"Patil, Sanjay" <sanjay.patil@sap.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Paul Fremantle" <paul@wso2.com>
cc	wsrx <ws-rx@lists.oasis-open.org>
Subject	RE: [ws-rx] i021 proposal

Hi Sanjay:
All the WS-Policy assertions apply both ways so I'm reluctant to
make an exception in this case.  That said, you are right we need
a use case and semantics for the 2-way case.  

The semantics, in my view are:
- Inbound: please send these messages to me using a reliable protocol
- Outbound: I will send these messages using a reliable protocol.

I think these are reasonable and useful but I don't feel strongly about
this part of the issue.

All the best, Ashok
 

> -----Original Message-----
> From: Patil, Sanjay [mailto:sanjay.patil@sap.com] 
> Sent: Wednesday, February 15, 2006 7:10 AM
> To: Ashok Malhotra; Yalcinalp, Umit; Paul Fremantle
> Cc: wsrx
> Subject: RE: [ws-rx] i021 proposal
> 
> 
> Ashok and others who care about this issue [please chime in]
> 
> I would like to understand a bit more the rationale behind 
> your thinking. So please allow me to ask a set of questions ...
> 
> The fundamental question asked by i021 is - does the RM 
> policy apply both ways? So let us try to answer the 
> controversial part of this question, that is -- should the 
> Destination be allowed to assert a requirement that the 
> Source must be prepared to handle the response messages 
> reliably. If yes, can you please provide a brief use case
> (bait: I may be convinced!)
> 
> If the answer to the above question is NO (that is, the 
> Destination can only talk about reliable messaging behavior 
> of inbound messages only), then the nature of i021 becomes -- 
> how to specify this semantic? Does the policy framework 
> provide us enough support to capture our needs, or do we have 
> to invent new syntax/mechanisms?
> 
> If the answer to the question is YES (that is, the 
> Destination should be in a position to assert reliable 
> messaging in both directions), then there are broadly two options
> - YES always, which means the Destination asserts the 
> reliable messaging behavior at a port/binding level and the 
> assertion is applied to all the inbound and outbound 
> messages. This may be close to the status quo.
> - YES but not always, which means the Destination would like 
> to have a finer level of control in asserting reliable 
> messaging behavior. This option is close to PaulF's proposal.
> 
> Let us try to hash out this issue by answering the above (and possibly
> additional) set of questions.
> 
> -- Sanjay 
> 
> > -----Original Message-----
> > From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
> > Sent: Monday, Feb 13, 2006 7:22 AM
> > To: Patil, Sanjay; Yalcinalp, Umit; Paul Fremantle
> > Cc: wsrx
> > Subject: RE: [ws-rx] i021 proposal
> > 
> > Sanjay:
> > In reading the mail on i021 there seems to be agreement that
the 
> > assertion should apply to various granularities including message.
> > 
> > If the assertion is applied to a WSDL definition that encompasses
> > inbound, outbound and, possibly fault messages, I'm not 
> sure there is 
> > agreement.
> > 
> > It can be argued that in this case the RM assertion applies to
all 
> > messages covered by that definition with the following semantic:
> > - Inbound: please send these messages to me using a 
> reliable protocol
> > - Outbound: I will send these messages using a reliable protocol.
> > 
> > Paul's proposal, which I am happy with, argues the above.
> > 
> > All the best, Ashok
> >  
> > 
> > > -----Original Message-----
> > > From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
> > > Sent: Monday, February 13, 2006 6:22 AM
> > > To: Yalcinalp, Umit; Paul Fremantle
> > > Cc: wsrx
> > > Subject: RE: [ws-rx] i021 proposal
> > > 
> > > 
> > > Just to kick the i021 discussion further (this issue has
> an amazing 
> > > characteristic of moving very fast in multiple direction,
> typically 
> > > away from the center of gravity and always needs some 
> impetus :) ...
> > > 
> > > How about saying that --
> > > A> RM Policy assertion applies one-way (inbound messages
only)
> > > B> RM Policy assertion can be applied at various granularities
 -
> > > service/port/binding/operation/message. Attachment at higher
> > > granularity overrides attachment at lower level.
> > > C> EPR based techniques may also be used to assert the
RM
> > behavior of
> > > outbound messages of a Service. Specifying the precise 
> syntax of how 
> > > RM Policy assertion can appear in an EPR and how the 
> policies in an 
> > > EPR interact with the static policies of the endpoints 
> (both ends) 
> > > is outside the scope of this TC.
> > > 
> > > If there is consensus on the above semantic, I believe 
> that Paul's 
> > > last proposal can be easily tweaked to reflect the same.
> > > 
> > > Please comment and let us continue hashing out this issue
> further on 
> > > the mailing list (data point: this issue is close to 8 months
old 
> > > now!).
> > > 
> > > -- Sanjay
> > > 
> > > > -----Original Message-----
> > > > From: Yalcinalp, Umit
> > > > Sent: Thursday, Feb 09, 2006 18:43 PM
> > > > To: Paul Fremantle; Patil, Sanjay
> > > > Cc: wsrx
> > > > Subject: RE: [ws-rx] i021 proposal
> > > > 
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Paul Fremantle [mailto:paul@wso2.com]
> > > > > Sent: Thursday, Feb 09, 2006 3:04 AM
> > > > > To: Patil, Sanjay
> > > > > Cc: wsrx
> > > > > Subject: Re: [ws-rx] i021 proposal
> > > > > 
> > > > > Sanjay
> > > > > 
> > > > > You are right. The proposal isn't yet fully clear
on the
> > > meaning of
> > > > > attaching WS-RM to a message or operation.
> > > > > 
> > > > 
> > > > That is not the real issue, see below. 
> > > > 
> > > > > How about if the following text was added, before
the 
> EPR text.
> > > > > 
> > > > > Attaching the RM assertion to a specific wsdl:input,
> > > > wsdl:output, or
> > > > > wsdl:fault construct indicates that the RM protocol
MUST be
> > > > used when
> > > > > sending that message (or MAY if the assertion
is marked
> > optional).
> > > > > Attaching the RM assertion to a specific wsdl:operation
> > construct
> > > > > indicates that the RM protocol MUST be used for
all
> > > > messages (whether
> > > > > input, output or fault) related to the operation(or
> MAY if the 
> > > > > assertion is marked optional).
> > > > > Attaching the RM assertion to a specific wsdl:binding
> > construct
> > > > > indicates that the RM protocol MUST be used for
all
> > > > messages (whether
> > > > > input, output or fault) related to the binding
(or MAY if the 
> > > > > assertion is marked optional).
> > > > > Attaching the RM assertion to a specific wsdl:port
construct 
> > > > > indicates that the RM protocol MUST be used for
all messages 
> > > > > (whether input, output or fault) related to the
port (or
> > > MAY if the
> > > > > assertion is marked optional).
> > > > > Attaching the RM assertion to a specific wsdl:service
> construct 
> > > > > indicates that the RM protocol MUST be used for
all
> > > > messages (whether
> > > > > input, output or fault) related to the service
(or MAY if the 
> > > > > assertion is marked optional).
> > > > > 
> > > > > You are also right about the EPR. I would recommend
> > > making the EPR
> > > > > policy override the WSDL policy, but once again
I think
> > > this is an
> > > > > issue with the overall WS-Policy Framework (i.e.
a
> > general Policy
> > > > > issue not a specific RX issue).
> > > > > 
> > > > 
> > > > I must agree that there is an issue which is beyond
WS-RX
> > here, but
> > > > not really about WS-Policy per se but metadata that
is 
> contained 
> > > > within an EPR in general. EPR may have metadata that
> mimics WSDL 
> > > > constructs in addition to policy assertions.
> > > > 
> > > > EPR policy and WSDL policy may conflict and EPR may
be stale. 
> > > > We punted on this in the WS-Addressing wg. We left
the
> > > question to be
> > > > answered using an unspecified lifecycle definition
of 
> the EPR or 
> > > > retrieval mechanisms, such as WS-MEX that will help
in
> > > resolving this
> > > > issue.  Therefore, I am not sure it is a good
idea
> > recommend making
> > > > the EPR policy override the WSDL policy. Let me ask
> this. Can we 
> > > > guarantee that the EPR will never be stale within an
> > WS-RM context?
> > > > 
> > > > Further, is the EPR policy about the EPR itself or
the
> > > endpoint that
> > > > it represents?
> > > > I have heard different answers to this last question
> > > depending on whom
> > > > I talked to. Can the EPR metadata contain both type
of 
> policy? By 
> > > > design, it is possible. It is a bucket...
> > > > 
> > > > I think we should punt on overriding just like WS-A.
> > > > 
> > > > 
> > > > > Thanks for your comments,
> > > > 
> > > > Thanks for the proposal. This is pretty much what I
was
> > > suggesting as
> > > > well in my email [1] for using message level subject
but
> > it appears
> > > > that you want to allow outbound or fault messages as
well. 
> > > I need to
> > > > think about the consequence of this a bit further,
so I do
> > > not think
> > > > that Sanjay's question is really answered by the text
you
> > > added wrt to
> > > > applying the RM assertion to outbound messages.
> > > > 
> > > > It seems to me if it would be cleaner to leave the
> one-way policy 
> > > > assertion at the input message only, so that for the
"outbound 
> > > > messages" the receiving end's policy assertion
would 
> apply. I am 
> > > > thinking in terms reconciling the policies of RMS and
RMD
> > > at both ends
> > > > (including extensibility). I think
> > binding/operation/input message
> > > > should be sufficient and is simpler.
> > > > 
> > > > > 
> > > > > Paul
> > > > 
> > > > --umit
> > > > 
> > > > [1]
> > > > http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archi
> > > > ves/200602/msg00027.html
> > > > > 
> > > > > Patil, Sanjay wrote:
> > > > > > Comments inline ... 
> > > > > >
> > > > > >   
> > > > > >> -----Original Message-----
> > > > > >> From: Paul Fremantle [mailto:paul@wso2.com]
> > > > > >> Sent: Thursday, Feb 09, 2006 1:43 AM
> > > > > >> To: wsrx
> > > > > >> Subject: [ws-rx] i021 proposal
> > > > > >>
> > > > > >> Proposal regarding issue 021. I'm not
quite sure
> > this is right
> > > > > >> yet, so I would appreciate feedback from
the 
> Policy experts.
> > > > > >>
> > > > > >> Based on CDII
> > > > > >>
> > > > > >> Delete 142-154 section 2.3 and replace
with.
> > > > > >>
> > > > > >> 2.3 Assertion Attachment
> > > > > >>
> > > > > >> The RM assertion can have Service, Endpoint,
Operation
> > > > or Message
> > > > > >> Endpoint Policy Subjects [WS-PolicyAttachment].
> > > > > >>
> > > > > >> WS-PolicyAttachment [WS-PolicyAttachment]
defines both
> > > > > abstract and
> > > > > >> concrete attachment points in WSDL [WSDL1.1].
Because the
> > > > > RM policy
> > > > > >> assertion specifies a concrete behaviour,
it MUST NOT be
> > > > > attached to
> > > > > >> abstract constructs:
> > > > > >>
> > > > > >>     * wsdl:portType
> > > > > >>     * wsdl:portType/wsdl:operation
> > > > > >>     * wsdl:portType/wsdl:operation/wsdl:input
> > > > > >>       * wsdl:portType/wsdl:operation/wsdl:output
> > > > > >>       * wsdl:portType/wsdl:operation/wsdl:fault
> > > > > >>     * wsdl:message
> > > > > >>
> > > > > >> The RM policy assertion MAY be attached
to the following
> > > > constructs
> > > > > >> * wsdl:service
> > > > > >> * wsdl:port
> > > > > >> * wsdl:binding.
> > > > > >> * wsdl:binding/wsdl:operation
> > > > > >> * wsdl:binding/wsdl:operation/wsdl:input
> > > > > >> * wsdl:binding/wsdl:operation/wsdl:output
> > > > > >> * wsdl:binding/wsdl:operation/wsdl:fault
> > > > > >>
> > > > > >> If the RM assertion is attached to the
wsdl:service
> > > construct, it
> > > > > >> MUST be considered to apply to all the
wsdl:port's
> > > referenced in
> > > > > >> the binding.
> > > > > >> If the RM assertion is attached to the
wsdl:port
> > construct, it
> > > > > >> MUST be considered to apply to all the
wsdl:binding's
> > > referenced
> > > > > in the port.
> > > > > >> If the RM assertion is attached to the
wsdl:binding
> > > construct, it
> > > > > >> MUST be considered to apply to all the
wsdl:operation's
> > > > > referenced in the
> > > > > >> binding.
> > > > > >> If the RM assertion is attached to the
wsdl:operation
> > > construct,
> > > > > >> it MUST be considered to apply to all
the wsdl:input's,
> > > > wsdl:output's and
> > > > > >> wsdl:fault's referenced in the operation.
> > > > > >>     
> > > > > > It seems like your proposal allows for attachment
of RM
> > > > > assertion at the
> > > > > > message level. In that case, wouldn't you
also want to
> > > specify the
> > > > > > behavior when the RM assertion is directly
attached to the
> > > > > wsdl:input,
> > > > > > wsdl:output or wsdl:fault constructs? Or
is that
> > > semantic somehow
> > > > > > derived from the above? I think the main
question of the
> > > > > issue i021 is
> > > > > > whether and how does RM assertion apply to
the outbound
> > > > (I hate this
> > > > > > term) messages of an endpoint, and I don't
see a clear
> > > > > answer to that
> > > > > > question in this proposal.
> > > > > >
> > > > > > There should also be statements for handling
the case
> > where RM
> > > > > > assertions are attached to multiple subjects
within the
> > > > same scope.
> > > > > >
> > > > > >   
> > > > > >> WS-Addressing allows for policy assertions
to be
> > > > included within an
> > > > > >> EndpointReference. Per section 2.2 above,
the
> > presence of this
> > > > > >> policy assertion in an EPR specifies
the level of
> > support for
> > > > > >> WS-ReliableMessaging offered by that
endpoint.
> > > > > >>     
> > > > > > Since the previous text regarding the WSDL
attachment of RM
> > > > > assertion
> > > > > > covers the behavior of outbound messages
also, there may
> > > > possibly be
> > > > > > conflicts when both the techniques of associating
> > > policies (WSDL
> > > > > > attachment and EPR inclusion) are used.
> > > > > >
> > > > > > -- Sanjay
> > > > > >
> > > > > >   
> > > > > >> Paul
> > > > > >>
> > > > > >> --
> > > > > >>
> > > > > >> Paul Fremantle
> > > > > >> VP/Technology, WSO2 and OASIS WS-RX TC
Co-chair
> > > > > >>
> > > > > >> http://bloglines.com/blog/paulfremantle
> > > > > >> paul@wso2.com
> > > > > >>
> > > > > >> "Oxygenating the Web Service Platform",
www.wso2.com
> > > > > >>
> > > > > >>
> > > > > >>     
> > > > > 
> > > > > --
> > > > > 
> > > > > Paul Fremantle
> > > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > > > 
> > > > > http://bloglines.com/blog/paulfremantle
> > > > > paul@wso2.com
> > > > > 
> > > > > "Oxygenating the Web Service Platform",
www.wso2.com
> > > > > 
> > > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
>