In CHA, server side holds the remote context; and the client side holds the local context. Client side acts as a facade for the server side. They connect each other by the J2EE EJB technology. In CHA server side, there is a remote context tree, which has two levels: root level and normal level.
The root level is consist of the contexts above the session context. The other contexts belong to the normal level. In the runtime environment, the data shared among different sessions are stored in the root level of the context tree. Such shared data will be cached statically in CHA server side. The updates of the root level contexts cannot be written back to the DB.
The CHA programming model does not allow the concurrent update to the same data in a CHA server. And it is recommended that the shared data in the root level context is read only, especially in cluster environment. Besides, inside a session, avoid using different threads to update the same data in a session context or the contexts below the session context.
The context in local mode can be an anonymous or pre-defined Context created by the application as a part of its business processing. Contexts of this nature are used as temporary storage collections that may be passed as a unite to other logic within the same application. These contexts are not shared outside of the VM in which the application runs, except as a part of a serialized object stream. In this regard, they are the same with any other local serializable object. There is one way to change the mode of a context from local to remote with the API of setRemote().
The local Context has many advantages over the distributed (Client/Server) Context:
▪ Higher performance with no networking or EJB-included latencies.
▪ Simpler operation with no EJB framework interaction. All operation code is contained within the application.
▪ Smaller system-wide memory usage. The single self-contained component has no client and server code and data to manage.
▪ Least impact on client code which uses direct access to Data Element values as a means to update Context content, because the Context is local to the application, operations that depended on this fact can operate without any change.
▪ Local contexts are serializable and may be shared using messaging techniques such as RMI serialization or serializable parameter. However, messages of this type or parameter can became large depending on the content of the local-mode Context.
The disadvantages of the local context are:
▪ Data cannot be shared within the Context hierarchy.
▪ Local Contexts may not take part in a Context hierarchy except as leaf nodes. While you can chain a local-mode Context to a remote-mode Context, you cannot chain a remote-mode Context to a local mode Context.
▪ Local-mode contexts may not be constructed from definitions in the DSE xml files. These are dynamically created and are anonymous.
▪ Local Context cannot be persistent by CHA server. Thus the fail-over support cannot be leveraged on CHA server itself.
Note One possible way to support fail-over is to persist Local Context into HttpSession managed by WebSphere.
Along with the client mode of the Context class, a remote mode is also required at the server end of the subsystem. The remote mode performs the actual data artifact collection and management in the service side rather than in the client side. In fact, this main difference between this mode of operation and previous versions of the toolkit is the primary value of CHA.
The remote mode Context is created as a result of creating a CHA Instance Session Bean and Entity Bean. For detailed information, see Using CHA.
Remote CHA is the key value of UDTT and CHA. It's advantages are:
▪ Data in remote server can be shared within the Context hierarchy and another container so that data stored in CHA server can be re-used and accessed cross multi-JVMs.
▪ Remote Contexts may be persisted in database that is controlled by CHA server itself. With this persistence capability, the data can be restored by another CHA server instance. Fail-over support is provided and managed by CHA component.
▪ Remote Context is constructed from definitions in the centralized context xml definition files.
The CHA facilitates scalability and availability by providing the necessary capability to share among containers and provide persistency support to data put into the CHA Server. The value of CHA is that CHA can greatly simplify the application architecture and reduce the need for extensive program changes when new screens or new logic or new channels are added or changed. Besides, CHA also simplifies the extra coding overhead required for communication among the many shared components. For example, if more business services need to communicate with existing services, no extra API is required to be added for existing services to obtain data from new one, and new services do no need to understand and use new APIs provided by the existing services. The new and existing services can refer to the enterprise-wide well-defined CHA hierarchy, even if they are across containers.
Leveraged on CHA, the complicated communication and architecture between multi business services and multi containers will be greatly simplified as shown in the figure below:
Note Shared CHA does not mean Remote CHA only. Although "share" is basic advantage for Remote CHA, the Local Context can still be shared if you define context as business service interface parameter.
