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. 

h3. 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!

h3. Why _pull_ is better than _push_

Because...

# Pushing a new version of a deployable to a Java server might require to update dependent deployables as well. The question is often: Where do you get the right versions from? 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. 

h3. 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).

h3. Looking a level deeper

As mentioned before Z2 uses the same module structure as the developer. But this is only the first level. Inside the projects z2 is organized into _components_. 

Components can be Java modules as well as web modules, database connections, VCS connections and more. Components have a two level name starting with the module or project name followed by a component name. These two names a separated by a slash. 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/database 

(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.

Components have a livecycle: 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. At 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).

Last but not least: the z2 component model is extensible. One can write it's own component types by developing a component factory.

h3. Cloning the sources

The z2_base project on git.z2-environment.net contains several repositories. This makes it easier to setup different systems for different purposes and allow to easily transport (or in git-terms 'fetch' and 'push') sources between systems. While one system serves for the development of the z2 foundation (which is the purpose of the project:z2-base project) another system might have a productive focus of running a webshop (for example called "z2-webshop"). 

The webshop would go into its own repository z2-webshop. Furthermore z2-webshop would contain clones of the z2-base.core and z2-base.base repositories from z2-base. 

Another setup could be to have development systems, test systems and productive systems. Usually the source are transported (pushed) from the development system to the test system where they are tested and qualified. Finally they are pushed into the productive system. However it is possible to do emergency fixes in the test system or even in the productive system. Of course nobody wants to apply fixes to productive systems, in the same way nobody wants to become sick. But sh*** happens. In case this is necessary the changes must be commited into the VCS of the productive system. Thus the huge benefit is that this change is automatically recorded in the commit logs. That means the z2-environment is completely auditable!

A transport of sources does not necessarily mean to reboot the whole z2-environment. Usually a z2-synchronization step is sufficient. Of course some components have to be released and thus reloaded - this is the true for all live systems. However the z2-environment minimizes the down-times by only stopping and restarting those components which have been changed (plus there dependent components). [[How_to_Gateway|How to Gateway]] describes a feature that goes even a step further and allows system updates with zero downtime.

h3. The source is the system

The motto of the z2-environment is: _"The source is the system!"_. Existing 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.

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