Common Links and Synchronization
Common Links
In a common link system the context manager does not enforce access privileges for the context data in the context system. Any application can get or set context subject data in a common link context system. Optionally there can be mapping and annotation agents as part of the common context system. There can only be one mapping agent for each common subject. Similarly, there can be only one annotation agent for each annotation subject in the common context. The context manager does not enforce access privileges for either the mapping or the annotation agents in a common context system.
To join a common context session, an application interrogates the context manager’s principal interface. The context manager’s principal interface is retrieved from the point-of-use device’s context management registry. The application will receive a reference to the context manager’s ContextManager and ContextData interface. The ContextData interface establishes the initial context of an application and allows it to be a participant in the common context session.
An application can leave a common context session by informing the context manager via the ContextManager interface.
While the context manager manages the context and data changes and acts as a repository for the data. Its understanding of the data is minimal and unnecessary. New context items can be added over time without requiring changes to the context manager.
Application Synchronization
All applications are obligated to respond to context change notifications and to synchronize with the new context. Depending on the specification of each context subject, applications may or may not remain synchronized with the context until the next context change. The CCOW Context Management Architecture defines two data definition policies for context subjects regarding the state of synchronization:
- Constant synchronization of context data is required for all participants when a context subject specifies constant synchronization. Whenever the subject is set all applications that are linked to the subject need to change their internal states to maintain lock-step synchronization with the subject. Constant synchronization enables the creation of context sharing capabilities. For instance, for a Patient Link that supports the safe use of applications where user can expect constant synchronization across all applications.
- Temporary synchronization requires that applications linked to a subject synchronize their internal states with the subject whenever the subject is set. However, once an application has been synchronized, users can alter the state. Such changes can cause the application to become unsynchronized with the other applications. Temporary synchronization is used when having inconsistent synchronization does not introduce safety or security hazards for users.