Ladies and gentlemen, I'd like to introduce Scott Morris. Welcome to session 611. The Learning Enterprise Is Now Open. We have members of the Open Knowledge Initiative from MIT, Jeff Merriman, Chuck Shubert, and Geoff Hulette, and the chief architect of Sakai Project. And I think these two projects are representative of a sea change that's happening in higher education today.

Institutions are working cooperatively to build open systems that support open specifications and open standards, to build new digital learning environments that are going to change new ways or create new ways of teaching, learning, scholarship, and research. So I'd like to start by bringing Charles Severance on to talk about Sakai. Charles? Charles Severance: Thanks, Scott.

So I'd like to start and ask, how many people have heard the word Sakai before? Okay, that's about half. It depends on the audience. If you're in a higher education, you've been to a couple of meetings, it's pretty hard not to have heard the word Sakai, especially in the context of learning management systems. This is about 50-50, probably because the other half are real developers that sort of do developer work for a living as compared to people in higher education. Sakai, I give Sakai as the project that has the most hype award in 2004 in higher education.

Because in higher education, it seemed no matter where you went, you heard about Sakai. And I'll talk a little bit about how that happened. So I'd like to start and talk a little bit about what Sakai is. The elevator speech, which is sort of incorrect, is that we are the open source learning management system. And while that's true, it really is much more than that. We are a project, we're a grant-funded project. We also are producing a framework, which is a way to assemble a vast collection of tools together. That are all collaborative in nature.

And then we have a release that's a product that can be used both in a collaboration and research environment, as well as a teaching and learning environment. So why does Sakai matter? Why would Sakai have to be on your radar? Why should you care? Well, if you're a higher education institution, maybe you should look very closely at Sakai. Sakai might be your next learning management system.

Open source does not necessarily mean cheap. People think, oh, this is free. Well, it turns out you have lots of developers that you have to still hire and do whatever. For higher education, really the value proposition comes down to control of your own destiny much more than free or cheap.

If you're a developer, Sakai, once we get the installation base up, will be a customer base with a piece of software that needs a lot of configuration and value add like directory services being plugged in, etc., etc. And so understanding how to work with Sakai is a potential way to either sell your particular learning widget or potential just sell services around Sakai.

Content providers like publishers or other high value content providers. Can look to Sakai to begin to produce highly standardized ways to plug in not only to Sakai, but to WebCT, Blackboard, and other learning management systems in a consistent way. So if we look at the Sakai project, we start out, yeah, that's why we were named.

That's Hirooku Sakai from Iron Chef. And the project we had at Michigan before this, we called it the Chef Project. So we needed to come up with a name that wasn't Chef. But we didn't want to call it like Chef 2. Because then everyone would kind of say, well, that's just Michigan's code again.

Turns out it was Michigan's code again. But by calling it Sakai was a way for people to wait about six months to figure out that it was Chef. So Sakai is the Iron Chef. So the idea is that we take these four institutions, Indiana, Michigan, MIT, and Stanford. And effectively chain ourselves together and jump off the cliff. Fall together for two years.

And then hit the bottom and have one open source learning management system that was satisfactory to all of us. Now we took some very unique approaches in this. We insisted on a BSD style license. And we took developers from each of the institutions. The grant turns out to be a small part of the money. We took developers from -- five developers from each of the core institutions. And they report to me.

I spend a lot of time in the air. Because I have developers all over the country that are working on this project. Because we have to build this. We have to build it for all of us. Not just one of us. We're not building this for one and handing it out. It's being built by everyone. So overall we're about $6 million. We're 20 FTEs. And we have a number of partners that are investing. Now one of the things that happens when you're funded through the Mellon Foundation is it's kind of like a mark. It's a brand.

It starts creating buzz the moment you're funded. So this is dated January 22, 2004. This is less than 30 days after we're funded. We're in the chronicling phase. We're in the chronicle of higher education. And all of a sudden the CIOs and CTOs of all these universities start saying what's this Sakai thing? Well there were literally hundreds and hundreds of open source learning management systems. But now Sakai has kind of risen above this. And so we think this is a very important thing that we can do.

And if you look at the commercial sector, go back in the mid '90s, lots of small commercial learning management systems. Then there was an industry shakeout. And two large commercial systems. And two large commercial systems came out of that. WebCT and Blackport. There are some small ones, Angel and Desire2Learn. They're kind of in there in the edges selling lower cost applications. But at the end of the day the industry sort of has settled on two large powerful products. So the first one is the WebCT.

In the open source environment, we really have had no consolidation. Everybody who has five or six programmers writes their own. Literally, there are hundreds of different open source learning management systems. So in early 2004, when Mellon Foundation bet on us to make one that could kind of bring order to it all, let's build at least one that's got at least four institutions that buy into it, and then potentially there will be more.

Now one thing about this project is it's only two years. We are not going to fund the project again. We've not asked for any renewal funding because it's ended. The project was to align the four institutions, not to keep writing software forever and ever and ever. We're going to turn this software over to an open source community at the end. December 2005 is the end of the Sakai project and the beginning of the Sakai Foundation.

