z2-Environment

h1. What is z2

h2. What is the z2-Environment?

The z2-Environment is a Java runtime environment (server or embedded) that allows to develop and operate Java applications (e.g. Web applications) in a new and particularly easy and consistent way.

What's the difference compared to Java servers like Tomcat?

The z2-Environment is not yet another Java EE container but rather a life-cycle container for other containers (it does uses Jetty as Servlet engine for example). It represents a radically new approach to development and operation Java application by greatly reducing required infrastructure from development operations and by greatly reducing the efforts required from developers to roundtrip and integrate. 

h2. The main point

The main point of the z2-Environment (which is also the main difference compared to other Java environments) is that it is directly attached to Version Control System (VCS) repositories. The repositories (currently Subversion and Git are supported) is used to retrieve source code files, Web application resources, and any other required configuration files. Z2 has an intimate understanding of the module and component structure contained in these repositories and uses available change tracking means to identify changes and can update its runtime state as required. The z2-Environment's runtime state - as a principle - reflects the stored module configuration in connected repositories. We also call the system centric approach a _pull_ deployment approach as changes and updates are retrieved as required. That strongly contrasts the traditional _push_ approach found in typical Java application servers that leave consistent application of changes across deployables to you!

!works_like_this.png!

h2. Why _pull_ is better than _push_

Because...

# Pushing a an update may require to copy numerous deployables to a Java server. The question is often: What deployables and do you have the right versions? Pulling solves this problem, because all it needs is the trigger to scan the VCS for *all* changes committed by you and your co-developers. The combination of manual trigger plus automatic VCS scan is called a _z2 synchronization_.

# Pushing deployables includes serveral preparation steps: One has to compile source files, package results into deployable units (typically some .war or .ear ZIP archives) and finally to deploy to each node of the system. Z2 does not need these intermediate packaging steps as it understands the very same module structure of the very same VCS the developer is working on. There is actually no difference between how the developer accesses the VCS using an IDE and how z2 accesses it. 

# The push approach easily leads to a divergence between the projects the developer is working on in his IDE and the programs and resources running on the runtime environment (as there is no 1:1 mapping anymore).  As described above, z2 uses the very same module structure as the developer (modules typically correspond to IDE projects), so that there is a 1:1 mapping between the projects in the IDE and the modules considered by the runtime environment. 

h2. But isn't there something missing?

You might wonder where the Java sources are compiled into binaries. The VCS contains only sources (apart from pre-compiled 3rd party .jar archives) and there is no build/make/deploy, so how does the JVM get its byte code to run?

Z2 compiles the sources on the fly (and on demand). The approach is similar to how Java servers handle JSPs for more than a decade now. Compilation, in particular at runtime when dependency code is typically already available in memory, has become amazingly fast and not causing noticable delays. Z2 uses the proven Eclipse Java Compiler. As z2 does not need to package resources into .war files or .ear files, time spent on ZIPping and unZIPping can be saved. Sources will only be compiled if required by changes.

Compiling in the execution environment is not a problem, rather a solution to cut short the tool chain (as an additional benefit,  sources are always compiled with the same JVM version the runtime is using).

h2. Looking a level deeper

As said above, Z2 uses the same module structure as what developers see as projects. On a next deeper level, Z2 organizes modules into _components_. Components, from a Z2 perspective is anything that has a managed life cycle by Z2. It is the smallest granularity of preparation for or removal from the system.

Examples of components are Java modules as well as Web application modules, datasource definitions, component repository definitions. The name of a Z2 components is made up by concatenating a module name and a local component name by a slash.

For example the module "com.xyz.webshop" may have the following components:

* com.xyz.webshop/java (containing the business logic, the database access layer, the web access layer in terms of servlets etc)

* com.xyz.webshop/web  (containing the Web artifacts like JSPs, HTML files, Stylesheets, images, JS files etc)

* com.xyz.webshop/datasource (containing the database connection settings)

The "java" and the "web" components contain multiple files inside folders and sub-folders while the "database" component is just a single .properties file.

Java components typically depend on other Java components which are declared in the java component's configuration file: *java/z.properties*.

Components have a runtime life cycle: They can be loaded and released. A component is loaded when it is first requested, possibly as early as part of the bootstrap process. A component is released during a z2-synchronization according to changes of its resources in the VCS or due to changes of dependency components. This way Java sources which have become invalid are unloaded, new versions are fetch from the VCS and compiled again. As a final step the released components can be loaded again (either on demand or as part of a partial bootstep process which is executed after a synchronization step).

The Z2 component model is extensible: By declaring and implementing component factories new component types may be made available to the platform. 

h2. The source is the system

The motto of the system-centric approach in the z2-Environment is: _"The source is the system!"_. Traditional systems with a push-deploy approach tend to become a heterogeneous conglomerate after a while, containing a mixture of original versions, patches, hotfixes and manual adjustments on config files. It is hard (or even impossible) to tell who installed that patch last month or who changed the memory settings yesterday. Often it is even difficult to tell what patch versions are actually deployed. And once this question is answered the next one pops up: Where do I get the corresponding sources for debugging and maintainance?

When the "source is the system", these questions are answered immediately. Changes to the z2-Environment are always changes in the repositories. And changes in the repositories are logged in the commit logs with author name and date, regardless if it's a fetch from another system (which is the equivalent to a patch) or a manual fix on configuration files. Also exactly the same sources are available, because there is only one source for (Java) sources which is the repository. When the Java sources are changed, z2 has to recompile them in order to get them executed. Thus it is always possible to debug a system with the most up-to-date sources.

h2. What's next

* Continue at [[Step_2_-_How_to_install_z2|» Step 2 - How to install z2]]

* Browse the reference documentation at http://www.z2-environment.eu/v20doc (TDC!)