Skip to content.
Sections
Personal tools
You are here: Home » Features » Using Enterprise WS to Connect Smirkboard to Perception

Using Enterprise WS to Connect Smirkboard to Perception

Steve Bennett
Last modified 18 Dec, 2006
Published 18 Dec, 2006
In this article Steve Bennett describes the Smirkboard to Perception toolkit demonstrator project which used Enterprise web services and the Sweet.net toolkit to transfer student and group data between Smirkboard (presentation software) and Question Mark Perception.

What I am about to do is describe a case study in connecting two different web applications together, in such a way as to share user data and group memberships from the one to other. However, before I get underway, I’ll just explain the terms title:

  • Smirkboard [1] is an application whose purpose is to host online audio visual presentations and allow them to be annotated by the people who have access to them.
  • Perception [2] is an online test application produced by Questionmark Computing and is the brand leader in web based online testing and is used in many Universities in this country and beyond.
  • Enterprise Services [3] [4] is a standard agreed by the IMS (Instructional Management Systems) consortium which specifies how person, group and group membership information should be shared between different educational systems in an SOA (Service Oriented Architecture) context
  • Sweet.net [5] is a toolkit funded by JISC and produced by Jon Rowett when he was at Brockenhurst College. It is a superb programming interface to the IMS Enterprise standard, allowing you to produce your own Enterprise web service very quickly on top of IIS

Now that’s done, I’ll describe the situation which motivated this project.

Basically, I have been teaching a course called “Multimedia Specification, Design and Production” at my university for a number of years now. It’s a course which teaches multimedia construction through Flash as well as covering development and evaluation methodologies such as Information Architecture and Heuristic Evaluation. On the first coursework for it, I make the students take a 50 question test in Perception. In the second coursework, the students produce a prototype website entirely in Flash. In the third coursework, they have to write an audio-visual critique of another group’s website which are then uploaded to Smirkboard. And in the final assignment they must redevelop their website, based on the critiques they received – and also annotate those critiques to signal assent or disagreement with points being made.

The two online applications used here – Questionmark Perception and Smirkboard – both have independent databases containing usernames and passwords for the students. The source of both of these are usually .csv files, obtained from the University’s VLE, Studynet which are then tweaked in order to make them compliant with Perception and Smirkboard’s different “import users” facilities. Of course all this is probably poor practice (though I’ve no doubt it is replicated across universities all over the land). Therefore, the goal of connecting Smirkboard to Perception’s user base was to test out the idea of sourcing one web application’s users from another web application’s database. And doing it using IMS Enterprise Services was a way of evaluating how feasible a generic solution to this issue might be.

Using Sweet.net

Writing an Enterprise web-service using Sweet.net turned out to be a straightforward and elegant process. Essentially this toolkit comes as a set of aspx and dll files together with a number of so-called adapters: for instance a Person adapter, or a Group adapter, or a Membership adapter. Within these are empty functions corresponding to the various method calls specified in the Enterprise spec: for instance, ReadPerson(), the function used to check a person’s bona-fides, or ReadGroupsForPerson() which will report back to the consuming application all the groups of which a certain individual is member. Your job as the programmer is merely to code in the various procedures necessary for responding: therefore the ReadPerson will interrogate the remote database, potentially compare user name and password, and pass back a resulting object. All the WSDL, all the Soaping-up, everything like that is completely taken care of by Sweet.net. It seemed a fairly straightforward idea at the outset, but involved negotiating a number of complex issues as time went on.

Issue 1:Access to Encryption Algorithms on Remote Database

When using Perception 3’s database, we found that student passwords were not encrypted while lecturer passwords were. Therefore, it meant we could easily authenticate a student through Perception’s database when they wanted to view Smirkboard, but that was not possible for a lecturer. Our solution to this was to create lecturers in Smirkboard who were essentially proxies of lecturers in Perception. Therefore, when a lecturer logged in, the username and password would be compared against corresponding record fields in the Smirkboard database, and upon success, this user inside Smirkboard, would become a proxy for the corresponding lecturer in Perception. After this, this Smirkboard proxy user will have control over the various groups that his doppelganger in the Perception database owns.

In practice it works like this. Smirkboard allows an administrator to specify a new data source – namely the wsdl address of the Person and Group services it seeks to invoke.

Creating a new External data source in Smirkboard

"Creating a new External data source in Smirkboard".

Having done this, the administrator can then import lecturers. Here, he specifies the password the proxy lecturers are to have in Smirkboard (those lecturers coming from the webservice we have named PLH).

Lectures imported from the PLH webservice

"Lectures imported from the PLH webservice".

And once this is done, this Smirkboard lecturer, now controls all the groups and students inside Perception that his namesake there will control.

Undoubtedly this was an idiosyncratic solution, which has so far proved highly practicable, though perhaps It’s not particularly generic. Nonetheless, it is likely in other implementations that similar work-arounds to ours might need to be employed, owing to the sheer sensitivity and importance of the data there, and the essential duty of administrators to protect it.

Issue 2: Transience of User Data

This is a very difficult issue. Essentially when you use Enterprise for sourcing user data, there is not necessarily any permanent record of that user within your own web applications. The user potentially might only exist within the session.

