Chapter 2 – Module Defined
by kirk knoernschild
Before we get started, we need to answer a rather simple question. What is a software module?
2.1 – Defining a Module
I’d like to say that a module is simply a “chunk of software.” Unfortunately, that doesn’t offer enough concision to differentiate a module from other software chunks, like objects, packages, services, or even applications. So we need to focus our definition a bit.
A software module is a deployable, manageable, natively reusable, composable, stateless unit of software that provides a concise interface to consumers.
That’s quite a mouthful (reminds me of the first definition of Java), and I feel badly about dumping this on us so early in a book that I had such high hopes for. But hopefully, after a bit of explanation, you’ll give me a second chance and keep on reading. We can illustrate this definition visually as shown in Figure 1. Let’s tease apart the definition.
Figure 1: Defining a Module
2.1.1 – Deployable
Modules are a unit of deployment. Unlike other software entities such as classes and packages, a module is a discrete unit of deployment that can be deployed alongside other software modules. In this sense, modules represent something more physical than classes or packages, which are intangible software entities. Examples of deployable unis of software include EAR, WAR, and JAR files.
2.1.2 – Manageable
Modules are a unit of management. In the presence of a runtime module system, software modules can be installed, uninstalled, and refreshed. During development, partitioning a system into modules helps ease a number of otherwise complicated activities. This includes improving build efficiency, allowing developers to independently develop autonomous modules, and plan the development effort along module boundaries. Examples of software entities that comply with this segment of the definition include EAR, WAR, and JAR files.
2.1.3 – Testable
A module is a unit of testability. Like a class can be independently tested using test driven development, a module can be independently tested as well. Examples of software entities that comply with this segment of the definition include classes, packages, and JAR files.
2.1.4 – Natively Reusable
Modules are a unit of intra-process reuse. Unlike applications or services, modules are not a distributed computing technology, though SOA principles can be used to design software modules. Instead, modularity are a way to organize units of deployment in a way that they can be reused across applications, but a module is always invoked natively. That is, the operations exposed by a module are invoked by calling the method directly.
The way we reuse modules is also different than how we reuse services. Typically, a service is deployed only a single time and invoked by multiple consumers. Because modules are used intra-process, a modules is deployed with each process that intends to reuse its functionality. Examples of software entities that comply with this segment of the definition include classes, packages, and JAR files.
2.1.5 – Composable
Modules are a unit of composition. Modules can be composed of other modules. Typically, this involves coarse-grained modules being a composition of finer-grained modules.
2.1.6 – Stateless
Modules are stateless. There exists only a single instance of a specific version of a module. We don’t instantiate software modules, though we do instantiate instances of the classes within software modules, and these classes may maintain state. However, the module itself does not. Examples of software entities that adhere to this segment of the definition include WAR, EAR, and JAR files.
2.2 – A Bit More Succinctly
Before we get too far, I’d like to offer a bit more succinct definition of a software module. Upon applying each of the various segments of the definition, we can more clearly state that:
A Module is a JAR File!
Comments
Figure 1 is awesome. It sums up pictorially what I’ve been trying to describe (not so elegantly) for a few years. Beautiful.
“A module is a JAR file” isn’t true. Maybe this is simply hyperbole. “A JAR file is a module” is closer to the truth, but even then there are caveats if a JAR file is to meet the criteria in this chapter. “A JAR file is the best basis for a module that is readily available in Java” is the truth, but is hardly worth saying.
I have only gone this far in reading the chapters but one thing which seems to be missing is the Module interfaces. In my view, a module’s definition is incomplete without talking about it’s interfaces (what does it offer?). You have already mentioned about dependencies – which is the “required interface” part of the module definition. I think it will be a good idea to touch upon the “provided interface” aspect of modules in the beginning to set the context for later chapters. The context of model (runtime or development) on the nature of these interfaces and the design (physical as well as logical) is a very important aspect of modulalization. Some patterns related to design of interface contracts, keeping runtime modularity, reuse and maintainence in mind, is something which will be of immense value.
Wanted to correct one thing… The definition does include interfaces “… provides a concise interface to consumers”. what I meant by missing is, some explicit mention of the provided interfaces.. just like you have provided some for other characteristics of the module (in 2.1.1 – 2.1.6)