Re: [bt-spec] Re BTP Issue 103 (was issues 100, 101, 103 and 105)

[Alastair Green <alastair.green@choreology.com>]

Mark, Jim:

Peter and I spent some time today going back and forth on this issue. Our
conclusion was:

The existing specification text is implementable, and produces a desired
behaviour which helps to enforce transactional integrity.

It can, at some level, be reasonably criticized: you could make a case for
splitting CONTEXT into ENROLLEE and CHECK, and renaming CONTEXT_REPLY to be
CHECK_REPLY. Then you would never see checking info (i.e. the reply address) in
ENROLLEE, and explicit control over checking would become possible (send
ENROLLEE only, or send ENROLLEE & CHECK).

However, it appears to us that checking is a 95+% case in this environment, and
that the weight of a single excess element (which is not present when not used,
i.e. in the BEGIN/BEGUN and Cohesion CONTEXT propagation cases) is not a great
overhead or trouble.

Our view, for what it's worth (2/20 votes), is that change in this area would be
possible, and even theoretically sweet, but is not strongly justified at this
stage in the life of the spec. We also suspect that implementation/deployment
experience would assist in further evaluating the type of change envisaged.

So, I would propose "defer" as the solution to the this issue.

It would be useful to see a concrete textual alternative, with all of its
ramifications worked out, if another resolution is proposed.

Alastair

Peter Furniss wrote:

> Mark asked me to forward this, arising from an offline discussion about
> which of the HP issues might be deferred.
>
> -----Original Message-----
> From: Mark Little [mailto:mark_little@hp.com]
> Sent: 13 March 2002 12:12
> To: Mark Little; Peter Furniss; WEBBER,JIM (HP-UnitedKingdom,ex1)
> Cc: Alastair Green; Bill Pope
> Subject: Re: issues 100, 101, 103 and 105
>
> We may need to forward this to the issues list, but we want to vote on 103
> prior to the 1.0 release. The basic problem is that CONTEXT stands out as
> not being used uniformly within the specification. In our opinion it's an
> application message extension and should only ever be seen within the
> application, e.g., the client/server "interceptors". We're *definitely not*
> advocating the removal of CONTEXT, but rather that it only ever be seen (as
> a separate entity) by the application when sending and receiving
> transactional messages that are related to it.
>
> The possible solutions to this is that we remove BEGUN+CONTEXT and embed the
> CONTEXT within the body of BEGUN, such that it is essentially the payload.
>
> Mark.
>
> ----------------------------------------------
> Dr. Mark Little, Distinguished Engineer,
> Transactions Architect, HP Arjuna Labs
> Email: mark_little@hp.com
> Phone: +44 191 2606216
> Fax  : +44 191 2606250
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:CEO
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard