ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] i089 proposal
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 4 May 2006 14:10:14 -0600
Paul,
From the perspective of developing solutions
to solve the various
RM-specific use-cases, there is no difference between
our proposals.
They are both polling solutions. So, the basic
question is whether
or not people want to have some kind of polling solution
in this spec
or not. At the f2f the straw poll clearly indicated
that the
thinking (at the time) was 'yes'. So, given
that assumption I find it
very disingenuous to discount our proposal as a valid
solution simply
because it 'can' be used in other non-RM situations.
What would
normally be considered a good architecture design
is now somehow viewed
as a bad thing.
Meanwhile, your proposal which hacks up the
protocol by doings
things like requiring the creation of a sequence for
no reason other
than to get an Offered one, or requiring the destination
to know when
the source needs a sequence so it can send this Offer
to begin with,
can't possibly be viewed as goodness - yet you're
promoting it like it
is simply because it reuses/bastardizes RM concepts.
Sorry, I just
don't understand that logic.
I think both proposals are valid w.r.t. trying
to solve real problems
that RM exposes. The set of use-cases each supports
is different
and we can discuss whether or not those use-cases
are things the TC
cares about however, they are all RM use-cases. Despite
the fact that
you may not see the value in certain use-cases (like
RM-enabled out-only)
isn't irrelevant to whether or not they RM use-cases.
You can argue that the
TC shouldn't care about those scenarios but you can't
argue that they
are not RM scenarios. So, to your assertion
that I've included
generic polling scenarios as part of my RM requirements...
show me where.
Show me how the sending of a GetMessage and getting
back a CS is not
an RM-specific scenario. Like I said, you can
argue that the TC should
not care about that scenario (I think you'd be wrong),
but you can not
argue that it is a generic non-RM scenario.
More comments in-line.
-Doug
Paul Fremantle <paul@wso2.com> wrote on 05/04/2006
02:55:55 AM:
> Doug
>
> Some comments:
> > I'm not promoting a general solution - not exactly :-).
What I'm
> > promoting is a solution that
> > solves all of the various use-cases that I believe the RM spec
should
> > address. In developing
> > the solution however, many people have noticed that it can work
even
> > when RM (the resend
> > until acked part of RM) is not turned on - and that is true but
> > nothing was added to the solution to
> > make that happen.
> However, you have defined (elsewhere) reliability very widely, including
> getting messages to endpoints that aren't reachable. So this argument
is
While in ramblings about why this could be viewed
as an appropriate RM
topic, sure - but please show me where in the proposal
it tries to address
anything other than the transfer of RM messages between
endpoints.
> really circular. Effectively what is says is that because I've included
> all the use cases for any polling situation in my requirements, I've
> ended up designing a system that supports them, even without any
> relation to the reliability mechanisms the WSRM spec has focussed
on. So
> effectively your proposal is completely orthogonal to the existing
RM
> spec. If we took your proposal, changed the namespace, and published
it
> separately, it would be a valid standalone spec that could be composed
> with RM or not.
Wrong - see above. There isn't anything in our
proposal that isn't there
to address a very specific RM need.
> > In fact, it would take a lot of effort (and IMO hurt the proposal)
if
> > it was modified
> > to only work like Paul's proposal - he tried very hard to tie
his
> > proposal to RM sequences, and
> > as a result he limited the RM scenarios he can support
> I actually believe that my proposal can support almost any scenario.
> However it focuses on the core scenario and requirement that we see
in
> the marketplace - which is supporting anonymous clients doing in,
> in-out, and in-multi-out MEPs against a server with a well-known endpoint.
I disagree - you're only focused on your scenarios
and somehow you think
those are the only ones that matter - sorry - this
isn't WS-Paul'sRM.
RM needs to allow for people to support as many scenarios/MEPs...
as possible
not just the ones _you_ consider 'core'.
> > - and he will end up changing the core RM processing model too.
> The phrase "core RM processing model" is very dangerous
if not
> disingenuous. The specification does not define the RM processing
model.
> It is up to each implementor to build a processing model for RM that
> supports the protocol. And so what you consider important about your
RM
> processing model may not be what I consider important. The use of
this
> term, as if it were something sacrosanct and untouchable, is misleading.
> If we focus on the actual use cases, scenarios and implementation
> details then the discussion will be much more open.
I disagree. The current RM spec specifies what
needs to happen on the
wire and its leaves implementations free to make choices
about how to
make that happen. While the spec doesn't say
"an RMS gets to choose
which sequence each message goes in", it doesn't
need to -its obviously
and implementation choice/detail that the spec should
not touch.
Our proposal doesn't change the set of choices available
to the
implemenation - and its those choices that I consider
part of the
"RM processing model". You're proposal
limits those choices and
therefore changes the processing model.
> For example, I think what you mean in this case is that either side
can
> create a sequence with the other side whenever it wants, and that
in my
> proposal this isn't true as the Client must Offer a sequence to the
Server.
>
> Of course in real life this is completely untrue. In the current spec
> the server cannot actually create a sequence with an unreachable
> endpoint. Simply because it can't reach it. My proposal doesn't change
> this. It is up to the TC to decide whether they want to support this
> aspect or not. However, it has very little to do with "changing
the core
> RM processing model".
>
> I deliberately didn't try to solve this because as you have shown
the
Good - you admit there are RM scenarios you don't
support - remember that :-)
> only way to do this is to create a complete alternative polling model
> under which the server can communicate with the client. In order to
> connect to an anonymous client, you need a context under which to
> communicate. You simply have a choice - use the existing context (the
> sequence) that the RM spec defines, or create a new one. The EPRId
model
> that you have proposed effectively adds a new context that the server
> must keep track of. Not only is this adding a new set of state to
be
> managed, but nowhere in your spec does it define the lifecycle of
this
> state. So it is undefined how long the server must keep track of this
> state. The server must buffer messages under this EPRId context and
has
> no defined mechanism for cleaning this state up. There is no fault
model
> around this. There is no way for the client to signal a clean up of
this
> state. So your proposal adds significantly to the implementation of
an
> RM agent, and also adds a considerable amount of ill-defined machinery
> that will come out in the interoperability testing and in implementation.
There is no new state to keep track of. Depending
on how people choose
to implement it, sure, they could do a lot of screwy
things and therefore
increase the amount of stuff they need to manage -
but in my mind you
don't need to define a new 'context' object that has
lifetime - you just
need to locate the messages targeted to an EPR. How
someone chooses
to do that is up to them - personally, I can do it
w/o the need for
something that requires the amount of overhead you
talk about (including
this lifetime stuff). Its interesting because
your proposal is actually
the thing that introduces new state - you require
sequences for no reason
other than a reverse one - while the new 'thing' is
an already established
RM entity, you're proposal mandates additional, and
unnecessary, overhead
while ours does not.
> My proposal is designed to work with the existing context model that
RM
> defines (a sequence) and to make minimal changes to how the server
and
> client manage and use that context. Because of the work the TC has
done
> in tightening up the lifecycle of this context and in interop testing,
> my proposal builds on top of an already stable and interoperable base
> with a small and clearly defined addition.
Wrong - you radically change how RM works wrt how
sequences are created
and managed - you introduce new uses for RM entities
that are not currently
defined in the spec, and change their usage pattern/model.
Ours builds
on top of the current RM stuff - does not change how
the existing RM entities
are used at all and allows current RM processing logic
to work unchanged.
It simply offers a new mechanism by which these RM
messages can
be transferred between endpoints.
> Paul
>
> >
> >
> > *Doug Bunting <Doug.Bunting@Sun.COM>*
> > Sent by: Doug.Bunting@Sun.COM
> >
> > 05/01/2006 03:00 PM
> >
> >
> > To
> > Doug Davis/Raleigh/IBM@IBMUS
> > 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
> > >
> >
>
> --
>
> 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]