- 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
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. Amy! (vreditel'nitsa obshchestvennogo poriadki) -- Amelia A. Lewis Senior Architect TIBCO/Extensibility, Inc. alewis@tibco.com
Received on Wednesday, 17 November 2004 18:07:37 UTC