Saturday, September 30, 2006


Took the last two days off to recover from surgery to my left shoulder. I injured it sixth months ago (or so), probably being thrown about in my dojo. Martial arts in my fifties is different than practicing in my twenties, I guess. Anyways, it left me with pain that wouldn't go away, so last thursday a sports medical specialist poked in there to file things down, shave a few loose ends, and generally tidy things up. So far, it looks like a complete success.

I've been doped up for the past two days and I can honestly say that drugs and Java just don't mix, so kids .... stay off drugs! I'm clearing out of the fog this morning and have started back in on work. Too much to do to sit in the living room channel-surfing.

One of the things I'll be spending more time on in the coming weeks is requirements for Sakai 2.4. I've started preparing a Sakai 2.4 Requirements Summary page. You can have a look at it, but it doesn't say all that much at the moment. It does start to shape some of the things that we could work on, but it's not a closed subject by any means. If you have suggestions or things you'd like included, give me a shout.

It's not the job of the requirements group to tell developers or designers how to write code for Sakai, but I do think that we can make the job easier by collecting up requirements, use cases, design sketches, comments from the community, etc. into a central place and then promote what needs to be done. Again, you can help me by telling me (representing the rest of the group) what you'd like to see captured or collected.

- Mark

Wednesday, September 27, 2006

Seasonal Migration

The air is a bit crisper here in New England. The geese are flying south for the winter. Migration is an instinct for the geese. Too bad data migration isn't instinctive as well.

We had a phone meeting of people interested in moving data into and out of Sakai yesterday under the banner of the Migration Working Group (Mig-WG). The key thing coming out of this meeting was the creation of five sub-projects related to migration:
  1. Vender Content Migration
  2. Sakai Archiving
  3. IMS Course Cartridge Support
  4. Open Courseware (OCW) Support
  5. Migration Architecture
Have a look at the meeting notes for more information.

Naturally, the architecture of migration is of keen interest to me. Zach Thomas has started crafting a migration architecture that should serve as the basis of an archive or migration service in Sakai. This approach calls for parsers and handlers that are registered with an archiving service. It has the nice feature of scanning through parsers to see who can handle a given package to be imported.

One idea that I've kicked around is creating some form of abstract content to serve as an intermediate data structure for import, export, and data handling. It seems to me that if we created a set of objects that describe content and how it is organized, it would enable n-way movement of data. For example, it would allow us to import and SCORM package and export it as OCW. It would allow us to select a collection of Sakai content and export it as an IMS Course Common Cartridge, or QTI Question Pool, etc. This content abstraction would be in-memory only and ephemeral, it's not intended to be persisted -- that's what content hosting does.

This is not a big step from the architecture that Zach has laid out. It does, however, prepare us to handle export, which we've kinda avoided so far. Export, especially for Common Cartridge, will be an important part of Sakai 2.4.

- Mark

Friday, September 22, 2006

Group Providers and Eids

As part of my upcoming workshop on integrating Sakai into enterprise environments, I'm writing a pair of user and group providers that will access a dummy student information system implemented as a set of MySQL tables. Conceptually, these providers are simple: they enable Sakai to sorta "look over there" for information about a user or a group.

