Glossary

The most important terms of z2 and where to find out more about them. Note: All z2_base javadocs can be found here:

Component

The z2 environment implements a simple but extensible component model that serves to realize its life cycle management operations. Components are identified from their persistent structure in Component Repositories (see IComponentRepository). A z2 component may consist of just a set of properties (see IComponentDescriptor) or additionally a complete file hierarchy. A component has a type that is interpreted by a component factory (see IComponentFactory). Examples of components are Web applications (see Constants), data source configurations, and Java modules (see IJavaComponent).

A component factory, when asked, provides a resource representing the component at runtime.

Java Component

Java Components abstract a notion of Java modules that can implement for example a Web application. Java components may expose types for use by other Java components. (see IJavaComponent).

Home

A z2 home is an installation of a z2 core in some file system location. A home holds the basic resources to
run a z2 environment as server or in embedded mode (see ProcessRunner ). In the server case, the overall runtime layout consists of one home process and one or more worker processes. The home process does not run application code but rather starts and manages worker processes according to a home layout (see IHomeLayout)

Home Layout

see home.

Home Process

see home.

Module, Project

The component model of z2 is (today) organized in a two step hierarchy. The top level of the hierachy is made up of modules. A taxonomy that is meant to express a meaning for humans and is not driven by technology. At the second level we find component definitions. Typically either as .properties files or as folders
containing component resources and one component properties file z.properties.

When developing, modules typically translate into projects in your development environment. In other words, typically development happens on the granularity of modules and we tend to use the term project and module interchangeably.

Resource

The resource management API in z2 serves to represent named runtime resources that may be depending on other resources and that may have dependants. The most prominent source of resources is component factories that instantiate and register resources representing components defined in component repositories. See in particular the Resource javadoc documentation.

Synchronization

The purpose of a synchronization procedure is to apply modifications to the contents of component repository onto the runtime state of the currently running system. A synchronization procedure consists of two steps: In a first step all component repositories are asked to indicate what components have been affected by changes to their contents since the last synchronization. Those components will be invalidated.

For a Web application this means it will be stopped. For a Java component this means its class loaders will be dropped as well as all referencing Java components will be invalidated as well. For a worker process this means that it will be terminated.

The second step of a synchronization procedure is a verification.

(See also ISynchronizer)

Verification

During a Verification, the home process and all worker processes will try to attain their configured target states. A verification serves to bring the system into a
well-defined ready-state after, for example, some resources have been invalidated or a worker process has been killed. The synchronization procedure concludes with a
verification.

Worker Process

A worker process is managed by a home process. See home and IWorkerProcess.