[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [business-transaction] Email votes - 7 Issues - Ends Tues April 9
> Issues > -------------------------------------------------------------------- > > Issue 4: Glossary is out-of-date YES. > -------------------------------------------------------------------- > > Issue 61: Tables of send/receives for each role > YES. > -------------------------------------------------------------------- > > Issue 87: Conformance Level > > -------------------- > Description > > 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. Something like: > 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. > > -------------------- > Proposed Resolution > > Change the second and third paragraphs of the conformance section to: > > An implementation may implement the functionality of some roles in a > non-interoperable way - usually combining pairs of roles, such as > Terminator and Decider. Such an implementation is conformant in respect of > the roles it does implement in accordance with this specification. Isn't this a bad choice of words since we've always said that there are many roles in the specification, but they don't need to be played by a unique actor for each? Why should this affect conformance? An actor can (and should) be allowed to perform more than one role without affecting the conformance of an implementation. > An implmentation can state which aspects of the BTP specification it > conforms to in terms of which Roles it supports. Since most Roles cannot > usefully be supported in isolation, tThe following Role Groups can be used > to describe implementation capabilities: > > After the role groups table, add > > The Role Groups occupy different positions within a business transaction > tree and thus require presence of implementations supporting other Role > Groups: > > - Initiator/Terminator uses control relationship to Atomic Hub or Cohesive > Hub to initiate and control Atoms or Cohesions. Initiator/Terminator > would typically be a library linked with application software. > > - Atomic Hub and Cohesive Hub would often be standalone servers. > > - Cohesive Superior and Atomic Superior would provide the equivalent of > Initiator/Terminator functionality by internal or proprietary means. > > - Cohesive Hubs, Atomic Hubs, Cohesive Superior and Atomic Superior use > outcome relationships to Participants and to each other. > > - Participants will establish outcome relationships to implementations of > any of the other Role Groups except Initiator/Terminator. A Participant > "covers" a resource or application work of some kind. It should be noted > that a Participant is unaffected by whether it is enrolled in an Atom or > Cohesion - it gets only a single outcome. NO. > -------------------------------------------------------------------- > > Issue 100: Separation of delivery information from payload YES. > -------------------------------------------------------------------- > > Issue 107: Reply to CONFIRM_TRANSACTION if all is ok YES. > Issue 108: Participant and service identification NO. > Issue 109: SOAPAction HTTP header must be present Abstain. Mark. ---------------------------------------------- Dr. Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax : +44 191 2606250
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC