Doug,
Interesting. A similar discussion about plucking bits out of their
assumed context has arisen in relation to WS-Coordination (part of TX).
I agree very much with your general approach on this. What's wrong with
using vacuum cleaner motors to drive interesting new science projects?
In general there is a strong tendency for people to confuse usages of
standards in their products (or imagined products) with all possible
uses. Specification writers can waste a lot of time trying to prevent
this. These attempts are analogous to the spare motor having a sticker
on it saying "Only use in an Acme Vacuum Cleaner: Acme take no
responsibility for other use." Aka, waffle for the lawyers, a litigious
way of saying: "on your own head be it". The specifications equivalent
is: "if you use some part of our spec for novel purposes, you had
better define how and why you are using it, and make sure you clarify
the limitations or extensions that you apply to the part you find
useful. Good luck to you." Obviously you run the risk that the part you
chose gets twisted in a future version because its primary use demands
change. So dependency on a very fast-moving spec in formation should be
eschewed, whereas dependency on a settled spec is often pretty safe.
Obviously, something that keeps getting reused (gains market share)
might be hived off when that's proven to be useful. But that's the end
of an evolutionary chain.
Let me give you another topical example. WS-Addressing uses SOAP fault
elements to hold its predefined faults information. Now, arguably,
WS-Addressing faults are meaningful for all bindings and
representations, and could/should have been defined at a more abstract
level than the SOAP binding. If they had been thought of as "part of
the XML infoset", i.e. a representation in XML of the abstract
properties, then they could have been rendered into a non-SOAPy format
(brand new schema). But they could equally well have borrowed the SOAP
fault representation even though they might be transferred outside the
SOAP context/binding in some theoretical future. Why not? It's there,
and it's got all the fields you need -- and it's XML.
On WS-TX, you correctly describe how it used to work. A recent decision
changed this: it was felt that the use of [reply endpoint] tended to
strongly imply (unless you were expert in the enumeration of angels on
pinheads) that you were using the WS-Addressing Core 3.4 rules on reply
formulation, which were not needed or intended in the WS-AT/BA context.
So we switched over to using [source endpoint] which carries no
processing/targetting rules baggage. It is is being used in WS-TX in a
very specific manner, which TX is careful to define. I think this
strengthens the force of your example, in fact. We picked up a general
purpose spanner, finding that the special tool designed for another job
was not the optimum choice. Care is needed in selecting and using the
tool -- but we certainly benefitted from pre-manufacture of the spanner.
Alastair
Doug Davis wrote:
Marc wrote:
> That
is going to lead to it being used for non RM applications.
Since most people in the TC have
remained silent on this issue I don't know whether this is something
other
people are worried about. But, in the event that some people are
thinking
about it I'd like to explain why I don't think this is a good argument
for discounting an otherwise valid (and IMO the more straightforward)
proposal
to resolve this issue. Earlier today I was trying to think of an
example where a feature of a WS spec was designed in such a way that it
_could_ be used for other purposes - and a very obvious one came to
mind:
wsa:ReplyTo. This one header/EPR was obviously designed to
denote where replies should be sent. However, WSA basically stops
there. It explains why WSA defines it, says what it's for and that's
it. However, if we following the same reasoning that some people
have put forward concerning our proposal, wsa:ReplyTo would either have
to be moved to a new spec or changed radically in some way simply
because
it _can_ be used in other situations that it was not originally
intended
for. Allow me to explain...
For those who may not have been
following the WS-TX specification(s), WS-TX reuses the wsa:ReplyTo on
its
one-way messages to denote, not where replies to the current message
should
be sent, but instead the location of one of the components of the TX
system
- just in case its EPR has changed or is no longer available to the
receiving
endpoint. WS-TX is allowed to do this because its reuse of this WSA
feature does not conflict or violate WSA's defined use of it. Should
WSA have been forced to move this reusable feature to some other spec?
Probably not . It was added to WSA because they needed it to solve
a very specific problem - the fact that WSTX was able to reuse it is of
no consequence to its useful/appropriateness to the WSA spec - it was
the
right technical decision for WSA. I think the same applies here.
So, echoing what Sanjay just
said in a note, let's discuss the technical aspects of the proposal and
whether or not its the best way for RX to solve the issue on the table.
thanks,
-Doug
Yes but it is not tied
to
RM in any way besides it’s namespace. That is going to lead to it being
used for non RM applications. There be dragons.
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, May 10, 2006 2:05 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon use
case
Interesting... a generic polling mechanism should consider things like
batching. I suppose it could also do such other basic things like
examine the wsa:ReplyTo so the polling response could be sent to
someplace
else. All these kinds of things could make perfect sense for a general
purpose polling mechanism. I wonder why our proposal doesn't do stuff
like that? Could it be because its not a general purpose polling
mechanism? Could it be that our proposal focuses on just one thing,
the re-establishment of a lost backchannel? naaa :-)
-Doug
Well Dave’s mention below is the first I’ve seen. Why is this such a
bad idea though? Returning multiple messages to a client after it polls
a mailbox location certainly seems a reasonable design choice. Such an
approach could compose well with something like WS-Enumeration.
Considerations
like this need to be taken into account in any honest examination of
designing
a general purpose polling mechanism.
Of course this, and the other two proposals (from one person), just
further
illustrates to me why doing this in this TC is a bad idea. Polling is a
general purpose mechanism that should be designed completely, not
partially
as it is in the three current proposals that take that approach.
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: Monday, May 08, 2006 1:15 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon use
case
Blimey - who suggested that! :-)
-Doug
One thing I do not want to see is boxcarring of multiple responses for
a single "Get*" response.
Blimey and crikey, what happens if the connection fails partway through
such a boxcarred response. Argh and yuck.
Dave
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Sunday, May 07, 2006 6:39 PM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon use
case
So, for every request message that had a response there would have to be
a GetMessage? 10 requests == 10 GetMessages? Doesn't seem optimal
:-)
Or if you mean that a GetMessage+msgID can pull back any response
related
to any request from the client->server seq, then how long does the
server
need
to maintain this state info? It would need to save every request
msgID since it
might appear later on in a GetMessage.
And, even if it did, can it really make any assumption about that
message
and any
message flowing in the other direction? Remember, under normal
circumstances
an
RMS could decide, for any variety of reasons, why a message goes into a
sequence.
You seem to be implying that by passing in a msgID that _all_ responses
related to
any message associated with the client->server seq (as correlated by
this msgID)
MUST then use this Offered sequence - seems a bit restrictive. Or,
if not MUST, then
it at least implies that it SHOULD, and if not either of those then
what
other sequence
can the server use since the client has no way of knowing when to Offer
any other.
I really don't understand the point of the Offered sequence as
currently
specified in
your proposal. Without any additional correlation info what can the
server
possibly
assume its used for? It doesn't know which endpoint sent it. It
seems like the only
option available with your proposal is the Offered sequence of the
original
client->server CS msg - and if either of those sequences
close/terminate
early then
all bets are off. And I think it links the two sequences pretty
tightly
- something I thought
we were trying to avoid.
-Doug
Paul Fremantle <paul@wso2.com> wrote on 05/05/2006 01:14:38 PM:
> Actually that was exactly the motivation for allowing the
GetMessage
to
> include a messageID for relatesTo matching. However, I am not yet
> convinced that the use case of an anon client shared across
multiple
> endpoints is really so useful. I can't imagine a case in which
this
> would be necessary. The scenarios for a shared sequence across an
> endpoint seem to imply some cluster of machines or corporate
gateway
and
> these usually have well defined endpoints. Alternatively, its
possible
> that a gateway could do its own correlation of responses back to
the
> correct endpoint.
>
> If you can persuade me that this is a highly valuable and very
important
> scenario I'd be happy to add the <wsa:MessageID> back into
the
proposal
> which would fix this. However, at the moment I would lean towards
adding
> a warning "here be dragons", that alerts implementors to
this issue.
> Since the situation is purely initiated by the "client"
then a client
> RMS should not initiate an offered anonymous sequence if it is not
able
> to distribute the messages to the right endpoint.
>
> Paul
>
>
>
>
> Doug Davis wrote:
> >
> > Maybe I didn't follow the thread but I thought the problem
related
to
> > how, when a
> > client sends a GetMessage, does the server know which client
is
> > sending the
> > message? It can't just send any message in the sequence
to any client
> > who
> > happens to be an RMD for that sequence. If the RMD spans
multiple
> > endpoints
> > the server needs to make sure that the messages for clientA
go
to
> > clientA and
> > not clientB. SequenceID alone isn't enough - so what other
> > correlation does
> > Paul's proposal use? Or is the answer that Paul's solution
only works
> > for
> > one endpoint per sequence? If so, we have yet another
restriction
on
> > the use-cases
> > that it supports.
> >
> > -Doug
> >
> >
> >
> > *"Marc Goodner" <mgoodner@microsoft.com>*
> >
> > 05/04/2006 09:22 PM
> >
> >
> > To
> > Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
> > cc
> >
> > Subject
> > RE: [ws-rx] Minimalist GetMessage proposal: the
anon use case
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > So how does telling the other side where to send the RM
protocol
> > messages not solve the problem you perceive 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:* Thursday, May 04, 2006 6:17 PM*
> > To:* ws-rx@lists.oasis-open.org*
> > Subject:* RE: [ws-rx] Minimalist GetMessage proposal: the
anon
use case
> >
> >
> > If I remeber correctly, that part of the spec just tells the
other
> > side where to send RM protocol messages to for the Offered
sequence
-
> > since it otherwise has no idea where they go.
> > -Doug
> >
> > *"Durand, Jacques R." <JDurand@us.fujitsu.com>*
> >
> > 05/04/2006 07:39 PM
> >
> >
> > To
> > Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
> > cc
> >
> > Subject
> > RE: [ws-rx] Minimalist GetMessage proposal: the
anon use case
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > That crossed my mind too…
> > But then the spec seems to rule that case out in case of
offered
> > sequences, given the exclusive scoping to one endpoint
assumed
by:
> > wsrm:Offer/wsrm:Endpoint (WD12, Line283)
> >
> > Jacques
> >
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > *
> > From:* Doug Davis [mailto:dug@us.ibm.com] *
> > Sent:* Thursday, May 04, 2006 3:53 PM*
> > To:* ws-rx@lists.oasis-open.org*
> > Subject:* RE: [ws-rx] Minimalist GetMessage proposal: the
anon
use case
> >
> >
> > I'm a bit lost - too much email on this today :-) but even
if there
> > as a wsrm:Identifier
> > in a message that doesn't tell you which client it is since a
sequence
> > can span
> > multiple endpoints.
> > -Doug
> >
> > *"Durand, Jacques R." <JDurand@us.fujitsu.com>*
> >
> > 05/04/2006 03:17 PM
> >
> >
> >
> >
> > To
> > "Paul Fremantle" <paul@wso2.com>
> > cc
> > "wsrx" <ws-rx@lists.oasis-open.org>
> > Subject
> > RE: [ws-rx] Minimalist GetMessage proposal: the
anon use case
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > - The case reliable-in/reliable-out works quite well,
provided
the RMS
> > does the correlation between initial sequence and offered
seq,
as
> > recommended in 4.2.
> > - The case unreliable-in/reliable-out seems to need the
"hint"
you
> > mention in 4.2., plus some other way to offer a sequence than
the CS
> > carrier.
> >
> > In any case, the many-anonymous(RMD)clients-
to-one-(RMS)server
appears
> > to be quite a common case (many users of the same WS
instance),
to
> > justify adding back 4.2 in your proposal...
> >
> > Jacques
> >
> > -----Original Message-----
> > From: Paul Fremantle [mailto:paul@wso2.com]
> > Sent: Wednesday, May 03, 2006 11:15 PM
> > To: Durand, Jacques R.
> > Cc: wsrx
> > Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon
use case
> >
> > Jacques
> >
> > You are quite right. This is an interesting situation. One of
the
> > problems is that we do not in this spec define how messages
are
> > allocated to sequences. The IBM proposal simply shifts this
problem
to
> > the EPRId as you point out.
> >
> > In one of my own early drafts of the proposal I had these
words
in
> > section 4.2, but I removed them for simplicity. However, if
they
are
> > useful they could be added back.
> >
> > "The WSRM specification does not define the allocation of
messages to a
> > sequence. In the case of reliable request-response with an
anonymous
> > client, the server MAY make a correlation between an incoming
sequence
> > and an offered sequence. In the case where the request
message
is
> > unreliable, and the client is anonymous, there might not be a
clear
> > basis to allocate messages to a given sequence. In this
scenario
the
> > client MAY add the <wsrm:Identifier> of the offered
sequence
as a SOAP
> > Header element or elsewhere in the message as a hint to the
server."
> >
> > Paul
> >
> > Durand, Jacques R. wrote:
> > > Paul:
> > >
> > > Are you sure this works when two different
(un-addressable)
clients
> > are
> > > sending an anonymous wsrm:Offer/wsrm:Endpoint to the
same
RMS-to-be
> > > endpoint, say for offering sequences S1 and S2?
> > > The offered sequences S1 and S2 have to be clearly
associated
from the
> > > start with the right client-RMD, by the server-RMS.
> > > With an in/out pattern where the in message is not sent
reliably, how
> > > would the server-RMS know if it should use S1 or S2 when
sending the
> > out
> > > message for an in message of one of the two initiators?
> > > Don't we still face the same issue of distinguishing
anonymous
> > endpoints
> > > that IBM proposal tries to address ( with wsrm:EPRid) ?
> > > (Do I miss something?)
> > >
> > > Jacques
> > >
> > > -----Original Message-----
> > > From: Paul Fremantle [mailto:paul@wso2.com]
> > > Sent: Wednesday, May 03, 2006 12:05 PM
> > > To: wsrx
> > > Subject: [ws-rx] Minimalist GetMessage proposal
> > >
> > > Based on some of the discussions it seemed to me that it
could be
> > > valuable to produce a completely "minimalist"
GetMessage proposal.
> > >
> > > This is a new proposal that is based on the previous
WSO2
proposal.
> > >
> > > The proposal removes the MessageID selector in the
GetMessage
-
> > relying
> > > on simply getting whatever message the server sends back
next.
> > >
> > > Also it removes the section 4.2. Effectively section 4.2
is an
> > > optimisation: for example to support
unreliable-in/reliable-out
a
> > client
> > >
> > > could do a createsequence+offer and never use the
outgoing
sequence.
> > In
> > > this case there is an overhead, which 4.2 aimed to
remove,
but this
> > > simplifies the proposal by focussing on the bare minimum
required to
> > > support the most common use cases, but still allowing
the
other use
> > case
> > >
> > > with a slight overhead.
> > >
> > > I've also included a sample message flow which I hope
helps
understand
> >
> > > the proposal and show the general usage.
> > >
> > > 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
>
|