1. Architecture Session: Introduction Scott Wilson 29-11-2005

2. This work is licensed under the Creative Commons Attribution-ShareALike license. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.0/ http://creativecommons.org/licenses/by-sa/2.0/ or send a letter to Creative Commons, 559 Nathan Abbot Way, Stanford, California 94305, USA

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

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

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

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

9. ReST Workflow

10. SOAP Workflow

11. SOAP Workflow - WSRF /Grid style

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

13. ReST Workflow (Activity- flavoured)

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

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

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