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


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 companiesThe process is not simply a technical specification, but as a way to establish a relationship between business entitiesWhile 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



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


Powered by eList eXpress LLC