RE: multiparty (was) Fwd: Re: message routing

[Cory Casanave <cory-c@enterprise-component.com>]

Stefano,
I have to respectfully disagree.  We need to distinguish between "managed
processes" and "collaboration processes".  A managed process has an entity
that "owns" it and "knows what is going on" in the large.  For example, a
factory will probably require managed processes to keep everything working
smoothly.  A collaboration process has independent agents that work together
in a defined way, but without any overall management.  If you buy something
with a credit card the series of interactions that goes on is an unmanaged
process.

Managed process couple the managed entities and all of the interactions into
one model.  This means that if one "sub contract" of that model changes or
is replaced the entire model is out of date.  It also means that a
management authority must be agreed on to keep track of the process and make
sure all players know the state of the global process and play by the rules.

It is my assertion that managed processes are unnecessary and undesirable
for the "B2B" level of interactions we are supporting with ebXML and
probably for the next layer down into the enterprise.  True 3+ party
agreements are rare to start with and difficult to write and to monitor.
When they are required a process monitor role can be assigned which, again,
makes the model into a synthesis of 2 party agreements (all with the
monitor).

The advantage of the two party collaboration restriction is:
* The binary collaborations are independent services and may be reused in
multiple processes.
* They may also be inherited from existing standards.
* They are simpler to think about and choreograph.
* No global manager is required (which has technical and business impact).
* The model is not monolithic and more adaptable to change.
* Two party collaborations fit with most legal structures.
* We know how to implement two-party collaborations and we know how to
combine them in a single role.
* The identities of all parties does not need to be known up-front (think
about this in the travel example).

This effect is demonstrated by the "first try" workflow engines, which were
very centralized and "managed".  This worked ok within one management domain
but became impossible to manage as workflows became distributed and
federated.  Workflows have tended to moved to the independent collaborating
agent model, with managed processes used for fine-grain workflow.

I suggest that if we consider such capabilities we work from examples which
require them, which the current example dos not.

Regards,
Cory Casanave
Data Access Technologies
www.enterprise-component.com

-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
Sent: Friday, July 27, 2001 4:26 AM
To: christopher ferris; bhaugen
Cc: ebxml-cppa@lists.oasis-open.org; ebxml-bp@lists.ebxml.org
Subject: RE: multiparty (was) Fwd: Re: message routing


> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: 26 July 2001 14:57
> To: bhaugen
> Cc: ebxml-cppa@lists.oasis-open.org; ebxml-bp@lists.ebxml.org
> Subject: Re: multiparty (was) Fwd: Re: message routing
> 
> <snip/>
> IMO, each party in a collaboration, multiparty or otherwise, can only
> *control* its own participation. It can and more than likely should 
> know only about the state of affairs between itself and its direct
> partners, not its partner's partners.

I think that each party is responsible to grant that it manages
its part of the collaboration in a way that is consistent with
the agreed upon SHARED AGREEMENT (involving the collaboration
as well as the QoS aspects).
But, by saying this,  each party is fully aware of the 
other partners participating in the collaboration even if 
he does not directly interfaces them. This happens
whenever a party is explicitely modelled in the overall
collaboration.
	I mean, in a collaboration someone may require
	a service to some stupid WebService (currency
	translator, for instance) which does not need
	to be modelled as a partner in the overall
	picture.
In fact, the "state" of the collaboration is built
from all the things that happened since the beginning
of the collaboration, not only from the things
I touch. 

/stefano
 

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org