190 likes | 266 Views
Architecture Session: Introduction. Scott Wilson 29-11-2005. 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/
E N D
Architecture Session:Introduction Scott Wilson 29-11-2005
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
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 • 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?
ReST Workflow
SOAP Workflow
SOAP Workflow - WSRF /Grid style
CCSI: SOAP-ish server-side Management of LDs CCSI model
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