Z2 Modules intro » History » Revision 3
Z2 Modularization Intro¶
The z2-Environment is a platform for modular application design (or, as we like to say: solution design). Its concept of a module does however differ from what other Java module runtimes offer in that a module in Z2 is not just Java code. In fact, in almost any Z2 based system there will be modules that contain no code whatsoever. That is not to say that Java code is not important or treated with indifference, it is rather that we recognize that a module, a logical partition of a system's ingredients, should contain any kind of component type that the system understands.
To understand Z2's modularization approach it is essential to understand its component model. A runtime system that hosts code and configuration for applications requires some sort of formalism to find instances of executable code to pass control to so that application can actually do something. In Z2 this is called components.
As said above, Z2 is not really code-centric. It would be absolutely ok, to have a Z2 implemented system that simply hosts a Web application with only static resources. No code at all. It may actually host a number of static Web applications that are to be made available or not based on some configuration.
To facilitate that complexity, Z2 implements an extensible set of component types. Or more specifically:
- You can declare components of a type
- Components can be looked up using Z2's core API or JNDI
- When providing, Z2 will look for a Component Factory for the given type to make sense out of the component's resources
One such component type is that of a Web application. Another one is that of a JAVA component. A component of type Web application would be expected to hold all kinds of Web application resources such as HTML files. A component of type Java is expected to hold Java types or other resources that can be retrieved via class loaders.
Now, component types have their very specific implementation. But they may know about each other. Web applications do for certain benefit from knowing Java components. Java components however do not understand anything about Web applications.
To look a component up means to request the component by some name and by some type. Component type implementation may present components to the retrieving party by any set of interfaces. This sort of polymorphism is essential to provide functionality to generic system functions (e.g. via a "Start me up"-interface) as well as to highly specific consumers (e.g. to retrieve a class loader from a Java Component via the IJavaComponent interface).
Now that we know what components are, the one thing left to discuss on the way to modules is component names.