RE: Collaboration Services (was: Business Service Interface)

[Stefano POGLIANI <stefano.pogliani@sun.com>]

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
>