OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: ebXML issues


Mark,

Thank you for taking the time to write this up.  I look forward to the call
tomorrow.

    Mark



-----Original Message-----
From: Mark Potts [mailto:mark.potts@talkingblocks.com]
Sent: Monday, July 16, 2001 8:54 AM
To: 'Alastair Green'; 'OASIS BT TC'
Cc: Sazi Temel (E-mail); David Welsh (E-mail)
Subject: RE: ebXML issues


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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC