Let me remind you what TMC is: It is an application shell that carries the Modules (a Java construct that has a defined purpose, a defined and unique set of functionality) that make up the total functionality of the application within itself. We use the concept of a customized Class loader and persistent state to achieve this.
I extended the illustration from my previous post:
We can say the following about the design:
- The Shell has a customized Classloader
- The Shell has a collection of Modules (code and instantiated objects)
- The Shell has a collection of Interfaces (interface objects that point towards one Module)
- A Module is installed into a Shell: The customized Classloader reads JAR files containing the Module code, loads these into the application (JVM), stores the code (String) in a Module collection and saves the Shell's persistent state containing the ingested code. The JAR file of the installed Module is deleted.
- The Shell's persistent state can contain application parameters and many more attributes (operation).
- A previously installed Module will be instantiated at the Shell's instantiation (start-up / initialization).
- One Interface Object is instantiated for each Module, other Modules (application code) evoke functionality of the Module through it.
So far we have discovered two process flows, one for installation, and one for initialization:
Below you will find a draft version of the Instantiation Process Flow. I might employ a slightly different organization/strategy once I start to implement it but for the moment these steps seem reasonable.
Draft Instantiation Process Flow:
I do not want to overwhelm or bore the reader with too much detail. I think that the explanation above describes an aspect of the idea and points into the direction that I want to go with this.
My next post will take a closer look at Java's Serialization Concept