MSG Architecture

MSG Server and Client Architecture Diagram

MSG AJAX Web Client

Source module: MSGClient

Quick View

This is the main MSG user interface. You can login via this interface at msg.open.ac.uk/msg (no longer available)

Connection, contacts, messaging and presence states are all handled via calls to the BuddyXML service described below via Javascript’s XMLHttpRequest function. An important fearture of this web client is that is supports instant notification state changes and messages. It achieves this by use of the BuddyXML wait command which is designed to hold its response until events occur. So, it could be said that the client spends most of its time waiting for responses from asynchronous requests to buddyxml service. This is important because the persistent socket communications normally used to implement an XMPP/Jabber client are not possible in the web browser without resorting to third party plugins or applets. The ‘cost’ of doing this type of http binding may not be as significant as you might expect since actual browser socket reconnections are reduced by use of http keep-alive.

BuddyXML

Source module: BuddyXML

Quick View

BuddyXML is a service that acts as the HTTP bridge between client and jabber server. It opens a persistent XMPP connection to a Jabber server, one for each connected user (i.e. tomcat session).
The service maintains an internal queue of a subset of XMPP events. The events are dispatched to clients when they are requested by a call to the service.

BuddyXML supports JSON style output to work around the “Same Source Connection” security constraint that applies to javascript XMLHttpRequest. This output mode is used to implement cross-server mashup integration with MSG. For example, this mode can be used to add presence, notification and click to chat functionality to other web applications or portal type environments.

The purpose of the link between this service and the Openfire mashup plugin is to provide an authentication route to Openfire that doesn’t involve creating a new jabber session. The link allows a user to attach to a pre-existing session without creating multiple jabber sessions. For example, if a user logs in using MSGAlert, then logs in again using the MSG Client. BuddyXML can use this authentication route to verify credentials before attaching the client to the existing BuddyXML session.

For tutorial and test page for BuddyXML service go to msg.open.ac.uk/buddyxml-tutorial/ (no longer available)

MSG Client API

Source module: MSGClientAPI

Quick View

This is a JavaScript library that allows a very quick route to adding MSG presence and click to chat functionality to a web site.  Note that this API uses the JSON output mode of BuddyXML to allow cross server AJAX integration. Note that although this API was designed for web integration, it was not used to implement the MSG AJAX Web Client described above.

For more information go to: /msg/developer/msg-api-guide/

MSGAlert

Source module: MSGAlert

Quick View

A small application that maintains Jabber connection and provides notification of new messages.

When logging in using MSGAlert, the application opens a connection on port 5225 to the Notifier Service. The username, password and Jabber host are transmitted to the Notifier Service, which in turn makes a call to the BuddyXML servlet to connect to the Jabber Server. 

Once connection is established, the id of the tomcat session created is returned to MSGAlert. It retains this session id which is used when launching the webclient. It allows the browser to attach to the tomcat session created by the Notifier Service.

MSGAlert also supports jabber presence changes. Presence status can be set in either MSGAlert or MSG WebClient, and this status is immediately reflected in both places.

Openfire Jabber Server

Source module: Openfire

Quick View

An open source Java based Jabber/XMPP server, provided by Ignite Realtime http://www.igniterealtime.org/  This server supports flexible mechanisms for overriding Authentication, User and Group provision, and facilities to extend services via plugin modules.

We are currently using versions 3.3.1, but it requires a small modification to the code base to class org.jivesoftware.openfire.session.ClientSession in order to support a mismatch between authenticated username and JID username. E.g. when using session tokens for SSO authentication.

Moodle MSG XML Services

These services provide a link Moodle user, group and authentication information for Openfire. wildfire-extra.jar uses these services to request moodle user information that needs to be replicated in the Openfire database.

To enable the Moodle replication within wildfire-extras, set the openfire system properties e.g.:
moodle.enabled = true
moodle.uri=http://al2273.vledev.open.ac.uk/ouvle/

For further information goto: http://technologies.kmi.open.ac.uk/msg/developer/msg-moodle-block-installation-guide/

Wildfire-extras.jar

Source module: WildfireExtras

Quick View

This comprises a set of Java classes that override providers of Groups, Users and Authentication within the Openfire server.

Wildfire-extras authenticate flow chart

Once a user is authenticated, this initiates a process (on another thread) that replicates information for that user. The action of this replication causes openfire user and group database to be updated with any changes that are required. When changes to user rosters are required, these are automatically propagated to any affected users that are logged in.  

Mashup Plugin

Source module: WildfireMashupPlugin

Quick View

This Openfire plugin was primarily designed to provide presence monitoring service and to allow authentication against the server without creating a jabber session. This authentication route is used to authorize BuddyXML session attachment for pre-existing user connections. For example, if a user logs in via both MSG Client and MSGAlert, these two connection sources can share a single BuddyXML session thus eliminating problems resulting from multiple jabber connections for a user.

User Web Admin Plugin

Source module: WildfireUserWebAdminPlugin

Quick View

The built-in Openfire admin console is only designed for ‘super user’ administartors, so this plugin was developed to allow ‘ordinary’ users to perform some admin operations, eg. password setting, group membership editing, uploading maps etc. This plugin can be accessed via: http://msg.open.ac.uk/admin

LDAP Server

An LDAP server can be used to provide authentication, user and group information for the Openfire Jabber Server.

To configure LDAP integration with Openfire, the openfire.xml configuration file must be edited to match the user and group schema used on the LDAP server. e.g.

Note that although Openfire has built-in classes for LDAP User and Group provision, their implementation suffers from a major drawback. It does not allow for dynamic changes to the LDAP user and group information. This means that changes are only reflected in Openfire when cached Users & Groups expire (after 6hrs) from the Openfire cache. This problem is addressed by the custom provider implementation in wildfire-extras.jar, where ldap users and groups are replicated in the openfire database at the point of login.

To enable the LDAP replication within wildfire-extras, set the openfire system property:
ldap.enabled = true

XMPP/Jabber Client

Openfire implements the standard XMPP/Jabber protocol and should allow connection via any Jabber client (e.g. BuddySpace, Spark, Exodus, Adium etc.…)