So you think of this kind of crazy two-year process where we've developed this software. At just a feverish pace, it's really almost like a blip in the open source world of learning management systems. Hopefully going forward, this will just be an open source product. Michigan and others will provide developers and will work with it. We're going to be running it in production, but it really is going to become the property of the open source community.

So for the first two years of this project, really? Yeah. We're forming the corporation in about a week, the Sakai Foundation Corporation, and we're going to transfer it all to the Sakai Foundation Corporation. So for two years, we had this little foot race, and we are running it like a small startup. We have a very hierarchical organization. I'm the chief architect.

Everybody reports to me. If a decision has to be made, I make the decision. People get mad sometimes. They fight in our board meetings sometimes. It's just like a company. That's only how we work for the first two years. It turns out we're rewriting so much software, and it's so painful for people to throw their learning management systems away that we have to be very, very agile and very, very quick during these two years. We hope the software we produce at the end of the two years does not require that kind of investment.

The future looks more like our Educational Partners Program. We have 80 schools who've committed to spending $10,000 per year to fund us to keep going. Now what they're going to fund is not necessarily the development, but more the coordination of the development of the entire community. So we're meeting with them this week. I get on a plane as soon as I leave here to go to our Sakai meeting with 400 people to talk about the current and present and future of Sakai.

We also have commercial affiliates. We all lived through the late 90s where everyone who had a domain name got a million dollars and a Ferrari, right? Well, we don't want Sakai to be viewed in that same way. We carefully want to make sure that Sakai stays an open source play, that the University of Michigan, Indiana University, MIT and Stanford, we're not in this for a buck.

We all had to agree that we would give this software away at the end to be part of the project. So what we do is we have commercial affiliates. Generally these commercial affiliates are the ones who are going to be the most successful in the future. So what we do is we have commercial affiliates.

Generally these commercial affiliates are the ones who are going to be the most successful in the future. affiliates are interested in adding value around services on selling Sakai. For a long time we only had three of them in their little companies. Well recently we got a big one, IBM.

Everyone looks at IBM and says, "Whoa, it's gonna change Sakai." Well, let me tell you the people at IBM that we're dealing with are IBM global services. They're not so interested in changing Sakai, they just wanna make a whole lot of money selling you all Sakai on IBM hardware. And so it's again the commercial affiliates are more oriented towards services around Sakai than they are buying favor within Sakai.

We have Sakai meetings. Our third one is happening this week. This is the first one that's open to the public. The first two were sort of members only. One of our patterns is to have things members only and then open them up as a transition to make it so that we are truly open by the end of the project.

In the future, as I mentioned, the grant ends 2005. We expect a $1 to $2 million revenue stream starting 2005 already to the foundation to stay in the open source. We expect that the core team is going to be on the order of 10 programmers and not a large set of people to do all the work.

But instead, a small set of people to coordinate it makes sense, coordinate QA and get releases out on time as compared to doing the actual work, where today we're doing the actual work. There's contributions from outside the core, but most of the work is done by the core. In the future, the core will be doing the release and the QA and the consulting.

Could I switch to demo one, please? So what I have here is I have what we call our quick demo. And in our distribution, there are two basic pieces of distribution. One is this demo that you simply unzip and put on your desk and run one command, and you've got Sakai up and running. I carry it around on a thumb drive, the full installation on a thumb drive.

I just made an install package in the previous session over there so that I could have a Mac install package out of it. It's really simple. We call this the show your boss version. Your boss says, I've been to a conference. I heard about Sakai. Why don't you get it up and running so I can take a look at it? Five minutes later, you go to localhost:8080, and bada boom, you've got it. So I want to show you a use case scenario that kind of gives a sense of the collaborative activity of it. I'll log in here.

And so, I have a series of workspaces, and these are like SharePoint sites or it's just a context around where information is organized. And depending on the site I'm in, I have a set of tools that run down the side. I'm going to make a site. I'm going to create a new site. I could create a course site or a project site. I'll create a project site. I'll call this one WWDC.

And I get a set of tools, and again this is that same set of some collaboration tools, some tools that are not, that are sort of general collaboration, others that are teaching and learning. You can import content from other sites if you'd created them. I'm about to publish the site. I'm going to make this publicly joinable by anybody, and I'm going to give them an access role. Here's where you start to see where it's not necessarily just about teachers and learners.

We have a lot of terminology in there that's neutral. Maintaining access makes sense if you're a teacher or a learner, but it also makes sense if you are The Chief Graduate Students and the Subgraduate Students, or you're the PIs on the grant and the graduate students working on the grant. Maintain is the ability to mess with the files, and access means the ability to write the files. So there's this membership button that now anyone who comes to this site can naturally join it. So I'm going to create the site.

And now it popped up in my site list because I'm the maintainer of it because I just created it. So now we see a series of buttons, the home button that tells you like the chat that's going on or the recent announcements. I should have put the schedule on, I forgot about that. Announcements is a way to make announcements and resources is a way to, oh shoot, I forgot I need to upload a file here.

So there's a sort of upload place. There's a chat room that you can work with. There's this presentation tool that's something I wrote that flips slides. If you know my history, I have this urge to distribute presentations. It's the thing I want to do. But we also have WebDAV that works nicely in Apple.

