Architecture Session: Introduction Scott Wilson

This work is licensed under the Creative Commons Attribution-ShareALike license. To view a copy of this license, visit or send a letter to Creative Commons, 559 Nathan Abbot Way, Stanford, California 94305, USA

Task Design the runtime and pre-runtime architecture for learning design systems Identify the major issues and unknowns

Source materials The “Dagstuhl diagram” The “VLE of the Future” CCSI/SLeD ReST Workflow System Model LAMS Tool API

Different worlds? How can we integrate LD with informal learning, social activity and work? Well, I don’t think they’re going to learn to speak LD! I’ve got a few ideas I’d like to discuss, and to hear yours too

Architectural problems 1.How does an LD system manage learning activities at runtime? 2.How does an LD systems communicate the activity states with client systems, and receive and process workflow events?

ReST Workflow

SOAP Workflow

SOAP Workflow - WSRF /Grid style

CCSI model CCSI: SOAP-ish server-side Management of LDs

ReST Workflow (Activity- flavoured)

Questions… How tightly does LD need to manage its clients? What is the role of synchronous services? How should they be modeled? Does LD need to be push/pub-sub as well as, or instead of, request-response? How do we fit tool integration into the picture? What is the impact of security concerns? How to specify tools/services in LD itself?

Monitoring and intervention Where and how does monitoring fit? Where and how can intervention occur?

Now its your turn! Using these models as a basis: –Identify the problems with the models –Identify solutions –Identify gaps –Define the services and components needed –Decide the preferred protocol type(s) s(e.g. HTTP, XMPP, RMI) and protocol style(s) (e.g. RPC/SOAP, REST, pub-sub) –Come up with alternatives that may be better