In a (relatively) recent post, I started to outline how a service broker mechanism could greatly increase the pace of innovation in LMS design. The basic idea was that individual applications in the system could provide services that other applications could automagically pick up on, without requiring developers to wire up integration individually every time. In this post, I’m going to illustrate how such a beast might work, using the example of adding a blog to a Learning Management Operating System.
Let’s imagine that we’re taking a relatively generic weblog application and adding it to the LMS environment. Each student would get her own personal blog–not within each course, but one personal weblog per student that stays with that student throughout her college career. Naturally, the weblog would have an RSS feed.
Now, it turns out that RSS feeds carry quite a bit of information that could be useful in a learning context. Here’s a list of just a small subset of the information available from my RSS feed, for example:
- The URL of my blog’s home page
- The ID of the blog’s author (in my case, it gives my email address as my ID)
- The software application that generated the posts
- The URL, title, description, contents, time stamp and category labels for each post
Notice two things about this data. First, it’s very generic and could be useful information about just about any content online. Second, the post-specific information (in the last bullet point) is pretty much exactly what you need to know about any assignment that a student submits for a class.
In order to start making use of this data in the context of an LMOS, the blog developer need only make a few relatively minor technical enhancements in order to plug into the service broker:
- Write an adapter that enables the RSS feed to talk to the broker. (Since RSS is a very common format, chances are good that such an adapter would already exist.)
- Tie the blog into the single sign-on mechanism, so that the LMOS knows that the person that owns a particular blog is also, say, a student in the Psychology 101 class.
- Extend the blog to be able to subscribe to category labels that are related to the groups to which the student belongs (e.g., the Psych 101 student should see a “Psych 101” category tag show up in her post category list).
Now we’re ready for some service broker automagic. Let’s say the student decides to write a blog post on a topic related to her Psych 101 class. As she writes her post, she looks over to the category list. Because the system knows that she is a registered student in Psych 101, it automatically adds “Psych 101” to her category list. She selects the appropriate category heading(s), writes her post, and publishes. The service broker, seeing that the content is labeled “Psych 101”, announces to all the applications within the Psych 101 course environment that it has some student-created content. “Can any of you applications do anything with this student-created content?” it asks.
It gets the following responses:
- The class RSS aggregator responds, “Yeah, I can do something with it.” It takes the student’s post and publishes it along with those of the other students in the class.
- The course activity tracker says, “Me too. Gimme some of that.” It notes the student ID, the time stamp, and the title and URL of the post. Using this information it adds an entry for the student’s class activity on that particular date.
- The grade gook says, “I can also use that.” Noting that the content is generated by the weblog application, it pulls the post text and URL into the student’s row in the gradebook under the “weblog entries” heading. The instructor can now assign a grade and comment to it.
Notice that the weblog developer didn’t have to write separate integration code for course activity tracker and grade book. The service broker was able to integrate the new application on-the-fly because the blog publishes the basic required knowledge in a standard format. All the blog developer had to do was write a connector that picks up the categories from the system and works with its single sign-on mechanism. The broker does the rest. It would be the same for any other application, too. You could, for example, use more or less the same mechanism to integrate your discussion board with the grade book and the course activity tracker.
But wait. There’s more.
Suppose we make one more minor enhancement. Suppose that individual applications within the course environment could publish categories to share with each other. Suppose, for example, that the grade book could publish a category corresponding to a particular assignment. Our student could select that particular assignment category for her post and the instructor would automagically have it show up in the appropriate grade book column, with the appropriate point scale and weighting, and so on. Let’s imagine, too, that you could set your discussion board to generate a forum topic for particular category (such as the assignment heading in the grade book) and generate a new thread for each post that comes in labeled with that category. Students could continue to post to their personal blogs that travel with them beyond the class, but the instructor could also create class-internal discussions based on those posts. This is all done using fairly generic mechanisms, so developers creating new applications won’t need to do anything special to integrate their new wiki, or simulation, or flux capacitor, or whatever with individual applications already in the course environment.
But wait. There’s still more.
Suppose that, in addition to having students publish information into the course, the service broker also let the course publish information out to the student’s personal data store (read “portfolio”). Imagine that for every content item that the student creates and owns in her personal area–blog posts, assignment drafts in her online file storage, etc.–there is also a data store to which courses could publish metadata. For example, the grade book, having recorded a grade and a comment about the student’s blog post, could push that information (along with the post’s URL as an identifier) back out to the student’s data store. Now the student has her professor’s grade and comment (in read-only format, of course), traveling with her long after the system administrator closed an archived the Psych 101 course. She can publish that information to her public e-portfolio, or not, as she pleases.
So a service broker can greatly increase the pace of innovation in LMS design by greatly increasing the ease with which new applications can be deeply integrated with the rest of the learning environment. If you add in a portal for unified display capabilities, you have your Learning Management Operating System.
Ah, I think I’m understanding you better now. The key to the functionality you describe here sounds more like a “Bus” than just a “Broker” to me. The “Broker” would be registering the services (e.g. grade book) for tools to use. The “Bus” carries the signals between services.
I know how to do brokers, the bus will be interesting to discuss.
Yes, I think “bus” is actually the right idea. I’m not the technologist of the crew, but I believe that the technologists at SLN who are working on this are looking at ESB (enterprise service busses) and possibly JBI (Java business integration)to do this work.
You are basically talking about a Service Oriented Architecture. The idea of a SOA is to have commonly understood messages that are then passed along to the applications. The broker doesn’t care what the app does with the mesage, just that is accepts such messages. The idea is that all of the seperate applications are coordinated through the messages.
In your example, the blogging software may create a “Course posting” message. When the instructor has graded the post the gradebook would create a “Graded Assignment” message that would find its way back to the student. The cool thing is that anything that can create or receive the messages can be part of the system. There is no need to replumb everything if you switch your blogging software just make it create and accept the proper messages. The student could use anything (email, cell phone, smoke signals) that can create the Course Posting message to submit her posting.
How the messages are structured or sent/received is immaterial. The secret to SOA is the use of messages to coordinate the applications.
This is kind of how I want to integrate dotLRN (LMS) and dotFOLIO (e-portfolio). A student can participate in the forums in their LMS, an aggregation of these postings can then be represented in an RSS feed, and referenced by the e-portfolio. In fact the search package in OpenACS automagically generates RSS feeds for search results. So a student can search for specific terms, and the results of the search on content they own can be aggregated into a RSS feed.
On a slightly related topic, I have just finished a trial of dotfolio, and found that the openness of blogs allowed for a lot of plagiarism to occur. Fortunately I share a room with a colleague that is developing a text mining framework. We were able to pass all the blog entries into his application and work out which blogs had been plagiarised. The techniques we used meant we were able to find every case of plagiarism. We believe that if we can integrate this into dotfolio, we’ll be able to detect plagiarism as soon as the student submits their posting. This almost real-time detection and response will probably deter students copying off other students, and so we won’t have to resort to drastic changes such as closing the system so that students can’t read other students’ blogs… especially when the blogs are related to an assessment.
The text mining approach is really interesting, and not solely because it helps with the plagiarism problem. Presumably, some faculty members would like to be able to recognize and reward legitimate quoting as a way of encouraging student-to-student interaction. With the text mining tool, that would be easier to track. Does the quoted text have a hyperlink back to the source? If yes, it’s a quote and should be rewarded. If no, it may be plagiarism and should be investigated. You could even publish a “meme propagation” graph to the students, showing how successful they have been at getting other students to legitimately quote them. And, of course, it would be useful for research purposes to look at what teaching techniques and what user interface changes encourage student quoting (whether proper or improper). You could, for example, do a study like this one.
I’ve started an experiment using RSS as away of distributing messages in a SOA. I’m mostly concerned about RSS being a fire and forget protocol with no way of knowing if the other systems got the message. Should I even care?
I could set up an acknowledgement system using comments, but that feels very kludgy.
Any comments?