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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa 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]


Powered by eList eXpress LLC