Hi Andreas, All,

On 22 June 2010 12:28, Andreas Maunz <andreas at maunz.de> wrote:

> Creation and deletion:
> - Webservice developers are encouraged to tie resources and policies as
> close as possible together in order to avoid "orphans", i.e. resources or
> policies that have no matching policy or resource, respectively. This is a
> design task, but could in the future also be more soundly tackled by a
> technology that attaches policies more directly to a resource.

IMHO this would be a nice feature to have, however a very careful  and
detailed investigation of possible pitfalls, especially in a
distributed context needs to be carried out. As we have discussed
already in a recent conf call, there are (at least) two cases where
resource-policy synchronisation could suffer, leading to "orphans"
(deadlocks):

1) Synchronisation at creation time -- we need to specify in details
how this is achieved. Somehow more tight requirements might be:

1.1) a resource cannot be published without a corresponding policy
being already in place;
1.2) a policy should be dropped if the corresponding resource is not
published successfully;

Discussion: Compliance with (1.1) could be achieved rather easily
through changes in the corresponding OT web service, which holds the
resource to be published. On the other hand (1.2) is trickier -- it is
not obvious who'll take care to delete a policy, which has been
created for a given resource that subsequently is not published
successfully. We might decide that again the OT web service, holding
the resource in question should delete the policy, or alternatively,
the policy service should check whether the resource is published and
in case that it is not, then delete the policy. A further complication
arises from possible network/service outages, which might happen at
random time and interfere with the desired atomicity of
resource-policy creation. In short, we would probably need to devise
some "rollback" mechanism which ensures that "orphan" policies and
resources cannot exist at any moment and under any circumstances. This
rollback mechanism would be complicated by the distributed nature of
the OT framework.

2) Synchronisation at delete -- again, we should study all scenarios
that might happen when a given resource and its corresponding policy
have to be deleted. Let's state again some requirements:

2.1) the resource should be deleted before its corresponding policy;
2.2) there shouldn't be any policies without a corresponding resource;

Discussion: It looks like both in (1) and (2) we would need an
additional state where a policy can exist for a short period of time
(how long?) without a corresponding resource in place. In (1) the
policy will be waiting for the corresponding resource to be published,
while in (2) the policy will be allowed to exist without a
corresponding resource while the policy is being deleted (I imagine
that this could take a while if the policy is complex and the policy
service has to respond to many requests simultaneously). We should
also think what would happen if the policy service does not delete a
given policy reasonably fast (how fast?) -- should the resource holder
service cancel the request and re-publish the resource? Who will
remember the previous policy state, allowing to perform such cancel
operation? And what about the resource to be re-published? Again,
atomicity of resource-policy deletion might be not easy to achieve in
all cases in our distributed framework.

Kind regards,
Vedrin