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.

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.

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.

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.

“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

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 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?

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?)

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.)