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