I do see the case for
reliable output. I’m questioning reliable output with unreliable (or no)
input. Do you have use cases for that Doug?
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Wednesday, February 15, 2006
4:55 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i021 proposal
If I'm following this...why is it hard to imagine a
case where there are multiple
outputs
and a CS is sent to the wsa:ReplyTo? Granted making it work with
anonymous
ReplyTo is problematic but the non-anonymous case should be
trivial.
-Doug
"Marc Goodner"
<mgoodner@microsoft.com>
02/15/2006 02:07 PM
|
To
|
"Yalcinalp, Umit"
<umit.yalcinalp@sap.com>, "Patil, Sanjay"
<sanjay.patil@sap.com>, "Paul Fremantle"
<paul@wso2.com>
|
cc
|
"wsrx"
<ws-rx@lists.oasis-open.org>
|
Subject
|
RE: [ws-rx] i021 proposal
|
|
First
off these seem like outlier cases. How much of a need is there for
reliable outbound only? Does anyone here have a
system that does this
today and could provide some additional input on
what is important for
this scenario?
The net of what you are pointing out to me is that
when the attachment
point changes to allow message there may be issues
if that is used only
on outbound messages. Can we save this as a new
issue after this one is
done? This seems potentially complicated and I
fear we are going to get
far a field from the core of this issue by diving
into that now.
Now violating my own suggestion...
"-- How would this use case interact with
CS/CSR since RM kicks in on
the
outbound message? "
This does seem odd, a CS back to the ReplyTo
right?
I don't really get your case (c) below. Can you
elaborate on that?
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/
-----Original Message-----
From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Monday, February 13, 2006 9:35 AM
To: Patil, Sanjay; Paul Fremantle
Cc: wsrx
Subject: RE: [ws-rx] i021 proposal
Sanjay,
Perhaps I did not express my discomfort on (B)
well and why I prefer a
restricted semantics to apply to "in"
messages only. I do not think that
the general use case is really thought out well
hence my hesistation.
I am in favor of applying the assertion at message
subject but I
hesitate its use with outbound messages when there
are multiple messages
in an MEP (inbound and outbound) and we allow
attachment to individual
messages due to complexity.
Lets consider the specific cases:
(a) There is an operation which has only output
message(s) in it. This
use case can easily be handled with endpoint
message policy subject and
does not require message policy subject. No
problem there.
(b) There is an operation which is input/output,
your typical request
response. Lets assume that we allow that the
assertion applies to
outbound message in a request response. Here are
the questions that come
to my mind.
-- How would this use case interact with CS/CSR
since RM kicks in on the
outbound message?
-- what would be the requirement on the sender of
the message wrt to
specific the respective WS-Addressing headers?
Take your typical use of WS-Addressing most folks
would assume that
request/response would map to sync
request-response where replyTo would
be anonymous (HTTP response). (Am I hearing i061
but it is out of scope
for inbound messages or not? :-))
I fear that the assertion would not really work
well with RM if RM only
applies to the outbound message only which applies
to the HTTP response
in this case.
(c) There is a complicated MEP with multiple
in/out messages where we
allow some of the messages to have RM assertions
and some others do not.
This is a rather complicated use case.
Endpoint policy subject is simple since it governs
both input and output
messages. If there is granularity needed to cover
at the message level,
we should allow them at the input message level
only where the RMD can
assert its requirements for the incoming messages
and RMS can initiate
the protocol. If we leave the assertion at the
inbound message only, it
is implied that a clearly demarcated interaction
with this party (hence
RMD) would require RM engagement and the sender of
the message accepts
this fact.
Otherwise, I fear that we need to clarify the
roles and responsibility
of client and/or RMS for case (b) and (c) well in
order to proceed.
"Redesign your abstract layer in order to
suit RM requirements" so that
cases (b) and (c) never occur may be a
recommendation we can make, but I
do not see that part of the proposals. This option
implies WSDL-last
kind of design as well. If this is what we would
be promoting, we should
be clear about it.
Hope this clarifies where I am coming from,
--umit
> -----Original Message-----
> From: Patil, Sanjay
> Sent: Monday, Feb 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
> > >
> > >
> >
>