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

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

Stefano,
See below...

> -----Original Message-----
> From:	Stefano POGLIANI [SMTP:stefano.pogliani@sun.com]
> Sent:	Tuesday, July 31, 2001 4:11 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,
> 
> 	I am not thinking that BigBrother imposes restrictions in the
> modelling (or, at least, I haven't formalized this in my mind).
	[CBC]  The restriction is that a party may only act based on
interactions with that party.  That is, an ordering constraint that affects
party "A" may not be based on an interaction between parties B and C.  For
example, you could not say: "Send the supplier a payment when the supplier
has shipped the product", you must say: "Send the supplier a payment when
the supplier (or shipper) notifies you of shipment".

	The fundamental difference in thinking is that actions and
constraints are specified in terms of one of the actors, not the "process in
general".

	You may say "of course", but a collaboration or activity diagram
does not explicitly enforce these constraints.  If these constraints are not
violated we can transform between the views of the process in tools.

> I think that BigBrother is not viable for a real "collaborative"
> approach since it implements a concept of "power", of "master/slave".
	[CBC]  Agree


> As well, I do not think that the 3+ global approach is merely a
> "tool issue"; I think that reconciling 3+ models to a set of
> bilateral is a simplification that can happen within the tool
> but is not natural in the way of thinking. For me (but I may
> be really wrong, of course) it would be the same that
> programming in assembler versus programming in a powerful 4GL;
> it is not because in assembler I could reach some economy
> and I could optimize the use of certain patterns that it is
> "natural" to program in assembler (at least, except for few
> gurus).
	[CBC]  Ways of thinking are many!  The advantage we have found in
having people think about it in this way is that it makes the
responsibilities very clear and prevents "illegal" structures such as the
ones we talked about above. However, providing a view based on the way you
want to think is fine - as I said, the "wide view" is what you want for a
top-down analysis.

	The binary+ view makes each protocol (binary collaboration) more
reusable such that it is useful in many business processes.  Does Fed-X want
to provide a service that is bound into a specific 3+ party process or does
it want to provide a service that is useful in a set of business processes?


	Also, many of the protocols used in these processes are
pre-existing.

> I also do not get the fact that bilater is closer to the service
> implementation: as i mentioned sometimes, I assume that the whole
> software implementing the framework will, soon or later (probably
> soon) be generated instead of coded provided that there is
> enough material in the specifications. So, I prefer to concentrate
	[CBC]  We do this today, so we are in agreement.  We also need to
make sure that the model is sufficiently precise for automated execution.
> on the architecture of an overall collaborative solution
> and on the modelling of it. Once they are done, probably a few
> clicks will be enough to deploy the hosting framework to an appserver.
> 
> In this context, re-use is more in terms of patterns; and this
> will be equally possible for bilateral or 3+.
[CBC]  Do you know OORAM (Trygve Reenskaug)?  It shown how to compose n-way
collaborations - very nice.  It was the basis for collaborations in UML but
some of the synthesis parts got obscured.

> Just my 2 cents
	[CBC]  I think the difference in our approach may come from
different "reference" problems in our head.  When I have come across these
multi-party situations, very few have really been multi-party - where all
parties know about each other and have an n-way binding agreement.  Most
have been some kind of "sub contract" or delegation.  Since 90% of the
problems really are 2 party or 2 party with delegation I have not put much
priority on the "true" muti party modeling.

	When people have been given the very powerful tools of multi-party
they tended to over-use them, making unnecessarily large, complex and
monolithic processes.  They also had trouble utilizing existing protocols
and reusing pieces of these processes.  So I have tended to encourage
decomposing these processes, the "composition of binary" approach is a way
to encourage this more "componentized" way of thinking.  Ultimately what I
would like is to tool the analysis process in the way you are thinking but
then have the tool guide the designer to decompose it as a refinement ready
to be run via automated techniques (I include component assembly, code
generation and model interpretation as all part of automated development).  

	Note that in either case we are WAY ahead of what off-the-shelf
software is providing today!

	It would be interesting to work through an example and see how the
approaches differ or complement each other.

> /stefano
	[CBC]  
	Cory

> » -----Original Message-----
> » From: Cory Casanave [mailto:cory-c@enterprise-component.com]
> » Sent: 30 July 2001 23:23
> » To: 'Stefano POGLIANI'; 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
> »
> »
> » 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
> » > »
> »