Educloud Alliance Technical Documentation

Educloud Alliance is creating and maintaining a standard which defines how it is possible to build a ecosystem of users, developers and service providers, which brings together learning management systems, content management systems, content producers, administrative systems and all other services to make it possible for everybody to freely discover, choose, buy, compare and use everything.

Principles

Principles are the key guidance when contributing and defining the standard. By following the principles one can help the standard to meet the goals set.

User point of view.: The main principle of the standard is to recognize and appreciate the goals of users. By understanding the motivations and rationales behind users’ actions it is possible to build environments that fulfill users’ needs and bring joy of use to their daily life.
Everything is open and free.: Everything is open and free for everyone to use everywhere.
Interoperability.: Not only people, but also services can discuss with each other, change information and thus build knowledge. Make it possible for every other service in the ecosystem to connect with your service. And bring more value by connecting your service to other services.
Be committed.: Ecosystem includes various actors with freedom to build and maintain their own services for their own purposes. With this freedom comes the responsibility to be committed to follow the ECA standard.
Excellence.: Create and contribute to a believable and viable standard which is easy to understand, implement and it convinces as many people as possible.
Use existing.: Use as much as possible existing documentation, interfaces, and field tested technologies. Make your own contribution reusable.
Offer reference implementation.: Reference implementation with written documentation is the ultimate proof that the idea works and is possible to implement.

RFC 2119 is used to define common vocabulary for requirements in the documentation.

Structure of documentation

Documentation consists of four levels presented in the image: Stories, Services, Interfaces and Infrastructure.

Stories are the highest level of documentation. Stories do not describe any technical solution, but focus on explaining the rationale. Why something needs to be done, and how it should work from the users’ perspective. A story does not describe a service as such, but the user, the usage environment, and the usage flow.

Services documentation tells what functionality is expected from a service, and how it relates to the stories. Services must work together to form functionality described in the stories. Services should adhere to common user experience guidelines which ensure that the user feels safe and knows the path between services.

A reference implementation should be included for testing the interfaces and related services built according to the documentation. This reference implementation is part of standard’s documentation, and available for all parties.

Interfaces are there for creating pleasing user experiences when several services are needed to meet the goals of the user. Interfaces enable service-to-service communication and data sharing, which helps creating seamless experiences to the user.

Infrastructure documentation is the lowest level of documentation describing the whole service architecture of ECA standard. It also contains the best practices guidance for hosting the services and the system.

Stories

A story shows a snapshot of user’s life with the system. It gives insight into what kind of people will use the system e.g. what kind of teacher, student or other person from the school world. And why they are using it. The key is to know your users!

The story tells the user’s problem or the goal, which the user wants to achieve. From the story, reader gets an idea of how the system can help the user and what kind of features there are. But it does not specifically tell what technology is used.

The story takes place in the right context i.e. for example in an environment such as school class, home office, or the bus, and describes the tools and capabilities e.g. tablet, mobile phone, limited network access. If relevant to the system, story may also tell about social context i.e. situations and communication of people with each other, or with some other systems.

The context of use, characteristics of the user and the goals help to identify design requirements for the service. From the story you can see, what other services you may need in order to fulfill user’s needs properly.

Stories do not tell you what kind of user interface you should build, or what kind of technical solutions should be used, as it leaves them open. Only interest is on whether the story is met with the final product or not, regardless of means.

For the user the whole system should look and feel coherent and there should not be inconsistencies or places where the actor does not know where in the overall system she currently is.

Following stories are identified to be the core stories of ECA’s standard.

Single Sign-on: Authentication and identification of the user should happen only once when she begins the session. Moving between services should be seamless.
Using learning materials: User must be able to use any material the way she wants.
Procurement and license management: Procurement of material and services should be easy and fair to everybody.
Curriculum: User should always know that what she is doing is in line with the curriculum.
Analytics and feedback loops: User should see her progress in real time and it must be possible to build feedback loops in all levels of the system.

Services

The standard is based on a service oriented architecture where functionality is split to services. The services defined in the standard are implementing the stories defined in the standard.

The standard must be accompanied by reference implementation which shows in practice how the standard is meant to be working. The reference implementation is not meant to be production system and it is not designed as such.

It must be possible to have multiple instances of all services when in production. It is up to the production system to define how many instances of different services are available to the users.

User authentication, identification and profile data

Authentication is considered separate from other services. All services need to know something about the user. Different services need different data about the user, but all of them need to authenticate and/or identify the user in some way.

These are the services which together form the basis of authentication and identification of users.

Auth Proxy: Common interface for services to use different Auth Sources. Provides single sign-on for services.
Auth Source: Authenticates the user when the user wants to open a session in one of the services. Auth Sources are handled by the Auth Proxy.
Connector: Connects user authentication source and user identity together. This makes it possible for the user to identify with multiple authentication sources and still have only one identity. Only the authentication source knows the credentials for the user.
Data: Common source of user data to all other services. Mainly used by the connector to query users and store the connection between authentication source and user identity.

Learning material

Handling learning material is focused in three key service types. Learning material is produced by the CMS and used in the LMS. Bazaar is mediating between them and allowing many-to-many connections freely between them.

Bazaar: Service which lets the user to browse and buy material from CMS to LMS.
Recipes: Service which builds collections of learning materials.
Learning management system: Service which consumes the content produced by the Content management systems.
Content management system: Service which produces content in some form.

Interfaces

The interfaces can be thought of as a highway of information which is flowing between services.

Services are publishing interfaces for other services to use. Interface definitions must be open to everybody, but the use and authorization of interface access is defined runtime by the services.

Services may have more interfaces than what is defined in the standard. These interfaces are not bound by the standard.

Auth IF: User authentication is done by common interface. The auth system has SP and IdP components.
Data IF: Data Service provides an interface to query for user data from Data Providers.
LMS IF: Between Bazaar and LMS.
CMS IF: Between Bazaar and CMS.

Infrastructure

The standard would not be complete without defining how the system as a whole is working and how the reference implementation is built. The production system can be different.

Contributions

If you want to contribute to ECA put your contributions in the open and begin the discussion how your contribution could benefit ECA and everybody else.