Re: [business-transaction] ORACLE BTP Issues

[Mark Little <mcl@arjuna.com>]

Geoff, I know that Pete has assigned these individual issue numbers but it's a lot easier to address them in your original email. Hopefully the committee can do the mapping when we consider the issues separately.

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.

I think this is in line with what we've been discussing. However, since I haven't seen or heard any explicit activity in this area I don't know what work, if any, has been going on already. There was discussion about having cohesions at a different conformance level to atoms, and I don't have a problem with that. As long as all of the conformance points occur within the same specification.

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.

I'm not sure what you mean by "reduce". Are you assuming we would have separate specifications? As I indicated above, we would prefer a single specification.

Issue # 2 : Cohesion vs Atomic

Clarification :

Our interpretation of Cohesion is similar to "Aggregate" / "Long Running Transactions".

Depends what you mean by "long running transactions". At last count there were over half a dozen protocols that would fall into this category.

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 ?

As above, I don't have a problem with this as long as the various conformance points are in the *same* specification. I can't remember if we have discussed how many conformance levels there would be, but it should definitely be a small number.

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.

Sorry, I don't quite understand the "more precise short-circuit". Since the JSR hasn't begun, aren't you pre-supposing how the work will go?

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.

At this point we're not defining any of the end-point participant mappings. BTP is protocol agnostic and for a good reason. If we add JMS specific information to the core protocol then what's the argument for not going a few steps further and adding support for CICS, Tuxedo, JTS/JTA, and other "popular" transaction protocols? Surely this is something that we can address at a higher level and at a later point in time.

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.

Are you suggesting that we enhance the specification with more diagrams? If so, then I'd agree: anything that increases the readability and understandability. In the past we've found UML to be useful in this respect.

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.

First of all let's steer clear of tying BTP to any one programming language or its support infrastructure. Just as we do not know which distribution protocol will be used (SOAP over HTTP, IIOP, carrier-pigeon) we don't know which languages will be used. I am against saying something along the lines of "BTP implementations must use JNDI".

 

At present we haven't specified how the application and cohesion are coupled. This does have portability implications but goes back to the first face-to-face we had in Mt Laurel where some people were worried about what BTP was going to specify. I agree that simply saying that the cohesion has X, Y and Z "interfaces" (i.e., messages it can accept) and leaving it to a vendor to say how an application can use it is not as useful as it could be. However, I think this is something that we can better address once we have experience of using BTP, i.e., in a subsequent version. I've said this before, but I'll say it again: I think that many more issues will come up once people actually start to implement and adopt the specification. Experience is everything here. And you never know - people may find that cohesions simply aren't what they want anyway, and the "standard" conformant versions will take over the world.

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.

Agreed.

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.

There will always be outstanding issues. JMS isn't a perfect standard either. Neither is the JTS, and that's been going for nearly 10 years. If we look at your double-digit issues and see which are actually show-stoppers then I don't believe they will be in the double-digits any longer. I agree that we shouldn't push through to adoption a specification that is broken and unimplementable. However, I don't agree that we should make sure that all i's are dotted, and all t's are crossed before we go to adoption.

 

Mark.

 

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark@arjuna.com | mark_little@hp.com
Phone: +44 191 2064538
Fax  : +44 191 2064203