LEADTOOLS CCOW Context Session Management

Context Session Management

A context session is made up of a set of applications and agents on a point-of-use device sharing context with each other. Multiple context sessions can be hosted on the same point-of-use device. However, only one of the sessions can be active at any given time. This allows different users to share a single device. It also allows a single user to have multiple context sessions on a device

A context session is created when the first application informs the context manager that it wants to “join” the context and it ends when the last application leaves the context session. Additional applications can join an active session to share a common context with the other applications in the session.

A user can explicitly create another context session. This is generally performed by a session management application specifically designed to provide session management functions for users. The CCOW standard allows applications to be designated to activate a deactivated context session. The session management applications are responsible for verifying the owner (i.e. user) before activating a session. The context manager can also ensure that only the designated applications are allowed to activate a deactivated context session. For example, the session management architecture enables a session management application to first authenticate the user before allowing the user to create a new session or activate an existing session. The session management application can do this either by serving as the application designated to authenticate users or by using a context action to request another application to authenticate the user.

The first context session is automatically activated. Any context sessions created after that are by default inactive until explicitly activated. Whenever a session becomes the active session for the device, the previously active session for the device is automatically deactivated. An application that previously joined another context session remains a participant in the (deactivated) session that it joined.

To enable session security(to prevent a user from accessing anyone else's sessions), applications are not allowed to join a deactivated session. Therefore, it is not possible for an application launched by one user to join a session that is owned by another user.

Creating a Context Session

There are two ways to create a context session.

1. By an application's request. If an application is the first to request a reference to a context manager, a context manager instance is created automatically. Additionally if it is the only context manager for the device the session that it represents is automatically active.
2. By a context manager. Any context manager can create a new session. When a new session is created a new context manager is created. Even though the new context session has been created, it is inactive until it is explicitly activated.

Deactivated Sessions

When a session on a device is activated the previously active session is automatically deactivated. Once a session is deactivated applications will be unable to join the session. This prevents applications that are associated with a user from becoming a participant in a different user's session. If an application tries to join a deactivated session the Context Manager will raise an exception.

Activating a Deactivated Session

The context manager of a deactivated session needs to be explicitly activated by an application that has been designated to activate sessions (usually a session management application). Once an inactive session is activated the previously active session is deactivated.

Session Termination

The context manager will be terminated when the last participant leaves the session. A context manager will also terminate if at least one application fails to join the session before a timeout. The timeout period is determined at implementation.