Z2 Modules intro » History » Revision 4
Revision 3 (Henning Blohm, 09.09.2013 10:10) → Revision 4/7 (Henning Blohm, 09.09.2013 13:43)
h1. 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. h2. Component Types 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). Check out "Components and Component Repositories":http://www.z2-environment.eu/v22doc#Components%20and%20Component%20Repositories for more details. h2. What makes a module Now that we know what components are, we are almost at the modules. Basically anything that Z2 cares about is components. In fact, apart from the most basic component types one thing left to even start having a useful runtime, the core system hardly knows anything more than what components are and how invoke component factories. In order to learn about component types and their component factories (that are actually components of type component factory), the z2-Environment relies discuss on component repositories. Within component factories, components follow a naming scheme that is typically directly derived from a file system structure. More specifically, components are named <pre> <module>/<component> </pre> So, in fact, what we call a module might as well be understood as a folder of components. As the level above the single component, it is a useful place way to define conventions for. The most important convention today modules is that all component type that have an association with implementation code (such as Web Applications), will look for names. h2. What makes a Java component of name _java_ in the module of the component. That is, although Java components can have any name, by this convention there is a primary Java component that other components of a module turn to when looking for code. Due to the nature of Java components (see CCKC), and since the Java component convention actually says to use the Java component's private loader, this defines _the non-public implementation of the module_. A _Web application module_ for example would then typically comprise of a component _web_ of type Web application and a component _java_ of type Java. Feel free check out the introductory samples to see how this works in practice. h2. Taxonomies