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: [ws-rx] i089 proposal


So adding RM to a stack makes certain scenarios harder or even
impossible absent some other mechanism. And you propose, as a principle,
that it is ok to add features to the spec to compensate. I find that
principle questionable at best. If a spec in certain domain requires
features from another domain to enable scenarios then you use composable
specs. IMO, the case at hand involves a spec that deals with reliability
and a set of scenarios that would be satisfied by comoposition with,
say, WS-Polling.

--Stefan
[Sent using Windows Mobile 5.0]

-----Original Message-----
From: "Doug Davis" <dug@us.ibm.com>
To: "ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org>
Sent: 5/1/06 6:09 PM
Subject: RE: [ws-rx] i089 proposal

"you could have a fully reliable system that involves anonymous
endpoints" 
- yes and no.
If you never have network failures then it _can_ work but if you assume 
network failures
(which is one of the points of RM) then it won't work w/o some kind of 
polling solution.

RM deals with reliable delivery (er, transfer) of message between two 
endpoints - it 
doesn't limit itself to the types of reasons of the two endpoints may
have 
trouble talking 
to one another. And if you think about what RM adds (resend until acked)

it actually makes
the problems worse.  As you point out, anon EPR might actually work but
if 
you have to
resend a message things start to fall apart because the RMS can't always

initiate the
connection.  So, asking RM to address a problem that it made worse seems

reasonable to me.
I'll address this more in my response to DougB's note.

thanks,
-Doug




"Stefan Batres" <stefanba@microsoft.com> 
05/01/2006 03:36 PM

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






Dug,

You say that "RM already deals with reaching unreachable endpoints" and
based on that you seem to be concluding that it is reasonable for RM to
deal with anonymous endpoints. But RM doesn't deal with reaching
unreachable endpoints, RM deals with overcoming failures; network
outages, machines crashing and so forth. Having an anonymous endpoint is
not a failure of any part of a given system. Or another way to say it;
you could have a fully reliable system that involves anonymous
endpoints.

--Stefan

-----Original Message-----
From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] 
Sent: Monday, May 01, 2006 12:01 PM
To: Doug Davis
Cc: ws-rx@lists.oasis-open.org
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]