Re: [business-transaction] Email votes - 7 Issues - Ends Tues April 9

[Mark Little <mark_little@hp.com>]

> 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