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

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

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

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

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

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

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

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

9. Integration Week

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

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

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

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

16. The framework changes

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

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

19. Gradebook Facades Authentication Context Authorization User Directory

20. Authentication – Who Is This? 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();

21. Context – Where Am I? 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);

22. Authorization – Think pragmatically 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); …

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. Loose Coupling As consumer of services –Spring-injected facades As producer of services?

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

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

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

28. Application ≠ Service 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.”

29. Service requirements

30. Service change: Request

31. Service change: Notify

32. Service change: API

33. Service change: Test

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

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

36. Gradebook 2.2 Source

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

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