Loosely Coupled Sakai

1. Loosely Coupled Sakai Ray Davis University of California, Berkeley

2. Deliver usable useful applications in a timely fashion. Goal:

3. Is it useful? Are you sure that it’s useful? Method: Empirical

4. User(-representative) driven Incremental Cyclical Opportunistic refactoring Loose coupling to framework & services Evidence-Based Programming

5. Naïve efficiency: Change vendor code directly. Can’t upgrade. Need to maintain unfamiliar code. Loosely coupled: Centralize dependencies. Local implementation. Loose Coupling ≠ Less Integrated

6. Project management = Risk management Cross-project dependency = Risk Why Loose Coupling?

7. Separation of concerns Centralization of concerns Avoid redundancy Avoid disruption Improve maintainability Improve testability Loose coupling = standard design principles at a project level

8. Unrealistic goals Inaccurate estimates Slow refactoring “Living fossils” Unpredictable disruptions “Vendor lock-in” De facto forking Results of tight coupling

9. Integration Week

10. Don’t make trouble for yourself. Facades to external services Don’t make trouble for other people. Service APIs What to don’t?

11. Multiple Moving Targets **SCREEEEEEE…**

12. Multiple Moving Targets Facades

13. Application-tailored interfaces to complex or unstable services Minimize maintenance costs Maximize pluggability Reduce costs of unit & application testing Self-document integration requirements Provide fallbacks Facades

14. Unit tests can be overdone. Generalization for re-use is usually premature. Loose coupling is a leading cause of tight coupling. No Sure Things

15. Is the framework changing? Will standalone implementations help development & testing? Will implementations be much work? When are facades useful?

16. The framework changes

17. Is the framework changing? Will standalone implementations help development & testing? Will implementations be much work? When are facades useful?

18. Facades Sakai 2.0 APIs Sakai 2.1+ APIs Gradebook GB Facades Tests Standalone

19. Authentication Context Authorization User Directory Gradebook Facades

20. public interface Authn { /** * @return an ID uniquely identifying the currently * authenticated user in a site, or null if the user * has not been authenticated. */ public String getUserUid(); Authentication – Who Is This?

21. public interface ContextManagement { /** * @param request * the javax.servlet.http.HttpServletRequest or * javax.portlet.PortletRequest from which to determine the * current gradebook. Since they don't share an interface, * a generic object is passed. * * @return * the UID of the currently selected gradebook, or null if the * context manager cannot determine a selected gradebook */ public String getGradebookUid(Object request); Context – Where Am I?

22. public interface Authz { public boolean isUserAbleToGrade(String gradebookUid); public boolean isUserAbleToGradeAll(String gradebookUid); public boolean isUserAbleToGradeSection(String sectionUid); public boolean isUserAbleToEditAssessments(String gradebookUid); public boolean isUserAbleToViewOwnGrades(String gradebookUid); … Authorization – Think pragmatically

23. public class AuthzSakai2Impl extends AuthzSectionsImpl implements Authz { public static final String PERMISSION_GRADE_ALL = "gradebook.gradeAll", PERMISSION_GRADE_SECTION = "gradebook.gradeSection", PERMISSION_EDIT_ASSIGNMENTS = "gradebook.editAssignments", PERMISSION_VIEW_OWN_GRADES = "gradebook.viewOwnGrades"; /** * Perform authorization-specific framework initializations for the Gradebook. */ public void init() { FunctionManager.registerFunction(PERMISSION_GRADE_ALL); FunctionManager.registerFunction(PERMISSION_GRADE_SECTION); FunctionManager.registerFunction(PERMISSION_EDIT_ASSIGNMENTS); FunctionManager.registerFunction(PERMISSION_VIEW_OWN_GRADES); } public boolean isUserAbleToGrade(String gradebookUid) { return (hasPermission(gradebookUid, PERMISSION_GRADE_ALL) || hasPermission(gradebookUid, PERMISSION_GRADE_SECTION)); } public boolean isUserAbleToGradeSection(String sectionUid) { return getSectionAwareness().isSectionMemberInRole(sectionUid, getAuthn().getUserUid(), Role.TA); } …

24. As consumer of services Spring-injected facades As producer of services? Loose Coupling

25. Application = Tool + Component? External Apps App Presentation App Business Logic

26. Customers End user ≠ Programmer Goals Browser-based workflow ≠ Efficient integration Contracts Functional specification ≠ API Project lifecycles Rapid change ≠ Negotiated stability Application ≠ Service

27. Project = Application + Service External Apps Application Service Shared Logic

28. Erich Gamma (Eclipse; Gang of Four): “You can go and expose everything, and people can change anything. The problems start when the next version comes along. If you have exposed everything, you cannot change anything or you break all your clients. APIs don't just happen; they are a big investment.... I really like flexibility that's requirement driven. That's also what we do in Eclipse. When it comes to exposing more API, we do that on demand. We expose API gradually.... So I really think about it in smaller steps, we do not want to commit to an API before its time.” Application ≠ Service

29. Service requirements

30. Service change: Request

31. Service change: Notify

32. Service change: API

33. Service change: Test

34. (left as an exercise for the reader) Service change: Implementation

35. Project = Application + Service External Apps Application Service Shared Logic

36. Gradebook 2.2 Source

37. From Seth Theriault's Sakai Developer Statistics: 766 lines - GradebookManagerHibernateImpl.java 728 lines - GradebookServiceHibernateImpl.java 252 lines - BaseHibernateManager.java Application logic ≠ Service Logic

38. Application Service Think Globally:Program Locally Shared Logic Facades to external services