OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Cory,

	See my comments below.
Ciao
/stefano

» -----Original Message-----
» From: Cory Casanave [mailto:cory-c@enterprise-component.com]
» Sent: 31 July 2001 17:15
» 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,
» 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.

	[stefano]
	The only difference I saw between what I "could not say" and what
	I "must say" is that the latter is more precise.

»
» > 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.

	[stefano]
	Having a "global view" involving all the participants prevents
	"illegal" things. I think that "illegal" is what is not
	agreed upon by the participants [in a first aproximation].

»
» 	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?

	[stefano]
	You can have re-usability via subprocesses.
	In any case, if I have a "fundamentally ternary relationship",
	that one will be the unit of re-use, of course.

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

	[stefano]
	Could you make some example?

»
» > 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.

	[stefano]
	exactly

» > 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.

	[stefano]
	No, unfortunately I do not know much of the theoretical
	apsects of this domain.

»
» > 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.

	[stefano]
	Maybe. Even if I tend to think that what we are talking about here
	is not so different from the design/architecture of fully distributed
	systems. In that case I did not always find "natural" the layering
	of sets of bilateral.


»
» 	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).

	[stefano]
	I do not see how automated techniques may work better for bilateral
	though...

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


	[stefano]
	Yes, but ...

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

	[stefano]
	Same request as other friends. I will try.
»
» > /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
» > » > »
» > »
»



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC