blob: fda53ea051aecca38df23f0c6d924584a8f60618 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
Overview
--------
An ECSA indexterm:[ECSA,overview]
is a service architecture for elearning based webservices. It provides
mechanisms for communication and authorization between elearning systems among
each other and management systems. This is implemented via a
MOM.
[[fig_ecsa_overview]]
.Components of an ECSA network.
//ifdef::hyperdoc[image::diagrams/ecsa_overview.svg[ECSA network]]
//ifndef::hyperdoc[]
[ditaa,target=ecsa_overview,format=svg,scale=1.2]
....
+----=----+ +---------+
| +-----+ | | +-----+ |
| |LMS1 +------------+ +--------------+ LMS2| |
| +-----+ | | | | +-----+ |
: | | | | |
| comm. A : | | : |
| | | | | |
| | +-+-+-+ |+-------+|
| +-----+ | https | | ||HIS/LSF||
| |LMS4 +----------+ ECS +-----------+ Proxy ||
| +-----+ | | | |+-------+|
+---------+ +-+-+-+ | |
| | : comm. C :
| | | |
+--------------------|-|------=-----+-----=---+-+
| +-----+ | | | +-----+ | |
| |LMS3 +------------+ +--------------+ LMSn| | |
: +-----+ | +-----+ | :
| community B +----=----+ |
+----------------------------=------------------+
....
//endif::hyperdoc[]
An ECSA builds up of three primary components:
- The ECS (elearning community server) serves the core functionionality of
an ECSA network. It provides named message resources to allow communication
between all participants.
- An ECC (elearning community client) is a participant in an ECSA network. It
has to be registered at ECS and must be able to talk to the ECS as a REST
based client. This participant normally has a native implementation of the
ECS interface. Our favourite ECCs are LMSs (learning management systems).
- An ECP (elearning community proxy) represents a special kind of participant.
It serves as a proxy for a none ECSA compliant system so that such a system
is able to participate in an ECSA network without ever knowing about it.
Sample usage scenario
~~~~~~~~~~~~~~~~~~~~~
Suppose you have several LMSs (learning management systems) and want to share
courses between them. You decide not to interchange the real courses but only
course links which consist of some meta data of the appropriate course
especially a link formed by an URL pointing to the real course so you can call
it through the WWW e.g.:
http://ilias.freeit.de/goto.php?target=pg_26_43&client_id=ecs2
Now it's possible for each LMS to communicate the released courses by the
resources provided from the ECS to an explicit LMS (point to point) or to a
community of LMSs (point to multipoint).
Because of the uniform application interface -- there are only GET,
PUT, DELETE and POST operations -- receiving participants can fetch
messages through a GET on the resource URL or sending messages
by a POST on the resource URL (with some additional query parameters
or header variables to point to the appropriate receivers).
To illustrate this we use the simple ECC application +curl+ to
send a message from one participant to another:
....
curl -i -H 'X-EcsAuthId: pid01' \
-H 'X-EcsReceiverMemberships: mid02' \
-H 'Content-Type: application/json' \
-X POST \
-d '{
"name": "Mathematics II",
"url" : "http://ilias...?target=pg_26_43&client_id=ecs2",
...
}' \
http://ecs.freeit.de/campusconnect/courselinks
....
In order to receive a message (in fifo mode) the receiving
participant may call:
....
curl -i -H 'X-EcsAuthId: pid02' \
-H 'Accept: text/plain; application/json' \
-X GET \
http://ecs.freeit.de/campusconnect/courselinks/fifo
....
Of course, there are several ways to operate on a resource.
//////////////////////////////////////////////////
For details on using the resources located on an ECS and the different
parameters (http headers, query strings) plea e see XXX for details.
//////////////////////////////////////////////////
|
