Re: [amtf] First shot at Abstract Model

 Hi all, 8-)
 this message contains my comments on the first draft of the 
Abstract Model. I didn't include them in the first message 
because they are proposed changes that I'd like to discuss.
 My comments 2) and 3) have been discussed outside of the 
abstract model work already.

 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?

  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.

 2) I don't think we need the "incoming" and "outgoing" 
operations. I.e. I don't believe we need solicit/response and 
notification operations because they are IMHO just 
request/response and one-way operations the other way.
 An orchestration language can say that a service with
wsdl:binding A needs a service with wsdl:portType B to function
properly and this will ease the matching of the second service
(as opposed to looking for equivalent solicit/response and
request/response messages in service descriptions, for example).

 3) I don't believe we need Services as currently defined, I'd 
rather see them implementing a single Service Interface (and 
providing one or more InterfaceLocations for it).

 4) In AM, do we need to tackle protocol bindings and type
languages in detail?

                   Jacek Kopecky

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

Received on Monday, 20 May 2002 10:13:45 UTC