JISC E-Learning Framework Discussions Service Toolkit “FlowTalk”

1. JISC E-Learning FrameworkDiscussions Service Toolkit“FlowTalk” Antranig Basman, CARET, University of Cambridge Manchester Developers’ Meeting, 1st August 2006

2. Goals * Implement a service provider for the ELF "messaging service" * Demonstrate consumption of the service in a variety of hosting/client situations * Promote debate and consensus on requirements on ELF messaging services • Establish and maintain an open source community infrastructure surrounding the toolkit (public issue tracking, source repository and discussion/support)

3. FlowTalk • Has many roles • As an actively used discussions tool • As a vehicle for teaching exercises • As an integration and interoperability platform • As a vehicle for exploration of the potentialities and meaning of the “web services” concept

4. FlowTalk – the application Why did we build it? Many varied use cases for extremely flexible discussions software: • Student exercises with multiple rounds of feedback, different messages visible at different stages. Learning designer would like highest flexibility in designing workflow of teaching exercise. • Discussions for “outreach” – schoolchildren where highly flexible moderation policies necessary, including “pre-moderation”. Should also be possible via email. • Discussions amongst distributed research groups, self-organising into small “special interest groups”. Should be capable of functioning as a pure email list as well as web board.

5. The Integration Landscape • Numerous VLE/CLE initiatives round the world • Very little or no scope for interoperability at any but the most basic level (e.g. IFrames, or “fire and forget” interop) • Tools developed for one environment are worthless in another (Bodington, Sakai, uPortal, Coursework, WebSchools, GridSphere, Blackboard to mention only some major names – many institutions have their own custom environments) • Most “integration” initiatives are bogged down with vendor vested interests (JSR-168, WSRP, ITP) • The rest are “specification” rather than “practice” led (OKI, WSRP again :P)

6. FlowTalk – the service • FlowTalk aims to be capable of a “first class user idiom” in every platform, while containing no platform-specific code • Initially targetted at Sakai and Stanford’s Coursework, but contains e.g. no Sakai-specific code within the service • The hoped-for end result – a “Universal Abstraction Point” for web services interoperability with hosting environments in general • Practical definition of “E-Learning Framework”

7. Notes on Sakai • Highly active user and developer community • Very much oriented towards in-JVM development • FlowTalk is an extremely untypical tool within Sakai • A lively “web services” initiative, but driven by the framework’s own definitions rather than exterior interoperability needs • A realistic representative of “integration difficulties” – lots of potential coupling, “peculiar” idioms and architectural “shortcuts” • If FlowTalk can succeed here, it can probably succed anywhere :P

8. Discussion Service Standards • ATOM publishing • RESTful standard • Nested hierarchy • Early stage definition/adoption • XMPP • Mature instant messaging protocol • No hierarchy • No “persistence” • NNTP • OKI Messaging

9. What’s missing • NONE of these standards makes any attempt to define an interaction with an environment • The “back end” of a user-facing web service is actually far more problematic than the “front end” • In practice the environment will want to be the host, becoming the personality of the tool, rather than the user interacting directly with the service. • The key environmental interaction (needing to be tackled first) for ELF discussions (and most other ELF services) is that with the permissions system. • A service that cannot respect and interpret host permissions is unusable

10. The Web Services Permissions Problem • Lots of initatives for expressing permissions and authorizations (XACML, SAML &c) • Very few for transmitting and synchronizing them • Key issue in web services is to avoid “chattiness” • Must anticipate key requirements by the client ahead of time, but be prepared for the unexpected • Dozens of permissions resolutions may be required by the client per query • Cannot call the host for each • The host may be exposing an extremely large space of resources, and the client may be asynchronous • Cannot push all information across in the request

11. Sakai Request dispatch cycle ToolSinkTunnelServlet DirectWebServiceFilter RequestDispatch FlowTalk HTML/HTTP request (Serialized ConsumerRequestInfo) RequestDispatch SiteService/ RealmService ) ( RemoteSyncServerUserManager InformationServlet * XML/HTTP request SakaiUIP ViewRender (copy bytes) * = At most once per request, and preferably never!

12. Ultimate Outcomes – Other Problems • Permissions is just one (but the most important up-front) environmental interaction • Some interactions are even harder to abstract, although the general classes of problem are similar (granularity vs. “unexpectedness”) – similar to those involved in ORM • For instance Sakai operates a dynamic “event model” – tools must participate to be first-class citizens • Searchability – driven off event system • “Reverse mapping” of resource space – as well as seeing itself “grafted onto” a point in host’s space, the service will want to export its resources back. • User Interface idiom – see RSF talk

13. FlowTalk Global Resource Hierarchy Global resource root (per FlowTalk installation) Sakai Client 1 root Sakai Client 2 root Coursework Client 1 root Directly served resources Per-consumer info (URLs, IDs) CourseWork “Nexus” Sakai Sites Role/Realm info (as Groups, PermissionLists) CourseWork Section Forums/threads Sakai Pages/Placements (=“Forums”) Consumer per-resource Permissions (none for Sakai) Forums/threads

14. RSF I • A “first-class” tool in each environment must emulate the environment’s look and feel – but in general WITHOUT access to its code and services • RSF is a new Java web programming framework which aids universal portability of web UIs through various approaches • pure HTML templating • Request-scope IoC

15. RSF II • In fact, enables apps to serve a generalised “user interface web service” that need not commit itself early to a particular rendering technology/idiom • Perfect for portal aggregators • Looking forward to GWT, essentially provides a “remote web programming environment” which auto-defines an infinity of web services through a dataflow language • “Front end” of ELF discussions web services may be derived from RSF bindings (simple EL strings and XML-serialised objects transmitted over HTTP)