Acronyms, Abbreviations and APIs

Steve Lay HeadshotPosted by Steve Lay

As Questionmark’s integrations product owner, it is all too easy to speak in acronyms and abbreviations. Of course, with the advent of modern day ‘text-speak,’ acronyms are part of everyday speech. But that doesn’t mean everyone knows what they mean. David Cameron, the British prime minister, was caught out by the everyday ‘LOL’ when it was revealed during a recent public inquiry that he’d used it thinking it meant ‘lots of love’.

In the technical arena things are not so simple. Even spelling out an acronym like SOAP (which stands for Simple Object Access Protocol) doesn’t necessarily make the meaning any clearer. In this post, I’m going to do my best to explain the meanings of some of the key acronyms and abbreviations you are likely to hear talked about in relation to Questionmark’s Open Assessment Platform.


At a recent presentation (on Extending the Platform), while I was talking about ways of integrating with Questionmark technologies, I asked the audience how many people knew what ‘API’ stood for. The response prompted me to write this blog article!

The term, API, is used so often that it is easy to forget that it is not widely known outside of the computing world.

API stands for Application Programming Interface. In this case the ‘application’ refers to some external software that provides functionality beyond that which is available in the core platform. For example, it could be a custom registration application that collects information in a special way that makes it possible to automatically create a user and schedule them to a specified assessment.

