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: [business-transaction] ORACLE BTP Issues


Please note that I will not be attending the next BTP conference call due to Oracle OpenWorld commitments.

As requested by the BTP committee here are the issues :

General clarification :

One assumes that the core aspect of the BTP specification is to define the process flows and XML types that will enable vendors to interoperate in transaction environments that leverage basic internet technologies. The BTP differs from other specifications in that the core aspect is transactional inter operability, therefore it is in all parties interests to agree on common forms of communication for transactions. 

The BTP addresses a new market which is an open TM architecture for the internet.
 

Current issues for consideration :

For the case of simplicity and clarity, I would recommend that the following seven issues be considered, the outcome of this will then precisely define the low level issues needed for implementation. I feel that every issue should be taken in a positive light based on a considered opinion that the core of the BTP spec has potential and addresses an acute business problem.
 

Issue # 1 : Conformance Level

Clarification :

The BTP specification could value from having a "bare minimum" conformance level and a "higher value add" level, this will enable vendors of varying sizes to implement a base level of compliance without having to invest heavily in engineering resources.

Question / Proposal :

Minimum Level = Standard ( Atomic )
Advanced Level = Enterprise ( Cohesion, J2EE interlinks, Collapsed HIGH-END TP, etc )

This should reduce the specification ( including business justification ) to an attractive size.

------------------------------------------------------------------------------------------------------------------------------------------------------

Issue # 2 : Cohesion vs Atomic

Clarification :

Our interpretation of Cohesion is similar to "Aggregate" / "Long Running Transactions". Cohesion can therefore be considered a low level underpin for possible ebXML process flows AND/OR multi-chain level process.

Atomic transactions as per the current spec is well understood and this element of  BTP spec adds significant value. Cohesion's is very desirable, however the current spec is a little vague.

Question / Proposal :

Due to the fact that implementing Cohesions is a nontrivial task, should this aspect be moved to the Enterprise level of the conformance spec ?

If Cohesions are to remain part of the core spec ( i.e. mandatory ) then further detailed explanation of mappings needs to be provided. Vendors who already implement "Cohesions" need much more detailed info on how to map to a BTP implementation.

------------------------------------------------------------------------------------------------------------------------------------------------------------

Issue #3 :  J2EE Inter operability - JMS short circuit

Clarification :

Oracle supports the current JSR, however a more precise short-circuit is possible to supplement the existing JSR.

If one acknowledges that JMS is one of the most popular ( i.e. widely deployed ) constructs of J2EE and that asynchronous loose coupling is the obvious way ahead, then the ability to share TRX context from a JMS provider via a well defined XML TYPE is both simple and attractive in that allows tight coupling with a core J2EE process.

The bottom line is that sharing context with a provider ( via XMLTYPE ) makes BTP very attractive and easy to implement.

Question / Proposal :

BTP supports JMS XMLTYPE, via an agreed BINARY XML ( W3C ) format which contains TRX context and thus provides a simple and fast bridge between BTP and JMS.

------------------------------------------------------------------------------------------------------------------------------------------------------------

Issue # 4 : Process Flows and TRX switch formats

Clarification :

Keep it simple and concise.

A process flow diagram that shows the state values as one progresses through the process chain is required. This should include when a sub co-ordinator receives/passes TRX control between constructs and when moving between Atomic and Cohesion process flows - especially during mid flow.

Question / Proposal :

Agree on state change values ( not just attributes ). Once again this state information needs to be accessible via future bindings.

---------------------------------------------------------------------------------------------------------------------------------------------------------------
 

Issue # 5 : Global state visibility - Cohesions

Clarification :

How is Cohesion state visible ?? As Cohesive transactions passes through application infrastructure, the state needs to be stored in an open address space. The spec HAS to state how this is to be achieved, as this element is a major point of inter operability. One can expect that by the very nature of Cohesive transactions performance is slow ( which is acceptable ).

Proposal :

State Maps should be stored in an LDAP v3 repository accessible via JNDI.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Issue # 6 : Benchmarking Metrics

Clarification :

The BTP metrics should be defined "functionally"  via process flows ( that include state maps WITH state changes ).

Proposal :

Withdraw benchmark levels till future date.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

Issue # 7 : The Spec level

Clarification :

The specification currently sits at v0.9 .. which implies very clear, concise definitions that an Architect can advise the business on and an engineer can build from. Is the committee confident that this is the case ?? On reviewing the specification our initial issues were in the double digits.

Proposal :

Do not force the spec through as adoption will be less attractive. Opinion is divided if all the elements are required. If time is essential then it is more desirable to focus on a STANDARD specification.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

Thanks,

Geoff.
 

begin:vcard 
n:Brown;Geoff 
tel;work:650 506 3230
x-mozilla-html:FALSE
org:Oracle Corporation;ATS Core Technologies
version:2.1
email;internet:Geoffrey.Brown@oracle.com
title:Technical Director
adr;quoted-printable:;;500 Oracle Parkway,=0D=0AOPL-A4094=0D=0A;Redwood Shores;CA;94123;USA
fn:Geoff Brown
end:vcard


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


Powered by eList eXpress LLC