RE: Comment

[MERCEY Jacques <JMercey@MEGA.com>]

Title:

> "A new kind of software is required here"
 YES, we do require new kind of software (off-the-shelf or own-grown) to deal with e-business conversations

> "and it needs to be compatible at each end of the the conversation."

Hummm, yeeesss, it depends on what you mean by “compatible”. Remember the “loosely coupled paradigm”. The conversation is defined at business level, not at technical level. It means that everyone who declares to support it is committed to do what is imposed by the contract at business level (send good, send money, build a machine, etc.) and, at application level, process and send messages according to what is defined in the collaboration. It does not make any assumption on the way he builds the machine or processes the messages. That is probably what Antoine wanted to say with “applications at each end will handle that".

The conversation is only defined, at run time, by an URN for the type and a pair of Ids for the instance. The 2 instance IDs are under the control of each party. A Message ID defines the position in the conversation. The Message ID may be a simple number as their should not be reuse of messages (even if, of course, message contents are reusable). The URN and Message ID are the intersection point between BP, TR&P and RR team works. The same plus the 2 instance Ids are the intersection point between BP and TR&P.

As far as each party has to keep track of the other’s instance id as well as its own and as far as it might be involved in thousands of such instances, one must keep these conversations the simplest and the shortest as possible in order to avoid managing too many handles pending for too long time. Conversations are the building blocks with which companies can build their own private complex business processes.

For instance, the following long conversation can be broken into 3 short conversations that can be used either all together in the long one or independently. In that last case, they are related, not by conversation ids but by the proposal id.

FYI, also enclosed is the metamodel we use at MEGA.

Regards,

Jacques Mercey
Vice President R&D
MEGA International
10 boulevard du Montparnasse
75015 Paris (France)
Tel : +33 1 42 75 40 21
Fax : +33 1 42 75 40 95
mailto:jmercey@mega.com
http://www.mega.com

-----Message d'origine-----
De : Bob Haugen [mailto:linkage@interaccess.com]
Envoyé : mardi 11 juillet 2000 16:16
À : 'ebxml-bp@lists.ebxml.org'
Objet : RE: Comment

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

long conversation.gif

short conversations.gif

MetaModel.gif