Loosely Coupled Sakai Ray Davis University of California, Berkeley.

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

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

GradebookGB

Facades

Sakai 2.0APIs

Sakai 2.1+APIs

Tests

Standalone

Gradebook Facades

• Authentication

• Context

• Authorization

• User Directory

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

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

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

Application Service

Facades to external

services