- From: Winkler, Steve <steve.winkler@sap.com>
- Date: Thu, 21 Jul 2005 11:52:36 -0700
- To: "David Hull" <dmh@tibco.com>
- Cc: <public-ws-addressing@w3.org>, "Mark Nottingham" <mark.nottingham@bea.com>
- Message-ID: <55620CF891864D4984A16302E4C420AA4AE21F@uspale20.pal.sap.corp>
Hi David,
<snip>If the idea is to have [message id] OPTIONAL but RECOMMENDED
everywhere, I'm all for it.</snip>
Yes, that is more or less what I'm advocating. Less so because you make
the leap that the message id would even be optional in requests where
responses are expected, which goes against the the working group's
current thinking. All that I would like to do is strengthen (or add)
the wording around strongly recommending (i.e. SHOULD) the use of
message id in all messages. I think that this is something that most,
if not all, working group members would be comfortable with (informal
conversations with other members have so far indicated this), but any
proposal beyond that will require much more discussion. You may have
good arguments for going beyond that and making the id optional in cases
where it is currently required, but I think this will be much more
contentious and I don't want to go down that road at this point in time.
Cheers,
Steve
________________________________
From: David Hull [mailto:dmh@tibco.com]
Sent: Thursday, Jul 21, 2005 11:30 AM
To: Winkler, Steve
Cc: public-ws-addressing@w3.org; Mark Nottingham
Subject: Re: Closure of LC86
Winkler, Steve wrote:
Hi David,
I'll take the time to make it shorter:
What I'm advocating is adding a sentence that basically
recommends that a message id SHOULD be present in all WS-A messages
(both requests and responses). The message id would still be, strictly
speaking, optional. As far as I understand you, we are in agreement on
this point, so I would like to limit any discussion for proposals to
this scope at this point.
Would that include changing the MUST to SHOULD for replies? I
gather from the discussion below that it wouldn't. If that's the case,
I'm not against adding such a sentence, but I don't think it changes
anything materially.
If the idea is to have [message id] OPTIONAL but RECOMMENDED
everywhere, I'm all for it.
I think I may just be more comfortable with the a la carte
approach than much of the group is. In my view, we're providing a
collection of very useful utilities. The way to get them used is to
make them useful (which they are). Requiring a facility whether or not
it's of use in a particular situation seems likely to raise the bar for
adoption. I can actually see someone wanting to be "lighter weight" and
defining <NewmansOwn:{Reply,Fault}To> with the same meaning as
<wsa:{Reply,Fault}To> except that you don't have to include <wsa:Action>
and <wsa:MessageId> in order to use it. Or worse, quietly just not
conforming and only paying attention to <wsa:{Reply,Fault}To>. I don't
endorse either approach, but I wouldn't be surprised if someone decided
to take one of them.
Now I can hear the reply coming from somewhere in the ether:
"But that's the beauty of the SOAP processing model: You can define
your own headers if you don't like ours." I think that's fine when my
headers don't overlap significantly with existing standards, but it's
not fine at all when my headers are playing in essentially the same
space as what's already there.
Is it more important to allow senders who don't need [message
id] for correlation to get replies even if they don't include [message
id], or for senders that do need [message id] to be warned that some
message they sent (they won't always know which one since there's no
[message id]) didn't include one?
I think the realistic answer is "it depends," and a receiver
should be able to behave either way (and advertise that behavior)
without breaking conformance. That's why I'm much more comfortable with
"SHOULD fault" than "MUST fault" in section 3.3. I would prefer to see
this handled by leaving the core flexible but biased toward stricter
behavior (i.e., faulting in this case). Bindings like the WSDL binding
can then make strict behavior the default while allowing loopholes for
more lax behavior. Of course, they can do this anyway (this flavor of
endpoint is WSA conformant except ...), but it seems better to add
constraints to the core rather than to selectively override ones that
are already there.
See below for some curt (in the interest of brevity, not
insolence) retorts to the points I found the most salient.
Cheers,
Steve
--------------------------
Steve Winkler
SAP AG
________________________________
From: David Hull [mailto:dmh@tibco.com]
Sent: Wednesday, Jul 20, 2005 2:22 PM
To: Winkler, Steve
Cc: public-ws-addressing@w3.org; Mark Nottingham
Subject: Re: Closure of LC86
Apologies that this is so long. As Blaise
Pascal once said, I didn't have time to make it shorter.
Winkler, Steve wrote:
Hi David,
Since I was probably the most vocal
opponent of making wsa:MessageId optional, I feel a response is probably
warranted. I think that some of the ideas in your proposal could make
the status quo better, but I don't agree with all of it.
As you'll remember from the Berlin F2F,
I was arguing against making message id optional. I actually went the
other way and advocated the utility of an ever-present message id, and I
used the auditing scenario as an illustrative use case. This was just
one use case, but I do think that message ids are generally useful, for
responses as well as all requests, and not just in the case of a request
where reply message is expected.
The main objection to this that I saw
would be the performance hit that the sender of a message would incur
when ensuring the uniqueness of the message id. This makes sense to me,
and I would be willing to relax my original standpoint from a REQUIRES
to a SHOULD contain a unique id, which would still allow performance
conscious senders to omit the id while encouraging the use of the
message id in all normal cases.
I would prefer, however, to stop there.
I have not yet seen a convincing use case where including a message id
would be prohibitive for correlation.
First, I'm not comfortable with the notion that
[message id] should be REQUIRED so long as it doesn't impede correlation
use cases. Just going by that, I could require that every request
include <wsa:Please/> and every response include <wsa:HereYouGo/> and
<wsa:HaveANiceDay>. These don't impede correlation, or anything else
for that matter, and they might improve the civility of network
commerce, so why not require them? The only difference with [message
id] is that we can identify particular cases where [message id]
certainly does help, namely auditing and cases where correlation is
needed and no other mechanism is available. But by that reasoning we
should require that WSS or WS-Trust or whatever be used everywhere WSA
is because they are certainly useful in some cases where WSA will be
used.
<SW>
<wsa:HaveANiceDay> and your other examples
provide no value. MessageId provides great value. We are writing a
core spec here on which other specs will hope to compose. If they can
be relatively sure that most default implementations of WS-A will have a
message id, they will be more likely to reuse rather than roll their
own.
</SW>
In this context, the performance hit is a
symptom, not a central factor. I'm more concerned that we are making a
sweeping requirement (but one that presently only sweeps over requests
and leaves other messages unswept) without a convincing case that the
thing to be required is always needed, and indeed with definite evidence
to the contrary.
<SW>I have yet to see such evidence.</SW>
This seems wrong from the beginning, but I
respect that others may view the burden of proof differently. In any
case, I'm more interested in reaching consensus (see below) than arguing
over the burden of proof (and thence over the burden of proof in the
argument over the burden of proof ... :-).
In fact, I think it's obvious that being
able to uniquely identify a message is of paramount importance in
correlation. If you choose to use an out of band correlation mechanism
and have it supersede what is defined here, then so be it. The WS-A
charter requires us to specify properties which allow for the
correlation of messages, and I think that a message id should still be
REQUIRED when a response is expected.
In a broad sense, being able to uniquely
identify a message is essential to correlation. However, this doesn't
have to be done by a message id. In the well-known case of SOAP/HTTP,
we identify the message, even in the presence of pipelining, by when it
comes back over the response channel.
<SW>This is transport specific. WS-A core
concepts are, per our charter, to be transport agnostic.</SW>
There are other cases where an endpoint will
effectively be created for the purposes of one message only, so
identifying the message is trivial. I've also mentioned the case where
the application-level payload carries a transaction id or something
similar and correlation is effectively handled at the application layer.
In these cases, the [message id] handshake is not adding any value.
<SW> By this rationale, we might as well just
all go home. Everything can be done in the application payload, and
everyone can roll their own systems. We're shooting for interop here.
If you want to do something extra, fine, go ahead, but don't expect it
to work with my systems out of the box.</SW>
I'm more interested, though, in cases where
correlation is or can be done by other SOAP-visible means. For example,
suppose I have defined a choreography such that for any given instance,
there will be exactly one message for each [action]. Each instance has
its own context ID header. Suppose that one piece of this happens to be
a request/response, but the request/response endpoint naturally doesn't
know that it's participating in the choreography. In a nutshell, when
the receiver of the response sees [action]=..../fooResponse, it knows
that that's the one and only fooResponse message for that instance of
the choreography. It doesn't need a message id.
<SW>True, but only because the choreography spec
can depend on the presence of Action to make it's determination. I
would argue that other specs could rely on message id to do other
interesting things in the same manner.</SW>
Or, on a completely different tack, suppose I
know that reliability is in play. The reliability layers that we know
of use a (sequence id, sequence number) pair to uniquely identify each
message. Rather than create another id on top of that, why not just
tell the receiver "put the sequence id, sequence number" of the request
in the reply and I'll know what to do. Let me be clear that I think
this would be completely out of scope for us. But I'm not sure we want
to actively discourage it, either.
<SW>There is nothing to stop the writers of that
spec from creating a URI encoding scheme to include the sequence id and
sequence number in the WS-A message id URI. Reuse achieved.</SW>
I would like for clients to be able to use
whatever's handy for correlation, or not correlate at all. In this
view, [message id] is our standard header element for identifying
messages -- which I think is pretty close to the charter -- and the rule
in section 3.3 is a way of leveraging this as one way of providing
correlation, if it's needed. The obvious concern here is that it might
hurt interoperability if the client can correlate any way it wants. But
I think this misrepresents what's going on. Interoperability comes from
the server being able to advertise exactly what it does and does not
guarantee with respect to the MAPs, not from the server refusing to
accept request messages that may work perfectly well for the client. As
long as the client knows that the server will always reflect the
[message id] of the request in the [relationship] of the reply, provided
[message id] is present in the request, the client always knows enough
to interoperate. The server has told the client the rules
unambiguously, and it can assume the client knows what it's doing.
<SW>No real disagreement here. I'll reiterate
that there will be less chance of a problem if the client is encouraged
to always send a message id. I personally still feel that a WS-A
request message that expects a response should still be required to
contain a message id. If you don't want this, maybe WS-A isn't the
right choice for you.</SW>
Suppose some later server advertises "I will
reflect [message id] if it's present in the request. I will also
reflect (sequence number, sequence id) if they're present." Is this any
less interoperable than what we have now? I would argue that if
anything, it's more interoperable. It will provide correlation for a
client that includes [message id], and it will also provide correlation
for a client that's using a reliable connection. The only argument that
I can see here is that this might undermine the universal use of
[message id]. Personally I'm uneasy with trying to use a correlation
facility as a lever to try to get people to support auditing, and I also
feel that the proposal I made is a better lever anyway.
<SW>I was never attempting to use correlation to
support auditing. I simply used auditing as a single use case (there
are more) to show that having message ids generally be contained in WS-A
messages is useful. I don't even really want to get into the
correlation discussion at all if I don't have to.</SW>
(I note in passing that the charter itself
refers to the definition of Identifier given in the Web Services
Architecture. This reads "Identifiers are used to identify resources.
In the architecture we use Uniform Resource Identifiers [RFC 2396]
<http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#RFC2396> to identify
resources." The second sentence is disputed. In short, there's not a
lot of guidance offered here as to what we're trying to accomplish.)
It seems that the two people with the
most opposite opinions have come quite a bit closer, but what should we
do about it now?
Indeed. I believe we're not too far from
agreement, if not on underlying philosophy, at least on the end result.
The issue was closed in Berlin, perhaps
a bit hastily at the end of a long meeting where people were jetlagged,
but it was still closed. Are you just registering your dissatisfaction,
or do you have a course of action you would like to propose?
Well, I do have a concrete proposal that might
be worth considering at some point. I don't think this is the right
point -- if I did, I would have pushed for consideration at the meeting.
Right now, I would rather go for CR and see what the director makes of
all this, realizing there may never be another opportune moment. Them's
the breaks. This was never a deal-breaker for me. I do strongly feel
that the spec could be better in this regard, but I don't feel that the
current handling of [message id] is irreparably broken. And to be
honest, plenty of specs have made it out the door with bigger flaws.
<SW>It's not a deal breaker for me either, but I
think the spec would be better off with the guidance that a message id
SHOULD be present in WS-A messages, unless a particular implementation
has a good reason not to include it.</SW>
However, I would like people to consider the
current proposal and in particular consider whether it supports
universal unique ids for messages better than the status quo. As far as
I can see, it does, by tilting the landscape heavily in favor of ids on
all messages, not just requests.
<SW>+1 with the focus, though I think your
proposal is too broad to gain widespread support. I would rather focus
on the focus, so to speak.</SW>
If there's a general agreement that it does,
then we can consider whether to try to bring it in at some point. Since
the proposal is a response to the group's closing of an LC issue, the
director will be aware of it and may also weigh in on whether it's worth
considering. Beyond that, it's up to the group to decide whether
there's a strong agreement that it's an improvement (there may not be)
and if so, whether there's a good way to bring it in without wrecking
the schedule.
In any case, I couldn't let an idea that seemed
worthy of consideration and might make life better for everyone just
lie. So there it is.
Hope this helps.
Cheers,
Steve
---------------------------
Steve Winkler
SAP AG
________________________________
From:
public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
Sent: Tuesday, Jul 19, 2005 7:17 AM
To: public-ws-addressing@w3.org; Mark
Nottingham
Subject: Closure of LC86
This message records my dissatisfaction
with the closure of Last Call issue 86, entitled "[message id] should be
optional." [1] and proposes a novel resolution that would resolve LC86.
This proposal should also be an improvement on the status quo regarding
the concerns that caused LC86 to be closed with no action originally.
Issue LC86 was closed with no action at
the Berlin face to face. TIBCO and others voted against this closure.
Since then, there has been further discussion of the use cases that
[message id] might or might not support, and the notion of [message id]
uniqueness has been clarified in the resolution of LC75. Both of these
events, together with the proposal below, introduce new information
relevant to the resolution of LC86.
In the discussion of use cases for
[message id], several possible uses were proposed. In my understanding,
only two held up to closer scrutiny, namely
* The original use case of message
correlation.
* The use of a standard,
transport-independent [message id] on all messages for various auditing
purposes.
Neither of these is grounds for making
[message id] a REQUIRED property. The original issue description argues
that [message id] need not be REQUIRED on all messages in order to
support message correlation, both because message correlation may not
always be necessary, even when the receiver is acting in a
request-response fashion, and because correlation can and in some cases
likely ought to be accomplished by other means. I also argue that
producing a [message id] and checking for its presence and uniqueness
consumes resources that may be scarce in some scenarios. In any case, I
do not believe that the correlation case was a major factor in closing
LC86 with no action.
I have argued separately [2] against the
second case, both on the grounds that the status quo does not
effectively support it, and on the grounds that it is out of scope for
the core of addressing, is not needed in all WSA deployments and so
should not be REQUIRED. Deployments that require a universal unique
[message id] can mandate it separately without contradicting anything in
the core, even if [message id] is made OPTIONAL in the core.
My understanding is that LC86 was closed
because it was felt that requiring [message id] would promote the
auditing use cases and making it optional would weaken this. However,
the status quo only requires [message id] in the case of request
messages. Further, it effectively discourages it in other cases. The
behavior of a node receiving a message with a duplicate [message id] is
unconstrained. There is thus no point in including a [message id]
anywhere it is not mandated, as there is always the risk of accidental
collision for any of various reasons. While this risk may not be large,
it is easily eliminated by omitting [message id] altogether. The status
quo thus supports auditing of requests while undermining auditing of
everything else. Further, it is difficult to see how to fix this. The
receiver of a reply or a fire-and-forget one-way message does not have
the option of throwing a fault on receiving a message with a missing
[message id].
I believe that the auditing use cases
can be better supported while allowing flexibility for deployments that
do not want [message id], with small changes to the existing text.
Namely
* Amend the description of the
[message id] property to add the italicized text:
An absolute IRI that uniquely identifies
the message. When present, it is the responsibility of the sender to
ensure that each message is uniquely identified. The behavior of a
receiver when receiving a message that lacks a [message id] or that
contains the same [message id] as a previously received message is
unconstrained by this specification.
* Change MUST to SHOULD in the
paragraph in section 3.3 reading
In either of the above cases, if the
related message lacks a [message id] property, the processor MUST fault.
* Add the italicized text to the
following paragraph in the same section:
[relationship]: this property MUST
include a pair of IRIs as follows; the relationship type is the
predefined reply URI "http://www.w3.org/@@@@/@@/addressing/reply"
<http://www.w3.org/@@@@/@@/addressing/reply> and the related message's
identifier is the [message id] property value from the message being
replied to, if it is present; other relationships MAY be expressed in
this property
This strongly encourages the presence
and uniqueness of [message id] in all messages in just the same way the
the present text strongly encourages its uniqueness alone. However, the
softening of MUST to SHOULD allows flexibility in situations where
[message id] is not wanted. In such cases, receivers may advertise, or
it may otherwise be made known, that messages lacking a [message id]
will be processed normally. Then, and only then, do senders know that
it is safe to omit the [message id].
This proposal provides the desired
ubiquitous unique id by default while allowing deployments to explicitly
waive the requirement when appropriate. It is thus an improvement on
the status quo in both flexibility and in support for auditing.
References:
[1]
http://www.w3.org/2002/ws/addr/lc-issues/#lc86
[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jun/0054.ht
ml and following thread
Received on Thursday, 21 July 2005 18:53:10 UTC