---

Implementing CCOW Context Participants

A context participant is an application that gets or sets context data from a context manager. The LEADTOOLS CCOW SDK supports both ActiveX and Web participants.

Web Context Participant

A LEADTOOLS Web Context participant consists of two major components. The following components are needed in order to enable a web application to become a context participant:

1. A Web Service (Leadtools.Ccow.Services.CcowParticipantService): The web service defines the CCOW web participant service contract, which enables a web context participant to be notified about context changes.

   This service is responsible for receiving context change notifications and sends the updates to the Web application.

2. Javascript interface (Leadtools.Ccow.js): Implementation of CCOW web components.

Perform the following steps to enable a web application to become a context participant:

• Host the Leadtools.Ccow.Services.CcowParticipantService web service
• In order to receive the participant notifications, create an object of the ClientContext class in the web application and register the following events:
  • CommonContextTerminated
  • Ping
  • ContextChangesAccepted
  • ContextChangesCanceled
  • CommonContextTerminated

ActiveX Context Participant

To enable an application to become a context participant, create a class that implements the Leadtools.Ccow.IContextParticipant interface in order to enable the following methods:

• CommonContextTerminated
• ContextChangesAccepted
• ContextChangesCanceled
• ContextChangesPending
• Ping

The class implementation is required to be a COM object. As a result, the ComVisibleAttribute is required when declaring the class.

Participating in a secure context system for Single Sign-On (SSO)

In order to achieve single sign-on (SSO), one application must be designated as the application for authentication. The CCOW demos that ship with the LEADTOOLS CCOW SDK have already designated the CCOW Authentication sample application as the application to perform authentication.

When launching any of LEADTOOLS CCOW participation applications with SSO enabled, the participant application will be user- and patient-linked. Otherwise, the participant application will be only patient-linked.

CCOW Context Participant Best Practice Recommendations

• If an application is not running in the context, then no CCOW icons should be displayed. Otherwise, the CCOW link icon should always be displayed.
• The CCOW icon should be shown in the broken-link state if the application failed to join the common context, but the application should continue to run in a stand-alone manner (if possible) and the user should be informed.
• When resuming or re-joining a context session after being suspended, applications should automatically tune to the current context.
• Applications should behave the same way whether they are responding to an externally-initiated context change transaction or to equivalent user inputs directed specifically at the application. Therefore, an application should go to whatever screen it would go to if the user had explicitly selected the object now in the context via the application. In so doing, the application should also apply the same business, access privileges and security rules that it would have had the user interacted directly with the application.
• The application should not change the context if it is tuned to the patient, user, etc. that is being represented in the new context. Instead, the application should respond to that part of the context that has changed.
• Enabling users to explicitly break the application's context link at any time should be configurable, a capabiliity that by default should be disabled.
• If the break-link configuration is enabled, then the break-link option in the dialog shown when a conditional accept or busy application state arises should be presented by the application.
• If the break-link configuration is disabled, then the break-link option should also be removed from the dialog shown when a conditional accept or busy application state arises.
• When the break-link configuration is disabled and there is a busy application, the dialog should simply state that the selected action (change) cannot be completed (because of the busy application). An "OK" button should be supplied to close the dialog.
• If an application has the ability to save unsaved data then it should do so and unconditionally accept when a context change transaction occurs, in order to minimize the frequency at which CCOW dialog boxes are presented to users.
• Avoid or at least minimize the use of modal workflows (dialogs) so that the user is allowed to indirectly change the state (e.g., the patient it is "tuned" to) via interactions with other applications.
• Applications should be configurable such that each context subject supported by the application can be enabled or disabled. The default configuration should be that all context subjects supported by the application are enabled.
• An application should always verify that the user that it is about to automatically log on is a valid user. Also, it should always enforce the same access privileges for a user who logs on via a CCOW User Link that it would if that same user directly signed onto the application.
• CCOW requires application inactivity timeouts to be configurable (including being disabled).
• Applications that are not interested in a particular subject should filter out that subject in order to reduce context change-related messaging overhead.
• Applications should minimize the need to conditionally accept context survey changes, which cause CCOW-related dialog boxes to be presented to the user.
• Applications should always provide a reason for their conditional acceptance. Also, a meaningful application name should be specified in the JoinCommonContext method so that the user can more easily determine which application generated the conditional acceptance message.
• An application should ensure that it does not take focus from another application when responding to a context change.
• Applications should not present dialog boxes (especially modal dialog boxes) when responding to a context change transaction initiated by another application.
• Applications should not get the data for a secure context subject if a secure binding has not been performed. Applications should always validate the digital signatures that it receives before assuming that the signed context data is valid.
• When an application is instructed to terminate, it must leave the CCOW context.
• The use of configurable suffixes is required in order be compliant with the CCOW standard. Further, it is best that the entire subject name used by each application for each subject that it supports be configurable.
• Applications should be configurable so that it is possible to control what happens to the common context data upon logging off or terminating an application that is a participant in the context.
  • The default configuration should be that whether logging off of the application or terminating the application only the application is affected: the common context data should not be affected by the application when it leaves the context.
  • The other configuration option is that the user subject is set to empty when the user logs off of or terminates the application. This has the effect of logging the user off of the common context session. In this case the other context data should not be altered by the application when the user logs off or terminates. This recommendation pertains to clinical-style applications and not applications functioning as a user or desktop manager. The default configuration setting should be to log off of just the application.