1 / 38

Loosely Coupled Sakai

Loosely Coupled Sakai. Ray Davis University of California, Berkeley. Deliver usable useful applications in a timely fashion. Goal:. Is it useful? Are you sure that it’s useful?. Method: Empirical. User(-representative) driven Incremental Cyclical Opportunistic refactoring

cael
Download Presentation

Loosely Coupled Sakai

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related