[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
+1 on Peter's "or, better" option.
Mark.
Peter Furniss wrote:
>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]