Page Comparison

...

Solution 4: Reducing Assumptions

The application has to understand the specific Functions where:

• Function 1: create Hold
• Function 2: update Hold

This requires an agreement. On the bright side, an agreement was removed from the Hold OSID with the elimination of the OrganizationIssueRecord. Now, if there was a way to dynamically figure out what Functions exist.

try (org.osid.authorization.FunctionList functions = functionLookupSession.getFunctionsByQualifierHierarchy(ISSUE_QUALIFIER_HIERARCHY)) {
    while (functions.hasNext()) {
        org.osid.authorization.Function function = functions.getNextFunction();
        for (org.osid.resource.Resource resource :  getListOfResourcesWhoCanDoThisFunctionOnThisIssue(function, issueId)) {
            org.osid.authorization.AuthroizationForm form = authorizationAdminSession.getAuthorizationFormForCreateForResource(resource, function.getId(), issueId, new org.osid.type.Type[0]);
        }
    }
}
 
org.osid.resource.Resource[] getListOfResourcesWhoCanDoThisFunctionOnThisIssue(org.osid.authorization.Function, org.osid.id.Id issueId) {
    display("please list the People and Organizations who can perform the following function on" + issueId);
    display(function.getDisplayName());
    display (function.getDescription());
    ...
 
    return (resources);
}

The agreement is reduced to identification of the qualifier hierarchy.

New Functions can be added or removed without any changes to the application code. In the original plan, the OrganizationIssueRecord would be changing with changing authorization requirements. Using an interface to harden authorization rules is not stable as it is the authorization rules that should be encapsulated even if the application is using the Authorization OSID directly.

Retrospective

1. Know the difference between a functional requirement and a solution. It's easy to be led by the nose into a clumsy solution. Most people think in terms of capturing and moving data. They also believe that any application responsibility means the end-user has to do more work. This is about service design and assigning responsibilities among blocks of code.
2. Some functional requirements are short sighted. Tightly coupling organizational affiliations with authorizations is not necessary in small environments and never holds up in an enterprise.  
3. People also have trouble with the asymmetry of services. How a consumer uses stuff coming out of a service and how that stuff gets in there are two different problems. In simpler designs, the data object goes in, the data object comes out. In a service paradigm, approach these two aspects independently. 
4. Generally speaking, encapsulation is good. But here, it makes more sense to surface the management of authorizations but in such a way as to carefully manage assumptions between the application and the Authorization OSID.

...