And unfortunately, we shipped before... We shipped before 10/4, and so our instructions have Goliath in them because of the HTTPS Apple thing. But now we're going to update the instructions. So I'm going to pop here and just bring up WebDAV. And I got the URL from this little site.

And so there's the file that I just uploaded through the web interface, and I'll just drag another file into there. Let's get that on. And I'll go back. And there is the file that I just dragged in. And so the resources tool has got a web dev capability. And so now I want to create a class. So I'll go back to my workspace, worksite setup, I want to create a new one. This time I want to create a class.

This is some information that I'll talk about in a bit about pre-published information about who's what teaching what class. And it knows who's teaching what class. Then it goes through the same set of steps. Pick a different set of tools, the assignment tool, chat room, the drop box, the grade book, resources.

So people can act, anybody can get in, and create the site. So there's my course site. Now, I was in the testing room, and I don't know how many of you got a chance to play with that Intel-based Mac, but it runs this application about 70% faster than a 2.5 gigahertz power PC.

So I'll just let you know that I'm ordering one as soon as I get back, because we're all Java developers. This whole thing's written in Java, and running Eclipse, I'm sure, is going to be about twice as fast as one of those things, and they're an awful lot cheaper. So I'm just very impressed with that hardware. We ran on it just fine. As Steve said, Java just works.

So let's go back to the slides now. So one of the things that faculty really find enjoyable about this software is that notion that they can create a group of students with four or five students just like that with a couple of button clicks. And that's because part of our fundamental goal is not just to think about this as precisely about the courses, but instead ad hoc teaching and learning and ad hoc communication.

We have four sites that are in production. I define production as there's enough people using it that when it goes down, phones ring instantaneously. University of Michigan, Indiana University, Yale University, and Foothill Community College. Foothill has 35 community colleges that are going to be using this as well.

There's a whole series of other organizations that have published the adoption plans for their use of Sakai. You can go to Google and type "Sakai adoption plans." My personal favorite is University of California Merced, which is, I think, right over that away. They are a new campus, and their learning management system is going to be Sakai.

They're going to be Sakai from the very beginning. So unlike the rest of us, they don't have to come up with any conversion scripts. They're just going to start with Sakai from the very, very first moment. And so we think that's kind of really a very cool adopter.

Now, technically within Sakai, we're going to have a bunch of tools written by a whole bunch of people. And so we've had to build a very robust and rich framework to make it so that dropping one tool in does not break another tool. We chose technologies in Sakai that we hoped would be comfortable in a typical enterprise organization that's not using Microsoft, meaning the typical Java stuff: Java, Tomcat, Java Server Faces.

We didn't make up too much stuff. And it turns out it fits beautifully inside Mac OS X Server because there are so many pieces of Mac OS X Server that are already there. And we just drop in the pieces that we need in addition, hook up the JK connector the right way, install the certificates, and off you go. We support MySQL. Out of the box. And Oracle, which is also available on Mac OS X Server as well.

The basic architecture of the software is what I call a two-layer architecture. If you remember, long, long ago, there was this concept of the three-layer architecture, which seemed really good when you first heard about it. But the three-layer architecture has all kinds of problems. I could spend a lot of time talking about why three-layer architectures don't work.

We use a two-layer architecture. It's also called the service-oriented architecture. And the idea is you break at least one place and create a very hard, impenetrable API at that place that you document the heck out of. So you split between your presentation and your persistence. Then you publish a Java doc, and you don't change it every day. This isn't like I'm the programmer writing the whole thing. It's like one programmer can write above the line, and another programmer can write below the line.

And they can communicate through Java doc. And we find that this solves lots of problems with keeping persistence out of the presentation code, unit testing, etc., independent development, and very importantly for us, reuse of code. So our announcement tools can post a schedule. Our chat tool can post an announcement. So you have all these tools that you think, well, there's just a chat tool. That's just one thing. No. It has capabilities that touch everything else, and it just calls the services for those other capabilities.

Our Sakai application framework, I don't really have time to describe it, but we really refactored our code in such a way to isolate the non-portable aspects from one web app container to another web app container. We're almost at the point where with our kernel, I can move between a servlet container such as Tomcat and a JSR168 container such as Pluto or the JSR168 without changing my tool code by just changing my kernel code. And so we have a series of things that we provide from the kernel.

These common services, which are like file systems and a presentation. I'll talk about each of these. And then the app developers write some tool layout code, some tool code, and then their own application services. Chat is a good example of an application service. This is just a simple show of the Sakai layout. We chose Java Server Faces. A lot of people give me a lot of crap about that. Everyone says Java Server Faces is a little young.

What we were looking for is a really solid presentation layer that is supported. And we wanted to make it symmetrical. And yeah, Java Server Faces is young. This is layout. It's almost like Zool or XForms or whatever, but it's even more pure layout. And the key thing is you've got to build widgets. If you don't want to build widgets, Java Server Faces becomes really, really frustrating because it's not like JSP with tags. This is really a layout language.

It's not a bunch of macros. And so these are very intelligent little buggers. And you can't just take your average web designer and say, "Go off and make a new one." You can't make a bunch of JSF tags. So we have senior developers making the tags. But the nice thing about it is there's no localization issues here, no internationalization, no accessibility issues. We tend to write tool code that ignores that and delegates that.

