[amtf] First shot at Abstract Model

 Hi all, this is my first shot at a skeleton of WSDL AM. 

 Every term defined below has a globally unique name. In some
cases it is a QName, in other cases a combination of a Name and a
parent's QName. This doesn't matter from the POV of this AM. This 
is also related to the issue of possible reusal of definitions - 
e.g. messages in 1.1 can be reused but message parts cannot, 
again, this doesn't matter from the POV of this AM.

 With some points in this draft I don't agree and I will post my
comments on this later, but I was trying to catch as much of WSDL
1.1 as possible.

 I have made a few changes from a straightforward abstraction of
WSDL 1.1 - these are listed below. They are meant to clarify the
intent and the resulting model is directly mappable to WSDL 1.1
(although some arrows would go in funny directions, if we were to
draw a picture).



 1) Message Parts
 A Message Part describes an atomic (from the POV of WSDL) piece 
of data.

 2) Messages
 A Message is a set of Message Parts. 
 Remark: A message (lowercase) is an instance conforming to the
description in a Message (capitalized).

 3) Operations
 An Operation represents a message exchange pattern. Currently, 
there are two kinds of Operations: OneWayOperation, 
RequestResponseOperation.

 3a) OneWayOperation
 In OneWayOperation a sender sends a single message to a 
receiver. The message is described by a single Message referenced 
by OneWayOperation.

 3b) RequestResponseOperation
 In RequestResponseOperation a sender sends a single message
(request) to a receiver, a receiver responds with a single
message (response) back. 
 The request message is described by a single Message referenced
by RequestResponseOperation. 
 The response message is described by one or more Messages
referenced by RequestResponseOperation. If there are more
Messages describing the response message, one is considered a
successful response, the others are considered a failure
response.

 4) Service Interfaces
 An Service Interface is a set of Operations describing a logical
interface. Each operation referenced from an Service Interface
can be marked as "incoming" or "outgoing".
 For an "incoming" operation the described interface is the 
receiver of the request. For an "outgoing" operation the 
described interface is the sender of the request.

 5) Protocol Bindings
 A Protocol Binding specifies how a single Service Interface can
be accessed using a concrete protocol. A Protocol Binding doesn't
carry the information identifying the protocol endpoint where the
Service Interface is located.

 6) Interface Location
 An Interface Location identifies the endpoint where a Service
Interface is accessible (and what Protocol Binding this endpoint
uses).

 7) Services
 A Services groups logically related Service Interfaces and
specifies one or multiple Interface Locations for each of them.


 Remarks: 
 i) the distinction of "incoming" and "outgoing" operations 
moved from Operations to Abstract Service Interfaces where it 
belongs (IMHO).
 ii) imports and types are not in this abstract model because
they are unnecessary here, IMHO.
 
 I'll post my comments on this draft later, hopefully today or 
tomorrow.


                   Jacek Kopecky

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

Received on Sunday, 19 May 2002 11:53:49 UTC