[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 013 - WS-C: Remove fault 4.5 ContextRefused
If we keep the tightly focussed meaning, I'd suggest making completely
clear with
"This fault is sent by a coordinator to indicate that the
coordinator cannot accept a context which it was passed in the
CurrentContext field of a
CreateCoordinationContext message"
or, better
"This fault is sent by an Activation Service to indicate that the
Activation Service cannot create a new context using the context passed
in the CurrentContext field of the
CreateCoordinationContext message"
Peter
ps: Max's messages on 013 and 008 don't seem to have been accepted by
the ws-tx@lists.oasis-open.org exploder or archive (I got them because I
was cc'ed). The one on 013 is copied in one of Sazi's messages. I gather
at least one message from Rich Salz behaved similarly. Do we have a
general problem ?
> -----Original Message-----
> From: Ian Robinson [mailto:ian_robinson@uk.ibm.com]
> Sent: 15 December 2005 09:14
> To: Sazi Temel
> Cc: Max Feingold; Peter Furniss; ws-tx@lists.oasis-open.org
> Subject: RE: [ws-tx] Issue 013 - WS-C: Remove fault 4.5 ContextRefused
>
>
>
>
>
>
> It might be better to be more explicit still:
>
> After:
> ==========
> "This fault is sent by a coordinator to indicate that the
> coordinator cannot accept a context which it was passed in a
> CreateCoordinationContext message" ==========
>
> Regards,
> Ian Robinson
> STSM, WebSphere Messaging and Transactions Architect
> IBM Hursley Lab, UK
> ian_robinson@uk.ibm.com
>
>
>
>
> "Sazi Temel"
>
> <sazi@bea.com>
>
>
> To
> 15/12/2005 02:26 "Max Feingold"
>
>
> <Max.Feingold@microsoft.com>,
> "Peter Furniss"
>
>
> <peter.furniss@choreology.com>,
>
> <ws-tx@lists.oasis-open.org>
>
> cc
>
>
>
> Subject
> RE: [ws-tx] Issue 013
> - WS-C:
> Remove fault 4.5
> ContextRefused
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Ok... The "Before" message was giving wrong impression - that
> a service was rejecting a context passed to it. The "After"
> message clarifies it. Thanks.
>
> .Sazi
>
> -----Original Message-----
> From: Max Feingold [mailto:Max.Feingold@microsoft.com]
> Sent: Wednesday, December 14, 2005 7:55 PM
> To: Sazi Temel; Peter Furniss; ws-tx@lists.oasis-open.org
> Subject: RE: [ws-tx] Issue 013 - WS-C: Remove fault 4.5 ContextRefused
>
> This fault was intended to represent the error condition of a
> coordinator that is rejecting a context provided in a
> CreateCoordinationContext message.
>
> I propose an editorial change to the fault text to clarify
> this. E.g.:
>
> Before:
> ==========
> "This fault is sent to a coordinator to indicate that the
> endpoint cannot accept a context which it was passed:" ==========
>
> After:
> ==========
> "This fault is sent by a coordinator to indicate that the
> coordinator cannot accept a context which it was passed:" ==========
>
> -----Original Message-----
> From: Sazi Temel [mailto:sazi@bea.com]
> Sent: Tuesday, December 13, 2005 12:03 AM
> To: Peter Furniss; ws-tx@lists.oasis-open.org
> Subject: RE: [ws-tx] Issue 013 - WS-C: Remove fault 4.5 ContextRefused
>
>
> I agree with the suggestion that ContextRefused should be
> sent to the application that "sends" the context.
>
> The sequence of message exchange involves an application
> service creates a context and "sends" it to another service,
> then that service registers with a coordinator. Even if the
> Coordinator gets ContextRefused message what can it do,
> ignore? No, it should probably inform the sender that "the
> other service" has problem with the context thus creating a
> complex message exchange sequence which can be avoided simply
> sending the refusal message back to original sender. I think
> the suggestion made below is correct and a simpler approach...
>
> .Sazi
>
> -----Original Message-----
> From: Peter Furniss [mailto:peter.furniss@choreology.com]
> Sent: Friday, December 09, 2005 1:16 PM
> To: ws-tx@lists.oasis-open.org
> Subject: [ws-tx] Issue 013 - WS-C: Remove fault 4.5 ContextRefused
>
> This is hereby declared to be ws-tx Issue 013.
>
> Please follow-up to this message or ensure the subject line
> starts Issue 2 (ignoring Re:, [ws-tx] etc)
>
> The Related Issues list has been updated to show the issue numbers.
>
> Issue name -- WS-C: Remove fault 4.5 ContextRefused
>
> Owner: Alastair Green [mailto:alastair.green@choreology.com]
>
> Target document and draft:
>
> Protocol: Coord
>
> Artifact: spec / schema
>
> Draft:
>
> Coord spec working draft uploaded 2005-12-02
> WS-Coordination schema contributed by input authors, not yet
> uploaded to Working Drafts folder
>
> Link to the document referenced:
>
> http://www.oasis-open.org/committees/download.php/15738/WS-Coo
rdination-
> 2005-11-22.pdf
>
> Section and PDF line number:
>
> Section 4.5 "Context Refused", ll. 451-459
>
>
> Issue type: Design
>
>
> Related issues:
>
> Issue 003 - WS-C: Appropriate categories of fault
>
>
> Issue Description:
>
> ContextRefused fault relates to application protocol
> behaviour which should not be specified by WS- Coordination.
>
>
> Issue Details:
>
> [This issue stems from Choreology Contribution issue TX-19.]
>
> Faults in WS-C should be divided into only two categories:
> those which apply to the process of context creation and
> registration (or which apply to the misuse of the
> conversational channel created by registration), and those
> which are basic faults available to all coordination protocols.
>
> ContextRefused is a fault that relates to an application
> protocol (an exchange between two applications that are
> attempting to establish agreed use of a distributed
> coordination protocol). Such protocols should define their
> own messages and faults.
>
> The preamble of this fault (l1. 452-453) states:
>
> "This fault is sent to a coordinator to indicate that the
> endpoint cannot accept a context which it was passed:"
>
> This description evokes the problem perfectly. An application
> communicates a context (by some means) to a service. The
> service decides that it does not wish to register any
> participants. This decision may be important, or unimportant,
> to the original propagator of the context.
>
> Example A: in an auction, the context has been posted on a
> secure website, accessible by registered bidders. The fact
> that registered bidder 43 is not interested in making an
> offer is uninteresting to the auction site.
>
> Example B: a client knows that he cannot proceed with a
> three-component trade unless at least one service for each
> component has registered. The client-service contract states
> that the service will either send a quote or will send a
> not-interested message, to ensure rapid conclusion of the transaction.
>
> Example C: same scenario as B, but the client simply tracks
> inbound quotes, and decides when he has sufficient to proceed
> to make a choice and conclude the transaction.
>
> Examples A and C do not require the semantic "not-interested" to be
> communicated: the semantic is not
> generally needed, therefore. Example B requires the semantic
> to be communicated from service to client, but not from the
> service to the Coordinator. We cannot assume that the
> Coordinator has any interest in presence or absence of
> particular participants, or their number ("checking").
> Indeed, products implementing protocols such as WS-AT and
> WS-BA typically leave checking issues in the hands of the application.
>
> These kinds of communications are the property of specific
> application protocols (or perhaps, of some future
> coordination protocols) but not of a general-purpose
> coordination framework.
>
>
> Proposed Resolution:
>
> Remove ll. 451-459 of the specification.
> Remove l. 100 of the schema document.
>
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]