All up to the presentation services. And so we felt that this was a way for us to write tools that could have a very, very solid layer presentation, that the layout is very clean, and we could delegate to the presentation services and the tag implementations extremely complex things. Now a lot of classic web developers find this frustrating because they're just used to hacking stuff. And this is not for the faint of heart, but we're trying to build a tool set with literally hundreds of tools that look and feel identical.

On the bottom end, we provide data in through the service providers. That's how that course information comes in. We provide the role information, the course information, and the user information. We have a number of user directory capabilities in our 2.0 release. LDAP, JLDAP, Kerberos. on an IMS enterprise.

And so we plug in all kinds of information from below because we basically demand that no one mess with our tables. These tables are supposed to be impenetrable. So if you want to plug in information, we've got an API. You feed the information is, then I can change this and do performance tuning to the extent I need to here, whereas I don't have the local code that's in the loop for lots of queries. So the plugins don't replace the persistence. They actually populate the information as necessary.

OKI is a founding partner of the Sakai project. And OKI in many ways has been the inspiration for much of the Sakai architecture, the service-oriented architecture, the naming of the APIs, the naming of the objects. But it's important to people to understand that Sakai is in the business of writing a piece of software that just works in Java and runs fast and is convenient to use.

OKI is in the process of writing standards that work in lots and lots and lots and lots of languages. And Geoff will talk more about that. So Sakai, we're working on. We're writing software that's heavily influenced and makes use of OKI where appropriate, whereas OKI is building something way beyond what Sakai is building. And that is interoperability APIs that work well beyond the Java environment.

One of the things that we've done is, in a way, we sort of have scared Blackboard and WebCT, and they wanted to work with us. And we said, are you going to take our software and sell services around it? And they go, no. And so they said, we'd like to work with you.

And we go, OK, how can we work with you? So we made up this IMS group, and it turns out to be really cool. And so what the IMS group ultimately has turned into is working on a standard that is effectively a light version of Chalkbox or PowerLynx. So if you're familiar with WebCT or Blackboard, this is a really elegant, elegant approach to bringing a tool in that's not physically present on the same system.

And so the idea is you have an externally hosted application that might be content, or it might be a testing engine or whatever. You have a learning management system, and then you have sort of the end user browser. And the idea is inside this learning management or collaborative environment, you have a button, and when you push the button, There's a web service request from the learning management system to the external application that gives session and context and ID and password and role information to this external application.

The external application returns back some URL with magic stuff on it, and then that URL is put into the browser, and then the user interacts with the application for a while. And then from time to time, based on the session information, it might do something like store a grade.

And so this is pretty clever, because it's basically using all web services here in just simple HTML, and it's pretty easy to write these things. You can write them in PHP or Perl or Python or anything. All kinds of tools can come in through this mechanism. And usually you think of a standards process has taken a very, very long time. IMS took a different approach to this. They said, let's just write the code first and write the standard later. So I'm getting on a plane in about two weeks to go to Sheffield, England, in Altilab, where we'll demonstrate two tools.

Working in four learning management systems. WebCT, Blackboard, Sakai, and Moodle will all be able to launch SAMigo and a thing called Concept Tutor from University of Wisconsin. So this is kind of impressive, meaning it's going to work, and then we're going to sit down and do all the kind of fluffy stuff about writing the standard and getting votes and stuff like that.

So, in summary, I'm almost done. In summary, if you're an educational institution, if you're a crazy one, you should join us. You come be part of our party. But if you just aren't so crazy, just keep us on radar, watch us. When we got 50 or 100 installations, maybe we'll be more interesting to you.

Commercial providers, companies, if you have a widget to deploy or if you want to just simply provide services, Sakai could create a market for you that makes plenty of money off of our customers. And content providers, we hope this IMS effort is going to allow us to build things that are not particularly in learning management systems but highly value-added content. One of the people we're working with is O'Reilly and Safari, trying to build this so we build Safari into Blackboard, WebCT, and Sakai all at the same time.

We've been working very closely with Apple for quite some time. We all carry around laptops. I've been sort of thinking about a commercial based on those laptops, and actually it was an early meeting between MIT folks and Michigan folks. We're doing this Polycom, and you look around the room and you say, all these gray-haired geeks all have laptops that are Apples. And you say, why is it that everyone in this room has an Apple? And that is because we all had a choice.

So... So basically the development of Sakai is effectively done on Apple's. A faster Java on the Intel hardware would be kind of nice. We basically run our internal collaboration server, collab.sakaiproject.org on Apple hardware donated by Apple, powered by XServe. And basically we see potential for a nice synergy between XServe and Sakai for small to medium sized organizations where they don't want to build a Linux expert.

They want to hit software update every couple of weeks and they get all the patches and they get the Java and then Sakai just keeps on running. And the fact that MySQL is there means that almost out of the box with little or no effort you've got a Sakai server that stays in production without a lot of effort and talent on your end. So you can go to the website www.sakaiproject.org.

There's a collab site where you can join any of our groups and see what's going on inside Sakai at collab.sakaiproject.org. We have a couple of mailing lists that you join there. And we're announcing maclearningenvironments.org which is not up yet but basically it's a way for us in this community to work together. We're waiting until our 2.0 release comes out and then going to put a nice skin on it and bring it up.

