RE: [ws-tx] Issue 013 - WS-C: Remove fault 4.5 ContextRefused

[Ian Robinson <ian_robinson@uk.ibm.com>]

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.