Scenario: changing names and email addresses

To illuminate this issue let’s think of a light-hearted scenario. Suppose a Miss H Mills a couple of years ago wanted to start a degree in Estate Management at the University of Life (uolife.ac.uk) owing to the likelihood of change in her life circumstances. During the first year of that course, her name changed to Mrs H McCartney, however in her final year, she began pestering the central admin unit to have her email address changed back to H.Mills@uolife.ac.uk – and moreover, she wanted all her previous submissions to the VLE changed such that this name was used rather than married name. For your typical VLE, that is unlikely to be a problem. In most web applications, the user would be represented by foreignKey in most of the content tables, and from that foreign key it would be possible to find out whichever name the user preferred to use, and since the VLE documents would be generated dynamically, each of the previous submissions could subsequently be seen only with the maiden name again.

However, now think of a VLE which didn’t have its own user database, but consumed an Enterprise service offered by the University’s Central data store. Because the user does not exist as a permanent record in a table in the VLE, there is no foreignKey for any contribution made by a user to cite. It would probably have to just have a field containing the name the user had at the time of making the contribution. How galling this would have been for Miss Mills!

The serious point I’m making with this story, is that thinking of users as transient, temporary phenomena who exist for a session rather than all time, means a number of big changes to the way we manage and think about user data. Take a simple scenario of a lecturer who wants to give access in Smirkboard to a number of presentations for a couple of groups. When he logs in, Smirkboard will need to look inside Perception to find how many groups this individual has control over – this might be different from the last time he logged on. Therefore Smirkboard must populate its tables of temporary users and groups with all the groups he currently has access to, and delete the previous list. He must also know all the fellow tutors to whom he might delegate management of certain content or groups, and these too will have to come from an interrogation of the state of the Perception database at login time. Therefore, in practice, everytime a user logs on, some kind of reconciliation of data needs to take place between the Smirkboard application and the Perception database – a task much more involved than the typical mere ascertaining of identity that happens at log in.

Issue 3: Agreed Taxonomies for Groups

In any e-learning application there are probably two “groups” whose existence one can take for granted– namely tutors and students. Basically there will always be someone who grades and someone who is graded. The IMS Enterprise specification certainly has this in mind in various fields pertaining to the Person: for instance, there is the SystemRole and there is the InstitutionalRole – the latter probably the most useful for us, having values such as: Student, Faculty, Member, Learner, Instructor, Mentor, Staff, Alumni, ProspectiveStudent, Guest, Other, Administrator and Observer etc etc.

However, in an application such as Smirkboard, where tutors have privileges, such as the assignment of content to groups, but also that of assigning management rights to fellow tutors over various content and groups (a facility that many e-learning applications might wish to have), then some built-in name for a group containing all the tutors, and another containing all the students, might be desirable. Of course we can, ad-hoc, create our own named groups, for example “alltutors” or even “tous_les_professeurs”. However, should we wish to use Enterprise to create a generic e-learning application, this would be problematic. People who wished to connect our e-learning application to their Enterprise service would have to follow our caveats: for example, this application can only work as long as two groups are created in the web service – “alltutors” and “allstudents”. Because of this, all the Enterprise web services which our application consumes, will need to adapt those services to create groups according to the names we specify.

Potential Scenarios of Use for IMS Enterprise

An unlikely scenario is extra-institutional collaboration. Server and database administration people are unlikely to look warmly on the idea of someone else’s application, from outside their university, interrogating its username and passwords. Of course the enterprise web service could be put through a secure socket layer with certificates exchanged between the consuming application and producing service. However, there would also need to be a very strong sense of trust in the other’s system, such that they could be sure usernames and passwords were not being listened prior to their sending in secure form to the service. For anything like this, systems like Shibboleth seem a much safer bet.

However, for doing things like simple utilities which are not catered for in existing VLE’s, the use of Enterprise would be a boon for developers, in that they would effectively writing to a clear standard when invoking user data, away from the vagaries of individual database setups. In this way, quite simple user database could support a raft of useful functionality which could simply be slotted in, as and when needed.

Future Developments for Smirkboard

After having struggled with the Enterprise spec, our next big goal for the system is going to be completely different. Namely it is to use Smirkboard as a platform for a Virtual Reality Literary Magazine project sponsored by the English Subject Centre [6]

Shockwave virtual reality environment for Smirkboard

"Shockwave virtual reality environment for Smirkboard".

For this, on top of the Smirkboard, we are building a Shockwave VR Environment, in which presentations, in this case, student written poems and short stories will appear in the system, which will be inhabitable by logged in users as avatars. For each presentation, the slides will become the walls of vast oval auditoria.

Preparations and calls for submissions to this magazine are already underway and we’re very much looking forward to its release in May 2007.

Steve Bennett is a Senior Lecturer in Computer Science, University of Hertfordshire.

References

[1] Connecting Perception to Smirkboard via Sweet.net Site

[2] Question Mark Perception

[3] IMS Enterprise Specification

[4]IMS Enterprise Services

[5] Sweet.net

[6] Virtual Reality Literary Magazine project sponsored by the English Subject Centre

 

Supported by JISC Supported by CETIS
Powered by Plone