Quoting Hannes Erven <[EMAIL PROTECTED]>: > 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).
thanks for the patch Hannes. isn't this already available in the spec? The spec allows for coordinator interposition. If a participant does not want to register with the registration service in the coordination context, he can register with a coordinator of his choice but MUST provide the "first" coordination context to the second coordinator at the time of creation of the second tx. This is not implemented in Kandula yet but it is very easy to implement-- the same reason why it was not considered;-) If you are implementing this then u need to add a new createCoordinationContext method in CoordinationService. i.e. a one that accepts a coordination ctx, Looking at the code I was not sure whether this is what u guys have done. > > 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. Well, if the application uses the RPC port type then this is not a problem either. Kandula was using all RPC port types earlier but we could not do interop tests as a result. So it only uses RPC port types for activation and registration now. For some reason IBM interop does not cause a problem with these 2-- I didn't remove them because I couldn't find a good reason why we need to go into all the trouble to do these inherently sync. operations in an async manner. Just implement the RPC port type for Completion and we are done for this. I hope I understood u guys correctly-- if not please correct me. In fact we are allowed have both. thanks again --dasarath > > > We hope you will find this suggestion useful. :-) > > > With best regards, > > -hannes > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