The API is the information that the programmer needs to write this registration application. ‘Interface’ refers to the join between the external software and the platform it is extending. (Our own APIs are documented on the Questionmark website and can be reached directly from

APIs and Standards

APIs often refer to technical standards. Using standards helps the designer of an API focus on the things that are unique to the platform concerned without having to go into too much incidental detail. Using a common standard also helps programmers develop applications more quickly. Pre-written code that implements the underlying standard will often be available for programmers to use.

To use a physical analogy, some companies will ask you to send them a self-addressed stamped envelope when requesting information from them. The company doesn’t need to explain what an envelope is, what a stamp is and what they mean by an address! These terms act a bit like technical standards for the physical world. The company can simply ask for one because they know you understand this request. They can focus their attention on describing their services, the types of requests they can respond to and the information they will send you in return.


QMWISe stands for Questionmark Web Integration Services Environment. This API allows programmers to exchange information with Questionmark OnDemand software-as-a-service or Questionmark Perception on-premise software. QMWISe is based on an existing standard called SOAP. (see above)

SOAP defines a common structure used for sending and receiving messages; it even defines the concept of a virtual ‘envelope’. Referring to the SOAP standard allows us to focus on the contents of the messages being exchanged such as creating participants, creating schedules, fetching results and so on.


REST stands for REpresentational State Transfer and must qualify as one of the more obscure acronyms! In practice, REST represents something of a back-to-basics approach to APIs when contrasted with those based on SOAP. It is not, in itself, a standard but merely a set of stylistic guidelines for API designers defined by an academic paper written by Roy Fielding, a co-author of the HTTP standard (see below).

As a result, APIs are sometimes described as ‘RESTful’, meaning they adhere to the basic principles defined by REST. These days, publicly exposed APIs are more likely to be RESTful than SOAP-based. Central to the idea of a RESTful API is that the things your API deals with are identified by a URL (Uniform Resource Locator), the web’s equivalent of an address. In our case, that would mean that each participant, schedule, result, etc. would be identified by its own URL.


RESTful APIs draw heavily on HTTP. HTTP stands for HyperText Transfer Protocol. It was invented by Tim Berners-Lee and forms one of the key inventions that underpin the web as we know it. Although conceived as a way of publishing HyperText documents (i.e., web pages), the underlying protocol is really just a way of sending messages. It defines the virtual envelope into which these messages are placed. HTTP is familiar as the prefix to most URLs.


Finally this brings me to OData. OData just stands for Open Data. This standard makes it much easier to publish RESTful APIs. I recently OData in the post, What is Odata, and why is it important?

Although arguably simpler than SOAP, OData provides an even more powerful platform for defining APIs. For some applications, OData itself is enough, and tools can be integrated with no additional programming at all. The PowerPivot plugin for Microsoft Excel is a good example. Using Excel you can extract and analyse data using the Questionmark Results API (itself built on OData) without any Questionmark-specific programming at all.

For more about OData, check out this presentation on Slideshare.

Conference Close-up: Options for Integrating with Questionmark Perception

Posted by Jane Townsend

I’m pleased that Steve Lay, Questionmark’s Integration Team Lead, will be with us at the Questionmark European Users Conference in Brussels to talk about various ways to integrate Questionmark Perception with other systems.

Steve’s presentation will focus on using QMWISe (Questionmark Web Integrated Services Environment) to integrate with Questionmark Perception.

Steve Lay

I asked him for a few details about his subject:

What are the key methods for integrating Questionmark Perception with other systems?

The first and simplest is something we call PIP – Perception Integration Protocol. This enables people to create special web links that in turn allow participants to go straight in to launch and take a test. We can even include things like single sign-on in this type of integration.

The second is to use package standards — such as SCORM or AICC – which internally build on the PIP protocol and provide a standards-based approach to integrating with learning content.

Our other method of integration, called QMWISe (Questionmark Web Integrated Services Environment), is a web services-based integration. You have to be a programmer to work with QMWISe, but the reward is a much more powerful integration, for example the synchronization of people information with Perception. You get many more options with this method, which more than compensates for the extra work needed at the programming stage.

Could you tell me more about the more powerful integrations that QMWISe makes possible?

With QMWISe, you can automatically schedule assessments to people and manage other aspects of the assessment process in a variety of ways. It can be used in a portal to integrate user data and for single sign-on: you can then connect straight through from the portal to Perception. It enables the synchronization of people information from, say, HR systems or student information systems:  in particular you might track changes to the people information held in these external systems. Custom programs can then push these changes through QMWISe to Perception.

The QMWISe method also enables users to develop deeper connections to LMSs. This is the technology we use in our Connectors such as the integrations with the SAP Learning System and Blackboard.

How are customers using QMWISe at the moment?

Perhaps the most popular way we are seeing customers use QMWISE is to integrate something like an external portal with Perception. This could be something like a Learning Management System (LMS) or a company portal. They typically provide single sign-on and show information about assessments that are available. They often find that this can be done more easily than they think by using QMWISe. Customers often use QMWISe to synchronize people information, as I mentioned before.

Who will benefit from attending your presentation?

In my opinion anybody who is thinking of doing integration with Perception will benefit. They’ll have the opportunity to find out what the options are, although we’ll be looking at web services integration in particular. People interested in deeper integration will benefit the most from the presentation. We’ll show a couple of typical applications to get things started. So if you’re using one of these common applications you’ll find something you can identify with and may even get to take home some recipes you can work with.

We hope you will be able to join us at the conference from 9 to 11 October. Click here to register.

QMWISe, Portals and Single Sign On

I had a great time at the European Users Conference in Amsterdam.  Thanks to Stoas for their key role in making this wonderful event happen! Stoas are a learning consultancy based in Holland that provides Questionmark Perception-based solutions to education and business there.

As Questionmark’s integration products owner, I was especially interested to see  plenty of sessions that looked at integration issues, from customizing the templates used during assessment delivery right through to integrations with customer portals. I wish I’d had the opportunity during the conference to attend some of the best-practice sessions that were timetabled alongside my own. Fortunately, the conference has a dedicated space on our Community Spaces system and many of the presentations are appearing there so that I can catch up — thank you!

One session I did get an opportunity to go to was a session presented by Stoas themselves on their use of QMWISe (with a bit on templates). QMWISe is the name of our web service application programming interfaces (APIs). With QMWISe, system integrators can link assessment management into their other systems. It also allows programmers to create custom user interfaces to suit their own processes.  QMWISe is a key component of our open assessment platform.

I liked the way the presenters talked about how they distinguish between single sign-on and what they described as “single log-on”. Traditionally, single sign-on means a single challenge followed by access to multiple systems. For example, you might be prompted for your user name and password when you log in to your company portal and, from there, access many of your organization’s systems without having to identify yourself again.

With a common, weaker form of single sign-on, the same identity is used across multiple systems even though the user is challenged separately as they access each one. Stoas used the term single log-on when referring to the stronger requirement and demonstrated a system that used QMWISe to obtain a single log-on from a customized learning portal into Questionmark Perception. The presenters went on to show us an interesting dashboard view that used a blend of QMWISe and custom database queries where no suitable API exists (yet!).

The difference between sign-on methods can be quite subtle. I expanded on some of the common models of providing participant access in my own best-practice session. For workers or students with personal computers, a familiar pattern is a “remember me” checkbox. This causes the Web site to store the access credentials in the user’s Web browser as cookies, reducing the need for a single log on. (Windows Authentication on PCs works in a similar way.)

In the future, single-sign-on complexity seems likely to be handled directly by the system administrators who install and configure Web servers. Plug-in modules for web servers are now available that allow an organization to choose from a variety of different authentication systems (also known as “identity providers”) to protect the web applications they host.  For on-demand services, standard protocols are emerging that allow customers to link to their chosen identity providers without having to host the Web application at all.

Now I am looking forward to the U.S. 2011 Users Conference, where I hope to hear some more excellent presentations.

Community Editions: Connecting Perception to Moodle 1.9

steve-smallPosted by Steve Lay

Last month I wrote about our new Community Edition program under which we’ll be releasing selected integration products as free-to-download Community Editions distributed under open source licenses.

Although this program represents an exciting new way to involve the development community, Questionmark is no stranger to working with open source. Moodle is a popular learning management system that is developed by an active community of open source developers. Questionmark has always distributed its connector products for Moodle under a similar open source license, so it is no surprise that our new connector for Moodle 1.9 is available as a Community Edition.

The connector is written in the widely-used PHP system used by Moodle itself and uses QMWISe (Questionmark Web Integrated Services Environment) and PIP (Perception Integration Protocol) to allow Perception tests to be included as activities directly within Moodle courses.

You can find our more information about the connector and the development project behind the Community Edition from our new developer site: On the site, you’ll find information about our Application Programming Interfaces (APIs) and all of our Community Edition projects. The Community Edition Moodle Connector page on the development site also links to the development project, which is hosted on the popular SourceForge system where you can download the latest version and even browse the code!

And finally, we’ve used Moodle as a development platform for the developer site itself, which means that we can demonstrate the connector working directly from the site. Look for the “Try It Out!” section on the Community Edition Moodle Connector page and see if you can answer my quick quiz on the main features of our Community Edition release program.

Introducing Community Releases: Connecting Perception to Blackboard 9

steve-smallPosted by Steve Lay

As readers of this blog will know, QMWISe is the name given to the set of web-services provided by Questionmark for integrating third-party applications with the Perception assessment management system. Used in conjunction with the Perception Integration Protocol (PIP), QMWISe is the starting point for developing connectors that integrate Perception with other applications like learning management systems.

The scope of QMWISe has grown over the years as John Kleeman reported in “Seven years of web services for easier integration”.  With over 100 methods to choose from, knowing which methods are best for your integration project can be a challenge.

Developers often work best by copying real examples of an interface in action.  It makes perfect sense for us to release the code for the connectors we develop ourselves in source code form to help supplement the simpler code examples available in the reference guide.

So I’m pleased to announce that we now have a new connector to integrate Perception with Blackboard Learn 9 and that this connector is available as a Community Edition under an open source license. The connector is a Blackboard building block and uses QMWISe and PIP to allow Perception tests to be scheduled within Blackboard courses.

The motto of the open source community is “release early, release often” and we’re capturing that spirit with the concept of a Community Edition.  A Community Edition is an important milestone on the way to developing full support for an integration product, however, it doesn’t represent supported software itself!  The Community Editions are aimed at a more technical audience who want to test out the latest version of the software before it is available as a supported release from the Questionmark website. We’ll be making updated versions of Community Edition software available on a regular basis as the development projects that underpin them progress.

The new Blackboard connector is not just available free of charge under an open source license. We’re also opening up the development process itself by hosting the project at OSCELOT, a community of developers dedicated to creating and maintaining open source software in the e-Learning community.  You can see how the project is progressing and download the latest version yourself from the Blackboard Connector page on our new developer support site.

And we’re not going to stop at Blackboard!  Look out for Community Editions of other integration connectors coming soon….

Seven years of web services for easier integrations

john_smallPosted by John Kleeman

A key objective for Questionmark Perception has been to make it an open system that handles integrations easily. Assessment isn’t usually standalone; most organizations need to integrate it with other organizational systems. There are many ways to integrate with Perception, including via our support of standards such as AICC, HR-XML and SCORM, but where standards are not available we recommend integration via our QMWISe web services.

Although web services are routine today, Questionmark adopted them very early: June 6th, 2009, marks the 7th anniversary of Questionmark’s web services, which we call QMWISe. (See our 2002 press release here.)

Two great advantages of web services are that you can call them from almost any platform or system and they are independent of the technology used. So you can code web services in almost any programming language or environment and interface with Questionmark Perception.

Another beauty of web services is that code written back in 2002 will still work in 2009,and code written today should still work in 2016! In the last seven years, there have been very substantial changes to the Questionmark Perception database format and to the user interfaces, but the APIs (Application Programming Interfaces) remain the same. And exactly the same code written then to call QMWISe will still work now. We have ambitious plans to continue developing Questionmark software in new ways, but code our customers write today for QMWISe will still work in the future.

Back in 2002, there were 37 web services methods. Over the years, we’ve added lots more methods and there are now 109. Example web services methods are to create a participant, schedule a participant or give a URL to get access to an assessment.

Many of our customers use QMWISe to integrate with Perception, so that as Perception versions change, their code can remain safe. We or our partners have also used QMWISe to build connectors to many other systems, including Blackboard, Moodle and uPortal. We also call QMWISe within our own software. For instance, Questionmark to Go passes all its results back via web services, and in the future we’ll be trying to use QMWISe more within other code–to “eat our own dog food” and ensure that QMWISe is fully able to be mission critical. By using web services within our own code, we will be driving QMWISe forward to cover more capabilities and so open up the platform to support a wide range of solutions integrated with third party applications.

One key lesson that we’ve learned over time with web services is that commitment and continuity are vital. No one wants to interface with a system that will change. And you need to have good documentation with examples, good scalability and good diagnostics–for instance a log of all SOAP traffic. We recommend that other developers consider making web services available from their own systems: it’s an excellent way of integrating.

In the future we’ll be announcing further improvements to QMWISe that should make it more useful for developers and provide easier ways for customers to integrate with Perception. Questionmark strongly recommends that anyone developing integration into our software uses our web services. We welcome questions, comments and suggestions for improvements, so let us know what you think!