So our 2.0 release is going to come out June 15th and so the site's up. If it's there we're probably testing it up to the 2.0 release. You can take a look at it and instructions will be there on how to join the groups and what groups are there etc. etc. etc. So with that I'm going to turn it over to Jeff Merriman. We'll do questions at the very end.

Thank you very much, Chuck, and thank you for leaving. Plenty of time. Chuck's already done a very good job, I think, of introducing you to OKI and how it's different from a project like Sakai. Sakai is really about, as you know now, if you didn't already, open source software, open source CLE for higher education and other domains, and about the community.

OKI really is about open standards, open specifications, and our concern is open systems. Sakai was, I mean, OKI was one of the founding, was really a foundational project from which Sakai and a number of other projects have evolved, Sakai being one of the most important. But we are, we are, have a different agenda, which we're going to talk about.

Sakai started, really, I mean, OKI started, really, in early 2000, when a number of institutions started talking about how to solve some very fundamental issues about the way that software integrates into a complex educational environment. It really started with conversations amongst those of us at MIT and Stanford. I was at Stanford at the time, and I'm at MIT now. Who were creating enterprise environments and trying to sort through all the various kinds of educational software that we wanted to run in those environments.

And finding it was kind of difficult. And finding that the specifications or interoperability standards, you know, were not as good as they were supposed to be. And finding that the standards necessary to do it well really didn't exist. Even the IMS Global Learning Consortium, who, for those of you who are familiar with that organization, Chuck's already mentioned it, IMS at the time was building and promoting data exchange specifications. What we needed were integration specifications. And that's what, that's what OKI set out to do. Initially funded through a grant from the Andrew W.

Mellon Foundation, they became interested very early on. It was an organization that has funded Sakai. And immediately we gained a number of educational collaborators. You can see the list on the screen. Folks who have the same vision, the same concern. How do we take all kinds of educational software, whether it's desktop, you know, client-side software to web-based systems, and get them to integrate together seamlessly in an enterprise environment.

You'll see, of course, that four of the founding partners are also the four founding institutions. The institutional partners of Sakai. And very early on we partnered with the IMS Global Learning Consortium. We wanted to make sure the work we were doing would be dovetailed with the work of IMS, would help to lead that community and be informed by it. And eventually the idea is to give the OKI specs over to the community, which we're actually starting to do now with the IMS Global Learning Consortium.

So OKI has really one primary deliverable. The product of OKI are a set of specifications that we call Open Service Interface Definitions, which Chuck has already referred to, OSIDs. They really are specifications that define how enterprise services in a service-oriented architecture sort of paradigm can be plugged into applications for various kinds of interoperability goals. They are interface specifications. For Java, they're bound as Java APIs. You're going to learn about what we're doing for Objective-C in a little bit.

But we are defining these abstractly. We're coming to agreements with the community at a service-oriented architecture, very abstract level about, you know, here's the kinds of services that educational software needs, here's how we factor them, and now here's how we do this in various technologies. The goals of this, motherhood and apple pie, right? We're trying to reduce costs. We're trying to set ourselves up for the future where we know at places like MIT, certainly, technology changes.

And how do we change technology in an education system? We're trying to create an educational environment so that we can mitigate the change across the board, right? How do we change out an entire authorization infrastructure without having to touch all the apps? And that's really what we're setting out to do, this whole plug-in notion, which we'll talk about. We're trying to increase opportunities for collaboration. Sakai is obviously doing a lot in that area.

But beyond Sakai, with the commercial sector, with the open source sector, how can we get these things to work? How can we get these things to work well together? And really, we talk about this a lot. What we want to see for educational software is a marketplace of software, where in the end, as an end user, you should be able to go and choose products, whether they're open source or off-the-shelf, shrink-wrapped products, and know that they can run in an environment that they really weren't necessarily initially designed for.

Initially, we released the Java API versions of the spec back in the spring of 2003. Those began to enjoy some limited adoption. We got more adoption as we moved to version 2, fixed a lot of things that were wrong with version 1. And in fact, now we're planning the version 3 release, which will probably come out later this year. But one thing that we did announce just today is the release of our new Objective-C bindings of the Open Service Interface definitions, primarily, obviously, for the Mac OS X developer community, primarily in the open source community.

And we're going to be doing that in concert with the Mac Learning Enterprise community that's now beginning to form. And we think this is an important thing for OKI. I'm going to turn over to Chuck Schubert, who's going to talk more about OSIDs. Thank you very much, Jeff. I'll be back. Jeff will be back. So what's an OSID? Think API. If you think API, you're pretty close.

What we're going to do in the next few minutes is take a look at a couple of examples of the kinds of ways you use OSIDs. And the way you use OSIDs will be instructive on what they are. One of the first things that we're going to look at here is the case of having clusters of compute nodes that are available for being able to Be used by people, students in the MIT environment. We have, at last count, about 150 clusters at MIT. Some are small. Some are fairly large.

We decided that we wanted to attack this particular situation because there are no current... mechanisms for us to be able to make these facilities available to students and others that are in the MIT community. So we want to be able to have a situation where we have a client sitting with a laptop being able to access a bunch of computers that are sitting behind some sort of wall.

