Extensible LD Service Element & Hybrid P2P/Server Runtime Architecture Bill Olivier Development Director, Systems and Technology JISC
Extensible Service Proposal The problem: Many new services are becoming available… How many can we support in LD? How should a new service be included in LD? Does the LD spec have to be regularly updated? Will all runtime environments support all services? 2 proposals: 1.An extensible service element for the LD Spec 2.A registry for LD Services
The LD Conference spec Essentially maps (open) LD roles to (fixed) Conference roles LDConference LD Role 1 Member LD Role 2 Moderator LD Role 3 Observer LD Role 4 Administrator
The LD Generic spec Essentially maps (open) LD roles to (open) service roles LD LD Role 1 Service Role 1 LD Role 2 Service Role 2 LD Role 3 Service Role 3 LD Role 4 Service Role 4 … …
Extensible Service Proposal This allows the Service element to be extended Service Vocabularies can independent of LD spec Need a common registry of Service Definitions –Type –Supported roles Where service can be obtained –As Software –As Online Service/s Service interface/s supported (if any) –Setup –Runtime
Hybrid P2P and Server Architecture Web Server / LMS 2 Session Servlet 2 Session Servlet 1 Session Servlet 4 Session Servlet 3 Personal LD engine Multi-player LD Co-ordination Service (PeerServer) Web Server / LMS 1 Peer 1 Personal LD engine Peer 2 Personal LD engine
Learning Design Components Search Store & Retrieve LD Components – Why? LD spec defines Metadata for: –LD Units of Learning –Activities –Environments –Resources –Plays, Acts, Role parts, Activity-Structures? This allows them to be indexed and searched for – and hence reused in higher-level assemblies. These can be reused Also enable high-level DragnDrop Learningflow Editors (as in LAMS authoring)