[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
Now I understand what the intent of ContextRefused was (not
understanding it is a pardonable error, given the wording of the
preamble :-) ), I would suggest we have one fault (CannotCreateContext),
that means: "I refuse to process your request to create a new context".
The special case: "because I don't know about the supplied context", is
one of a number of reasons why new context creation can be refused.
Presumably the underlying reason has to be described textually, to give
more detail, for any of the cases where the AS refuses to play ball.
In other words: is it justified to have a special fault for this
circumstance?
In thinking about this, consistency with CannotRegisterParticipant is
possibly worth bearing in mind.
Alastair
Ian Robinson wrote:
>
>
> 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-Coordination-
> 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]