[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