This post is part of a series on the concept of a Learning Management Operating System.
In my last few posts, I argued that accommodating niche learning applications is an important part of the next wave of LMS design, pointed to Google Maps as an example of a niche application that’s designed to be easily integratable, and pointed to Apple Dashboard as an example of a framework for integrating niche applications. Now I’d like dispense with the analogy and talk about the correct foundation for an LMOS integration framework: the portal.If you want to experience a modern portal is from a user’s perspective, just go to My Yahoo!. You’ll see a bunch of boxes on the page–one with your stock quotes, one with your weather, one to look up phone numbers, and so on. In other words, each box is a window into an application, much like a Dashboard widget. You can rearrange the boxes on the screen, add new ones, take old ones down, and sometimes even configure preferences for particular boxes.
Now, when you’re building a platform for which you want developers to create applications (like either Dashboard or a portal), you want integration to be as easy as possible (lowering the barrier for entry) and you also want, whenever possible, to use industry standards, so that you’re not asking developers to learn skills that won’t be useful for any other purpose. In the case of portal applications, there are two relatively new standards that aim to accomplish these goals. To begin with, there’s the Java community’s JSR-168, or “portlet” standard. JSR-168 is a standard for integrating applications into those little boxes, or portlets, on your portal pages. Because a wide range of portal products–including FOSS projects like Liferay and Apache’s Jetspeed as well as closed source products such as IBM’s Websphere and Oracle’s 9i Portal–support JSR-168, developers can build portlets for one and know that they will be able to run on a wide range of portal platforms. JSR-168 is also intended to make it easy for developers to create portlets using the tools and styles with which they are most comfortable, starting with the trivially easy. If all you need to do is put a page in an iFrame, you can do that with JSR-168 very easily. Likewise, it’s trivial to display one or more RSS feeds. If you need to do something more elaborate, you can write portlets using Java servlets, JSPs, or XML/XSL. You can even build portlets using PHP or Perl if you so desire. There are also small but growing collections of FOSS and closed source JSR-168 portlets that you add to your portal, like the ones here, here, here, here, here, and here.
If you can’t find an existing JSR-168 portlet that does the job for you and none of the JSR-168 development options suits your fancy, then you can draw on a second portal standard, called WSRP. WSRP is a standard for building a portlet using XML. It can be written in pretty much any programming language, and the portlet application doesn’t have to be hosted on the same server as the portal itself. So, for example, you could run a .NET portlet in a Java portal using WSRP. Many of the Java portals that support JSR-168 also support WSRP.
So, to my mind, the heart of an LMOS should be a JSR-168- and WSRP-compliant portal, because it can accommodate the long tail of learning applications through ease of integration.
Now, a couple of caveats. First, just because one can technically integrate portlets written in many different languages into a common portal doesn’t mean that you should. There are practical limitations in terms of performance and support. I’ll address some of these considerations in a post some time down the line. For now, the main thing is to remember that great flexibility is not the same as infinite flexibility. Second, having a My Yahoo! equivalent with a bunch of learning applications does not, by itself, make for a decent LMOS. You’re going to need to integrate some of the applications with each other, you’re going to need some more system-wide behaviors in place, and you’re going to need to enforce at least some common interface conventions. That said, I believe that these challenges–particularly the level of inter-application integration required–are often over-estimated. I will argue over the next few posts that it is possible to create a seamless learning environment in which there are only a few, fairly loose points of integration. This will be essential if we are going to break up the monolithic LMS.