OK, so Stephen Downes doesn’t like the LMOS:
I have been sort of sympathetic to the concept of the learningmanagement operating system (LMOS) because, after all, the concept includes things that I favour: distributed resources, user access to the underlying system. But I began to falter when Mark Feldstein said “We don’t just want to offer many different affordances. we want to orchestrate them.” And following his link to Bernie Durfee has sketched out a first use case implementation sent me over the edge. I’ll say it bluntly, and apologize later: this is the most ridiculous thing I’ve seen. Durfee is describing what the rest of understand as ‘upload a file and base a discussion thread on it’. Something I did right here in about 10 seconds today. But he requires J2EE containers, portlet containers, service integration agents, native Java interfaces, a whole mess of stuff. Ridiculous. Absurd! That’s it – if that is what is meant, toast the whole LMOS concept.
I’m going to ignore the fact that he got my first name wrong. Frankly, I think language like “ridiculous” and “absurd” is unnecessarily hyperbolic when used in reference to a plan that simply articulates a language-specific implementation of fairly widely established standards for enterprise systems in general and enterprise learning frameworks in particular. It’s also not terribly collegial or respectful. And finally, it doesn’t reflect a grasp of the problems we are trying to solve.SUNY has 64 campuses with 414,000 students. If we web-enhance every face-to-face class on all 64 campuses, that comes to supporting a total of 3.2 million enrollments annually–not even counting fully online classes. Somebody has to provision all of those courses from a server, make sure it all scales, and support all of those applications. If you really want all your faculty to be empowered to dive into blended and online learning, you need to be able to support and automate your processes.
You also need to be able to customize the environment in a sustainable way. Bernie Durfee understands these challenges very well, since he was one of the early architects on the uPortal project. The broad questions we are looking to answer with LMOS are as follows:
- How can we create a system in which we can add a tool and have all other tools in the system automatically integrate with it? (And please don’t tell me that everything can be done with RSS.)
- How can we support a broad array of tools backed by a broad array of standards–current and future–with one architecture that will allow all of them to be plugged in interchangeably?
- How can we accomplish all this while being able to support a few hundred thousand students?
Those are hard challenges. Hard enough to require a reasonably complex architecture. Bernie addresses this complexity by pushing for web standards like WSDL that are precisely designed to make complex interoperability challenges as simple as possible–but no simpler.
And if Stephen is shocked by the nature of Bernie’s solution, then he frankly hasn’t been paying attention. Because Bernie basically took JISC’s widely touted e-Learning Framework, identified a few missing pieces, and described how it could actually be implemented in Java:
The ELF is nothing more than a very, very, very high level good idea. The LMOS takes that good idea and makes a real framework out of it. This picture needs to have wheels put on it so people can drive it around. It needs to have a real implementation, such as in Java to create a JELF.
A JELF would look like exactly like the ELF, but there would need to be specific interfaces declared for each service.
I’m not sure why Stephen would find this approach “ridiculous” or “absurd”, but I am surprised and disappointed by his tone. Stephen is always direct, but he’s crossed over the line from direct to insulting. If he wants to debate the merits of the LMOS constructively, then let him propose an alternative design. Ad hominem attacks are not worthy of him.
So yes, Stephen, I think you owe somebody an apology. But not me.
G’day Michael,
I think I’m going to have to side with Stephen. With a nod, however, that your comments re: the language he used isn’t that conducive to discussion.
The argument looks like the standard one between the supporters of the fair ends of various spectrums
– agile versus plan-driven
– LAMP versus Java
– bottom-up versus top-down
– ateleological versus teleological
I generally fall into the former and my PhD work indicates this.
My main belief around why the Java/complex architecture approach will not work that well is that organisations, and especially Universities and e-learning, are non-deterministic.
No matter how complex a technical architecture you have technical artifacts are deterministic.
Technical artifacts can only ever hope to support non-deterministic activities effectively if they are able to be changed really fast.
Supporting people to use the system is easy compared to being able to keep changing the system to reflect what they want to do.
That’s why I think the ateleological approach will work better.
For example, take a look at the recent posting that circulated in the blogosphere comparing the uptake of Moodle versus Sakai.
Of course, this is all my opinion. Don’t have any real proof.
david.
David, your point regarding complexity is well taken. In fact, the LMOS was designed precisely to encourage bottom-up, non-deterministic evolution of learning environments. (And ironically, the original post which Stephen criticized but never directly addressed was in praise of mashups.) But if you want to judge whether the LMOS proposed design is overly complex, I think you need to look a little deeper into the details of the architecture and the specific problems we are trying to solve.
To begin with, let’s ask and answer the question, “complexity for whom?” Who needs to deal with the LMOS architecture, at what level, and for what purposes? Having raised the question, let me lay it aside for just a moment and ask another one. What programming language does Google use to develop Google Maps? What does their architecture look like? What’s the architecture of Flickr? Truthfully, I don’t know and I don’t care. I don’t have to care. Because there is a very low barrier of entry to creating mashups with their applications. The fact that there are (at the most conservative estimate) close to a thousand public mashups of Google Maps within six months of the APIs being released is testament to the fact that web services are critical. And if you’re developing an application for the LMOS, it’s all about web services. You don’t have to know Java or JBI. Want to write your LMOS app in PHP? Go to town! You just need to know –at most–a couple of web services interoperability standards. If you’re lucky and you can use a well-established standard like RSS without having to build a specialized UI, then just use RSS. It’s that simple. If you want to have a specialized display or use a less ubiquitous standard then you might need to learn WSRP or WSDL. The tools are there, but you only need to learn as many as will be useful to you. And the Java implementation is hidden from you unless you don’t want it to be hidden.
Second, there is a kind of complexity that happens when simple architectures try to scale to handle complex problems. In our case, we believe that the number of learning applications appropriate for a learning environment are about to explode exponentially. If you believe that to be true, and if you also believe that these applications will often need to talk to each other, then you need to worry about the number of integration points exploding at an even faster exponential rate. If you start with one application in your environment and add another, you have at most one integration point. But if you have ten applications, you could have up to ten factorial integration points. And so on. That’s just not sustainable.
Much of the complexity that Stephen complained about was designed precisely to address this problem and the drag it places on the pace of evolution of learning environments. Sure it would be possible to integrate a content repository, a discussion board, and an announcements app a lot easier than the way that Bernie proposes, but how much work is involved with adding a fourth app? And how much work is involved with swapping in a different content repository when you find a better one? Once you reach a certain number of integration points, the least complex architecture is the one that requires the least work per integration point.
We recognize that we’re trading one kind of complexity for another, and that the trade-off isn’t the right one for everyone. Moodle is a ripping success precisely because it is simple down to the core. But Moodle isn’t our model. Google Maps and Flickr are our model. We imagine the LMOS will have far fewer installations than Moodle but potentially support just as many teachers and students. And we hope to provide unprecedented evolvability in the process, at the expense of more complexity in the core. The gamble is that the vast majority of evolutionary changes won’t require changes to or even knowledge of that core.
Finally, let’s understand what the LMOS really is intended to be. It’s intended to be a set of fleshed out standards and a reference model. The reference model happens to be designed in Java, partly because Java fit well with the institutional needs of the developers and partly because we believed there was a shorter path to implementation due to a large number of usable existing pieces in projects like uPortal and Sakai. But if don’t like JELF and would rather have PHPELF, be our guest. We hope that the work we do in hammering out standards and finding architectural sticking points will still be useful to you.
Michael,
You have raised a number of points well worth exploring and debating. But I wonder whether your all around “flogging” of LMSs is quite fair.
For example, in “Unbolting the Chairs” you make a quite a bit of the fecundity of extensions built on the Google API compared to the Blackboard API. Based on the example, you would have us draw the conclusion that Google’s architecture is good and Blackboard’s architecture is bad. Google mashup is flexible and Blackboard architecture is bolted down and inflexible. Is this a fair comparison though?
Mashups like Google Maps are attractive and invite extensions because they make available *content* freely to the world. But that’s hardly the point of a production LMS. If you lay out content candy for the world to consume, why are we surprised that people find all kinds of ingenious ways to do just that? LMS developers have the opposite problem to contend with, namely that content needs to be protected and doesn’t get out beyond the local context. Content re-use tends to be secondary.
Al, I believe that I originally stated that I was “flogging” the LMOS, meaning promoting it, rather than “flogging” the LMS’s, meaning beating them about the head and neck. I also would hope that the article doesn’t come across as simply as “Blackboard bad, Google good.” If we have to be that simplistic (and I hope we don’t), I would boil it down to “closed, heavy APIs bad, tinkerability good”.
I also disagree with the assertion that mashups are attractive solely because of the content that they provide. If you look at many of the web 2.0 apps–del.icio.us, Flickr, 43 things, and so on–many of them provide no content at all inherently, relying on users to supply that content. Rather, what’s attractive about these apps is that it’s easy to do things with content.
So yes, I think the comparison is fair. You can provide all of the flexibility of the Web 2.0 stuff and still provide adequately for student privacy and for copyright protection.
Michael, I am not sure conceptually what problem or set of problems the LMOS is trying to solve. To say that we want the ability to “tinker” and we “flexibility” remains too abstract. Of course, you will point me to examples like flickr, del.icio.us, etc. to make it concrete.
But the analogy is stretched for a number of reasons. Take an application like flickr. It’s success is dependent first on the fact that it solves a concrete problem very well, namely the desire among users to organize their photographs. If it didn’t do that well, none of the other fancy things would matter. The flickr team also understands good design and usability, a concept that most of the LMS folks, including .LRN, struggle with
The problem with LMOS concept, it seems to me, is that you are asking for an infinitely flexible and malleable system that can be adapted to suit an arbitrary instructor’s teaching style. That ain’t realistic. Most faculty I think want predictability and reliability first. There is the boring aspects associated with a course management system. And most of us have delivered on that.
Good APIs should allow someone to extend the system. I can point to a number of innovative pedagogical applications that have been built with .LRN. I am sure that Blackboard, WebCT, Moodle can give you their examples. The same will follow with Sakai.
I guess I would benefit from a clearer statement of what the ideal LMS is supposed to look like. We can call it your LMOS. The statement of the ideal should be independent, at first cut, of technologies. And then let’s start evaluating existing LMS against that standard. I know that is your aim and I support it. I need to read your postings more carefully.
I would also urge that your site have trackback capability. I notice that Stephen Downes has commented on your comment but I discovered it only accidentally. I mean if all this mashup stuff is so cool, why can’t we (the pedagogic elite) carry on a simple distributed discussion?
As a co-founder of the LMOS project who co-wrote its Mission and Vision and a co-author of SUNY Learning Network’s Request for Public Comment from which the LMOS emerged, and as the Director of Technology of SUNY Learning Environments and Bernie Durfee’s supervisor, I guess I should chime in here. I have been leery of participating in Michael’s forum as I see his writing and the great discussions that follow as the first stage of our development process: analysis and requirements building.
It really doesn’t matter what process you follow, they all begin with scratching that personal itch. Well I don’t know how hairy Eric Raymond is, but considering the number of requests we get from Mark’s evil twin brother Michael Feldstein and his teaching and learning staff at SUNY, they’re a motley pack in desperate need of a flea bath.
But I wouldn’t have it any other way. I am a firm believer that, at this stage, designers should have the freedom to dream up any tool they can imagine without the hindrances of reality (costs, time, feasibility, viability scalability or even my ability). It seems to be the developers paradox, we either get requests for new tools or enhancements that are so vague that development can never satisfy the user, or even worse, a request for a predefined technology based on the latest “solution” masked as required functionality. Michael’s use case is neither.
In order to escape the above mentioned paradox of too vague vs. too specific, we require our user-developers to submit use cases. And Michael’s use case is definitely not: “upload a file and base a discussion thread on it.” For clarity, the use case is:
1. Faculty member uploads a digital artifact (Word document, PDF, movie, whatever) into an Alfresco folder called “Discussion Assignments.”
2. Faculty member fills in a metadata fields for the artifact called “Assignment Title” and “Assignment Description”.
3. Faculty member clicks “save” (or “submit,” or whatever).
4. An announcement appears in the Announcements portlet with the following information:
– The title “Discussion Assignment”
– The text from the “Assignment Description” metadata field
– A link to the artifact
– A link to the discussion thread
5. A new discussion thread is created with the following information in the parent post:
– The subject line of the post is the data from the “Assignment Title” field
– The body of the post is the data from the “Assignment Description” field
– The body also contains a link to the artifact.
In this use case Alfresco and the Announcements portlet are actually two different applications that, although presented to the end user through a common interface, actually have no idea one another exists. However, despite their disparity and separation, activities done in one application updates the other. This would be like dragging a word document into a directory/folder on your C drive/hard-drive and having a new table row with the name of that document appear in an Excel spreadsheet.
What all of this (the LMOS) is about is providing the same level of interoperability found within “enterprise” LMS’s without the direct and preconfigured/defined connections between tools/features/functionality/etc. The reason users can add an assignment to their courses in current commercial LMS’s and see them pop up in the grade book, the announcements and so on, is because those connections have been hard coded into the application by the programmers during development. In these applications, the content repository knows there is an announcements window and the developer has included a reporting feature in the functionality. But what happens if you add a new tool (if you even can)? If the original developer never accounted for that tool, then there really is no communication and thus interoperability between them. This is what the LMOS is specifically trying to address: allowing users to add disparate tools that do more than present together in one interface, they work together.
What an interesting discussion. Really makes my day here, although it is quite foggy outside!
I just want to make one quick remark on Alfred’s assertion “LMS developers have the opposite problem to contend with, namely that content needs to be protected and doesn’t get out beyond the local context. Content re-use tends to be secondary.”
Is it really? Do we have to protect content? Look at the number of beautiful pictures on Flickr that have Creative Commons licences on them. Why not choose that model for educational resources too! So i agree with Patrick: let’s think out of the box!!!!
Isn’t Sakai chasing the dream of modularity and inter-operability? How does it fall short architecturally?
“Do we have to protect content? Look at the number of beautiful pictures on Flickr that have Creative Commons licences on them. Why not choose that model for educational resources too! So i agree with Patrick: let’s think out of the box!!!!” –Wytze Koopal.
Wytze, you miss my point. I have nothing against open content. In fact I am a big advocate of both open source and open content. The point is that LMS application developers have to optimize the design from sets of requirements, some of which are at odds. For example, implementing generalized search on a completely “open” web site is relatively trivial compared to a site baesd on complex permissions. Suppose I am a member of four courses, four communities, and various subgroups within each. Implementing search in such a context is considerably more difficult. RSS is another example. Implementing a public RSS feed is relatively trivial compared to an authenticated feed that tracks multiple layers of permissioning.
G’day All,
Like Wytze I was going to question Alfred’s point about open content. But, it appears, that I also have misunderstood the point.
Alfred, I’m not sure your clarification has helped me fully appreciate your point, yet.
You mention that the LMS developer needs to fulfill the requirement based on “a site based on complex permissions”.
My first response was, if all the content is open then is there a need for complex permissions.
You then say “Suppose I am a member of four courses, four communities, and various subgroups within each. Implementing search in such a context is considerably more difficult”.
Okay, so maybe the problem is my understanding of permissions implying that access to content is limited as opposed to meaning information that has been identified as of interest to particular groupings.
Based on my, which I’m sure is severely limited, understanding I can see any number of technical approaches that aren’t that difficult (depending on how the content is implemented).
e.g. With tagging and all content being open, assume all the information of interest to my groups has a specific tag. Use the simple open search and then apply a filter to return only information with the appropriate tags.
Obviously, I must be missing something.
David.
To begin with, I am not a member of the “pedagogic elite.” How could I be? I don’t teach anymore. My job is to suppot the pedagogic elite, along with the pedagogic not-so-elite.
As Patrick points out, our first use case in the LMOS wiki is pretty concrete. Here’s a second and a third. For a more complete account of the concept and value propositions of e-Learning Frameworks (of which the LMOS is one possible instantiation), see this white paper [PDF} from JISC.
Yes, it’s true that groups and permissions makes the challenge tougher. But there is a lot of work being done on just this problem in portal, SOA, and federated identity project communities. This is a solvable problem.
David, there are lots of reasons why you may need to keep contents of a class or group behind a login. First, there are privacy and confidentiality issues. Sometimes it is necessary and appropriate to give community members safe, private areas to collaborate where they know who will and will not be able to see their contributions.
Beyond that, as much as we all would like to see more Open content, the fact of the matter is that we cannot mandate copyrighted content out of the classroom by fiat. (At leat, I can’t at my institution.) As long as faculty members want to use copyrighted content, we need to provide affordances that enable them to do so legally.
Regarding the differences between LMOS and Sakai, Bernie writes in the wiki:
Sakai created its own APIs, while the LMOS aspires to use standards–and in particular, non e-learning-specific standards, wherever possible. LMOS also places a heavier emphasis on web services than the current generation of Sakai.
I still don’t understand what an LMOS is.
Can you provide a “high-level” conceptual diagram of an LMOS and then contrast that with what you call a monolithic LMS. By high-level I mean a diagram that you would draw on a napkin. It should delineate the principal elements of the architecture and the relevant interactions between them.
Just to motivate further discussion let me present a highly simplified overview of the OpenACS/.LRN architecture. The core platform consists of three layers:
# Infrastructure is the very low-level engine – this is where database-connections, data-persistence, and logging is handled. This is also where requests are processed and sent on to the appropriate components, language (locale) is determined, and templates are applied.
# The Kernel takes care of critical tasks such as logins, permissioning, and access control. It also keeps track of users, groups, content, and the inter-relations between all objects in the system. For lot of day-to-day administration, the Kernel is where you work – through a control-panel you set permissions, activate applications and so on.
# Services. Through simple APIs you access to functionality like versioning, mail, search, categorization, auditing and more. These are mainly used by developers, building applications on top of the Core, and applications such as .LRN.
I don’t see any reason why we can’t accomodate the “use cases” you have in mind. We have blogs, we have wikis. If you want to create a “web 2.0” app we can do it with this architecture. Name it, we can do it.
Can I swap out the dotLRN discussion board and put in a different one? If so, how much work is involved to get the new discussion board to integrate in all the same ways that the existing one does? Does it just require configuration, or do you have to rewire all the integration points? And does it have to be written in TCL, or can it be written in any language?
That’s the difference. Clean, standard interfaces defined for all major applications. If you read the eLF documation that JISC has out, it’s pretty clear. I’m not going to sketch it out; JISC and Bernie have both done far better jobs at it already than I ever could.
Could dotLRN be an LMOS? Sure. Is it one now? No.
Let’s fast forward. Suppose your LMOS is written. Can you swap in an arbitrary discussion forum (e.g. .LRN) at will into your LMOS. No way, right? Only ones that work according to your standard, right?
It’s trivial to achieve interoperability and plug-and-play if you get everyone to use YOUR standard. What’s different about the LMOS proposal than someone walking into a room, noticing that people are speaking various languages and then proposing that we all use Esperanto?
But, first, I have a healthy respect for markets. What is the incentive for developers (commercial & open source) to use your standard?
Secondly, isn’t this supposed to be what OKI + Sakai (in particular OKI) are all about. I still haven’t heard a good answer to this question. Aren’t they still promising inter-operability. That was the whole AIM of the project.
Michael,
I just want to state that my comments are not intended as criticisms. I am trying to understand the concepts involved. It’s a worthwhile discussion we all need to be having. Thanks for stimulating the discussion.
Al, no worries about misunderstanding your intentions. I generally don’t respond to comments that I perceive to be unproductive. That said, I would urge you to spend some time looking at the e-Learning Framework site and Bernie’s write-up in the wiki (referenced above), because they do get at the heart of some of the questions you’re raising.
The point is not to insist on “our” standard; that was the problem with Sakai. The point is to identify pre-existing standards wherever possible, and where none exist, foster the creation of new standards. For example, if you scroll down to the discussion on the bottom of this page, you’ll see a conversation about the degree to which the Atom standard would map to discussion board functionality. (The preliminary answer appears to be “pretty well.”) If it turns out to be adequate, then any discussion board that can translate its data and API calls to and from Atom could plug into the LMOS. This is precisely what Sakai didn’t do, most likely (at least in part) because they felt they couldn’t abandon the legacy CHEF code.
The incentive for participation by consumers (i.e., purchasing institutions) is that they have more granular control over their toolset. If you like Sakai overall but think that WebCT has a better discussion board, why shouldn’t you be able to license just the discussion board? Why shouldn’t WebCT be able to sell pieces rather than all-or-nothing? The result is increasing commodification of the infrastructure elements, which is never anything that the sellers want but is often something that buyers can demand. At the same time, it does allow market developers to specialize more in particular niche applications rather than feeling like they have to build ten mediocre learning applications just so that they can have a bundle to go with their one great one.
😉 I have been following this post with interest. I have also taken many of the comments made in response to your posting and placed them upon the Blackboard and Webct are One blog. Each comment has a link back to your site and I hope the conversation continues. I think it is one that is needed for the next generation of LMOS to be developed. The LMOS camps need to come together and share the best of all worlds. Keep up the great blog work.
Darren Cannell
Several random points.
1. I will read more about ELF etc. Nonetheless, it would be valuable to have 5-10 slides on the business case for LMOS. Most of the documents I have seen thus far are laced with jargon and mind numbing obscurity. One of the slides should address the effort involved. One month? Six months? Three years?
2. The concept needs to stand on its own independent of technology implementation. In other words, we should be able to realize it on a J2EE, LAMP, or .NET stack. My own prejudice is that Java implementations introduce an order of magnitude more complexity and cost. As an additional exercise, it would be helpful if someone could outline what an LMOS might look like using a LAMP stack.
3. The major commercial providers (Blackboard, WebCT) will never go for it, so the spine would have to be open source. I attended the Blackboard-WebCT town meeting. One of the comments by Carol Vallone (WebCT CEO) was very revealing. The question from the floor was whether the merger was prompted in part by open source pressures. Ms. Vallone replied that they welcome open source and she saw a lot of potential for open source applications using their APIs to hook into their base platform. Their business model is to control and continue to extend the spine so it reaches as deeply as possible into the enterprise.
You know, I scrawled about two pages of reply in longhand after reading Michael’s response to Stephen Downes, but when I thought about typing it in, I realized I’d need to expand it to something even _bigger_. And as we all know, sane scoping is an essential part of project management. 🙂
Regarding the more recent replies, a couple of points:
“Sakai” is not a monolith dropped from the hands of an iron giant, although its early design process may have given that impression. Primarily (as far as I’m concerned, anyway), it’s a way for developers and designers in “enterprise-sized” higher education to openly collaborate on open source software aimed at higher education.
Would you be surprised to learn that the majority of technical leaders from the Sakai core schools agreed last year that we should “identify pre-existing standards wherever possible” rather than insisting on Sakai-branded alternatives? Similarly, I think most of us would have agreed that it’s better to collaborate with existing successful projects than to start from scratch, and that it would be better to support LAMP applications than to rewrite them: Java programming is expensive and higher education is poor. If we need component support that Spring doesn’t give us, we could work with Spring; if we need portal support that uPortal doesn’t give us, we could work with uPortal; if we need database support that’s missing from JForum, we could help JForum development…. (Case in point: I saw yesterday that Unicon dealt with their need for a missing feature in Apache Tomcat by working with the Apache team to get it into Tomcat 5.5. The Sakai framework has the same need, but hacked it independently.)
Obviously, there’s been a gap between those goals and what’s been delivered, but that may be just a matter of growing-up-in-public pains. Anyway, as of this year, Sakai isn’t a closed-membership project where decisions are made in private. Either Sakai survives with open discussion and open contributions or it doesn’t survive at all. I hope some of your readers grab the chance to influence its future, because I’m afraid chances like this don’t come along very often.
(Feel free to trim this next part if it looks too much like spam, but some of the more technical types might be interested in my pitch for Loosely-Coupled Sakai development.)
I’m glad you jumped in here, Ray. As you point out, there’s no reason why Sakai couldn’t evolve to fit the vision of the LMOS, just as there’s no reason why dotLRN couldn’t. We were quite excited about signs of interest/movement in this direction–including but not limited to your presentation–at the Austin conference, as we were also excited by the encouraging responses that Chuck Severence and Vivian Sinou submitted to SUNY’s Request for Public Comment document.
I attended Ray’s presentation at Sakai Austin last December and he is right on the mark. Sakai had some real world issues to deal with, as campuses needed a fully featured LMS to migrate to while the Sakai “Core” needed some proof of concepts to get others interested. I fully recognize and applaud Sakai for its efforts, yes it wasn’t the ideal path and arguably worked against some of the tenants of open development (Core left a bad taste with many looking to participate early). But now with a change in gears, Sakai is in position to embrace the development activities like those at Cal have done with the grade book. After, again after, you read Ray’s “Loose Coupling” presentation, read Chuck Severance’s reply to the SLN Technology Strategy (http://le.suny.edu/sln/rpc/rsp/rpc_sakai.pdf). Both outline the need for “Tool Interoperability” based on open standards.
I am very happy to see Sakai (now with a base of code, users and developers) move this direction. I am also happy to see commercials like WebCT looking ahead. Those following the sakai.collab discussion probably have seen chatter about pulling in Sakai tools into WebCT and vise versa Powerlinks into Sakai. But this is NOT the LMOS project. IMS TI (or IMS TIR) does not address what the LMOS is all about tool to tool or tool to LMS interoperability. (The LMOS is interested in portlet to portlet and portlet to portal interoperability, but its really the same thing conceptually.) IMS TI is to an LMS what JSR-168 is to a portlet. Great a tool or portlet will display in the LMS or portal respectively, but having an aggregate view of tools isn’t enough. Any event or content that occurs in one tool/portlet that is relevant to another tool/portlet (again see the use case) should be passed.
Ray is spot on, the first hurdle to get where the LMOS wants to be is getting all the tools to present together, and his observation about working WITHIN communities is the best method. Our goals with the LMOS is not to fork any project, but to work with communities (Sakai, JASIG, MOODLE, eLF, etc.) to promote and develop deeper integration and interoperability based on common open standards. The LMOS is the next phase of integration development, not a replacement, allowing users to add disparate tools that do more than present together in one interface, they work together.
(Isn’t this how I ended my last post?)
This is a great discussion and I think it points out that we are all (or at least many of us) struggling a bit to understand the world with composable applications (a key tenet of Web 2.0).
I think the basic description of the need for a way to compose together and orchestrate components that will make up an overall learning solution is right on the mark.
However, I’m struggling a bit with your technical direction versus the direction that most of the Web 2.0 applications seem to be taking. It is very interesting (to me at least) that you are choosing Portlets, JSR-170, JSR-168 as your wrappers. Most of the Web 2.0 tools are going a very different way. Yes, its a complete mess right now. Yes, I have to figure out things like how do I get my group of learners integrated so that they can participate in a discussion, but the ease of composition in Web 2.0 is a HUGE factor in the rapid adoption.
I would also think that there is something in the middle here. If you build the LMOS as you indicate, couldn’t you still integrate and orchestrate with Web 2.0 applications? What would the complexity be there?
Tony, if it’s done right, the LMOS should provide the middle ground you’re asking for. (Let me put in my usual caveat here that I’m not a technologist, so take my technical explanations with a grain of salt.)
One of the goals of the Java Business Integration standard is to support supporting web services (and all the ease of development/evolution that comes with them)in an environment where you have a bazillion of these web services strung all over the place and you need to make a little order out of the chaos. In other words, it’s an attempt to enable entire systems based on web services.
Think of it as a router. You stick a service onto one end and have it attach to an application somewhere further down the line. You plug in the wires (or services) and the router does the magic.
In cases where either you are using a standard such as RSS for your service or where that service has a WSDL description, you just plug it in and it goes. You can ignore the fancy Java back end. In cases where neither is true (e.g., you want to use the Flickr or Google Maps API), there’s maybe a little more work because you’re not writing naked HTML pages. But my sense is that there are more and more JSR-168/WSRP adapters that would let you develop your mashup in Ruby on Rails or whatever and present it in the portlet with not much more work than normal. And if all else fails, there are iframe portlets that do the job with no more effort than…well…an iframe.
So I think the imposing architectural diagrams are somewhat deceptive. The LMOS core should act like a black box that the service writers don’t really need to understand in order to extend the system.
I also, along with Tony Karrer, am struggling with your technical direction. I want to come back to a point that Ray Davis makes in his insightful document called “loose coupling”.
“When you look at what a web application really needs from a collaborative framework, it’s usually not much. Many useful LAMP applications, for example, can get by with nothing more than authentication, and the majority can “plug into” a framework with just a context service and some external authorization code.”
Why not make the LMOS (the spine) as light-weight as possible? And then follow the loose coupling architecture that Ray describes. Why do we need all the Java overhead? At first glance it seems to me that your Java-centric LMOS is overwrought.
It’s a fundamental weakness of your current proposal that you are beginning with a technology first (i.e. Java). You should begin with the problem you are trying to solve. Describe in a technology independent way what an LMOS is supposed to do. For example, the list might look something like this:
a) it should handle authentication, including compatibility with external authentication schemes such as ldap and kerberos;
b) it should handle groups;
…..
etc.
Again, say clearly what
Al, the high-level description of the solution goals already exists. It is called the e-Learning Framework, and plenty has been written about it. LMOS is a proposed implementation of that framework. So yes, it is technology-specific, though we are careful to couch it as one possible implementation rather than the solution to th e-Learning Framework problem.
And frankly, I’m a little confused by your position. Further up this thread you were complaining about how hard it is to do an RSS feed in an environment where you have to deal with authentication and permissions. You can’t have it both ways. Either you feel that the sorts of issues that characterize an “enterprise” solution matter or they don’t. If you don’t believe they matter, and if you don’t think that hand-wiring every integration point is that big of a deal, then yes, the LMOS architecture is “overwrought”. But if you believe that an enterprise LMS makes sense as a product category, and if you believe that the number of application-to-application integration points is likely to grow exponentially, then the proposed architecture becomes a little more reasonable.
My quick take on ELF is that it’s incoherent and mostly mystification. I am sure a lot of smart people, including technical people who know a lot more than I do, have done a lot of smart thinking on this topic but it still makes no sense to me. Maybe it’s just me.
Here is one example. The diagram describes three layers: common services, learning domain services, and sample user agents. If one looks at common services and the items under it, it reads like a classification scheme invented by Jorge Luis Borges. I can understand authentication, authorisation, and group as falling under common services. But you also have chat, calendaring, and whiteboard. Huh? And email management, what is that? From an architectural perspectives it looks like a disaster waiting to happen.
Pardon my candor.
I do think that what you are after is important and what is being provided architecturally by existing systems is not adequate. But I have yet to see a coherent description.
I will try to post something more “constructive” tomorrow.
Couple quick thoughts –
Michael – I actually had never understood the ELF to be more that a list of services (a reference model) not an architecture. You’ve gone beyond that and defined an architecture. I may have missed the point.
Michael – can you get a tech person to comment on the value of going with JSR 208, 168, 170 vs. the mish-mash of RSS, REST, microformats, etc? And particularly, where that choice is going to make life better when you are trying to integrate various tools out there that are probably not portlets, but more likely widgets w/ badges.
Al – I tend to agree with you that there’s confusion in the ELF about what should be part of the framework vs. built on top. I think that the JELF actually is a pretty reasonable view that you need to put some common services for things like identity, authorization, integration, orchestration and then have things sit on top. Unfortunately, the diagram that shows all the applications as existing “inside” the framework is misleading. If you move them to sit on top, its a more interesting picture.
Tony, you’re spot-on about the relationship between eLF and JELF. eLF is a reference model and JELF is an architectural implementation of the reference model. eLF describes the problem, the goal, and a very high-level solution concept. JELF, operationalizes it with a an architecture. Your request is also spot-on. A friend external to SUNY just contacted me today with a draft of just such a document; with luck, it will be out soon so we can talk about it.
I also strongly suggest moving this conversation to the pages of the LMOS wiki itself:
http://confluence.sln.suny.edu/display/LMOS/Home
All of the pages allow commenting (at the bottom). Direct dialog with the developers would probably be more fruitful there than in what is turning out to be a very long comment thread on a non-technologist’s blog post.