Re: [amtf] First shot at Abstract Model

Jacek,

Please see couple of comments below in <PY>.

Thanks, Prasad

Jacek Kopecky wrote:

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

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

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

<PY>This has been a very contentious issue but, once again I think we
need both. I am not sure how do you capture an outgoing operation as
reverse of an incoming operation at the abstract level?
</PY>

>
>  An orchestration language can say that a service with
> wsdl:binding A needs a service with wsdl:portType B to function
> properly

<PY>Are you suggesting we mix binding level and abstract level? I am not
sure what the above is conveying?</PY>

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

<PY>I still fail to see how this can work? I think we need a way to
capture things from the initiator (invoker perspective) in addition to
service provider perspective. It is not all symmetric in the Business
process (or flow) level. B receives Req-1 from A and Req-2  from C and
sends a Req-3 D, which replies to A and B and B replies to C. How can
this be captured all in a symmetric manner?
</PY>

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

<PY>BTW, Service is not an entity at the abstract level but I see your
point. I do think however being able to group portTypes (interfaces) is
useful. As Sanjiva had been arguing for also, having ServiceTypes that
group portTypes is more logical at the abstract level than going from
portType to port and Service.
</PY>

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

<PY>The bindings seem like a clear cut case of not belonging in AM
unless we are changing the definition of what abstract is. Current line
of division between abstract and concrete is what I still have a
reference here. Are you thinking we need to revisit that?
</PY>

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