FW: BPML

[Bob Haugen <linkage@interaccess.com>]

---
Ismael is trying to sssuuubbsccribe (the original word
in this line got my first forward attempt bounced) to the bp list, 
but apparently the web signup is broken.  In the meantime, here is his
reply to David RR Webber and others' comments on 
two-phase commit.

-----Original Message-----
From:	Ismael Ghalimi [SMTP:ghalimi@intalio.com]
Sent:	Wednesday, August 23, 2000 10:27 AM
To:	David RR Webber; Brunner, Eric
Cc:	'ebXML-BP@llists.ebxml.org'; 'Bob Haugen'
Subject:	RE: BPML

David,

You are perfectly right: from a technical standpoint, the two-phase-commit
protocol works at the Internet level. Provided that you can solve issues
related to the propagation of transaction contexts (using IIOP for example),
this is definitely doable.

Nevertheless, our understanding is that it does not work from a practical
standpoint.

First, complex transactions between partners are very hard to achieve in a
synchronous fashion. The probability of failure of a single component of the
IT chain from you to your partner being significant, performing transactions
in an asynchronous fashion dramatically increases the odds of success for
the completion of the transaction. This is why collaboration protocols like
RosettaNet make the assumption that all the transactions between partners
are asynchronous. This prevents the use of the 2PC protocol at the
partner-to-partner level.

Second, currently existing IT infrastructures are largely non-transactional.
In such a context, developing a protocol defining the way partners will
collaborate based on the 2PC protocol will lead to nothing: in any pair of
partners, there is a very good chance that one of them never heard about
transactions at all. The actual benefit of using the 2PC protocol at the
partner-to-partner level is pure fantasy.

Third, making the assumption that we could use the 2PC protocol at the
partner-to-partner level (while it would never be actually leveraged as
explained above) will lead developers to ignore the real issue, which is in
this case: how do we make B2B transactions reliable when the 2PC protocol is
not available? The answer to this question naturally is: use compensating
transactions.

In such a context, we believe that, even though offering the 2PC semantics
at the partner-to-partner level is technically feasable, it is practically
undesirable. Actual partner-to-partner processes will be very complex
because they will have to deal with compensating transactions that, by
essence, have to be explicitely defined to a large degree (as opposed to the
rollback of 2PC transactions). In such a context, there is a need for
standardized partner-to-partner processes (or PIPs in the RosettaNet
terminology). Such standard processes will have to work with many different
existing IT infrastructures and as such cannot make the assumption that such
infrastructures are transactional.

Introducing the 2PC semantics at the partner-to-partner level would confuse
the developers and make very hard the choices between 2PC rollback and
compensating transactions (when such choices would make sense). The
immediate outcome would be even more complex partner-to-partner processes
that nobody would actually be able to implement (look at how complex it is
to actually implement the trivial PIPs defined by RosettaNet to get an idea
of the complexity of implementing partner-to-partner processes that would
mix 2PC rollback and compensating transactions).

At this point, we believe that clearly separating internal processes (where
you can do pretty much what you want) and partner-to-partner processes
(where several entities have to reach an agreement) has many benefits, from
a purely practical standpoint. This is one of the reasons why BPMI.org
exists today.

Nevertheless, we are convinced that developing protocols that would support
the 2PC protocol make sense for some applications. This is precisely why
some are considering to add this semantics into SOAP (to a certain degree).
Our only concern is that the applications that would benefit from such a
feature are not real business processes, but technical components of IT
infrastructure supporting business processes.

I hope this helps.

Best regards

ig.


> -----Original Message-----
> From: David RR Webber [mailto:Gnosis_@compuserve.com]
> Sent: Wednesday, August 23, 2000 7:27 AM
> To: Brunner, Eric
> Cc: 'ebXML-BP@llists.ebxml.org'; 'Bob Haugen'; 'Ismael Ghalimi'
> Subject: RE: BPML
>
>
> Message text written by "Brunner, Eric"
> >
>
>  (For example, two-phase commit does not work
> over the Internet.)
> <<<<<<<<<<<<<<<<<
>
> And of course we have architected a solution that does this -
> so there!
>
> It's just a network for gosh sakes (with wrinkles).
>
> DW.