Skip to end of metadata
Go to start of metadata

Chat Tool

1. Introduction

1.1 Purpose and Scope

This document is to illustrate the system design of Instant Messaging (IM) and Chat, technology choices and rationales.

Both IM and Chat are related technologies to each other and often handled together. In LAMS, we can use Jabber technology for the following reasons that will cut down the development efforts significantly.

  1. Based on open standard (not commercial or proprietary protocols).
  2. IM/Chat server can be an independent development effort which can readily plug into the LAMS.
  3. Libraries and modules are available for interface code to integrate both.
  4. This model serves as an example of using another server integrated into the LAMS as a Tool.

In LAMS, we can use the technology as two components:

  1. Chat Tool: chat forum (group chat) is a synchronous communication channel between teachers and Learners while in a sequence.
  2. Instant Message (IM) Tool: A synchronous and asynchronous communication channel while outside sequences. It is still class-based. It includes functionalities, such as, on-line instant message delivery, off-line message, 1-to-1 chat, group chat, group announcement. The group announcement can be site-wide involving all groups.

N.B. The IM Tool, in fact, can do both IM and Chat and could be referred as ?IM/Chat Tool?. To avoid the confusion, however, the term ?IM Tool? is used in this document. Also, ?IM and Chat Tools? is used when both Tools are referred.

The contacts available to users will be based on the lessons in which Teachers and Learners are involved. The messages will be delivered immediately if the recipient is online, or will be stored for later delivery if the user is offline. If the user is in a chat session, the message will be displayed on the message pane (1-to-1 chat or group-chat). Otherwise, for IM Tool, it may be displayed as a closed envelope (marked as unread) in a ?delivered message? list. For Chat Tool, the end user may be able to view old messages by some means (such as by scrolling back on the chat pane). This is because the Chat Tool will not have the full Jabber capabilities and will show limited interfaces that are only required to do Chat; e.g. it will be suppressing message list or contact list.

Normally in Jabber the user can login/search/connect to other Jabber servers, add/delete users and join/disjoin groups. In the LAMS, however, the user gets a pre-selected server automatically (no server choice or conscious login), gets the selected group/user lists from the server, and they cannot modify the lists. For version 1.1, it is also requested to suppress posting from Learner(s) to Learner(s) in IM Tool.

1.2 What needs to be designed/built

  1. IM/Chat server installation and configuration. Modification may be needed for logging (if the glue codes do not do logging and portfolio export).
  2. IM Tool GUI (modified web front-end for a Jabber IM client)
  3. IM Tool (Java code), designed as a LAMS System Tool Java component as well as a Jabber client. Since this component has System Tool APIs, it installs normally as a LAMS System Tool. It communicates with web GUIs and LAMS core. It is responsible for the LAMS specific functions such as group set-up, moderating, portfolio. However, actual IM & Chat functionalities, such as messaging (normal, chat or group), presence and roaster, are delegated to a Jabber server.
  4. Chat Tool GUI (modified web front-end for a Jabber Chat client)
  5. Chat Tool Java code, designed as a LAMS Activity Tool Java component as well as a Jabber client. Since this component also has Activity Tool APIs, it installs normally as a LAMS Activity Tool. It communicates with web GUIs and LAMS core. It is responsible for the LAMS specific functions such as authoring, runtime group set-up, moderating, portfolio. However, actual IM & Chat functionalities, such as messaging (normal, chat or group), presence and roaster, are delegated to a Jabber server.

1.3 Constraints

