Architecture Session: Introduction

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/ 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 • How does an LD system manage learning activities at runtime? • 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: SOAP-ish server-side Management of LDs CCSI model

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