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

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

Stefano,
The fundamental point of agreement is the lack of the "BigBrother" which we
both recognize imposes certain restrictions on what can be modeled (and
those restrictions don't get in the way 99% of the time).  Given this, your
preference for looking at the overall "global" view of a 3+ party
collaboration is only a tooling/syntactic issue, you could look at it as a
set of binary collaborations with transitions inside the common roles or as
a (restricted) ordering of the messages in the entire collaboration.  We
could transform between these views isomorphicly.  I do agree that the
overall view is appropriate for top-down analysis.

While it is great to be able to see this overall view, the binary view is
also valuable because it shows each of the services (corresponding to each
binary collaboration), easily mappable to implementation,  which are then
reusable in any number of multi-party processes.  Once these are defined we
can also use assembly of existing service to help define new collaborations
(top down meets bottom up).

If we are only looking at a tooling/syntactic issue the BPSS model need not
be changed to accommodate the view you would like.

Cory

> -----Original Message-----
> From:	Stefano POGLIANI [SMTP:stefano.pogliani@sun.com]
> Sent:	Saturday, July 28, 2001 11:53 AM
> To:	Cory Casanave; christopher ferris; bhaugen
> Cc:	ebxml-cppa@lists.oasis-open.org; ebxml-bp@lists.ebxml.org
> Subject:	RE: multiparty (was) Fwd: Re: message routing
> 
> Cory,
> 	please see my comments embedded in the text.
> Best regards
> /stefano
> 
> » -----Original Message-----
> » From: Cory Casanave [mailto:cory-c@enterprise-component.com]
> » Sent: 27 July 2001 21:05
> » To: 'Stefano POGLIANI'; christopher ferris; bhaugen
> » Cc: ebxml-cppa@lists.oasis-open.org; ebxml-bp@lists.ebxml.org
> » Subject: RE: multiparty (was) Fwd: Re: message routing
> »
> »
> » 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.
> 
> 	Something like EAI vs B2B, I imagine.
> 	In EAI you may have something like a Central Process Engine
> 	(iPlanet Integration Server, Vitria, BizTalk, MQWorkflow...)
> 	that manages in a centralized way the flow of activities. This
> 	is what, I think, you call "managed process".
> 
> 	I agree that in the B2B space (or, anytime you have "partners"
> 	that is independent entities that agree on performing some
> 	tasks) you cannot have this approach. So you have "independent
> 	agents that work together in a defined way". There is no
> 	central "Big Brother" to control them; the control is embedded
> 	in the collaboration definition.
> 		I am NOT saying that there is no control; I am saying
> 		that there is no "Big Brother" to control. But the
> 		partners, in some way, control each others by means of
> 		the collaboration software implementing an agreed
> 		upon process. Much like the BPSS/CPA and BSI.
> 
> » 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.
> 
> 	More or less I agree. The "sub contract" may, eventually,
> 	not invalidate the whole in some situations, but this
> 	is irrelevant.
> 
> »
> » 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).
> 
> 	I am not saying that for 3+ parties we need a BigBrother.
> 	As I mentioned before, we need to make sure that the
> 	collaboration architecture is able to provide each
> 	partner the means "to control the others" (on demand,
> 	of course) and to "synchronize the state of the
> 	collaboration".
> 	This is sort of some techniques used in Hardware
> 	(I think) where components contribute to the whole
> 	by means of some quorum and some signals.
> 
> »
> » 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.
> 
> 	Well, a part from the BigBrother (which I think is not
> 	necessary for multiparty), all other statements are
> 	things that seem to me not "objective". I mean,
> 	I still think that when there are many parties,
> 	the 3+ is the most natural way of expressing and
> 	modelling it.
> 
> » * The identities of all parties does not need to be known up-front
> (think
> » about this in the travel example).
> 
> 	I do not understand what you mean here.
> 	I **personally** think that dynamic partnership is still
> 	a very young and delicate concept, but I do not
> 	understand how this topic may affect 3+.
> 
> »
> » 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.
> 
> 	Not so sure about this.
> 	Anyway, EAI (which is what we talking here) moved firmly
> 	to process-driven automation in the recent years.
> 
> »
> » I suggest that if we consider such capabilities we work from
> » examples which
> » require them, which the current example dos not.
> 
> 	Do not understand this. May you elaborate more?
> »
> » 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
> »