The LAMS has additional features to or suppressed features from the standard Jabber capabilities.

  • In LAMS 1.1, IM Tool only works outside Designs.
  • Chat Tool only works inside Designs.
  • IM and Chat Tools use ?shared groups? preset by the LAMS. This means that users may not add contacts to their groups. Also, users are automatically subscribed and subscriptions cannot be refused or cancelled, although their statuses may be changed if the user is away or the Moderator changed the status of the user. Teachers can add/delete users to/from the Lesson from the Monitor but not in the IM and Chat Tool. Teachers may deactivate or hide Learners from Contact list in Monitor, which show/hide the users from all clients. (N.B. Note that Staffs are not users.)
  • In both Tools, messages cannot be blocked.
  • In both Tools, group announcement (headline or error) cannot be blocked.
  • In Chat Tool, Learners may not choose to move to 1-to-1 chat. It is always group-chat.
  • In Chat Tool, Teachers may choose to initiate 1-to-1 chat from Monitor.
  • In Chat Tool, Teachers may not appear to join in chat session.
  • In LAMS 1.1, in IM Tool, Learners may not send messages to or chat with other Learners.
  • In LAMS 1.1, in IM Tool, Learners may not send group message or chat with multiple users.
  • In LAMS 1.1, in both Tools, Learners may not send group announcement (i.e. headline).
  • Both Tools may not communicate with any other IM/Chat servers (Yahoo!, MSN, etc).
  • Both Tools may not communicate with any other Jabber servers.
  • Both Tools may not search other Jabber servers or search groups on the local server.
  • In both Tools, messages are plain text (neither with any mark up nor with any attachment).
  • Both Tools work on port 80 (to be confirmed).

2. Functional Model

2.1 General Functional Description

2.2 Functional Requirements

Authoring: Advanced Tab

On the advanced tab we have the usual suspects plus the special shared resources ones:

  • Locked when finished
  • Filter keywords. This features should be a checkbox that when checked allows the teacher to enter keywords into a textarea input separated each of them by a space.

2.3 Use cases and User scenarios

IM Tool

Primary Actor

Use Cases

Teacher

Create a Lesson. This creates a unique IM Group ID in IM Tool. The IM Group ID is used to create the actual Jabber Group with Contacts in a Jabber server

Teacher, Learner

Start using the tool. IM will show group list, user list (regardless of the groups), users (when a group is opened) and messages read/unread (for the group and all together).

Teacher, Learner

Posting a message to another user. Learner can?t post to another Learner in version 1.1.

Teacher

Posting an announcement (spam the entire class)

Teacher, Learner

Receive a message. IM Tool must be available even if you are not in Learner UI. IM clients must refresh to show "real time" messages. If the user is in a chat session with the sender, it should appear in the Chat pane. Otherwise, it should appear in the message list as a closed envelop. An off-line message appears as a closed envelop.

Teacher, Learner

Read a message

Teacher, Learner

Reply to a message

Teacher, Learner

Read an announcement. Announcements appear as pop up when the user is on-line, and you must read it. An off-line announcement must appear as pop up next time the user logs in.

Teacher, Learner

Read/print history (chat history with a group)

Teacher

Read/print logs (IM transactions)

Teacher, Learner

Read/print portfolio (user can be selected)

Teacher, Learner

Logout

Teacher, Learner

Refresh connections

Teacher

Hide/show messages

Teacher

Hide/show, activate/deactivate Learners

Teacher

Archiving a Lesson archives the IM Group as well.

Teacher

Deleting a Lesson will delete the IM Group as well.




Chat



Primary Actor

Use Cases

Teacher

Create a Lesson with a Sequence which has a Chat Activity. This creates a unique Chat Group ID in Chat Tool. This ID is used to create a group-chat Group in Jabber server.

Teacher, Learner

Start using the tool. The user will see all users present. Also, the user may chose to view past messages.

Teacher, Learner

Posting a message to the group.

Teacher, Learner

Read old chat messages before joining

Teacher, Learner

Read/print history

Teacher

Read/print logs

Teacher, Learner

Read/print portfolio

Teacher

Complete the Activity

Teacher

Log out chat

Teacher, Learner

Refresh connections

Teacher

Hide/show messages

Teacher

Hide/show, activate/deactivate Learners

Teacher

Force-complete Learners

Teacher

Author Activity content, properties etc.

Teacher

Post-set define-later content in Monitor

Teacher, staff

Preview Activity

Teacher

Archiving the Sequence archives the Chat Activity

Teacher

Deleting the Sequence deletes the Chat Activity

2.4 Actions



Action

Description

createIMGroup

When a lesson is created, IM Group is also has to be created with the Jabber server. A normal Tool can do this when a user of the Group uses the Tool for the first time. The use of this Action is the Monitor.

createChatGroup

The group may be created when the first user gets to the Chat Tool Activity. In this Group, a Learner can send messages to other Learners with group-chat messages. Although the Monitor must participate to be able to see messages, he/she must be hidden. Also, the Monitor can see messages in logs or produce profiles. 1-to-1 Chat or IM is prohibited.

getIMTool

Get the IM Tool GUI

