Architecture Session: Introduction

1
Architecture SessionIntroduction

• 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/lic
enses/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

5
(No Transcript)
6
(No Transcript)
7
Different worlds?

• How can we integrate LD with informal learning,
  social activity and work?
• Well, I dont think theyre going to learn to
  speak LD!
• Ive got a few ideas Id 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)
14
(No Transcript)
15
(No Transcript)
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?

17
(No Transcript)
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