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