Z2V2.1 is out – working on v2.2

It’s been a while already. Forgot to put it up in the blog: Version 2.1 of the z2-Environment is ready for use and learn. All the new stuff has been described in this previous post.

Among the features we plan for 2.2 the following stand out:

• Eclipsoid-style Z2 support for IntelliJ IDEA
• The Hub component repository

The goal of the first item is clear: Resolve a classpath for modules in the IDE corresponding to your runtime state (read on here for example) and offer the same developer convenience that can be achieved using the Eclipse plugin for users of the IntelliJ IDE.

The Hub component repository (or HubCR) requires some more background. By default, a Z2 installation (a z2 Home) accesses the version controlled storage that holds the system definition directly to download and prepare (and compile) modules as needed. This is the underpinnings of the system centric, pull-deployment based approach. In some situations however, it is not desirable to have source code on production servers at any time. This may be for compliance reasons or for fear of risking theft of intellectual property.

This is where the HubCR comes in. As a principle, all modules, all component resources, essentially anything the Z2 runtime knows about is served by component repository implementations.  There are implementations for Subversion, Git, file system folders, development workspaces and now, the latest addition, for another Z2 server that provides a consolidated, source-code free and pre-compiled view onto production resources (the HubCR provider).

So, instead of having production systems read and process source code directly, an intermediate node provides a semantically equivalent but pre-processed view onto the system definition:

The way the HubCR does that is by maintaining a pre-compiled and source-code stripped snapshot of the original production configuration. At the same time, the HubCR is just a regular z2 Home that runs the production config.

To the real production nodes (on the right in the diagram) however, the HubCR presents everything but the HubCR and other remote component repositories.

As a result, production systems can be completely separated from the source level details of the system definition. They don’t even see authentication details to the configuration store – only those necessary to access the HubCR service. At the same time, the pull semantics are preserved and updates can flow in and will be distributed consistently as for any other Z2-based system.

 

 

If Santa Claus would use Java best practices….

Imagine Santa would use Java best-practices to have Christmas presents built. He would…

… not use complete blueprints, instead he would specify only parts of a gift (there is a leg, there is a red dress, …);

… declare some random number of aspects – more or less abstractly (“legs need to attached too main corpse, …”) – and leave the details to his gnomes;

… declare a brush on the blueprint (if the eyes need to be painted, you need a brush right?);

… not realize that paint could be taken literally as a part of dolls in red dresses. As paint comes in cans, the gnomes would mount the empty can to the back of the doll.

Eventually his gnomes would stitch dolls in red dresses onto male cats. Sometimes several. As dolls are unthinkable without Spring rolls, there would be some. The cat would eat all of those. Most likely it would fall over, dump a heap, jump the wall, or all of it in some random sequence….

Merry Christmas to all of you!