Transcript bennett

Connecting Smirkboard to
Perception via Sweet.net
Applications summary
• Smirkboard
– A tool to host audio visual presentations
– Allow viewers to shared-annotate such presentations
– Administrators can associate presentations with
particular groups
• Questionmark Perception
– A tool for hosting online quizzes
– Administrators can associate quizzes with particular
groups
Technical Scenario
Remote
Database
Sweet.net
IIS
E
N
T
E
R
P
R
I
S
E
W
E
B
S
E
R
V
I
C
E
Your Web Application
Enterprise Method Calls
readPerson()
readGroupsForPerson()
Web Interface
Motives
• Practical: to avoid duplication of data
between systems used in a Masters’
module
• Idealistic: to establish a system where the
adding of new data sources for access
control purposes was really simple
Authentication & Provisioning
• Check username & password against
record in external data source
• On success bring in all group and
membership info
• Within Smirkboard maintain records of
group and media associations
Issue (1) • Questionmark Perception encrypts
Instructor passwords but not student
passwords
• Therefore authentication of students was
possible but not lecturers
Issue (2) – Obtaining Persons
Based on Role
• You obtain Persons in IMS Enterprise only
through their membership of groups
• However, it does have provision for
defining roles
– SystemRoleType
– InstitutionalRoleType
Why would you need lists of
Persons based on role?
• Give management rights over assets to
fellow instructors
Issue (3) Transience of Data
• Typically user details as they visibly
appear in any web application is likely to
be sourced from some kind of sql
statement invoking the user table whose
contents are more or less permanent
Typical Discussion Board
• Usually a system will list contributions to a
discussion board by iterating over a join
between a table of comments and a table
of users
– I think x is great by Johnny
• I agree by Jane
• I disagree by Peter
Discussion Board PseudoCode
Rs = new recordset(“Select * from
comments,users where comments.userid =
users.id”)
While not rs.eof
print “<BR>” & rs(“title”) & “ by “ &
rs(“username”) & “<HR>”
rs.moveNext
End While
The Heather Case
• Suppose a student enrols at uolife.ac.uk to
do a course in Estate Management
The Heather Case
• Suppose a student enrols at uolife.ac.uk to
do a course in Estate Management
• She gets given an email address
[email protected]
The Heather Case
• Suppose a student enrols at uolife.ac.uk to
do a course in Estate Management
• She gets given an email address
[email protected]
• In her second year she gets married and
changes name to
[email protected] and then takes a
break from her studies
Returns
• However she comes back to her course 2
years later with her domestic
circumstances changed, and instructs
central admin to change her moniker back
to [email protected]
Returns
• However she comes back to her course 2
years later with her domestic
circumstances changed, and instructs
central admin to change her moniker back
to [email protected]
• She makes a request to the university
authorities that all previous transcripts and
records of her activity on the student
intranet should use her maiden id
Traditional vs SOA-style treatment
of user data
• In the traditional example of the db driven
web app – it becomes a trivial task to
change her name in her student record to
change the name appearing by her
contributions
Traditional vs SOA-style treatment
of user data
• In the traditional example of the db driven
web app – it becomes a trivial task to
change her name in her student record to
change the name appearing by her
contributions
• In an context where user data is supplied
by calls to a web service there comes a
very complicated tradeoff to weigh up
No Permanent User Table consequences
• We can either have ids stored in the comments
table which relate to the user in the remote
database
– But everytime we iterate over the comments to
produce the discussion page, we would have to make
webservice calls for each contribution
No Permanent User Table consequences
• We can either have ids stored in the comments
table which relate to the user in the remote
database
– But everytime we iterate over the comments to
produce the discussion page, we would have to make
webservice calls for each contribution
• More likely we have full text field containing the
user’s name at the moment of posting
– But then Heather is forever McCartney!!!
Why not just have a temporary user
table in the “consumer” web app?
• Because hmills might also leave the university –
(and her record might be deleted in the remote
database)
• That would mean that in a join between a
temporary users table and the permanent
comments table, her comment would not figure
• But should her comment be expunged just
because her being has been expunged from the
university, just as she has from Mr McCartney’s
life?
Being Serious
• There will always have to be a complex act of
reconciliation between the contents of the
remote database
(persons,groups,memberships) and the
persistent traces they leave in an Enterprise
consuming web application
• These traces could be:
– The actions of a group while its membership changes
in a remote database
– An individual’s progression through a learning design
while their name/title/nickname/status (e.g they
haven’t paid their fees) changes in the remote
database
Potentially 3 models of dealing with
data transience
• (1) total transience: during sessions maintain
and verify huge session objects with a list of
group memberships which gets negotiated with
Smirkboard on every transaction
• (2) moderate transience: every log-in, populate a
db table with temporary list of group
memberships and flush on next login before
repopulation
• (3) small transience: effectively make
Smirkboard a “shadow” of Perception, every so
often just comparing its memberships and
aligning them
Service Oriented Architecture for
User Data Conclusions
• For certain uses it offers a compelling case
– An application can be written away from the vagaries
of individual db setups – merely requiring that a
standard implementation of an ims enterprise service
is present
– But with applications of real complexity where user
actions have persistent consequences then the
complexity of thought required to implement it might
make the tradeoff between ease-of-development vs
transferability lead developers to renounce the goal of
transferability