[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; [email protected] � 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; [email protected] � > 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; [email protected] � > � 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; [email protected] � > � > 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; [email protected] � > � > � 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; [email protected] � > � > � 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; [email protected] � > � > � > 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