Bob,
thanks a lot for the nice mail. Please find embedded my comments.
/Stefano
>
> >This said, when I read through the "Collaboration Modelling Metamodel"
> >document I found myself a little bit lost.
>
> The online example might help (watch for word wrap):
> http://www.ebxml.org/project_teams/business_process/wip/ccbp-analysis/mmx/index.html
> (Although it really doesn't get down the level you are looking for...)
I think this is the "analysis" view of the BP. This is waht needs to be
done to fully anaylise and describe the BP from an Analysis perspective.
I did not find the "execution model".
>
> >Actually, with the BusinessServiceInterface paper I am looking for "reconciling"
> >the Conceptual view presented by that (and other) document(s) with an
> >"execution oriented" view, which is the one which will finally exercise (at runtime)
> >all the other concepts
>
> I agree that this is necessary. The BP group is working on an XML-ization
> of the metamodel. Jean-Jacques, a participant in this thread, is one of
> the main participants in that effort.
Well, I am not probably the best person to judge on this.
I think that the "XML version" of a BP (not talking about the metamodel here,
but about the "concrete BP" modelling the trip-reservation BP, for instance)
would need to express the choreography in terms that should be
univoquely interpreted.
>
> Figures 12 & 13 in the metamodel document are Jim Clark's
> attempt to specify the runtime software for managing the
Yes, indeed.
> commercial transaction patterns (but not the longer
> collaborations). So far, there is no similar spec for the
> runtime software for longer collaborations. Thus I suggested
> that the two levels might reasonably be separated into
> two different service levels: the commercial transaction level,
> which has been specified and is in fact pretty much implemented
> by some of the RosettaNet vendors, and the collaboration level,
> which I suspect is not.
Looks that they describe the things from the point of view of an Actor
but I miss the "global picture" of the process.
>
> >Now, the same consideration applies to the management of state.
> [...]
> >Of course the message from Party_A changes the state of Party_B; but it also
> >changes the state of the global system (the global Business Process). I am not
> >interested in "managing" the private state of each party [...] but I am interested
> >in managing the global state (the state of the Business Process) as it evolves
> >through the sequence of messages and activities.
>
> Exactly! However, there are objects in the metamodel
> (the Economic Elements, see especially Figure 7) that
> represent the most common economic relationships
> involved in business collaborations. For example,
> negotiations often involve making reciprocal commitments,
> and the state of the negotiation is actually represented
> by the states of those commitments: e.g. Proposed,
> Countered, Accepted, Rejected, etc.
> Likewise the Economic Elements explicitly model
> order-fulfillment-payment collaborations.
> Those are some of the hooks I was talking about.
> They need some refinement, which was put on hold
> to give the requirements for the Tokyo POC highest
> priority.
Do I interpret correctly that you say that "Economic Elements"
are part of the state?
If yes, I tend to agree. But in the execution Model I would have
"something" which represents them and I would probably also
need "something else".
In some way, deriving the "state" from the information provided
at Analysis time; is it right ?
>
> Thanks again,
> Bob Haugen
>
