Runtime components : Core components : Contexts : Concept : Context resources (data and services)
  
Context resources (data and services)
The chain of responsibility pattern determines which context should hold specific resources (data and services) within the context tree. For example, if there is data that all the workstations on a branch server must share, place this data in a branch-level context in the tree. If the workstation contexts are children of the branch context, this common data is available to them. A service running in a context attached as a child (directly or indirectly through one or more other child contexts) to the workstation context can access this common data because the data exists in the chain of contexts. This encourages operations to share and reuse resources while keeping the application unaware of their location.
Within a context, each resource has a unique name. However, this name does not have to be unique within the context tree or even within the context chain. The same name can exist in multiple contexts. To handle multiple instances of a name, the toolkit only returns the first resource it finds with the name. This allows you, for example, to define two host services (a real one and another for testing) with the same name in different contexts. You can then switch between the two services by either changing the context chain or by removing the first service encountered in the context chain.
The toolkit can search for a service by name (alias) or by type. The service name is an alias that identifies the service. The name must be unique within the context but can be in many contexts within the context tree. The service type groups services of similar functionality. Applications that use services by type normally do not require a specific implementation of the service to perform the appropriate function. When the toolkit searches for service by type, it returns the first service it finds that belongs to the named type.
To hold its data, a context has a reference to a typed or non-typed collection of data elements. A context with a refType tag refers to a keyed collection containing only typed data. A context with a refKcoll tag refers to a keyed collection that can have typed or non-typed data. An application must never directly reference a context's keyed collection to access context data. The following example shows one context definition that uses the refKcoll tag and another definition that uses the refType tag:
<context id="contextForOpThatEmploysData" type="op" parent=...>
  <refKColl refId=.../>
  <refService refId=... alias=... />
</context>
<context id="contextForOpThatEmploysTypes" type="op" parent=...>
  <refType refId="typeForMyOp"/>
  <refService refId=... alias=... />
</context>
For the context with the refType tag, upon context initialization, the toolkit instantiates a keyed collection from the typeForMyOp type.
When a context is unchained, the toolkit makes its data available for garbage collection. The toolkit automatically sends all of the context's services a terminate action so that they can do their housekeeping process to release resources to the system.
Go up to
Concept