A Workflow-based Architecture for e-Learning in the Grid

1
A Workflow-based Architecture for e-Learning in
the Grid

• Luiz A. Pereira, Fábio A. Porto,
• Bruno Schulze, Rubens N. Melo
• lpereira,rubens_at_inf.puc-rio.br,
• fporto,schulze_at_lncc.br

2
Agenda

• Introduction/Motivation
• Description of the Environment
• Description of the Architectural Model
• Related and Future Works and Concluding Remarks

3
Introduction/Motivation

• Motivation
• PGL (Partnership In Global Learning) Project
  (PUC/UF)
• Many partners providing learning content in a
  global scale data distribution, technological
  heterogeneity, easy and cost effective content
  access.
• e-Learning scenarios requiring computational-inten
  sive learning objects for simulation purposes
  (LNCC)
• Fluid mechanics course containing the simulation
  of a fluid path, which requires the computation
  of virtual particles trajectories (applied to
  hemodynamics)

4
Introduction/Motivation

• Requisites
• Effective e-learning environments should promote
  high cooperation. Benefits
• in the cognitive domain, improving learning
  capacity and academic performance.
• in social and affective ones improving group
  and individual self-confidence.
• It is important to consider new methods to reduce
  learning content development costs.
• It is also important to consider (cost) effective
  content delivery mechanisms.
• Many cases requiring massive computing power
  and/or data storage usually not available in a
  single workstation.

5
Introduction/Motivation

• Proposed Solution
• Cooperation ? WfMS, providing
• Executor-task assignments
• Effective interaction coordination
• Execution duration control and synchronization
• Coordination of the execution of tasks involving
  massive computation and/or data processing.
• Content development cost reduction ? use of
  modular and reusable learning modules (LOs)
• To facilitate deployment and execution assignment
  
• Reusability and standardization contributing to
  content development costs reduction and quality
  improvement.

6
Introduction/Motivation

• Proposed Solution(cont.)
• (Cost) effective content delivery mechanisms ?
  Web based environment
• Massive computing power and/or data storage ? Grid

7
Introduction/Motivation

• TEAM is both
• An architectural model Teamwork-support
  Environment Architectural Model
• Operating environments based on the architectural
  model Teamwork Applications Manager

8
Introduction/Motivation

• TEAM (the architectural model)
• TEAMA
• TEAM (the environment)
• TEAME, instantiated to e-learning.

9
Description of TEAME

• Students and teachers would execute instructional
  steps cooperatively guided by a WfMS
• WfMS deals transparently with distribution,
  autonomy and technological heterogeneity of the
  content repositories that are located in the
  partners sites
• Content is LO-oriented and is described using the
  IEEE-LOM standard.

10
Description of TEAME

• The processing unit of the environment is called
  a peer, working as a gateway to environment
• Provides users authentication,
• User-environment interaction control,
• Execution context management.
• Each user is associated to a peer
• A site is a logical collection of peers sharing a
  common learning purpose
• Users have transparent access to resources within
  sites in which his home peer is included

11
Description of TEAME

• The environment is logically divided in two
  scopes, external and internal, according to user
  roles.

12
Description of TEAME

• The external scope
• Provides an environment for students accessing
  courses they are registered to attend.
• External users see the (distributed)
  environment as just one piece
• The workflow enactment services provide this
  transparent vision to external users, routing,
  retrieving and allocating resources to/from
  proper peers

13
Description of TEAME

• The internal scope
• Refers to the working context of the
  environments the internal users
• Technical support staff,
• Application developers,
• Database administrators and
• Learning content developers

14
Description of TEAME
15
Description of TEAME

• What about content?
• It is LO-oriented
• Developed in reusable modules from scratch
  and/or
• Developed by aggregating LOs developed by other
  partners
• Lightweight or
• Heavyweight, requiring Grid resources

16
Description of TEAMA

• Architecture based on mediator(s) and wrappers
• Peers are functionally identical but some of them
  run on top of a grid (operating) system to access
  resources provided by grid environment(s).
• Grid resources management to be done
  transparently from the user perspective

17
Description of TEAMA
TEAMA conceptual view
18
Description of TEAMA

• Each peer in TEAMA is a stack of three layers (a
  3-tier architectural model)
• User Interface,
• Workflows services (business processes/rules)
• Other services (data persistence, resource
  scheduling, ) .

19
Description of TEAMA
User interface with the environment a web
browser or a .NET application.
The functional core of the architecture The
workflow enactment service managing a convenient
portion of the whole workflow instance.
Service layer provides data persistence and grid
access for heavyweight tasks.
TEAM 3-tier architecture
20
Related and Future Works and Concluding Remarks

• At LNCC we are developing a grid infrastructure
  to be used transparently from several kinds of
  applications.
• One of these types of applications is an
  e-Learning Management System capable of sharing
  distributed e-learning modular content and
  controlling student-student and student-teacher
  collaboration.

21
Related and Future Works and Concluding Remarks

• TEAM extension towards its integration with grid
  infrastructure is at its initial phase.
• We need to integrate user authentication between
  TEAM and the grid
• We need to develop a more refined authorization
  policy that will include information on user
  rights to access a LO
• We need to extend our current LO storage and
  query services
• We need to refine how our search for LOs will be
  implemented
• We need to improve workflow specification to work
  on a non-structured scenario