I am playing around with the concepts of components and environments in my microbean experiments.
The fundamental idea behind microbean is that with CDI 2.0 every last piece of your application can be its own self-contained artifact (including the main class with its main() method). Each such artifact is a CDI bean archive. When you put them all together on the classpath and run java org.microbean.main.Main, then your application works. This might include running servers, deploying things, and so on, but it’s all loosely coupled and tiny. It is the act of bringing these archives together—drawing a lasso around them with a CLASSPATH—that constitutes deployment.
As we’ve seen, CDI has the notion of a bean archive, but it doesn’t really have a notion of a group of bean archives. I am going to use the wonderfully overloaded term component to describe this concept.
These components might need some other facilities provided by various portable extensions. There is a hazy way in which a group of portable extensions providing services is different from a group of bean archives providing business logic. I’ll call this aggregation an environment.
With these provisional terms in place, we can thus say that components run in environments. We can also say that environments support components.
Then the act of deploying a microbean application becomes: pick one or more environments and one or more components and put them on the classpath, and then run java org.microbean.main.Main (or any other main class that simply starts up a CDI SE container and shuts it down; this just happens to be a convenient prefabricated one).
How could we represent these components? On disk, we don’t really want to represent them at all. A component as used here is a notional construct, after all: it’s a bunch of jars that belong together in some way. For management purposes, however, representing them in Maven pom.xml files of a particular kind looks like a good way to go.
This also seems to be a good way to represent environments as well.
Maven’s pom.xml file and the dependency graph it implies is one of the most misunderstood artifacts in all of Java software engineering. Most developers know that it describes a project and its dependencies, but did you know you can include a non-jar project pom.xml file (an artifact of type pom) as a dependency itself, thus effectively pulling in (transitively) its dependencies? This can lead to version surprises, but did you know that a pom.xml‘s section can be used to lock down the version of a given artifact, whether it appears directly or transitively as a dependency? Finally, to complete the puzzle, did you know that a pom.xml can, itself, appear in its own <dependencyManagement> section, thus offering a way to lock its own version down as well as those of its dependencies?
These features mean that we can define both components and environments as artifacts of type pom. I’ll be exploring these concepts over the next few blog posts.
