If what you are saying
is we shouldn’t spin our wheels on crazy MEPs +100 kagillion(sp?). Let’s
cover the well understood ones and move on.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Wednesday, February 15, 2006
5:03 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i021 proposal
Before we can discuss how RM should be used with
multiple in/out MEPs
I'd
like to understand how people can use those MEPs w/o RM and when the
wsa:ReplyTo
is anonymous. Single req/res w/o RM and anon replyTo is
obvious.
Change it to single req/multiple response(anon) and I'm lost how that is
supported
today with vanilla WSA (no RM). If someone can explain how that works
then
we can see how RM can be added to that.
My
feeling is that it isn't supported today using just WSA - and I think it would
be
a mistake for this TC to try to solve this problem when RM is in the picture.
We
should first let the WSA guys solve it and then add RM on top of it.
-Doug
"Yalcinalp, Umit"
<umit.yalcinalp@sap.com>
02/15/2006 06:36 PM
|
To
|
"Marc Goodner"
<mgoodner@microsoft.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
|
|
> -----Original Message-----
> From: Marc Goodner
[mailto:mgoodner@microsoft.com]
> Sent: Wednesday, Feb 15, 2006 1:35 PM
> To: Yalcinalp, Umit; Patil, Sanjay; Paul
Fremantle
> Cc: wsrx
> Subject: RE: [ws-rx] i021 proposal
>
> You are focusing on a case that has a lot of
potential problems,
> reliable outbound only for a req-resp service
when the ReplyTo EPR is
> anonymous. This seems like an edge case that
is possible when the
> subject level is changed to allow message. I
don't think this case is
> driving the issue. Do you see that
differently? Is this something that
> could be prevented by providing appropriate
guidance in the
> spec to not
> do this or do you have a use case you are
trying to support?
We seem to be talking past each other. I simply
asked the question what
would happen message level subject was permissable
AND replyTo/anonymous
address was permitted in a request/response.
As I point out, the issue is not with the message
level Policy subject,
but the replyTo/anonymous when RM is engaged. If
we assume that
replyTo:anonymous is not allowed in this case,
there is no issue on the
outbound message attachment. Right?
Of course, this case is not driving the issue of
whether we should allow
message level policy subjects. We need to be clear
what is
allowed/disallowed WHEN message policy subject may
be used.
>
> The multiple input/output message thing
sounds scary. I can't
> imagine a
> reason why you would have one input message
defined as reliable and
> another not. Again, do you want to support
that ability and if so why?
> If not couldn't this also be guarded against
with the appropriate
> guidance in the spec?
I am not clear what you mean by the last sentence.
Are you suggesting we
should disallow/discourage this use case or are you
against message
policy subject?
If we were to disallow anonymous destination, I do
not think we need to
restrict anything. Again, it seems to me there is
an issue with
replyTo/anonymous value, not the use case or
message Level policy
subject.
>
> And no, I do not believe that RM only applies
to asynchronous
> messaging.
> It applies to both asynchronous and
synchronous messaging.
Not clear. Do you mean there is a way to retranmit
responses reliably
when the backchannel is used?
>
> Marc Goodner
> Technical Diplomat
> Microsoft Corporation
> Tel: (425) 703-1903
> Blog: http://spaces.msn.com/mrgoodner/
>
>
--umit
> -----Original Message-----
> From: Yalcinalp, Umit
[mailto:umit.yalcinalp@sap.com]
> Sent: Wednesday, February 15, 2006 1:24 PM
> To: Marc Goodner; Patil, Sanjay; Paul
Fremantle
> Cc: wsrx
> Subject: RE: [ws-rx] i021 proposal
>
>
>
> > -----Original Message-----
> > From: Marc Goodner
[mailto:mgoodner@microsoft.com]
> > Sent: Wednesday, Feb 15, 2006 11:08 AM
> > To: Yalcinalp, Umit; Patil, Sanjay; Paul
Fremantle
> > Cc: wsrx
> > 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?
>
> If ReplyTo is anonymous when a message is
sent, it does not make sense
> to me to allow this case. How can you
CS on a ReplyTo/anonymous when
> the response is not reliable...
>
> The issue there is actually related to other
issues and discussions:
>
> "Do we envision reliable messaging to
require asynchronous message
> exchanges" or do we allow SOAP/HTTP sync
responses (not acks) in the
> mix? I believe this gem is hidden within
Doug's other issues with
> anonymous.
>
> If you agree that reliable messaging is only
possible with
> asynchronous
> message exchange, my concern wrt (b) becomes
irrelevant. I
> would see no
> problem in allowing outbound messages to have
RM assertions.
>
> Perhaps that is what you are getting at as
well, but I can not tell.
>
>
>
> >
> > I don't really get your case (c) below.
Can you elaborate on that?
>
> I had WSDL 2.0 MEPs in mind, or rather what
is expressable with WSDL
> MEPs where an operation may have multiple
input and output messages.
> Again, if you start from the assumption that
all message exchanges
> defined for the MEP are asynchronous and not
relying on the
> backchannel,
> again I think the issue will be mute.
>
> >
> > Marc Goodner
> > Technical Diplomat
> > Microsoft Corporation
> > Tel: (425) 703-1903
> > Blog: http://spaces.msn.com/mrgoodner/
> >
>
> Cheers,
>
> --umit
>
> >
> > -----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
> > > > >
> > > > >
> > > >
> > >
> >
>