OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


<ml>cutting out some text which I think we agree on.</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.
Not necessarily. The interceptor/filter knows about contexts and threads for sure and it *may* know about participants, but it need not. In the example I gave, it didn't need to know (and couldn't know) about participants. It's the same as what happens in a J2EE environment with, say, an XAResource that is enlisted by a transaction-aware JDBC driver - all of this happens at the application level and all the interceptor did was do the thread-to-transaction association.</ml>
 
(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. )
<ml>Yes, and perhaps we should examine this.</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>
<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 ? 
<ml>Could be both. I was originally thinking about the client, but there's no reason why the service couldn't be given this control. Probably should and probably should be the default.</ml>
 
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.
Agreed. All of this would go away if we required services to be invoked within the scope of an atom. But if we don't want to do that then there's always the possibility that a single service might enrol multiple participants for a single invocation.
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.
Again agreed. Some of this may well come down to "best practices" or "rules of engagement". But we need them.
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.
Mark.
 
----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250
 
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC