[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 004 - WS-C: Add new fault CannotCreateContext
Peter, Ian I am including below Max's reply to my (and Peter's original) issue 013 e-mail since it clarifies the issue 013 which is somehow the base for the issue 004 discussed here. I am happy with the new text for the issue 0013 now. ,Sazi --- Max's e-mail ---- 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:" ========== ----- eof Max's e-mail ------------ -----Original Message----- From: Peter Furniss [mailto:peter.furniss@choreology.com] Sent: Wednesday, December 14, 2005 1:33 PM To: 'Ian Robinson'; ws-tx@lists.oasis-open.org Subject: RE: [ws-tx] Issue 004 - WS-C: Add new fault CannotCreateContext I don't see how "beefing up" a definition "This fault is sent to a coordinator to indicate that the endpooint cannnot accept a context which it wa passed" (ws-coord working draft lines 452-453) can turn it into some equivalent of "This fault is sent by the Activation Service to the sender of a CreateCoordinationContext to indicate that a context could not be created." in Alastair's proposal. The sender is different, the receiver is different and the point in the context's lifecycle is different - one refuses to accept an existing context, one refused to create a new context. Similarly the [Reason]s are different and align with the defintions. At a pinch, either could be called "ContextRefused" and it may have been the intent among the authors to have a fault for the Activation Service to say "no", but that intent is not reflected in the input documents. Given the working draft definition of ContextRefused, one might consider using it it when an Activation Service could not create a new context given the particular value of /CreateCoordinationContext/CurrentContext. But even that would not fit the definition as that says it is sent *to* a coordinator, not from one. Peter > -----Original Message----- > From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] > Sent: 14 December 2005 16:55 > To: ws-tx@lists.oasis-open.org > Subject: Re: [ws-tx] Issue 004 - WS-C: Add new fault > CannotCreateContext > > > > > > > The ContextRefused fault (subject of issue 13, although the > fault is misinterpreted in that issue) was originally defined > for this purpose. It is certainly arguable that the > ContextRefused fault name is misleading and that the > description could be beefed up. > > Regards, > Ian Robinson > STSM, WebSphere Messaging and Transactions Architect > IBM Hursley Lab, UK > ian_robinson@uk.ibm.com > > > > > "Peter Furniss" > > <peter.furniss@ch > > oreology.com> > To > > <ws-tx@lists.oasis-open.org> > 09/12/2005 17:53 > cc > > > > Subject > [ws-tx] Issue 004 - > WS-C: Add new > fault > CannotCreateContext > > > > > > > > > > > > > > > > > This is hereby declared to be ws-tx Issue 004. > > Please follow-up to this message or ensure the subject line > starts Issue 004 - (ignoring Re:, [ws-tx] etc) > > The Related Issues list has been updated to show the issue numbers. > > Issue name -- WS-C: Add new fault CannotCreateContext > > Owner: Alastair Green [mailto:alastair.green@choreology.com] > > 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 "Coordination > Faults", l. 371 onwards > > > Issue type: Design > > > Related issues: > > Issue 003 - WS-C: Appropriate categories of fault > Issue 005 - WS-C: Add new fault CannotRegisterParticipant > > > Issue Description: > > Activation Service should be able to communicate inability to > create a context > > > Issue Details: > > Faults in WS-C should be divided into 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. > > Under the first category, it seems reasonable to expect that > an Activation Service may not be able to satisfy a request to > create a CoordinationContext. Reasons might include: capacity > constraints; authorization failure; resource failure (loss of > connection to persistence store, for example). > > > Proposed Resolution: > > 1) Insert new Fault description (order in section an > editorial matter) as follows: > > 4.x Cannot Create Context > > This fault is sent by the Activation Service to the sender of > a CreateCoordinationContext to indicate that a context could > not be created. > > Properties: > > [Code] Sender > [Subcode] wscoor:CannotCreateContext > [Reason] CoordinationContext could not be created. > [Detail] unspecified > > > 2) Add new enumeration to schema type ErrorCodes: > > <xsd:enumeration value="wscoor:CannotCreateContext"/> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]