Connecting Smirkboard to Perception via Sweet.net

1
Connecting Smirkboard to Perception via Sweet.net
2
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

3
Technical Scenario
Remote Database
Your Web Application
W E B S E R V I C E
E N T E R P R I S E
Sweet.net
Enterprise Method Calls readPerson() readGroupsFor
Person()
IIS
Web Interface
4
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

5
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

6
Issue (1) -

• Questionmark Perception encrypts Instructor
  passwords but not student passwords
• Therefore authentication of students was possible
  but not lecturers

7
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

8
Why would you need lists of Persons based on role?

• Give management rights over assets to fellow
  instructors

9
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

10
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

11
Discussion Board PseudoCode

• Rs new recordset(Select from comments,users
  where comments.userid users.id)
• While not rs.eof
• print ltBRgt rs(title) by
  rs(username) ltHRgt
• rs.moveNext
• End While

12
The Heather Case

• Suppose a student enrols at uolife.ac.uk to do a
  course in Estate Management

13
The Heather Case

• Suppose a student enrols at uolife.ac.uk to do a
  course in Estate Management
• She gets given an email address
  hmills_at_uolife.ac.uk

14
The Heather Case

• Suppose a student enrols at uolife.ac.uk to do a
  course in Estate Management
• She gets given an email address
  hmills_at_uolife.ac.uk
• In her second year she gets married and changes
  name to hmccartney_at_uolife.ac.uk and then takes a
  break from her studies

15
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 hmills_at_uolife.ac.uk

16
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 hmills_at_uolife.ac.uk
• 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

17
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

18
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

19
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

20
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 users name at the moment of posting
• But then Heather is forever McCartney!!!

21
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 McCartneys life?

22
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 individuals progression through a learning
  design while their name/title/nickname/status
  (e.g they havent paid their fees) changes in the
  remote database

23
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

24
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