Re: [bt-spec] Deferred BTP Issue 108 : Participant and serviceidentification

[Mark Little <mark_little@hp.com>]

 

<prf> the need is to associate some application work (at the service) with the identifier that is used on the PREPARE_INFERIORS etc.  The identifier itself doesn't have to be understandable, just the terminator application has to know which identifier will affect which bit of work. If the (opaque) identifier is present as a field of or associated with the application response, the terminator can just remember the identifier as having that assoication. So

 

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

 

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>

 

 The application message could carry a field that was known to be in the ENROL - this could be the "inferior name", but the identifier would probably be more use, precisely because it is known to be unambiguous. (In fact, I'm not so sure the inferior name is any use on thinking this through). This is clearly an application [protocol] responsibility - the identifier becomes a parameter on their message.

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

 

<ml>I think the confusion could be my fault if I was using name instead of identifier in text. Meant "whatever handle the decider  

 has to control termination", which is the indentifier.</ml> 

 

<prf>

Yes - INFERIOR_STATUSES presents both the application(serivce)-chosen name (if there was one) and the btp-chosen identifier. PREPARE_INFERIORS etc use only the identifier.

</prf>

 

Peter

Mark.

 

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250