Of the two, the user provider (UserDirectoryProvider) is more powerful. A UserEdit object is passed to the provider (in several of it's methods) which is completed by the provider implementation, presumably drawing on a enterprise-wide information service such as LDAP, CAS, PeopleSoft, etc. Using the user provider, you can pretty much use an external system of record to maintain your user definitions.

However, this is not the case with the group provider. The group has two important methods:

getUserRolesForGroup -- pairs of user ids and roles for a given group.
getGroupRolesForUser -- pairs of group ids and roles for a given user.

For this to work, however, the group must already be established on the Sakai side of things. In part, this is because the group provider is really only getting information about members of groups (and their roles) or determine which groups a user is a member of. It is used to implement authorization on the Sakai side, and thus requires that sites be defined in Sakai, not elsewhere.

Earlier in the year, I developed a way to access Sakai tools from MIT's Stellar course management system. One of the big stumbling blocks was that authorization was defined on the MIT side of things and was required to remain there. Further, there were thousands of sites defined in Stellar that (in theory) would have to be provisioned in Sakai for the tool integration to work.

I got around this problem by adding a few new methods to the group provider:
  • isAllowed() - an authorization check.
  • isGroup() - check to see if this group is known to the enterprise
  • getAllowedFunctions() - get the list of allowed functions.
with some modifications to the BaseAuthzGroupService code, these functions allowed authorization to be moved external to Sakai.

I have the code around, if people are interested. The modifications to the authz group implementation was such that if external authorization wasn't implemented, it would fall through to the current database solution. Is this a useful thing to include in a future release?

Enterprise Ids

Josh Holtzman recently lamented that he was bit repeatedly by Ids vs Eids while developing providers for the new course management service. Even in the existing providers, the use of these two identifiers is confusing. It's quite clear what the difference is: the user id is the Sakai identifier, the Eid is the enterprise identifier. They could be the same, since user ids can be supplied when the user is created, but I believe we are trying to establish a practice of letting the system assign a GUID.

Regardless, I also had quite a bit of trouble with my test harness and use cases trying to get Sakai to understand the equivalence of a given user id and her eid. Likely this is due to my lack of understanding, but how DO people figure this out? There is some documentation, but frankly, it doesn't help much when it's time to code.

Ids and Eids will figure prominently in my up coming workshop. It's something that developers need to have a good understanding of if they are going to implement providers or do other kinds of system integration with Sakai.

- Mark

Friday, September 15, 2006

Course Cartridges, Requirements, and Integration

Well, it's been a busy week in spite of not being out in Ann Arbor for Sakai Integration Week. I miss the geek-intensive meetings we used to have in previous years, but Chuck tells me that he'll be setting something up soon, perhaps connected to the Atlanta Conference.

Course Cartridge
Some may know that I've been working with Zach Thomas and others on moving data around for Sakai. This has several aspects to it including archiving, data migration from other CMS environments, portable portfolios, Open Courseware support, and IMS Common Cartidge. You can learn more about this at the Migration Confluence Site but what I want talk a bit about is Common Cartridge (CC).

For years, the major textbook publishers (Pearson, Thomson, McGraw-Hill, etc.) have made their content available electronically and often augment a textbook with on-line material. Professors who select one of these books can get a "course cartridge" which is a piece of data enabling content access from a course environment. Many of the leading course environments support such things (BlackBoard, WebCT, Angel, etc.)

Early last year, Sakai hosted a meeting out at Foothill College with publishers to discuss support for this kind of content in Sakai. Chuck Severance suggested that what was needed was an industry standard rather than writing custom access for each CMS and volunteered IMS to manage it. Well, this led to a course cartridge guideline last year, and the development of a specification this year. The spec isn't done and won't be until next year, but the key aspects of it are firming up nicely. IMS gave an industry briefing on it last week in Lynnfield, MA.

The course cartridge specification is a profile of IMS Content Package. That means that it perscribes EXACTLY how content package is used to create a common cartridge. It's very specific in what it allows and what it doesn't Data types are limited, but include most of the things that people would like to distribute as content: web materials, learning objects including SCORM, assessments based on QTI, etc. Content can be either in the package, or accessed remotely. Provisions are made to define authorization and the Tool Interoperability Guildlines (also jump started by Sakai) is used.

While the spec has a ways to go, Zach has already got prototype code up and running as part of the new archive module additions in 2.3. This was based on demoware shown at alt-i-lab last June in Indianapolis. With today's code freeze, archiving functionality is final, but we'll be testing it against sample cartridges and tweak it up for robustness. Meanwhile, I'll be attending the CC spec meetings and helping the Sakai development team to stay on track for conformance. I think this will be a very important feature in the future and it's very cool that Sakai is out in front of it.

Requirements WG
Mara Hancock stepped down as the chair of the Sakai Requirements group after doing an outstanding job of establishing this group. I led my first meeting of the group today. There was a lot of discussion on how the process has worked to date and how it can be improved.

Simply put, the requirements group has the job of getting people to make suggestions and working with those people to refine them into a form that will encourage designers and developers to step up and work on it. Refining them means collecting use cases, extracting requirements, and perhaps guiding early design efforts. Naturally, I'm open to any ideas any of you may have in making this process better. Sakai is a community of volunteers and generating work enthusiasm is a big part of getting things done.

Part of promoting this process will include several events at the up coming Sakai Conference in Atlanta. The REQ-WG will report out on the process to date, examine some success stories, and explain how the Sakai development process is very different than developing a commercial product. We are also exploring the idea of have a requirements writing workshop, perhaps in conjunction with the UI Book Camp. All TBD at this point, but interesting.

Integration Workshop
I'll be presenting a Sakai Developer Workshop focused on integrating Sakai into enterprise environment on Oct. 16 - 18, 2006 in Phoenix. There are still places left if you are interested in attending.

Meanwhile, I'm working on finishing up the material for it. I'm writing a small tool that displays a list of Sakai sites. If you click on one of these links, you see a page with all members of that AuthzGroup. You can then click on one of the group members to see their full name and email address. Besides illustrating how to use various Sakai services, this application will serve as a test harness for workshop participants to write Group and User providers. These providers will interface to a dummy student information system that I've put together in a MySQL database that will run locally on a LAN. I'm writing the sample providers now.

Part of the course will also include writing an application to populate course sites using SakaiSpeak (our web services system). While the app could be written in PHP, Perl, or Ruby, we'll probably do it in Java since it's already a requirement for the workshop. The test application (MemberTool) will show new course sites as they are added by the webservice application.

- Mark

Wednesday, September 13, 2006

The Blogosphere Comes to Sakai

Steve Githens has created Sakai Planet to aggregate blogs about Sakai. Personally, I think it's a great idea to bring together people's thoughs in one place. Since I've used TechnoMark as my off and on technical blog for a while, I may as well feed it into Sakai Planet as well.

This is integration week at UMich. Sadly, I have too much going on to be there. I'm still juggling work on the IMS Common Cartridge specification with supporting Zach Thomas and his archiving work, ramping up to speed as chairman of the Sakai Requirements WG, preparing for Educause, and finishing off the development of a new Sakai workshop focused on system integration (see to register).

Lurking in the background is a JSF bug that's had me stumped for months. Even a very simple JSF program (literally Hello World) doesn't render, dumping XML into the browser instead of rendered HTML. I've spoken with many people about it, but few clues. It's hard to debug this stuff, too. Well, I'll get back to it as time allows.

I have to admit it's been great to have the OSP confluence site and lists folded into Sakai. It's a lot easier to track what's going on there now and get a better idea of how OSP integrates into Sakai. There are some really outstanding tools that are not getting the visibility that they deserve. Hopefully, we'll see more at the upcoming Atlanta Conference.

Speaking of the conference, the conference commitee is coming together nicely under the leadership of Brigid Cassidy. Brigid accepted the role of Program Chair a few weeks ago and already has things organized and moving forward. I think Atlanta is shaping up to be a really great conference.

- Mark