Project

General

Profile

Step 1 - What is z2 » History » Revision 9

Revision 8 (Udo Offermann, 11.09.2012 14:03) → Revision 9/14 (Henning Blohm, 11.09.2012 19:40)

h1. What is z2 

 h2. What is the z2-Environment? z2-environment? 

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

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

 The z2-Environment z2-environment is not yet another Java EE container but rather a life-cycle container for other containers j2ee container/servlet engine (it does actually uses Jetty jetty as Servlet servlet engine for example). It represents though), but it is a radically new approach on how to development develop and operation operate Java application by greatly reducing required servers and get rid off a huge amount of infrastructure from development operations beside the main product and by greatly reducing the efforts required from developers pain people have to roundtrip and integrate.  

 keep this infrastructure alive. 

 h3. The main point 

 The main point of the z2-Environment z2-environment (which is also the main difference compared to other Java environments) servers) is that it is directly attached to Version the VCS (Version Control System (VCS) repositories. System). The repositories VCS (currently Subversion subversion and Git git are supported) is used to retrieve source code files, contains the Java sources, Web application resources, and any other required configuration files. files organized in modules (the modules usually correspond 1:1 to projects in your IDE). Z2 has an intimate understanding of the knows this module and component structure contained in these repositories (including dependencies between modules) and uses available change tracking means to identify changes and can update its runtime state as required. The z2-Environment's runtime state - as get an overview by simply scanning a principle - reflects the stored module configuration configured root folder in connected repositories. We also call the system centric approach VCS. In the same way z2 easily findw out what has been changed since the last scan by examining the commit logs. As a _pull_ deployment approach as last step z2 _pulls_ the changes (all resources and updates are retrieved as required. That strongly contrasts the traditional _push_ approach found configuration files) into its working directories. These three simple VCS access methods allow z2 to consistently update itself in contrast to typical Java application servers that leave consistent application of where you have to make sure to consistently (re-) deploy your changes across deployables to you! (this is called _push_ approach). 

 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 Were 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. colleagues. 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 .war,    .ear ZIP archives) and finally they are deployed to deploy to each node instance of the system. Z2 does not need these intermediate packaging steps as packages, because it understands the very same module project 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.  
 Both are using some java libraries like jgit or svnkit and both are working on the same resources. 
 # 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 project structure as the developer (modules typically correspond to IDE projects), developer, 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    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 will typically not be noted causing noticable delays. any delay. 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 Hence, in productive mode sources are compiled once and the execution environment system runs for a (hopefully) long while before patches/upgardes are applied. 

 Thus compiling on the server is not a problem, problem but rather a solution to cut short the tool chain (as solution. As an additional benefit,    sources are always compiled with the same JVM version the runtime server is using). using. 

 h3. Looking a level deeper 

 As mentioned before Z2 z2 uses the same module project 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]]