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



As you said, ping on request and CS or app-level message (RMified or not) on the response is fine.  That works because the correlation is no longer being done at the WSA level but at the application level.  I would claim that if there are multiple pings coming from multiple clients then the ping must contain some kind of correlator so the server knows which client its talking to and it can then determine what kind of message it can include in the response.  And the output message would most likely have to be defined as an xs:any - or at least defined to allow for the various options (CS, app msg...).  But all of this is really true whether or not RM is in the picture.

What I don't get is how it can work when we want the correlation to be done below the application - basically at the WSA level.  Right now I don't think it can be - at least not with the current WSA.
Single req/single resp using WSA and anon replyTo is fine without RM - I think we all agree with that.
Single req/multiple resp using WSA and anon replyTo without RM is problematic - hopefully we can all agree with that for the reasons I stated above.  Without some kind of polling mechanism and some kind of correlator defined in WSA there's no way to get the 2nd+ responses.
So, when I look at adding RM into the mix for either of these two cases I start to think that the response side (whether its defined as single resp or multiple resp) ends up becoming a multiple response because of the possible need to resend those responses.  And since we don't have a solution for this case with a generic WSA soap stack I think it would be a mistake to define one for just when RM is used.

I am in no way discounting the importance of this scenario though - I do think its very important - but I don't think it is in scope for this TC.  RM, as written, is really just about delivery of soap messages between two endpoints and its really only focused on one-way messages.  We get the request/response aspect of it by defining two one-way sequences.  The use of Offer to link these two sequence goes beyond our mission (IMO) and tries to expand our scope to one where we're trying to solve a much different problem (the single req/multiple resp MEP w/anon replyto) and that's not really our job - if its anyone's job its the WS-Addressing WG's job.  Let's let them solve that first and then we'll add RM on top of it.

thanks,
-Doug



"Marc Goodner" <mgoodner@microsoft.com>

02/15/2006 08:16 PM

To
Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
cc
Subject
RE: [ws-rx] i021 proposal





Interesting, that ping could provide a channel for the CS. A Offer seems better so the CS to the client wouldn’t be needed, then the connection could be used for the response flow. No reliable in though…
 
The question for this scenario is does a CS in response to an application message seem right? It doesn’t seem right to me, particularly when that isn’t the defined response message for the operation. Do you have an idea for how the RM sequence would first be established to the client Doug?
 
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/



From: Doug Davis [mailto:dug@us.ibm.com]
Sent:
Wednesday, February 15, 2006 5:09 PM
To:
ws-rx@lists.oasis-open.org
Subject:
RE: [ws-rx] i021 proposal

 

The case that I keep thinking of is one where the request is something akin to
a 'ping' and the response is an app-level message.  The 'ping' can be lost because

it will be resent anyway in a while, but the app-level message can not be lost.  People

do this all the time when one side is behind a firewall and they use the 'ping' to

simply create a connection so the endpoint outside the firewall can send it messages

back to the endpoint inside the firewall.  We have use-cases in the management domain

that use this all the time - its a way for the resources outside the firewall to still send

data back home to their manager.

-Doug

"Marc Goodner" <mgoodner@microsoft.com>

02/15/2006 07:57 PM


To
Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
cc
 
Subject
RE: [ws-rx] i021 proposal

 


   





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?

 
Marc Goodner

Technical Diplomat

Microsoft Corporation

Tel: (425) 703-1903

Blog:
http://spaces.msn.com/mrgoodner/


 



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



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