Re: re - BTP Issue 108 (was RE: [business-transaction] Email votes -7 Issues - Ends Tues April 9 = RESULT)

[Mark Little <mark_little@hp.com>]

> On 108 itself, I would assert:
>
> the concerns are really application protocol issues, not BTP ones. More
> precisely, they
> are concerns of BTP-using applications, and therefore need to be addressed
> in the
> specification of the application+btp contract between the parties.

In as much as they make cohesions useable in a standard way, then I agree.
However, this should not be taken as a reason to not do something in the 1.0
specification. I think we are close to agreeing on the solution. If we do
not do this then cohesions will IMO not be used.

> "applications" in this sense includes the btp-supporting infrastructure
> (such a interceptors/filters etc that deal with the application messages,
> containers or whatever that keep track of thread-associated contexts, and
> transaction-conscious resources that determine what enrollments are
> necessary)

Yes.

> no change is needed in the normative spec; the existing fields and
> qualifiers provide the necessary information signals between the parties
> involved - there are unambiguous identifiers that can be quoted by
> application (or application-associated) messages, and there is an
> application-determined inferior-name that can be as precise as is pleased.

Yes, but we need to specify how it should be set in order to allow an
application to use a cohesion.

> Explaining how to define an application+btp contract/protocol is not
> something that needs to be in the spec itself.

Totally disagree here. There needs to be a statement on how users can use
cohesions. Simply giving them loads of XML and implying that that's all
they'll need does readers, implementers and users of all kinds a disservice.
After having worked long and hard on putting these damn things into the
specification let's not fall at the last hurdle by making them un-useable or
throwing away interoperability. We already have propsective customers who
are turning away from them for precisely this reasons.

> I'm not at all sure we know
> all the ramifications (in fact, I'm quite sure we don't), still less agree
> on them. Some of this is going to be in user guides for BTP-using
products.
> It might be specified in some way in WSDL or similar, that stated the
> expectation and nature of a service.

I'll say it again: standard and interoperable!

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250