The core of CHA is the context. While CHA contexts are similar to the contexts in Java(TM) 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 that 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. 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.
The following diagram shows a high level view of the CHA architecture.
A service or business process instantiates a local or remote CHA context using the API of the Context class. Note that the service or business process can use a provided name or a generated one. Once created, a local context cannot become a remote context and a remote context cannot become a local context. The service or business process interacts with local and remote contexts using the same API.
The client side of a remote context is little more than a mechanism for passing requests on to the server side. It delegates business functions to the server side. The client side can have a read cache and a batch update enabled. The read cache contains all of the data elements and values that have either been retrieved from or sent to its remote counterpart. The batch update gathers small sequential updates (add or set) and sends them as a single message instead of a series of messages. See Read cache and Batch update for more information.
In the CHA server, EJB instances create and maintain the server side of remote contexts. A session bean (CHASession) handles static method calls while an entity bean (CHAInstance) handles instance method calls. Note that the Context class does not require access to the CHAInstance home interface to retrieve a remote interface. The CHASession EJB can perform all instance queries using local EJB interfaces to create or find CHAInstance objects.
The client side of the context or a non-toolkit J2EE client drives the creation of the EJBs. Toolkit applications cannot directly create the EJBs. Each context has an instance ID, which is unique in the global system. Note that the server side of a remote context identifies whether the context is static or dynamic depending on whether the definition files contain a definition for the context. See Context type for more information.