Separating transaction initiator, participant and coordination services

[Hannes Erven <ha...@erven.at>]

Hi folks,


attached is a patch proposal to allow the separation of the involved 
parties.
This patch - in fact, it's just a second configuration option - allows 
the initiator to create a coordination context at a remote coordination 
service (instead of using the local one). If the config option is empty, 
  the local service is used.
(I renamed the configuration options to make more clear what they mean.)

Also attached is a sample kandula.properties file with sample settings - 
  a "client" service at port 8081, and kandula services at port 8281 
(but commented out).

Georg and I set up a test environment with TestSuite1 and Participant 
services deployed on port 8181, and kandula activiation/registration and 
protocol services on port 8281 -- yes, that works like a charm! ;-)


The rationale behind this is to allow the initiator application (at this 
time via the kandula configuration) to use an external coordination 
service, e.g. when the participants refuse to register at the "local" 
(initiator) coordination service, which is (from the participant's point 
of view) untrusted. All transactions could be coordinated by a third 
party which is trusted by everyone.

Vice versa, the initiating application does not any more have to expose 
its services to the public.
In fact, it does hardly need to expose any service to anyone - there is 
just one message in the 2PC protocol, the final transaction outcome 
notification, that originates from the coordinator and hence requires 
the initiator to expose a service.
But even this could easily be overcome by allowing the initiator to 
query the transaction's status from the coordinator (perhaps we will 
suggest that to the WS/AT specification authors - any comments on 
that?!) so that the transaction initiator can be fully firewalled, 
nat'ted or whatever.


We hope you will find this suggestion useful. :-)


With best regards,

	-hannes