Andreas Maunz wrote:
> Hi Vedrin,
>
> Vedrin Jeliazkov wrote on 06/22/2010 01:30 PM:
>> 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,
>
> I would go for that, because... (see next comment)
>
>> 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.
>
> ... that could only be done by periodically checks of the policy
> webservice, which seems not good practice to me (however, we might
> need such a "garbage collection" despite that).
>
>> 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.
>
> Yes, it feels somehow awkward having them separated. We try our best
> to have the AA service up at all times. Christoph is currently
> preparing a hot-spare system. However, please also keep in mind that
> OpenSSO (formerly SUN Access Manager) has been used in companies for
> decades(!) like that, e.g. Deutsche Telekom is one big customer.
... in a centralized setting, not for dynamically creating policies for
distributed REST resources  ... note SOAP services being used for decade
have normally a single or very limited number of  fixed entry points
(URIs).

Regards,
Nina
>
>> 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.
>
> Only for a "virtual second". Exceptions during resource deletion must
> be caught and policy only deleted on succesful resource deletion.
> Of course, policy deletion could fail as well. In that case, resources
> would have to be restored. However, this might be impossible.
> Therefore, a workaround would be to first delete the policy instead of
> the resource. This would be safe, since, without a policy, access is
> blocked completely. Also, policies can be downloaded before deletion
> (in order to back them up for easy restore).
>
>> 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.
>
> Policy deletion before resource deletion could also address some of
> these issues.
>
> Regards
> Andreas
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development