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
- From: Peter Furniss <peter.furniss@choreology.com>
- To: bt-spec@lists.oasis-open.org
- Date: Fri, 25 Jan 2002 12:30:47 +0000
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