LMOS Services and Service Brokers, Part I

One of the most important concepts in the LMOS Project Vision and Mission Statements is the service broker. In fact, it may very well be the most important concept. But it can be a little abstract, especially for non-technologists (like me). In the next couple of posts, I’m going to do my best to explain what it is and why it could make a very big difference in the evolution of learning management systems.

Have you ever stopped to notice that you can copy stuff (usually text) from just about any application on your computer and paste it into just about any other application? Whether you use Windows, Mac, or Linux, cut, copy, and paste are pretty much universal operations. In fact, it’s so omnipresent that, on the very rare occasion when it doesn’t work, it’s really annoying. We just take it for granted that it will work. We even take for granted that it’s smart–that it knows the difference between copying text, copying an image, and copying a spreadsheet, for example.

How did the creators of the various operating systems get cut/copy/paste to work with all those different applications? Did they convince every single application creator to write special routines into their programs that “integrate” their software with other applications? If I wrote a new email client and got the copy/paste to work with a word processor, would I have to write more code to get it to also work with a spreadsheet?

Not freakin’ likely.

Cut, copy, and paste are services provided by the operating system to applications that run on it. The “clipboard” (or “pasteboard,” or whatever it’s called in your particular operating system) is an application that provides functionality automagically (or pretty nearly so) to every application. Developers don’t really have to think about adding it, and they certainly don’t have to think about adding cut/copy/paste code once for every other application on the machine. If they did, then…well…we’d probably be doing a lot less cutting, copying, and pasting.

The clipboard is an invisible application, but visible ones provide services too. For example, in Windows XP, I can right-click on a file and “send to email recipient”, i.e., I can email it. My email client does that, obviously. And it’s smart, too. If I right-click on a web page in my browser insteade of on file on my desktop, the option I get is to “send link…”. It knows that it has to do something different with a web page on the internet than it does with a file on my desk. And if I change my browser, I can still use that function in the new browser. Automagic.

A little closer to home, Moodle has some features that work like services. For example, you can apply filters to any text input field that uses the HTML editor. With these filters, you can do things like the following:

• Have the system automagically hyperlink words to their corresponding glossary entries if they are in the glossary.
• Automagically link to resources, activities, or wiki pages that have the same title as the words you are typing.
• Automagically embed a Flash or Quicktime player when the appropriate media file is added.
• Automagically filter out dirty words.
• Automagicallyconvert TeX markup to mathematical expressions.

There’s a lot of automagic going on here. But the biggest automagic trick of all is that developers who create new Moodle tools don’t have to do a lot of work to get all the power of the filters. If they use text input fields that have the HTML editor, they will automagically (or nearly so) get these services in their tools.

Notice, too, that the developer who creates a particular filter doesn’t need to know anything about the applications that will use it other than that they use the HTML editor. This is critical. The more that the developers of the different components have to coordinate in advance, the less likely it will be that the services will ever get wired up.

Let’s look at a concrete example from the LMS world. At the SUNY Learning Network, one of the things that we like about our current home-grown LMS is that instructors can grade and comment on discussion posts. It enables faculty to give much richer assessment and feedback on very fine-grained student participation. (Some faculty members construct rubrics to show students what constitutes a good discussion post and how their posts will be evaluated.) Anyway, WebCT just added this feature to CE and Vista 6.

Why did it take them so long? They’ve had a grade book for quite some time. Theoretically, any student contribution to the class should be capable of receiving an evaluative comment and a grade, regardless of what LMS tool the student happened to use in order to make that contribution. The problem is that WebCT, like every other LMS that I know of, requires developers to write specific code to connect their application to the grade book. So, for example, even though discussion posts are now gradeable, if somebody were to add a blogging application to WebCT tomorrow, and they wanted blog posts to be gradeable, they too would have to write special code linking their application to the grade book. Wouldn’t it be better if every student-contributed item to a class could automagically gain the capability to receive a grade and an evaluative comment?

It is possible to build a system this way. In fact, it is possible to build a system with services everywhere. Automagic oozing from every crevice. But all that oozing can get messy. So to keep the ooze from mucking up the works, you need some sort of…(I’m about to stretch this analogy beyond the bounds of all reason)…an ooze plumbing system. If there are services everywhere, then you need a service broker. In my next post, I’ll describe how a service broker might work in the LMOS.