business-transaction message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: ebXML issues
- From: Mark Potts <mark.potts@talkingblocks.com>
- To: 'Alastair Green' <alastair.green@choreology.com>,'OASIS BT TC' <business-transaction@lists.oasis-open.org>
- Date: Mon, 16 Jul 2001 08:53:48 -0700
Alastair / Pal
I
agree and have been talking al lot with David Welsh about ebXML to get a better
view on UMM and the underlying rationale behind the specification of BPSS as
well as the CPPs and CPAs.
While I agree that we don't want to
be derailed at this time - we do need to give some separation such that
the ebXML folks don't feel that we are delivering a competitive standard or a
specification that represents a direct subset of their scope and
initiatives.
To that end we could, at this point in time,
position BTP in the following way with
reference to ebXML ( this summarises some
of the findings in the paper Sazi and I worked on and the discussions between
David Welsh and I over the last week or so);
ebXML's CPP/CPA process deals with forming a compatible trading
channel between 2 companies. The process is not simply a technical specification, but as a way to establish a relationship between business entities. While ebXML already deals with a lot of extensive
'business' interaction patterns
(what they refer to as a
transactions, commercial and business) BTP offers one way to technically bind
different company systems, specifically in the
area of lower level transactional (2PC
protocols for loosely coupled business
entities).
This
statement is very broad and high level but as you point out without a working
group made up from both parties its difficult to define the exact opportunities
and leverage points. Within the document Sazi and I have worked on we have
pointed some areas that could be looked at further and again at a high level set
out some possibilities. David Welsh has also had some good input to the
possibilities and in my own mind these are crystallising somewhat. I have also
attached the revised version of the Workflow groups document for people to read
prior to Tuesday (including Sazi's revisions).
Some Rationale and
discussion:
Commercial Transactions are the definition of interactions between a
Requesting Role and Responding role within a business collaboration. A
Responding Role (Service Provider), offers a Activity within a Business
collaboration. The relationship or agreement that a Requestor and Responder
roles enter into is a contract that defines the obligations the Responder will
adhere to as per the agreement, including how it will acknowledge receipt,
accept the request, and process the request in terms of response and
confirmation. This part to me is part of the Agreement / Contract that a
Consumer and Provider enter into as apart of the business collaboration, and not
a transaction protocol.
Business Transactions and the defined patterns in section 4.1.3 -
4.1.8 describe interaction patterns between requesting and responding roles
based on different types of Activities - i.e. Business Transaction Activity
(BTA), Query response activity. The additional features at this level include
the Business signals ( indications of where in the action a role is or
confirmations of receipt).
The difference I see is that BTP
defines a separate 2PC ( potentially two pipe model ) type protocol for
coordinating participants enrolled in a transaction. The coordination, the
termination, takes place outside the Service invocation ( what I am reading to
be a BTA in ebXML). The contractual declaration of timeouts and
response obligations of a service are outside the scope of BTP and are only relayed as part of the message set ( if
they were always static then they could be declared possibly).
I see there is a lot of scope for
leveraging the BTA in ebXML with BTP behind the scenes to help coordinate BTAs
that are relax isolation of their internal transactions and need ways
to "back out after
completion". I have not seen anywhere in ebXML (yet) where the ability
lies to have business transaction activities be completed successful as far as
the Responder is concerned and then at a later stage the Requestor want to back out of that business transaction activity .
I suppose that in the Receipt
process defined in BPSS, beyond Schema validation, the acknowledge
receipt could be seen as a "prepare" and vote ready (in BTP speak) but I don't see
as a Responding role that you want to commit to this without completing the
activity (Activity Processing stage )and responding.
2001-07-16.BTPModellForWF2.doc
- References:
- ebXML issues
- From: Alastair Green <alastair.green@choreology.com>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC