The core of CHA is the context. While CHA contexts are similar to the contexts in Java clients in that they contain data and have a hierarchy, they have an additional wrapping that enables them to exist in a distributed environment as an entity EJB.
Note The CHA contexts are completely separate from Java client contexts. Data in a Java client context only moves to the application presentation layer through HTTP requests and are then formatted into one or more CHA contexts.
A CHA context can be local or remote. When local, the context acts as temporary runtime storage. Local contexts are dynamic in nature and can be anonymous or defined in an external definition file such as dsectxt.xml. Their life expectancy is short and they expire when the business process or service that is using them ends. Business processes and services cannot share local contexts with each other outside of the JVM in which they are running except as a part of a serialized object stream. In this regard, a local context is the same as any other local serializable object. For more information, see Local Context.
When remote, the CHA context has a server side and a client side that acts as a facade for the server side. The server side consists of an entity EJB and a session EJB. Non-toolkit J2EE client applications access the server side directly as a normal EJB. Toolkit entities such as a service or business process access the server side only through the client side facade. The client and server sides connect to each other using J2EE EJB technology. For more information, see Remote Context.
In CHA, many context nodes are organized as a context tree. There is always a single path from the root node to one of the leaf nodes. The following figure shows the context tree.
The information stored in the context nodes in this path provides the required data that is needed to complete a transaction. CHA provides different modes of implementation of context.
CHA is responsible for the following functions:
▪ Initialize the UDTT settings at the very beginning
When you use UDTT at the very beginning, configuration settings from btt.xml will be read into memory for each component's initialization. This process will be invoked by CHA. CHA will also create the initialized context tree according to the configuration.
▪ Create context instances
CHA creates the context instances with various parameters. Context.java is used as an interface, which might have many implementations. And ContextFactory.java is provided as the access facade for creating context instances.
▪ Locate a context instance from the context tree
In CHA runtime, all the context instances are organized as a context tree. There are parent-children relationships among different context instances, and each non-dynamic context instance has a unique randomly-generated instance ID. Given a context name or instance ID, CHA provides the searching functions of a specific context instance from the context tree. Such functions reside as static methods in ContextFactory.java.
▪ Get and set value of the data stored in context instances
Contexts in CHA stores the system or application data, as a result, CHA provides the get and set methods to access the stored data.
▪ Destroy context instance
At the exiting point of CHA, the unused context instances should be destroyed from memory. CHA itself provides functions and methods to unchain a context node from the context tree, and clean it from the memory cache.