getChatTool

Get the Chat Tool GUI

IM Tool Server Interaction

Learner launches Learner GUI -> Learner GUI requests IM GUI -> IM GUI logs on and requests a list of IM Groups -> IM GUI displays IM Groups.

Monitor launches IM GUI in Monitor -> IM GUI logs on and requests a list of IM Groups -> IM GUI displays IM Groups.

Learner selects a Group and a Teacher (or Teachers?) -> post a message to Teacher(s).

3. Data Model

3.1 Description

3.2 ER Diagram

4. Presentation Tier

Componet Diagram

4.1 General GUI Layout

4.2 Authoring interface and flow

4.2.1 Object stores in the session

4.3 Monitor interface and flow

4.3.1 Object stores in the session

4.4 Learner interface and flow

4.4.1 Object stores in the session

4.5 Admin interface and flow

4.5.1 Object stores in the session

4.6 Export Portfolio interface and flow

4.6.1 Object stores in the session

5. Business Model

The business model of the LAMS IM and Chat Tools has two parts. The first is the Tool Shell code, which implements the IM and Chat Tools with Tool API. The second part is the messaging handlers. The actual implementation of the messaging handlers is delegated to a Jabber server and a client code.

The Tool codes have APIs to set up groups and send messages (normal, chat or group), presences and roasters. Since Jabber has slightly different APIs to do these than what the LAMS require, the Tool codes must convert or to translate the communication between the LAMS and the Jabber server/client.

Further the Tool codes can be divided to front-end and backend codes. From the front-end, normally it would be irrelevant that the backend is actually using another server since the backend implementation details should be a black box. In this case, however, the front-end should also use a Jabber client to generate communications between the front-end and backend. Otherwise, we would have to use our own communication protocol in the front-end and the backend should translate them to Jabber communications. Such a front-end protocol would be redundant. Alternatively, we could intercept the Jabber stanzas and modify them for what the LAMS requires at the backend maybe using a filter pattern, but doing so also introduces unnecessary complexity and should be avoided.

For this reason, the simple solution appears to be that the LAMS Tools must supply a modified Jabber Web client to present a Web GUI. The Web client directly communicates with a Jabber server just like a normal Jabber client. However, the client will be modified to obtain additional features, such as auto-login when the client starts, and also to suppress normal Jabber functionalities, such as (1) search users and servers, (2) Learner posting, or (3) certain group chat (described in above sections). This way, we do not have to invent a new front-end protocol for or to intercept the Jabber messages sent between the client and the server.

Also, in this document, it is assumed that a JSP Jabber client will be used that may be based on JWChat which uses HTTP-binding (JEP-0124: HTTP Binding) of the Jabber protocol and port 80.
It is also possible to use a Flash client for the same purpose, although it will be using the standard Jabber stanzas and XML port on port 5222 (non-SSL or SASL/TLS) or 5223 (SSL). There is also a Flash client library for XMPP available for ActionScript (XIFF) . Similar to JWChat, the client must be modified to add auto-login feature and also to suppress unwanted features (see above).

6. Data Model

6.1 Database schema

6.2 Data Definitions

7. Sequence Diagram

If required/needed

8. Testing considerations

9. Other technical considerations

10. Third Party Libraries

Third party libraries used in chat tool:

Library

License

Reference

Javascript Jabber Client Library (JsJaC)

LGPL

http://jsjac.jabberstudio.org/

Smack API

Apache (modified)

http://www.jivesoftware.org/smack/

11. References

  1. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
  2. JEP-0140: Shared Groups <http://www.jabber.org/jeps/attic/jep-0140-0.1.html>
  3. JEP-0093: Roster Item Exchange <http://www.jabber.org/jeps/jep-0093.html>.
  4. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.
  5. JEP-0083: Nested Roster Groups <http://www.jabber.org/jeps/jep-0083.html>.
  6. JEP-0033: Extended Stanza Addressing <http://www.jabber.org/jeps/jep-0033.html>.
  7. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
  8. JEP-0124: HTTP Binding <http://www.jabber.org/jeps/jep-0124.html>.
  9. XIFF <http://www.jivesoftware.org/xiff/>.
  10. Drawing from the discussion of architecture (Yoichi, Anthony and Ernie) See chat_im-architecture.jpg (attached file)
  • No labels