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.
>> 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?
-hannes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
