Quoting Hannes Erven <[EMAIL PROTECTED]>: > Hi Dasarath, > > > > thanks for the patch Hannes. isn't this already available in the spec? > > The spec allows for coordinator interposition. > > Yes, but the current kandula sources always use local activiation > services to create new contexts. All interposed coordinators hence must > have access (= can send messages) to the "local" master coordinator. > > With the patch, the context can be created at any activation service, > local or remote. There is no more need for > activition/registration/protocol services running at the initiator. > > Participants still can choose whether to register directly at the > coordination context's "root" coordinator or to interpose an > intermediate controller. >
This again I think is possible in the current implementation since the begin method of the TM allows you to specify an activation Service to use. If you do not specify an activation service it uses the default service. Isn't this the problem you are trying to address? > > >> 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. > > > > Well, if the application uses the RPC port type then this is not a problem > > > either. [...] > > 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. > > I gotta look deeper into this. > > That final message originates from the coordinator, so in situations > where the initiator cannot be contacted from the coordinator (e.g. is > behind a NAT) this message cannot be sent. > As I see it, this is a sync vs. async operations issue - isn't it? There 2 things here. sync vs. async and using the same transport connection. If you use sync port types with a bidirectional transport like HTTP this problem does not arise. --dasarath > > > -hannes > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
