- From: David Hull <dmh@tibco.com>
- Date: Thu, 21 Jul 2005 14:30:12 -0400
- To: "Winkler, Steve" <steve.winkler@sap.com>
- Cc: public-ws-addressing@w3.org, Mark Nottingham <mark.nottingham@bea.com>
- Message-id: <42DFE9B4.3080903@tibco.com>
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" 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.html
>> and following thread
>>
>
Received on Thursday, 21 July 2005 18:30:34 UTC