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


Doug,

I may be struggling with a similar issue to Marc though I would phrase 
it differently: Could you please describe how your "general" solution 
fits into the Charter[1] under which our group was formed?

thanx,
    doug

[1] <http://www.oasis-open.org/committees/ws-rx/charter.php>

On 30/04/06 17:57, Doug Davis wrote:
>
> Marc,
>   First, I'm glad that I think we're all in agreement that a polling 
> solution is the right solution for these issues - I think that alone 
> is progress.  So, as you say, the question then becomes a matter of 
> placement of function.  Up to now I think most people have chosen to 
> ignore this issue.  Yes some groups (like WS-BaseNotification or 
> WS-Management) saw the issue and defined their own domain specific 
> solutions, but they are just that - domain specific.  As you say in 
> your note, a more foundational architectural solution is a better 
> approach.  So, is RM one of those specs?  RM clearly isn't domain 
> specific and it deals with transfer of messages between endpoint - so 
> far so good.  As I've said several times, I don't think its a stretch 
> to think of reliability as more than just resend until acked.  Right 
> now RM already deals with reaching unreachable endpoints - but we've 
> been thinking of it limiting itself to 'unreachable' meaning 
> temporarily down - or poor networks connections.  I really don't think 
> its hard to see anon endpoints as being part of that grouping - there 
> really isn't much of a difference.  In all cases the other side isn't 
> guaranteed to be there - the only thing that's special about this case 
> is how the connection between the two endpoints is established - 
> beyond that everything else is the same (at least for our proposal - 
> Paul's doesn't keep everything else the same but that's a different 
> note :-).
>   Perhaps I didn't say it correctly, but its not that I think its RM's 
> job to get the anon/sync world to look as much like the async world - 
> what I meant to say is that we wanted our polling solution to allow 
> them to look the same to the code that makes use of it.
> thanks,
> -Doug
>
>
>
> *"Marc Goodner" <mgoodner@microsoft.com>*
>
> 04/28/2006 04:32 AM
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [ws-rx] i089 proposal
>
>
>
> 	
>
>
>
>
>
> I’m certainly against banning anon. Why is it the mandate of RM to 
> “get the anon/sync world to look as much like the async world as 
> possible”? Your proposal makes it clear that is what your goal is, but 
> that is also foremost in my mind why it has nothing to do with RM. 
> That statement clearly scopes the problem you are trying to solve as a 
> foundational architectural concern below the level of RM.
>  
> 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:* Friday, April 28, 2006 1:28 AM*
> To:* ws-rx@lists.oasis-open.org*
> Subject:* RE: [ws-rx] i089 proposal
>  
>
> I think this scenario is required for RM.  At the last f2f we talked 
> about how an RMS may need to create new sequences for a variety of 
> reasons - one of which was because people wanted to be able to create 
> a new sequence based on the soap version, but there are lots of other 
> reasons people may need to create 'em.  IMO, the use of the anon EPR 
> should not impact these types of decisions - remember we're trying to 
> get the anon/sync world to look as much like the async world as 
> possible.  If we allowed anon EPRs to impact our RM 
> processing/decision-making model then we would need to explore banning 
> the use of anon, which I believe is something your against.
> -Doug
>
> *"Marc Goodner" <mgoodner@microsoft.com>*
>
> 04/28/2006 04:14 AM
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
> cc
> 	 
> Subject
> 	RE: [ws-rx] i089 proposal
>
>
>  
>
>
>   	 
>
>
>
>
>
>
> Doug, is that scenario required for RM or polling in general? As soon 
> as you start talking about a server side RMS establishing a sequence 
> to an un-addressable client I think you are beyond RM. You can’t 
> establish inbound communications from a server to an un-addressable 
> client without RM so why is this an RM problem?
>  
> If we are looking to add a tightly scoped polling mechanism to RM for 
> specific scenarios this one would not be high on my list.
>  
> 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:* Friday, April 28, 2006 1:05 AM*
> To:* ws-rx@lists.oasis-open.org*
> Subject:* Re: [ws-rx] i089 proposal
>  
>
> I do believe that the scenario you're talking about is a required one 
> but I would phrase it
> a bit differently.  An RMS (whether its the client-side RMS or the 
> server-side RMS) needs
> to be able to follow the same RM processing model.  And part of the 
> processing model
> is the ability to decide "if", "when" and "how" to use RM.  As we talk 
> about in the Q&A
> section of our proposal, an RMS having the option of choosing to 
> decide which RM sequence
> to use, when to create new ones, or even when to use RM at all are all 
> part of the RM
> processing model and those aspects need to be maintained even in these 
> anon cases.
> In your proposal you put the burden on the RMD to make a lot decisions 
> on behalf of
> the RMS, that's quite a change to the RM processing model and I have 
> no idea how the
> RMD could ever know all it would need to know to make those decisions. 
>  For example, how
> would it know when a new sequence is needed by the RMS?  That is why I 
> believe our
> proposal is a better fit for RM - it allows the RMS to retain all of 
> the same logic and choices
> that it has in the async world.  Our proposal simply re-establishes 
> the backchannel that
> the RMS (on the server side) is looking for - nothing more.  Once that 
> is there, it is then
> back to "standard operating procedures" - the RMS can do whatever it 
> would normally
> do.
> thanks,
> -Doug
>
> *Paul Fremantle <paul@wso2.com>*
>
> 04/27/2006 05:51 PM
>
> 	 
>
>
> To
> 	Marc Goodner <mgoodner@microsoft.com>
> cc
> 	wsrx <ws-rx@lists.oasis-open.org>
> Subject
> 	Re: [ws-rx] i089 proposal
>
>
>
>  
>
>  
>
>
>   	 
>
>
>
>
>
>
> If the TC isn't attached to this scenario then this section can be
> deleted. The scenario is simply when you want to send unreliably but
> receive reliable responses. I've heard this stated as a requirement in
> some scenarios, but WSO2 doesn't have any pressing scenarios of this ilk
> so we would be happy either way.
>
> Paul
>
> Marc Goodner wrote:
> > So is an RMS engaged at the client side or not? This is weird, why would
> > the infrastructure on the client side decide to do this?
> >
> > Marc Goodner
> > Technical Diplomat
> > Microsoft Corporation
> > Tel: (425) 703-1903
> > Blog: http://spaces.msn.com/mrgoodner/
> >
> >
> > -----Original Message-----
> > From: Paul Fremantle [mailto:paul@wso2.com]
> > Sent: Thursday, April 27, 2006 12:57 PM
> > To: Marc Goodner
> > Cc: wsrx
> > Subject: Re: [ws-rx] i089 proposal
> >
> > Marc
> >
> > This is the case where the client is making an offer but not creating an
> >
> > outbound sequence - thats all. A client offers a sequence, and then
> > reliably gets messages from the server that are buffered under that
> > sequenceID.
> >
> > Paul
> >
> > Marc Goodner wrote:
> >  
> >> I still don't understand why offered sequence is being used in the
> >> explanation. If this is going to usually be used with an offered
> >> sequence I'd like to understand how, that isn't explained in my mind.
> >>    
> > If
> >  
> >> it is applicable for any sequence, offered or not, I'd like to
> >> understand that as well. The current text only confuses me in its use
> >>    
> > of
> >  
> >> the term and I'm afraid your explanation below isn't helping me get
> >>    
> > past
> >  
> >> it. Perhaps comparing the two modes would be a better approach.
> >>
> >> On 4.2, "Offer a sequence without the overhead of requesting one"? I
> >> don't understand. The text refers to the RMD requesting a sequence
> >>    
> > from
> >  
> >> the RMS, but it sounds like this is an unreliable request so doesn't
> >> that mean there is no RMS at the client? Isn't this about the service
> >> acting as an RMS and the client acting as an RMD? So the pattern would
> >> be client sends one way message to service (GetMessage?), response is
> >> Offer, then client sends a response to the response of Accept? What
> >>    
> > does
> >  
> >> the service return to that?  Why wouldn't the service send a CS in the
> >> body of the GetMessage response to the client?
> >>
> >> Marc Goodner
> >> Technical Diplomat
> >> Microsoft Corporation
> >> Tel: (425) 703-1903
> >> Blog: http://spaces.msn.com/mrgoodner/
> >>
> >>
> >> -----Original Message-----
> >> From: Paul Fremantle [mailto:paul@wso2.com]
> >> Sent: Monday, April 24, 2006 1:11 AM
> >> To: Marc Goodner
> >> Cc: wsrx
> >> Subject: Re: [ws-rx] i089 proposal
> >>
> >> Marc
> >>
> >> I use the words "Offered Sequence" informatively and non-normatively.
> >> This is most likely to be used with an offered sequence, but isn't
> >>    
> > tied
> >  
> >> to that.
> >>
> >> As regards 4.2, this is there to satisfy the scenario where you only
> >> want reliable responses. I added this in for discussion because I know
> >>    
> >
> >  
> >> that some members find this an important scenario. In that case you
> >>    
> > need
> >  
> >> to be able to Offer a sequence without the overhead of requesting one.
> >>    
> >
> >  
> >> It is related to the anonymous client because without a real endpoint
> >> the server cannot send a CS to the client so it relies on an offer.
> >>
> >> Paul
> >>
> >> Marc Goodner wrote:
> >>  
> >>    
> >>> Given 1 and 2, yes some text that clarified that not only is this
> >>> specific to RM but that a general solution would be preferable would
> >>>    
> >>>      
> >> be
> >>  
> >>    
> >>> best.
> >>>
> >>> On 3 I suppose, I don't like seeing WS-A headers in the body of a
> >>> message though. Do you really even need the response for a specific
> >>> message? Why not return any responses or messages for that sequence
> >>>    
> >>>      
> >> that
> >>  
> >>    
> >>> have not been acknowledged? And what are you talking about when you
> >>>    
> >>>      
> >> say
> >>  
> >>    
> >>> this is tied to the offered sequence? What offered sequence? I don't
> >>>    
> >>>      
> >> see
> >>  
> >>    
> >>> anything here that ties the use of your GetMessage proposal to an
> >>> offered sequence.
> >>>
> >>> I don't understand section 4.2 in your proposal at all. What does
> >>>      
> > this
> >  
> >>> have to do with the rest of this proposal?
> >>>
> >>> Marc Goodner
> >>> Technical Diplomat
> >>> Microsoft Corporation
> >>> Tel: (425) 703-1903
> >>> Blog: http://spaces.msn.com/mrgoodner/
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Paul Fremantle [mailto:paul@wso2.com]
> >>> Sent: Thursday, April 20, 2006 1:57 AM
> >>> To: Marc Goodner
> >>> Cc: wsrx
> >>> Subject: Re: [ws-rx] i089 proposal
> >>>
> >>> Marc
> >>>
> >>> 1) Yes - I completely aimed this to be a specific model for RM. I
> >>>    
> >>>      
> >> would
> >>  
> >>    
> >>> be happy to include language that indicates that if a more general
> >>> purpose firewall crossing mechanism was in place this should not be
> >>> used.
> >>> 2) The wsrm:Identifier is a required part of my proposal, and
> >>>     As a much lower technical detail, I do not believe your 
> proposal addresses one of the major issues
> >>>      
> >> therefore
> >>  
> >>    
> >>> this proposal is completely tied to the use of RM.
> >>> 3) The suggestion of using messageNumber is interesting. The
> >>>    
> >>>      
> >> motivation
> >>  
> >>    
> >>> for using a message ID was that there may be situations where I
> >>>      
> > really
> >  
> >>>    
> >>>      
> >>  
> >>    
> >>> want the response to a given message. We do not - so far - have any
> >>> concept of a response to a given RM messageID, so that seemed like a
> >>>    
> >>>      
> >> new
> >>   As a much lower technical detail, I do not believe your proposal 
> addresses one of the major issues
> >>    
> >>> concept to me, whereas WS-A systems do keep track of responses to
> >>>    
> >>>      
> >> given
> >>  
> >>    
> >>> messageIDs. But I'm not averse to your suggestion. However I wish to
> >>> make clear that in my proposal you MUST have both the Identifier and
> >>>    
> >>>      
> >> the
> >>  
> >>    
> >>> messageID - so it is still very closely tied to the offered sequence.
> >>>
> >>> Paul
> >>>
> >>> Marc Goodner wrote:
> >>>  
> >>>     As a much lower technical detail, I do not believe your 
> proposal addresses one of the major issues
> >>>      
> >>>> I hope that this is scoped to RM and not a general purpose polling
> >>>> mechanism. I assume that is your intent in that you use the
> >>>> wsrm:Identifier and indicate that you see this being part of the
> >>>>        
> > core
> >  
> >>>> spec. Still it seems like including language that indicates that
> >>>>      
> >>>>        
> >> would
> >>  
> >>    
> >>>> be advised, particularly noting that if there were a general purpose
> >>>> polling mechanism that it might be preferred over this one.
> >>>>
> >>>> So following from that why is MessageID in the GetMessage? Isn't the
> >>>> identifier enough? If it isn't wouldn't the addition of
> >>>> wsrm:MessageNumber do the trick?
> >>>>
> >>>> Marc Goodner
> >>>> Technical Diplomat
> >>>> Microsoft Corporation
> >>>> Tel: (425) 703-1903
> >>>> Blog: http://spaces.msn.com/mrgoodner/
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Paul Fremantle [mailto:paul@wso2.com]
> >>>> Sent: Thursday, April 06, 2006 12:40 PM
> >>>> To: wsrx
> >>>> Subject: [ws-rx] i089 proposal
> >>>>
> >>>> Folks
> >>>>
> >>>> At the F2F I took away an action to come up with a proposal for i089
> >>>>        
> >
> >  
> >>>> before the call. I'm sorry its so close to the call.
> >>>>
> >>>> I've attached a proposal for review. This is a work in progress, but
> >>>>      
> >>>>        
> >> I
> >>  
> >>    
> >>>>    
> >>>>      
> >>>>        
> >>>  
> >>>    
> >>>      
> >>>> think it helps call out some of the issues involved around i089.
> >>>>
> >>>> I think the most important questions for the TC are:
> >>>>
> >>>> (1) How does a customer/user use WSRM in a two-way scenario if one
> >>>>    
> >>>>      
> >>>>        
> >>> side
> >>>  
> >>>    
> >>>      
> >>>> is anonymous?
> >>>> (2) Adding a "GetMessage" makes the protocol more symmetric, but
> >>>>        
> > also
> >  
> >>>>      
> >>>>        
> >>  
> >>    
> >>>> might overlap with a wider non-reliable solution to this problem. Is
> >>>>    
> >>>>      
> >>>>        
> >>> it
> >>>  
> >>>    
> >>>      
> >>>> in the scope of this TC to add this?
> >>>> (3) In the case we do add it, what criteria do we use to select
> >>>>        
> > which
> >  
> >>>>      
> >>>>        
> >>  
> >>    
> >>>> message to request.
> >>>> (4) Is this a generic solution (i.e. can the RMD request messages
> >>>>      
> >>>>        
> >> from
> >>  
> >>    
> >>>>    
> >>>>      
> >>>>        
> >>>  
> >>>    
> >>>      
> >>>> the RMS in all cases) or special cased to anonURI scenarios?
> >>>>
> >>>> Paul
> >>>>
> >>>>  
> >>>>    
> >>>>      
> >>>>        
> >>>  
> >>>    
> >>>      
> >>  
> >>    
> >
> >  
>
> -- 
>
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://feeds.feedburner.com/bloglines/pzf
> 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]