Sakai and OpenSocial: A Different Approach to Distributed Learning Applications


This is a guest post by Dr. Ian Boston for the On the Horizon series on distributed learning environments. Dr Boston holds a first degree in Engineering and a PhD in parallel computing. During the early 1990’s he parallelized grand challenge applications in science and engineering. After a frenetic period of multiple startups in Silicon Fen, as a founder, angel investor and board member he returned to the University of Cambridge to become CTO at CARET. The University of Cambridge joined the Sakai Project and over recent years has contributed greatly to its development. Ian was honored to be awarded one of the first Sakai Fellowships and speaks regularly at Opensource meetings in the US, Europe and Australia.

The online world has realized that connections and communications are capable of leveraging greater efficiencies and delivery than application silos. This movement started with the scaling requirements driven by the growth curves of the large internet startups like Amazon and Google. Strangely web technology has not changed much for 10 years but we have all started to realise that the web is a simple place where bytes on the wire is all that we are communicating.

Distributed web applications became possible in the late 1990’s, informed by the numerous parallel distributed applications in science and engineering. Although there are challenges in employing wide scale parallelism and distributed architectures, the discipline leads to loose coupling. The loose coupling allows development teams to communicate with one another through standards and interfaces, and allows the skills mix within those teams to compliment each other rather than being in conflict. The absolute key to success with this style of application and development is sophistication through simplicity; as there is plenty of complexity available to overwhelm all stakeholders.

These dreams are not just dreams, over the past 8 months we, at Cambridge, have been practicing this approach and seen the benefits.

 The trigger was the announcement in November 07 of the OpenSocial API by Google and a few key phrases from that announcement that opened from our eyes to the possibilities. Web development is simple, there are 100s of 1000s of web developers out there developing applications using whatever works for them. If we, in delivering applications for education create barriers to entry that prevent that army of developers from engaging we will lose the benefit of the powerhouse that is represented by the open source development community. We were working on Sakai, the development teams were largely populated by hard core Java developers, often with only a passing interest in the UI. Every new team member with a passion for UI soon became disillusioned and unproductive.

So we threw away the Sakai rule book, and embraced a different development strategy. This strategy, feeding on the pace of innovation in OpenSocial and its reference implementation Apache Shindig, has enable us to transform the Sakai interface. A UI layer developed by UI designers and developers in pure Javascript and HTML is connected to Sakai using pure HTTP protocols with a minimal layer of REST semantics. The UI designers and developers are engaged and productive. The Java developers are focused on building data services to a wire specification; delivery and the pace is an order of magnitude greater with applications taking hours rather than months to get into production. We will shortly be going live with this application at Cambridge. Looking at this as a distributed parallel application, we now have between 1 and 4 previously idle processor cores per user, rather than asking several thousand to share a single box, with all the associated environmental impact that central processing provision brings. In addition to the desktop, those user CPU’s include devices like iTouch, iPhone and other mobile devices, all naturally cooled by the atmosphere.

Underneath, it is Sakai, operating as a data server, but ontop it is Gadgets, Widgets and Ajax applications delivered in HTML. We call this SData, where many of the concepts are borrowed from GData and other Google API’s.

Meanwhile the OpenSocial specification is evolving; version 0.8 has introduced the idea of Groups. The focus of protocol development has moved away from ATOM and towards a simpler, and more browser efficient REST based JSON API. Our development path is on a parallel but converging track with OpenSocial. Networks within academia will become embedded into the applications delivered from academia. Just as Facebook grew though the academic community out to the masses, there will be a class of applications, with detailed knowledge of the needs of education, hosted within Universities, supporting teaching and learning and research, but integrating with distributed services from applications all over the internet. The monolithic application in teaching and learning and research has died. We cannot afford to develop and maintain it; in the process replicating the work of so many others. We have an opportunity to leverage global services provisioned by others, paid for by advertising, but with this approach we can maintain control over the information and services that are dear to teaching and learning and research.

Share Button

Google+ Comments

This entry was posted in Ed Tech and tagged , , . Bookmark the permalink.

3 Responses to Sakai and OpenSocial: A Different Approach to Distributed Learning Applications

  1. Scott Wilson says:

    I think this is a really interesting direction you’re taking. We’ve been doing something very similar here by developing on the W3C Widgets specification, extending to add support for collaboration-type widgets. Again, parallel with OpenSocial and Shindig. We’ve been experimenting with different containers including Moodle, WordPress, and Ruby on Rails apps.

    I really like some parts of OpenSocial, and it certainly has momentum. I just hope it converges with genuinely open standards rather than remains a Microsoft-style de-facto proprietary technology.

  2. This sounds like a very interesting and encouraging initiative. I had no idea this was going on in the Sakai world. The lessons of the Web are very well expressed with the phrase “connections and communications are capable of leveraging greater efficiencies and delivery than application silos”. It is my impression that “hard-core” Java developers, besides not focusing on the UI layer generally fail to take this into account by considering the Web as just one more UI. (Your article has the same problem, by the way: it needs a link.)

    It would be wonderful if VLE and social software could be made more permeable. I see social networks and VLE taking a federated approach with standard communications protocols between them. On that view, we need the equivalent of SMTP and XMPP. The original OpenSocial spec did nothing in that regard: standardizing a widget platform is interesting but not world changing. Making connections between people (or profiles anyway) on different networks on the other hand is potentially revolutionary. Maybe the RESTful API in OpenSocial 0.8 is the beginning of moving in that direction.

  3. Pingback: Sakai and OpenSocial (via OLDaily) «!

Comments are closed.