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] BTP Issue 8 : Deaf clients


 This was discussed in Liberty Corner, and on at least one phone call, but doesn't seem to have been discussed on the list.
 
"Deaf client" has two potential meanings:
 
a) the particular application element cannot listen for inbound calls, but is able to access btp coordination services which can listen, and can receive calls from whereever the transaction gets to.
 
b) the application and its btp support (i.e. desired location of the topmost Coordinator or Composer) are in an environment that cannot receive incoming calls.
 
 
The first is already dealt with, as in the original suggested solution, using the control relationship. All the mesages of this are request/response, and the Decider is never expected to take the initiative. (so a coordination hub would be in the orange zone or DMZ of the firewall)
 
The second could be handled in theory, but would require major changes to the recovery model. All the recovery has to be initiated by the superior and follow "presume-nothing" rules - superior persists at enrol time, and performs recovery for both confirm and cancel. The change affects both sides, and is really a different protocol - and much too large to contemplate for the current edition.
 
Given the above, it would seem this issue need detain us no longer:
 
Proposed solution
No change is needed.
 

BTP Issue 8 : Deaf clients

Source: Alastair Green, Choreology
Category: technical
Description:
Desire for clients which can initiate transaction, and invoke application service(s) in transactional context and terminate transaction, but cannot listen independently because of firewall or other restrictions or policies. 
 Suggested solution:
Given the ability to do RPC over request/response carriers (see previous issue on SOAP RPC), this is possible using the 0.9 specification facilities, by making the Factory/Decider a remote, within-the-firewall service. (Server-side transactions). No need to modify specification.

  
 


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


Powered by eList eXpress LLC