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

Jacek,

I agree permitting multiple (alternate) response is good but, I disagree with
taking away (the current) multiple alternate faults if we can not have multiple
alternate responses. Consistency is not a factor here IMO. I am ok with both or
current one.

Regards, Prasad

Jacek Kopecky wrote:

>  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>