In this particular case, we have a couple of things that we really wanted to try on the initial program that we put together. One of the things was that we wanted to look at finding out who people were and look at an authentication situation, and we wanted to find out what they could do or look at an authorization situation. We had a set of cluster services that we wanted to put together and make available.

We didn't want to bind those to any particular back-end cluster. We have lots of Linux clusters that run Rocks and other scheduling systems, and we have The Apple clusters that run Xgrid. And so we're really interested in having something that's a little more general purpose. We could have chosen to write these as a single monolithic application.

What we did instead was choose OSIDs as the way we wanted to deal with that. So we wanted to create a set of APIs. An OSID has the ability to serve as a plug-in from the standpoint of the particular implementations of the technologies that are underneath, and it also has the ability to serve as an API for the applications that are using it. So it's really an abstract definition of how these things should fit together.

We chose for our particular initial test of this an Apple cluster. We chose X509 certificates for authentication, finding out who you are. We decided to build a small little authorization system, and we had a scheduler that we put behind our cluster services. We wanted to make these so that later on we could kick in to Kerberos or some other kind of thing.

For the authentication, we wanted to be able to use our local roles database for the authorization for what students could do, and we wanted to be able to make things generally useful, cluster services generally useful. In that vein, we've done a demonstration. I'd like to turn over the situation to the presentation to Geoff Hulette, who works with me at MIT, to talk about one of our implementations of this.

Hi, I'm Geoff Hulette. I'm going to show you a really quick demo of an application that we wrote internally at MIT that uses two OSIDs, the authentication and the authorization OSIDs. And this is just basically just like Chuck was saying. What we were looking for here was authentication and authorization, so who you are and what you can do in this application.

And so we basically wrote a web application that's going to let you allocate nodes on a cluster and then construct a Mathematica script that you then download and use to connect Mathematica running on your desktop to the cluster on the back end. And actually, so this demo is, at this point in the demo, we've actually already used the OSID, so it's pretty transparent. You can see up in the corner, this web application knows who I am. That's hitting the authentication, the who you are part OSID.

And that's using X.509. And you can see there's the table of Mathematica nodes up there. And that's going to look at my authorization, which is going to tell this application how many nodes I can allocate. Now, the OSID story here is that if we wanted to swap, we're using X.509 for authentication. And our own kind of SQL tables for authorization. If we wanted to, we could very easily swap out the X.509, say, for a Kerberos implementation.

If you already had that implementation, all you would have to do is just drop in that bundle into this application and change like a line in the config file, and you would be running on Kerberos instead of X.509. So that's a big benefit from our perspective. So I'm just going to run through this really quickly. At this point, I'm going to go ahead and allocate two nodes on our cluster back in Cambridge, Massachusetts.

So you can see it's constructing the script as we're doing this. So this is going through the authorization. Every time I do this, it's asking, you know, am I at my maximum, you know, we could ask questions like where could I allocate the nodes. It's not built in because we only have one cluster we're really dealing with here. So I have two nodes allocated now. And I'll go ahead and download the script, Mathematica script.

So I execute this. This is actually a better Mathematica demo. This goes ahead and uses the Mathematica parallel toolkit to connect. This is connected to our XServe cluster. And so now you're actually running Mathematica here. We're connected to a cluster on the back end. And I'm just going to run a really quick demo. This is just going to factor a range of integers in parallel on the cluster. So ta-da. And that's it. Turn it back over to Chuck. Thank you, Geoff. If we could go back to the slides, please.

So the OSID technology is, in fact, something that is-- An abstraction layer that allows you to do the kinds of things that we've just seen. We could go beyond what we've shown with authentication and authorization to another set, a more complete set of APIs that we've defined. So these are the OSIDs that are currently shipping in version 2. There are kind of two types of OSIDs. One are the common services that are independent of an educational system. The other is the educational services.

And we'll see now a As soon as I get through describing this last thing, a demonstration of the repository API. We've moved this into a very abstract level. We initially started out with our definitions of the OSIDs being in Java. We had as a design goal going through the development of the OSIDs that we would be language independent as possible with Java.

We had in mind being able to do bindings in other languages. So in the last six to 12 months, we have gone from having Java only to being able to have other language bindings. We've done this by casting the OSIDs, the abstract definitions, in XML. The XML we're calling OSIDs, there's a An XML schema to define what an OSID looks like.

And we've abstracted the language dependent part and put that into an XSLT translation for individual things. We have translations, of course, into Java so we can see that we can make the round trip from starting in Java and getting back there. We've also got, in the last few days, we've released an initial version of the Objective C language binding. We've got other language bindings that we've been working on, and they've been very instructive in making the exoSIDs much more general purpose.

The exo-sids in Objective-C have two kinds of things. One is the definition of the o-sids themselves that are in a framework, an Objective-C framework rather than a Sakai framework. And the other is that we have individual implementations that are put in other frameworks. The major loading aspect of being able to put a dynamic bind between the OSID and some implementation, whether in authentication it might be X509 or Kerberos or what have you, is through a loader.

