Loosely Coupled Sakai Ray Davis University of California, Berkeley

Goal: Deliver usable useful applications in a timely fashion.

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

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

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.

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

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

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

Integration Week

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

Multiple Moving Targets **SCREEEEEEE…**

Multiple Moving Targets Facades

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

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

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

The framework changes

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

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

Gradebook Facades Authentication Context Authorization User Directory

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

Context – Where Am I? public interface ContextManagement { /** 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. * *the UID of the currently selected gradebook, or null if the * context manager cannot determine a selected gradebook */ public String getGradebookUid(Object request);

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); …

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); } …

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

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

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

Project = Application + Service External Apps Application Shared Logic Service

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.”

Service requirements

Service change: Request

Service change: Notify

Service change: API

Service change: Test

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

Project = Application + Service External Apps Application Shared Logic Service

Gradebook 2.2 Source

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

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