Integrating Sakai into your university environment depends a lot on just how integrated you need it to be. The following kinds of integration can be considered:
- Unintegrated
- Database Integration
- Enterprise Service Integration
- Portal Integration
See also:
Unintegrated
In many cases, Sakai can be used quite successfully as an unintegrated service on your campus. Some schools, for example, only use Sakai to provide work and research group support.
To use Sakai unintegrated, simply install it on a server following the directions provided in Installing Sakai. Sakai comes with a full set of tools that enable it to be managed and used without any additional campus integration.
Database Integration
By default, Sakai is configured to use a database called Hypersonic. Hypersonic is a very lightweight database that runs in-memory. It can be configured to write out the current database to a DDL file at the close of a session, but that's not a very efficient approach for anything larger than a developer environment. Oracle is the preferred database for large campuses. Support is also provided for mySQL as well.
(child page references to configuring Oracle and mySQL go here.)
Enterprise Service Integration
Enterprise integration involves changing some of the default services that Sakai uses and replacing then with implementations against your local enterprise service. For example, many colleges use LDAP to contain person information. Integration code for LDAP is available from LDAP Integration.
(talk about file system integration)
(talk about student information systems)
(talk about gradebook systems)
(talk about authentication approaches)
(talk about authorization systems, such as CAS)
Portal Integration
Currently, Sakai uses it's own portal based on Apache JetSpeed. There are plans to enable Sakai tools to be used in other portal environment via WSRP.
Providers
1. What actually is sakai provider?
A provider is a way to get information from an external data source. Because providers can be swapped in and out, they function a bit like plug-ins, with some restrictions.
2. Where they are getting called?
The two important providers (user and group) are set up in providers/component/src/webapp/WEB-INF/components.xml. There, you will see which implementations of GroupProvider and UserDirectoryProvider are mapped to the component names. There is also a CourseManagementProvider as well.
3. Is there any relationship between providers and services?
Yes. The UserDirectoryService (defined in legacy services) defines the UserDirectoryProvider. The GroupProvider is defined in AuthZGroups, also in legacy services.
4. If I want to create a new provider , where should I start from?
Have a look at one of the existing implementations and copy it. You'll need to give it your own name, which means tracking down all instances of names in maven projects, etc. BTW, they are not that hard to write.
If possible can anyone provide some links/pointers regarding sakai
providers and their architecture.
The javadoc is available at:
http://cvs.sakaiproject.org/release/2.1.0/javadoc/org/sakaiproject/service/legacy/user/UserDirectoryProvider.html
and
http://cvs.sakaiproject.org/release/2.1.0/javadoc/org/sakaiproject/service/legacy/authzGroup/GroupProvider.html
Charles Severance has a presentation available at:
http://www.dr-chuck.com/talks.php?id=67
See more at LDAP Integration
5. Is provider information cached?
Yes, in some cases, it is. See Provider Caching for some anecdotal documentation.
Using Types with UserDirectoryProvider - Glenn Golden
Scott, make the provider (or batch loader) set the user "type" field to something special to indicate their provided nature. Or a set of type fields, if you need type for other purposes. Internal users will be "registered" or "guest" or something distinguishable.
Then you can get the current User object from UserDirectorService, and check the type.
Another option is to define a custom User object property, again marking the user as provided. Internal users would not have this set; your provider and or batch uploader would set it. Same results.
The advantage of using type is you can then also control if a user can or cannot create their own sites, since different user types use different user authzGroup templates (and about the only interesting thing about these templates is that they control a user's ability to create sites).