And the loader checks to make sure that the managers of the implementation meet the definitional managers in the XOSID definitions. We have another example of the kinds of things that we're doing here, and that is I'm going to turn over to Geoff to be able to talk about that. Geoff Huette: Thanks, Chuck.

So you saw with the HPC demonstration, the point there is we're trying to build the software so that these kinds of underlying services can be plugged in and replaced. The benefit, of course, being that as we change technologies, we can change those fairly easily. Another benefit being as we want to share these applications across institutions that might have different sorts of infrastructures, that should become easier as well.

So really, again, this marketplace of applications, of plug-ins, is something we're trying to build. Chuck showed you the list of the OSIDs. One of the OSIDs that's really getting a lot of traction right now in the industry and the open source community is our repository OSID. And I'm going to show you a couple demos that use that and show off some of the other features of the approach. First of all, the world of repositories, certainly in higher education, is a very complex one.

These days, faculty and students alike want to access lots of content from lots of different kinds of applications. So typically what we see today are applications that are sort of bound to a particular repository of content. And with the OSID approach, we're trying to break that. The problem with breaking that is that it's a complex world.

Imagine this poor laptop here sitting in an environment like MIT's or Michigan's or wherever, running a computer. And you're running an app that wants to access content in various repositories. Well, you have repositories that are institutional. You have digital library systems that are institutions. We have published material that you might be subscribed to that might be out there on the internet someplace.

All kinds of things. You might even have local content, content that you slip a DVD disc into your machine and you want to access that from the same app. Complex world. What makes it more complex is that there are lots of standards out there. In the repository space. There's a lot of protocol standards.

Things like SRW, the Search and Retrieve Web Service, that's being promoted by the library community. Things like DRI, the Digital Repository Interoperability Spec, built by IMS Global Learning Consortium. You have folks doing things with SOAP, with other kinds of web services, some proprietary, some other. And of course there's lots of content standards out there. Things like IMS Content Packaging, Dublin Core, Score, and so on. SCORM, we can go on. Very complex.

What we're trying to do with the OSes is help make that world a little more palatable for the poor application that wants to take advantage of it. I'm going to show an app called Search Party. Search Party, this is sort of an initial build of it. It's something being developed by the Mac Learning Environments Project.

Brian Bias, one of the developers who's really taken the lead on this, is working with that. And Search Party is one of the first Cocoa apps out there that actually takes advantage of the OSes. Now it's taking advantage of Java, the Java versions yet. We haven't quite gotten to the point where we can use the Objective C.

But this diagram, similar to the ones that Chuck was showing earlier, sort of gives an idea of what's going on. Here are, here's Search Party running on the machine. And here are a whole bunch of repositories that it might want to get access to. Search Party allows you to do federated search across multiple resources. And it's a great way to get access to multiple repositories and bring back the content into your Mac OS X environment. Well, gosh, there's lots of those things.

Through the plug-in model and the ability through the OSes to actually load multiple implementations into a single app at any one time, we've helped make this easier for Search Party. So in this diagram you see there's a plug-in I call SRW. That's actually using the Search and Retrieve Web Service standard, which allows us actually to plug into a number of repositories that support that standard. And we can do that all do. There's a product called Harvest Road Hive.

Harvest Road, you saw, was one of the Sakai partners. The Hive is a repository product. Harvest Road's a company in Perth, Australia. It's a real nice product. And we wanted to plug that in. In fact, Mac education, the Mac learning environment folks were starting to talk to Harvest Road as they did Search Party. And there's others.

There's the Fedora Digital Repository System, which is a library system. Open source that's been created. There's a company in Italy called Junty Interactive Labs that has another learning object repository product. And the idea was, you know, if we could start building plug-ins for these things, we could make the life of an app like Search Party much easier. And really put the hands of integration into the end user. I just want to be able to get the plug-in, install it like I'd install a printer driver, and just have it work.

The story gets more interesting as you bring more apps into play. There's a tool that will not be shipping with Sakai 2.0, but we hope to ship with something like Sakai 2.1 or a fairly immediate release. A tool currently codenamed Twin Peaks. I don't know if it will be called that in the end. But Twin Peaks is really the same kind of thing, but for Sakai. It's a tool that allows you to search across various repositories of content and bring those into your Sakai environment.

What we can do with the O-sids is As a system administrator, you can grab the same plug-in, the same basic jar, and bring it into the Sakai environment to drive Twin Peaks, the same one that you'd use to bring into a Mac OS X environment to drive Search Party. So we're really trying to, with the OSIS, to have a model where we can have that kind of choice and that kind of flexibility. If we go back to Demo 3... Demo 3.

Thank you very much. First thing I'm going to show is Search Party. This is it. Like I say, it's sort of an early release. It's pretty nice as it is, but there's a lot of ideas we have to make it even better. It's a slick little Cocoa app that allows you to load in repositories. There's sort of four loaded in here.

And to basically search across them to find content. The four we have, two actually exist at MIT, part of the Visualizing Cultures project, which is really a growing collection of art images from mid-1800s and late-1800s Japan for teaching history. The other two are plug-ins that we got from Harvest Road themselves, hitting against two demo sites actually in Perth, Australia, that we hope are running right now.

