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.
|