RE: Conversations, or BP alignment with TR&P and Architecture

["Nieman, Scott" <Scott.Nieman@norstanconsulting.com>]

The answer to your question is "no".  

My opinion is that the state of each object may be uniquely different based
on the business events or scenario.  It is possible to abstract this to a
higher level specifically to object life cycle management; i.e.,
isObjectAlive, lastTimeAccessed, etc.  That information surely belongs into
TRP, at minimum represented as exception handling messages/ routines.  Some
of the other information really belongs to an instance of an object model
which is business domain specific.

This is an issue for the Technical Coordination group to deal with those
gaps.

Scott

-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: Saturday, July 01, 2000 7:11 AM
To: 'ebXML-BP@lists.oasis-open.org'
Subject: Conversations, or BP alignment with TR&P and Architecture


Has anybody discussed alignment of the BP metamodel
with the Transport, Routing & Packaging and Architecture
specifications?

I just did some reading in the most recent documents for
both groups, focusing on the issue of conversations.  By
"conversation", I mean message exchanges consisting 
of more than one message, e.g. a long-running Business
Transaction.  

The BP metamodel assumes the need for long-running
conversations.  So does TR&P, and (maybe) Architecture.
However, the responsibility for defining the software
that manages these conversations is not clear.

Practically speaking, long-running conversations require
some software to manage the ongoing state of the conversation
and apply the rules, e.g. Business Transaction Constraints
and Ordering Rules, and possibly manage Duality relationships.  
This software could live at both ends of the conversation, 
using a shared or duplicated Business Process Definition, 
or it could live in a shared Business Transaction processing service,
e.g. an Internet "marketplace".

ebXML TR&P specifies in diagrams an Integration System
where Business Rules and Document Choreography from
Business Process Modeling are supposed to take place.
However, this Integration System is then declared out-of-scope
for TR&P.

In the TR&P diagrams, instances of the Integration System
live at both ends of a message exchange. The Integration
Systems have their own private repositories, which can
access a Master Repository.

The ebXML Architecture documents use these same 
diagrams.  However, Architecture goes on to propose
an "ebXML Application" at each end of a message
transmission which uses a Business Process model.
Architecture does not mention transaction semantics
or long-running conversations.

However, transaction semantics are declared to be within
the scope of TR&P, including "support for a session-based
transaction and/or a long term transaction".  

TR&P also wants to support Multiple Round Trip Document
Exchanges:
"A Multiple Round Trip Document Exchange consists of:
1) a Request Message sent from one Party to a second Party, followed by
2) a series of Exchange Messages that are exchanged between the two Parties
until finally
3) the second Party generates and sends a Response Message back to the first
Party.
Examples of Multiple Round Trip Document Exchanges include:
4) the exchange of messages required to make a payment using payment method
protocols such as [SET] or [Mondex]
5) the exchange of messages required to negotiate an agreement on terms and
conditions."

TR&P also has a (simpler) counterpart to the Business Process Definition
hierarchy of the BP metamodel:
"A Service Definition describes a process that can be carried out by a
Party. It consists of either a
Document Exchange or a set of Sub-Services. Each Sub-Service is a Service in
its own right. So, at the
lowest level, all Service Definitions are described in terms of a Document
Exchange.
The dependencies between the Sub-Services in a Service is described in a
Sub-Service Choreography.
An instance of the execution of a Service Definition is called a
Transaction."

"A Transaction is an instance of the execution of a Service 10 .
Examples of a Transaction include:
1) a Purchase Transaction that buys a Company Report for $20. It consists of
three Sub-Service
instances:
a) an Offer Service instance to buy the Company Report for $20
b) a Payment Service instance that accepts a Payment for $20 using a credit
card, and finally
c) a Delivery Service instance that delivers the Company Report as an HTML
web page.
2) a Buying Service that consists of the following Sub-Services:
a) three Price Negotiation Service instances that negotiate the price of a
Photocopier
b) a Purchase Order Service instance that places the order for the
Photocopier."

TR&P is also proposing conversation templates (as I have repeatedly proposed
in BP discussions).

tpaML, which we considered briefly in Seattle, proposes TPA "objects"
that live at each of a long-running transaction, managing the conversation.
It appears that tpaML has software that manages conversations.

My impression in Seattle was that Edifecs/RosettaNet has software
to manage conversations as well.

Comments?

Respectfully,
Bob Haugen

=======================================================================
= This is ebxml-bp, the general mailing list for the ebXML            =
= Business Process project team. The owner of this list is            =
= owner-ebxml-bp@oasis-open.org                                       =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-bp                                           =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-bp myname@company.com                        =
=======================================================================

=======================================================================
= This is ebxml-bp, the general mailing list for the ebXML            =
= Business Process project team. The owner of this list is            =
= owner-ebxml-bp@oasis-open.org                                       =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-bp                                           =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-bp myname@company.com                        =
=======================================================================