The Sakai Application Framework in 2.0 and 2.1 releases use a set of core API implementations for Agents, Groups, Authorization and SakaiSuperStructure that are tightly coupled. This limits adopters' ability to replace one of these services with a wrapper to a live information system. Some institutions, for example, favor providing Sakai registrar or student information via a web service or database outside of the Sakai application.
In order to support this style of deep integration the Enterprise DG should advocate for consideration of this model in the API designs, and should form a working group to implement alternate services that are loosely coupled. This activity is not intended to conflict with the original Provider-based model of integration. Rather this is intended to offer integration alternatives to schools that do not want to support the batch-driven provisioning approach.
- Multiple schools would like to use this approach
- The Enterprise DG will need to provide structured input into the SAF design to ensure it does not prohibit this option
- Just-in-time pulling of external data can make lazy initialization of eg. courses possible. One scenario could be a basic cloning of a template, the first time the teacher responsible for a course is accessing it. Data could be gathered from the registrar (current enrollment) and course description management (populating Schedule and Worksite Info), and the site could be made visible/accessible for the students as well.
- Just-in-time pulling of external data releases Sakai from Enterprise data lifecycle management.
- Dependencies on external system for performance in Sakai has been an expressed concern for the Core developers.
- Loose coupling of services can deterioate performance.