[amtf] Multiple responses? (was: Re: First shot at Abstract Model)

 Prasad, 
 you made an excellent point about 1b, I agree it's not a good 
approach now.
 As for 1a, I think we need to be consistent - why have different 
faults and not different successes? I'd be OK with either both or 
none. 

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 21 May 2002, Prasad Yendluri wrote:

 > >  1) RequestResponseOperations references a successful response
 > > Message and a list of failure response Messages. I believe we
 > > should change this in one of the two ways below (I really don't
 > > know which one is the better one):
 > 
 > >   1a) One success response Message and one failure response
 > > Message. Rationale - we don't describe possible variations of the
 > > success response, why should we describe the variations of the
 > > failure response?
 > 
 > <PY>
 > I think the current way of multiple faults is desirable (though only one
 > of them could be returned). This allows for capturing all error
 > (fault-conditions) that an operation could result in. That is an
 > operation can fail for multitude of reasons and it should be possible to
 > enumerate them. It might be the case that one fault message (say at the
 > binding level)  might be able to capture thins but, at the abstract
 > level it would be desirable to permit enumeration of > 1 fault
 > conditions.
 > 
 > If any I would call for permitting alternate +ve responses as well (we
 > have an issue that captures this).
 > </PY>
 > 
 > >   1b) A set of response Messages without distinguishing between
 > > failure and success responses. Rationale - the distinction
 > > between a failure and a success is sometimes fuzzy and belongs to
 > > the application.
 > 
 > <PY>I have the opposite view. I think it is very useful to see the
 > failure conditions as separate from positive response conditions at
 > abstract level. Other wise how to you define flows that are conditional
 > ?</PY>

Received on Wednesday, 22 May 2002 09:38:07 UTC