The document proposes a learning framework that provides required learning services or features on demand using microservices. The framework allows continuous evolution of learning systems to meet changing user needs. It does this through semantic description of components and services, allowing sound configuration and adaptation of learning applications. Future work includes deploying and testing the system in real settings, extending it to support collaborative requirements, and investigating automated semantic description of new components.
Separation of Lanthanides/ Lanthanides and Actinides
Domain Driven Design and Provision of Micro-services to build Emerging Learning Systems
1. Domain Driven Design and Provision
of Micro-services to build Emerging
Learning Systems
Maha KHEMAJA
Maha_khemaja@yahoo.fr
maha.khemaja@issatso.rnu.tn
1
TEEM’16 Salamanca 2-4 November
2. Introduction and problem statement
Research Context
Main requirements of the future system
Proposal
Conclusions and future works
4. 4
A single system containing an
important set of features that
may not be required by all users
Several kinds of learning
systems, each targeting generally
a specific domain and specific
set of tasks
The emergence and the exponential evolution of features
One user's learning needs could not be consequently covered by a
single learning system
One single system may cover much more features than required
5. 5
As micro-services based systems rely on software infrastructures that
allow continuously building and providing components to target systems at
run-time
New kinds of building methodologies
New learning frameworks that are flexible enough to take into account at
the same time users' learning needs and the learning features exponential
evolution and to provide just in time required learning or supporting services
or features.
Micro services oriented systems advocate the use of fine grained and self
contained components exposing their services via well defined interfaces
to build software.
Micro services are very suitable for mobile or pervasive computing
contexts, flexible enough to help adapt and/or reconfigure the software
(system) at run-time.
6.
7. How to continuously build and evolve learning systems in order
to take into account emerging needs and technology.
How to automate the process that allows to collect new domain related
features, map developed software components automatically and
semantically to features and to deliver those features with relevant
configuration to intended target learning systems
How to configure and /or apply adaptation/reconfiguration mechanisms
with regard to main software good practices such as high cohesion and loose
coupling
How to manage software components dependencies when composing a
new feature or adapt an existent one.
How to reason about tradeoffs related to communication models in order
to answer to low latency issues (e.g. for games, affect computing or other
emerging domains).
8. A business capability defines the organization’s capacity to successfully
perform a unique business activity.
A business goal is an objective or target to be achieved by a business.
A goal describes a certain system functionality or property that should
be achieved (expressed as intentions) generally considered from the
users’ requirement perspective.
The notion of feature is commonly used to describe the functional and
non-functional characteristics of a system.
A context means a specific responsibility. A bounded context means
that the responsibility is enforced with explicit boundaries.
9. 9
TLS BC G F Ca C
ITS Learner
Model
Traces the
learner’s
results
Quiz Assessment MCQ
component
LMS Enrolment Allows
learners’
enrolment
Learner
manageme
nt
Creates
learners
records
Enrolment
component
SG Gameplay Have funny
activities
Gaming Manages
game rules
Rule engine
Affect-
ITS
Sensing Identify
stressful
states
Sensor Collects
affective
signals
Sensor
interface
component
10. 10
A learning system should provide self contained
features
Each feature should pertain to a unique bounded
context
Features' workflows could be either synchronous
or asynchronous. One's feature components
should be fine grained
One's feature architecture should be built
accordingly to high cohesion and loose coupling
principles.
Clients consuming that feature should interact with
well exposed interfaces
All artefacts or resources required by a learning
feature should be rendered available thanks to a
resource manager
Underlying infrastructure should allow dynamic
components assembly
TLS’s requirements PS’s requirements
Back end systems should allow
clients to interact with shared
services and resources
Should provide services for
managing features components,
features configurations as well
as targets architectures.
Provide services to discover and
classify features and
components accordingly to
bounded contexts and
capabilities.
16. 16
Finally the third category of services is much more concerned
with services semantics and relevance for addressing specific
learning system features.
The first category addresses micro-services development
and packaging as well as applications' assembly and
reconfiguration at runtime.
The second category of services concerns components storage
and indexing, features' building and cloud or P2P
provisioning or delivery to target systems or platforms.
17. 17
Web oriented and RESTful implementations over OSGi
Additional components allowing asynchronous
communication models between services (such as the
publish/subscribe model)
Additional components allowing the use of Emerging
technologies as new Human Communication interfaces,
sensors, IoT. Available for OSGi based Frameworks
18. 18
Central concept of services provisioning relies on that of
repositories storing artefacts (i.e. bundles, resources and
configuration files).
The repository could be managed by a provisioning server (SaaS
model ) or by a Peer in cases of ad-hoc networked infrastructures.
OSGi runtime instances have to be deployed on peers or client's
devices and servers as well as a deployment mechanism that
supports modular deployments.
Either the client or the server should also embed a resource
manager entity providing resources management facilities.
19. 19
Semantic Web Services (SWS) combines concepts and
techniques from both Semantic Web and Web services
Main aims of SWS are to transform Web services descriptions
into more machine-understandable descriptions.
This could enable a more dynamic usage of Web services as
automatic discovery, selection, composition, invocation and
monitoring based on sound meaning of services capabilities.
Analogously to SWS, semantics are added on top of OSGi
bundles repositories to semantically describe bundles and
services capabilities
21. 21
Map abstract specifications made previously to concrete
data structures and algorithms or programs.
For instance, formal models are mapped and converted to
OWL ontologies, generating consequently a set of
ontologies such as the Goal ontology, the OSGi
bundles/services ontology and the Feature ontology.
Specific applications of the system will also require
domain ontologies for describing semantically learning
tasks, resources and artefacts processed collaboratively as
well as their corresponding results.
A reasoning engine is used therefore to process and make
inferences on these ontologies.
29. 29
The problem of ever changing user's learning needs by providing a solution for
continuously building learning systems.
We have proposed a learning framework that provides just in time required
learning services or features which are deployed as fine grained and self
contained Micro services exposing their services via well defined interfaces.
Automation have been done by means of semantic description of its
components and services allowing thus a sound configuration and adaptation of
learning services or resulting TLS applications to take account users contexts
needs or emerging technologies.
This work is quite different from other research works addressing SOA based
learning systems in many aspects.
30. 30
Future works aim, to deploy several TLSs and to test them in
real settings.
Secondly, to extend the proposed solution and its ontological
models to take into account dynamic aspects related to
collaborative requirements and specification.
Use meta-modeling (MDA or ODA approaches) for dynamic
code generation and packaging accordingly to inferred contexts
and requirements.
How to obtain semantic descriptions about new or third party
components in automatic manner