RE: Comment

[Bob Haugen <linkage@interaccess.com>]

Antoine Lonjon wrote:
> Bo Haugen made a very interesting comment about the management of long
> transaction. I took the position that this should not be the focus of
> ebXML. I would like to clarify the point. 

Antoine, it was not clear to me from your message whether you had
changed your position.  While I would not say that this should be 
"the focus" of ebXML, I think that ebXML must deal with the issue.

What I understood you to say in the conference call was something
like "the business applications at each end will handle that".

I doubt it. Most business applications I know are inward-looking.
They wouldn't know how to handle a long conversation with another
company if it smacked them in the interface.  A new kind of software
is required here, and it needs to be compatible at each end of the
the conversation.

While it may not be ebXML's job to develope such software, 
I think ebXML must specify how such software should behave.

You went on to add (where I thought maybe you were changing
your position):
> Concerning Business Process Definition, they define Steps. But nobody is
> declared to be responsible to the triggering and management of theses
> Steps. In short, there is no contract between parties to manage the steps.
> Who is responsible to launch the next transaction? In such a case, there
> would be a need of some shared state of the conversation as Bob Haugen
> underlined in his previous comments 

> It seems to me that the attempt to add another concept above Business
> Transaction is the need for an overview that represents what could be done
> (scenario) with an assembly of Transaction. For instance, Offer Goods
> Transaction then Payment Transaction then Delivery Transaction. The "then"
> is not contractual here. No party is responsible of it. It is just a
> proposal to assemble different Business Services.

In my recent proposal to simplify the BusinessProcessDefinition
hierarchy, in response to Karsten Riemer's issue #k, any level
of the hierarchy could have OrderingRules and TransactionConstraints
that could manage sequences of Transactions.   I think this would
handle your issue.

(By the way, "Contract" in the ebXML metamodel means
"Economic Contract", not "rules for transactions".  Those 
would be covered by BusinessTransactionConstraints.

> The Transaction based contract is more loosely coupled. The common
> implementation between parties is kept at the TR&P level. The step further
> (Business Process Definition) needs an extra coordination feature that
> lives between both parties.

We agree.

Regards,
Bob Haugen