Transcript 2 Deliver - Ioan Rosca

Five years for five perspectives
on TELOS
Ioan Rosca, PhD. in educational technology
telecommunication, computer, information and instructional systems engineer
researcher and conceptual architect at LICEF, Teleuniversity, Montréal
[email protected]
LOR06, Montreal, 10 November, 2006
Summary
•
•
•
•
•
•
•
•
Introduction : history of a conceptual quest
Main objectives: produce, deliver, intermediate
Vision 1: extending the resources space; emergent mode
Vision 2: reproducing processes; orchestrating mode
Vision 3: distributing services; technical match
Vision 4: managing knowledge evolution; semantic match
Vision 5: managing production cascades; administrative match
Current work: managing service negotiation
History of a conceptual quest: a retrospective perspective
Previous
work
MOT, Explora, Adisa, ION
Val, Gadisa, SavoirNet
GEFO
TELOS0
TELOS dev
conceptual
architecture
Conceptual quest
consolidation
Conceptual
refinement
Technical architecture
1999
2003
2005
2006
2008
MISA (DE104,
212,214,xxx)
e104 d104
e212
exxx
35 editors
e104c
e104b d104
e212b
exxxb
exxxc
d104
2.1c
2.5f
Adisa d 1d
e104d d104
e212d d212
e214d d214
ADISA
Adisa
c
Adisa f
SchEd DataEd
2.1b
2.1a
e104a
Adisa 1+
schema
schema
104
xxx
LinkEd
exxxa dxxx
b Adisa1
Data
online/offline
ION resources aggregator 2.1c
MOT
ResEdit ResMan ResCon DocMan
EXPLORA
Env
SR PR
wsc
Adisa
service
server
service
data adaptor
client
2.3a
e104g data 2.5g a(104)h 104d1
104d2
e212g
a(212)h
212d1
exxxg
a(214)h
a(104
GADISA 212,
P1
edstyle
214)i
service bus 2.3b
adviser
adviser
kernel
Explora
2.4 epiphyte
library
semnatic “bus”
function
editor
Fa
Ba
designer context
Racc
Rpro
Rins
D
central context user context
2.2 a
f(104e,
212,
214)
function
data
explorer
functional aggregation
K ref
metaf
VAL
2.2 b
Main objectives: produce, deliver, mediate
C(K)
LKMP
LKMP
LKMP
LKMA
(lesson)
D(K)
LKMS
(platform)
LKMA manager
D manager
Resource
repositories
Service
providers
LKMA
(lesson)
P(K)
F(K)
LKMP manager
LKMS
(platform)
T manager
3 Mediate
C(K)
LKMA
(lesson)
T
1 Produce
Core factory
Resources and
services obtainer
C(K)
LKMS
(platform)
P manager
F manager
K manager
2 Deliver
Core libraries
Resources and
services provider
1 using and extending
us resources repositories
fi
co
us
ag
TELOS
e
TELOS
m
S
m
e
w
e M
e
TEL
T
E
L
O
S
e2
o
d
n
d
e3
R
4
ir
ip
r
ed
p
fi
e4
r,p
u
fu
ac
us
5 administrating production cascades
TELOS -core
LKMS library
LKMA LKMP
si
dis
3 distributing objects
and services
sa
ua
u
dis
s1
aS1 p1
p2
a2 p3
p4
d,d
a,r
us
di
e1
pu
2 modeling,
managing, and
E
reproducing
e processes
e
P
4 managing global knowledge evolution
TELOS
sa
te
c1 de
c2
c3
le
ob
ta’
ta
s2
a3 p5
p6
a4 p7
p8
persons
p1
objects
ob1
o1
a primary rs
procedure
p2
o2
ob2
operations author
compose
model
ob3
ps
support person adapter
support
resource
a1 abstract actors a2
i1
o1
i2
o2
i3
is1
as2 abstract
instruments
b abstract procedure model
Adapting
orchestrations
ob x
Function knowledge reference system
editor
resources repositories
Function
adaptor
person directories
concretise
function operations
elements
directories
e meta-procedure
user of functional cycle analyst
record
Function
Function
finds and
react
executor
analyser
executes
px
py
ob x
ob y
ob z
a1
a2
a1
a2
o1
o2
e1
e2
is1
as2
rs x
ps x
c model with concretised elements
is1
executed as2
operation
rs x
ps x
d secondary procedure based on function execution
From learning to explanation
learning: activities as competence operators i-f
c1i
c1f
c2i
c2f
c3i
c3f
100%
explain
explain
explain
M
f
i
ka
0%
kb kc kd
i
k1
mastership
measured
competences
effects of explanation Ci?
on various learners Cf?
ke
knowledge
f
k3
refining
k2
participate dialog
consult
competences
k1.3
k1.2
Ci
k1.1
k3.1 k3.2
Ci,Cf
Cf
k1.3.1
k1.3.2
learning topologies
•
k
consult
Explicative capacities and pedagogical indexation. In order to observe the competence equilibrium
around pedagogical operations, I have organised the competences space of a person P on "postures":
(knowK, aimK, explainK(x,y), describeK(x,y), recommendK(x,y), evaluateK(x,y))- where the
parenthesis show a predicate depending on the detained (x) or aimed (y) "mastering level" of the person
to which P could explain directly (transmit by a document, evaluate, recommend etc) the knowledge k.
The indexation of explicative documents poses similar problems to that of referencing support persons.
They can be partially considered the author's representative towards the expected user (minus the
interactivity limitations). That is why I have also characterised their explicative potential by (c1,c2)
increases.
O
e
O
E
E
O
O
D
D
8 Competence
optimization
E
c1
A
E
E
O
O
O
A
D
a
d
A
D
f2
A
e
E
E
E
O
O
O
d
a
a state changes
for Toeda
topology
c2
f1
e
A
n
e
E
D
d
D
A
D
a
d
e
e
E
E
O
o
D
A
D
A
d
a
d
a
A
R
b global allocation
problem
?
Service negotiation with TERMS
x
y
define
propose
z
categ
accept
grou
ask
service
filter
E
D
A
supp
doc
assist
v
manage
deliv
answer
u
lkms
TERMS
negot
O
syst
lkma
contracts
c1o1s1
c2d1s1
demands
d1s1
requ
lkmp
actor
offers
o1s1
services
s1
work
part
negoti
E
e
e
O
E
E
O
o
D
A
e
d
a
E
D
A
D
A
O
d
a
d
a
D
A
solve
concur
solve
transac
solve
compl
memor
TERMS - Telelearning Extended Rights Management System
Technological background
•
•
•
•
•
•
•
•
TERMS is built on a multi-tier J2EE architecture inspired by the MVC model that is
designed to scale well on a cluster of front-end and back-end servers.
The data layer uses the DAO pattern, providing a bridge between the data servers
(HypersonicSQL, MySQL or other SQL-compliant data server) and the business layer
(implemented in EJBs).
The front-end is handled by servlets and JSPs, designed with action patterns in mind,
extended with custom tag libraries, filters, listeners and additional web development
frameworks (WebWork, Sitemesh).
The Web Services access gate is implemented with the xFire framework, providing
full WSDL and SOAP support.
Designed to be portable across different servlet runners and EJB containers, TERMS
currently uses Resin Caucho as its application server, using the Hessan binary
protocol for fast access between front-end and back-end.
Security is handled both explicitly and through the servlet runner's security roles and
constraints, the application fully supporting Secure HTTP, through JNI and OpenSSL.
The current payment mechanism uses Verisign's Java API, but can easily be swapped
with alternatives.
Other involved technologies include the ANT build platform, the JUnit testing
package, the java activation framework, JAAS, SAAJ, MAIL, XML Parsers (Crimson,
JAXP, JDOM...), log4j, Spring etc.