[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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). I think that BigBrother is not viable for a real "collaborative" approach since it implements a concept of "power", of "master/slave". 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). 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 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+. Just my 2 cents /stefano » -----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