W3C home > Mailing lists > Public > www-ws-desc@w3.org > November 2004

Re: Summary, 9-11 Nov 2004 WS Description WG FTF: two objections

From: Amelia A Lewis <alewis@tibco.com>
Date: Wed, 17 Nov 2004 13:07:09 -0500
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: www-ws-desc@w3.org
Message-id: <20041117130709.4507e866.alewis@tibco.com>

On Tue, 16 Nov 2004 12:51:25 -0800
Jonathan Marsh <jmarsh@microsoft.com> wrote:
>   Issue LC50
>     ACTION: DBooth and Anish to clarify what a node is

Reading the minutes, I'm slightly disturbed by the overall hyperfocus on
client/server models of networking.  Here, as in other places, there is
a strongly-held assumption evident in the discussion that "service" ==
"server" and the partner of the service is always a client.

The definition of "node" in part two is intentionally vague (David Booth
experienced interesting problems in the task force, trying to achieve a
precise definition, because too tight a definition might mean, for
instance, that a node which is a service cannot make use of its own
interface as a client ... granted, a corner case, but ruling it out by
definition seems to go a few steps too far).

For this issue: different names of nodes (A, B, C) imply that identity
MAY be different, but do not require it.  A node of a given name has
identity.  This is the only assertion about node identity that the
message exchange patterns make.

Therefore, for instance, in section 2.2.3, the use of a single node,
named N, interacting with the service, absolutely precludes the
participation of some other node (N1, O, M, whatever).  In the current
request-response MEP, the request message comes from one particular
named node, and both faults and responses MUST go back to that
particular named node, because there is no other node mentioned in the
MEP, and there is no flexibility permitted.

The "generalized" pattern of in-out would have a request from some node
N1, a response to some node N2.  Whether N1 and N2 are the same node
would be left unspecified.  They MAY be, but are NOT REQUIRED to be.

According to the rules of features/extension, WS-Addressing/WS-MD or the
equivalent is able to override the meaning of these MEPs in particular
bindings, effectively highjacking the messages (rather than describing
the MEPs accurately).  This is ugly, but it's the status quo at present.

MEPs containing two messages all share these issues.  Wherever the "node
N" interacting with the service is mentioned more than once in a MEP,
there is potentially a parallel MEP, in which there is a node N1 and a
node N2 (more likely with input-first MEPs than output-first; it is more
common to redirect a response than to nominate an alternate respondent).

>   Issue LC59a
>     RESOLUTION: In-Optional-Out and Out-Optional-In will be marked at
> risk 
>                 when entering CR and will be removed unless we see 2 
>                 interoperable implementations

Objection: TIBCO Software, Inc., requests that this be modified to "All
MEPs are to be marked as at risk when entering CR and will be removed
unless we see 2 interoperable implementations."  This MUST include
in-out, among others.  Only if this is done will anyone bother to define
"interoperable implementation" in a testable fashion, as the
client/server computing crowd will have their toys perfectly protected
in advance.

(vreditel'nitsa obshchestvennogo poriadki)
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
Received on Wednesday, 17 November 2004 18:07:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:45 UTC