So we can do the demo. The thing about the Harvest Road sites is they kind of gave us two sites with identical content. One nice thing I can do here is I can disable one. Otherwise, we'll do the search, and we'll get multiple versions of the stuff. So I'm just going to search across these three, and we'll try something.

I don't think it did yet, but we'll see. I guess I downloaded a lot of these Maverick images already. Oh well, maybe it did show up, I just didn't notice. But I can click on one here, I can show it in the finder at this point. You can imagine this app being able to send these things off to the various iLife and iWork type apps that might want to have access to this content.

There's a little helicopter image. Let's see if this is, I thought I had... Huh, I thought I had three in there already. But anyway, you get the idea. So SearchPro is a nice little app. Scott can probably talk a little more about the Mac learning environments plans for this app, but they want to certainly move it forward under an open source community through the Mac learning environment community.

I'm going to show one more demonstration that ties this session together, I hope. You should recognize this. It's actually, I'm running Sakai version 1.5.1 here. I didn't have access to the cool new one. There's a project that I mentioned earlier called Twin Peaks. It was developed at Indiana University.

And it's a little UI widget that allows you to go in and populate various things in Sakai with content from an external source. And I have it running. I've created a little Sakai site here, a little OKI 101 worksite with an announcements tool. I could have added more tools. I just added an announcements tool to it.

And I can, I have one announcement in here called test. I can add a new announcement called another test. And I can write some things like this is a test. And let's say I wanted this announcement to include content from an external source. And I can write some things like this is a test. And let's say I wanted this announcement to include content from an external source. And I can write some things like this is a test. And let's say I wanted this announcement to include content from an external source.

Well, what Indiana did with Twin Peaks is they created a little widget here, a little icon I can click on. Well, what Indiana did with Twin Peaks is they created a little widget here, a little icon I can click on. But basically it brings up, and we need to pretty this up a little bit, but it brings up a search window.

And it allows me to choose from a number of sources, which you may not be able to read in the back, but they include some of the ones we've already been looking at, like the Harvest Road Hive. So I can use that, and I can do a search. Let's see, what did I do the search for earlier? WAVE.

and let this go. And again, the point here, this is the exact same plug-in that resulted in that Harvest Road repository choice showing up in that menu item. And that this Twin Peaks tool is now going and somewhat slowly doing a search, again, to the same Harvest Road repository in Perth, Australia. And if we're lucky, it'll come up pretty soon. The network's been a little slow around here, and who knows what's happening in Australia.

And this brings up a nice little, what we call, lightbox view that allows you to sort of choose from thumbnail images of these various things. And I think this might have been the one I got earlier. I can add this content now, and I can go and I can post.

This announcement, and when I look at it, it brings it up and it says, here's the message, this is a test. You can click here to get to the Mavericks image, and it just works. That's the exact same mechanism going on the back, using OSI interface, talking to the repository.

So the plug-in model we think is really powerful, and what we're showing here is that it's working in two very different kinds of apps. One's a Cocoa app, happens to be talking to Java VM, but it's a Cocoa app running on a client. One is a web app running off a web server. So there you go. Let's go back to the slides, and we'll finish up.

So, let's quickly talk about some of the adoption issues. First of all, we think the OSIDs, as you can imagine, have a lot of value for developers, both commercial and non-commercial. They really begin to define some critical pieces of service-oriented architecture specifications that allow for these kinds of interoperability that you're seeing. We're trying to help developers factor products. I mean, Sakai is a really good example of a system that's factoring itself pretty much along the OKI model.

To prepare itself for this kind of enterprise integration, integration with other kinds of services. It's important, we think, especially for the vendor community, and even for the open source community, to begin to think about how the products are going to fit into existing infrastructure, existing services that customers might have.

Obviously, a lot about integration going on here. We're trying to encourage an environment. Through this marketplace we're talking about, to reduce the coupling between components. So, again, if you can go out and buy a product off the shelf and bring it into your enterprise environment, just have it work, right? That's what we want. And, of course, code reuse.

Chuck talked about it. It's really important to us, especially with small development teams, that we can reuse as much of this stuff as possible. And these specs help us to do some of that. For institutions, if you're from an institution here, you know, a lot of people are thinking about what is the e-learning infrastructure. Typically, you start out with a set of apps that tend to be your infrastructure. At places like Michigan and MIT and Stanford, we've been building infrastructure for years. Not four years, but for many years. And, you know, we've learned a lot.

And the OSITs help us to define a service-oriented approach to these kinds of things. We're finding it's really easy with this model to begin to scope projects. Who are you going to put on various tasks? Chuck mentioned this as well. You need to write an implementation against enterprise infrastructure.

You need to write a tool, right? What are the pieces of those things? What can the tool developer just not have to worry about because it's being taken care of by infrastructure? Call the OSIT and it just works. We've already seen some people generating RFPs based on this. You know, you can really become much more particular with vendors.

You know, what is it your product needs to support? Why don't you support this OSIT if you're going to integrate in our environment? That kind of thing. And, obviously, one of the original things, you know, how do you open a path for multiple products in the environment? LMSs and collaborative learning environments are great, but they're one piece of a larger picture. We want to bring all kinds of apps into our educational environments that just work together and to serve various kinds of purposes.