[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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