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] i090 - What is Offer good for anyway?



Paul Fremantle <paul@wso2.com> wrote on 02/12/2006 01:45:57 PM:

> Doug
>
> I know you think that the WS Polling spec
> (http://www.w3.org/Submission/ws-polling/) sorts this out better :-)

As much as I'd like to push it, I've purposely tried to avoid it because
I believe it to be out of scope of of this TC.  Solving the anonymous
replyTo with firewalls is not an RM specific problem and I'd much prefer
a solution that didn't require RM to be used.

> I think that reading the text below as forbidding the option that DougB
> has suggested is pushing things. My reading is that text is trying to
> give an example.
>
> If the consensus is that the text does forbid it, I would suggest we ask
> the WS-A team to change this.
>
> 1) I believe that the approach proposed by DougB offers a way of using
> one-way synchronous HTTP requests to offer a two-way reliable exchange,
> with very little overhead in the case where requests are reliably
> delivered.
> 2) I think this approach is highly consistent with the current spec and
> we simply need to add some clarifications to make the scenario
> interoperable and clear.
> 3) I think this model is highly desirable given the prevalence of
> firewalls. For example, many Small Medium Enterprises (SMEs) can easily
> run systems that only make outgoing HTTP requests with no change to the
> infrastructure. Similarly, this allows smart web clients to make WSRM
> calls. For example, an enhanced IE or Firefox could use WSRM to build
> reliable AJAX clients using this approach.
>
> So I am strongly in favour of us doing the work to make this option
> possible using the specified document. And I encourage the TC to work to
> figure out the spec improvements that will make this interoperable,
> rather than excising the option because it isn't yet clearly specified.

I'm very concerned that we're gotten off subject here.  By including the
possible impl. choice in my original note I was simply asking if that is
what Marc had in mind - and I'm still wondering.  Marc?

w.r.t DougB's scenario...let's look at this differently, forget about RM
for a minute and let's take the case where there are two clients talks
to one server.  Both clients send a request message (w/o RM) to the server
at the same time, and they both include an anonymous wsa:ReplyTo.  Hopefully,
we can all agree that if the server decided to send client 1's response to
client 2 and client 2's response to client 1 that people would not be
happy.  So, now let's add RM into the picture and simply make both clients
use the same RM sequence.  Nothing different should happen w.r.t. which client
_should_ get which response - in this case all RM is buying us is that the
messages will be reliably delivered and probably done so InOrder.  Nothin more.
Yet, the approach you seem to be advocating is that mixing up the responses
would be ok.  Without some additional mechanisms (or at least good text) in
place how can the server know which anonymous client should get which response
unless its uses the original http socket? Simply because they're both using
the same inbound RM sequence doesn't mean that the RMD is free to mix up
their responses.

thanks,
-Dug


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