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


I do not know if I am right, nor I am qualified to validate
a mathematical model of this kind. But...

...my feeling is that trying to reconcile multi-party collaborations
into a series/coordination/pattern-driven set of two-party
collaboration is an academic effort at least from a modelling
point of view.

In some way, by applying some rigid practice I can "approach"
OO-style of programming in any language; but is this "natural"?
I mean, does this effort pay back?

A different problem is the implementation. I mean, if for
implementation purposes it is better to decompose in two-party
collaborations, then a "tool" could take care of this (in some
way, I program in a high-level language but the compiler
translates into binary/assembler...). So, at runtime a
multi-party may be decomposed in a way that is not
even seen by the designer if this makes more sense from
some mathematical/efficiency point of view.

So, accept my apologies if this is so simplified; as I said,
I do not have any mathematical proof of what you say (or of
its contrary), but I am not looking for it. I am looking
for a way to express "simply" some concepts

Best regards

/stefano

» -----Original Message-----
» From: bhaugen [mailto:linkage@interaccess.com]
» Sent: 26 July 2001 18:56
» To: John Yunker; ebxml-cppa@lists.oasis-open.org
» Cc: ebxml-bp@lists.ebxml.org
» Subject: Re: multiparty (was) Fwd: Re: message routing
»
»
» From: John Yunker:
» > This issue gets really thorny unless you keep two concepts front and
» center:
» > Any one "transaction" is between two parties, and a party's
» responsibilities
» > and capabilities are specified in the protocol in which they "agree" to
» > participate.
»
» I fully agree.
»
» Moreover, when it comes to dependencies between transactions in a
» collaboration, many (if not most) of them will also be between
» two parties,
» because they will be commitment-fulfillment relationships and commitments
» are (usually?always?) between two parties.
»
» In other words, many (all?) multi-party collaborations can be resolved to
» a group of two-party dialogs.
»
» In still other words, the complexities of workflow models with splits and
» joins etc may be avoidable in many cases.
»
» -Bob Haugen
»
»
»
» ------------------------------------------------------------------
» 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