<taxi:reservation>
<taxi:provider>acme</taxi:provider>
<taxi:location>13
Railway Cuttings, East
Cheam</taxi:location>
<taxi:pickuptime>20020415T2100Z</taxi:pickuptime>
<taxi:confirmationcode
type="btp"><btp:identifier>urn:foobar:1234abcd</btp:identifier></taxi:confirmationcode>
<taxi:resrervation>
would tell the terminator application all it
needs to
know.
<ml>Assuming the above is on a response from a
service then that's fine. However, it does now require that that information
is now know about by the service. It may not be. The service may not actually
know about its participants since the enlistment may not happen at reception
of the incoming request. All that may happen at that point is the thread-to-tx
association. Participant enlistment may not happen until much later (if at
all) when some transactional work is done (i.e., work that is required to be
controlled by a coordinator). Now the thing that does the enlistment may not
be known about to the service or the BTP
interceptor/filter/you-know-what-I-mean. An example of this would be how JDBC
2.0 drivers do enlistment of XAResources under the covers from the application
that uses them such that the application/EJB doesn't know its happened and
can't get access to that information
anyway.
We
want to be able to support the above scheme since we believe many services
will be transaction unaware at he business logic level and where the
enlistment occurs is a configuration/deployment/implementation choice. Now I'm
not saying that the participant information can't be available to be returned
to the invoker, only that we can't assume it will be. So, we need some way for
a decider to get this information. Calling inferior_statuses will always
return a list of participants and could be used to figure out what has "just"
been enlisted. Obviously this could be done by the service on the outward call
to fill in the blank above if it doesn't normally have direct access to the
participant information or it could be done by the caller. Runs some risks
though since one outward invocation may cause may participants to be
registered.</ml>
<prf2> ok, late and hidden
enrollments may be trickier - you've re-persuaded me about the inferior-name
qualifier, which can handle the late
case.
hidden (but not late) can be handled by
putting the identifier in the header or equivalent. (this would be done
by the interceptor/filter/... - which surely does know what's going on, even
if it doesn't know
why.
(I privately wondered at one point if we
needed an "inverse-context" - really an inferior context which could be
associated with application messages, in the same way that the existing
CONTEXT (which identifies a superior) is associated. However, when you come
down to it, the content would just be the inferior-identifier, or the
inferior-name if the identifier doesn't exist yet.
)
That one doesn't use the name at all. The name
allows a sort of indirection, and one might
have
<taxi:confirmationcode
type="btpname">acme-345624</taxi:confirmationcode>
and appearing in the
INFERIOR_STATUSES
<btp:status-item>
<btp:inferior-
identifier>urn:foobar:abcd1234</btp:inferior-handle>
<btp:status>prepared</btp:status>
<btp:qualifiers>
<btpq:inferior-name>
<btpq:inferior-name>acme-345624</btpq:inferior-name>
</btpq:inferior-name>
</btp:qualifiers>
</btp:status-item>
</prf>
<ml>As mentioned in one of the very first
emails on this subject, this isn't a problem if all services are invoked
within the scope of an atom; it's a problem if you call a service directly
within a cohesion. So perhaps we should *require* any non-atom invocations to
specify some "name context" within which participants will be enlisted (an
atom id is an implicit context). So it's down to the sender to specify
something that the decider can then key on later. No name context is illegal
if no atom context is present.</ml>
"sender" is the
service-side application ? Or client-side ?
It won't generally
help for the client-side to give a name that it expects to see back on the
enrollments arising from that invocation. If there is the possibility of
multiple enrollments, we need to ask if the client will want to choose among
them, or will always treat them as a unit with a single confirm/cancel
decision. If the latter, then the client ought to create its own atom and
propagate that. If the client wants to choose (or tolerate failures) among the
enrollees, then it needs to know which they are *within* the group, not just
that they are part of it. (obviously there could be exceptions to that - any 2
from N will confirm, but that's a bit odd). If the service wants to some
of its participants to be treated as units, then it should create a
sub-coordinator to cover them, and enrol that as an inferior to the propagated
cohesion - identified appropriately.
That doesn't
preclude a client putting some value on the invocation that will re-appear as
part of the inferior-name though. It seemed that was an application
consideration.though, since its only needed in certain cases.
Peter