Peter, this is good. Thanks for collapsing the email down to this. Fine by
us.
Mark.
----- Original Message -----
Sent: Friday, April 19, 2002 5:23
PM
Subject: [bt-spec] RE: re - BTP Issue 108
(was RE: [business-transaction]Email votes - 7 Issues - Ends Tues April 9 =
RESULT)
Let's see if the attached text covers things. I've
made it a Word document as it's changes to the existing text in the "Control
of Infeirors" section of the model. I believe it lines up with the rough
consensus that was emerging. It has the gist of the paragraph below as an
example, with some other expansions to suggest the other ways of doing
things.
I
would be very happy to see this (final exerpt below) as the resolution
to issue 108.
IMO this is better than the original proposal of "service identifers"
in that it provides for the
use of returned application data in cohesive decisions as well as
service type and service
instance identity information.
=bill
> if the client thinks
it will, or might choose *between* different
> participants
enrolled as a result of the invocation (cancelling some parts
>
and confirming others parts of the work done because of the
invocation),
> then it MUST be expecting to have some way of
identifying which parts of
the
> application work belong to
which participant. We've agreed that's an
> application
issue.
This is where we might be arguing at cross-purposes. I'm
not talking about
multiple participants on a single invocation as
being a problem. If that's
the case (i.e., that multiple
participants are enlisted) then a) if the
client knows this can
happen it's already an application problem, or b) if
the
participants aren't mutually exclusive so that they all have to do
the
same thing then the service does something with a
sub-coordinator. So in
case b) the problem collapses back to being
that the client doesn't have a
handle on the inferior for the
cohesion termination stage.
If we tie the participants
with the related service (as you suggested earlier) then we could use it
as an handle (not the participants since the client does not know the
participants but knows the service and since the service tied with
participants the composer or coordinator knows what to
do.)
I think what we (Peter and I) are agreeing
on now is that the participant (inferior) handle that is used to enroll
needs to be unambiguously identifable with the service that enrolled it
*and* the invocation that caused it to be enrolled. Then calling STATUSES
will reveal enough information about the participant later for the
cohesion to be terminated. If an application wants to ship that
information back to the caller in the application response then that saves
a later round-trip to the coordinator.
<pf> the
limitation on this is that there isn't always a service or an
invocation on it. So this solution has to be constrained to the case where
there is. But the solutions that work in other cases (like putting the
unique inferior identifier itself in the application message) would also
work here. But there could again be cases where that won't work for some
other reason (e.g. delayed enrollment) So it's all just
advice for the application designer, not btp
specification.
If the text in the enclosed document does seem
ok, I'd like to propose it as a solution so we can (re-)vote
108.
Peter