Monday, December 16, 2013

Monolithic vs Modular Java

To start this series of articles on OSGi, we'll take a look at the difference between monolithic and modular.

Why is it important?
Monolithic and modular Java are part of the same software architectural spectrum. How much is monolithic and how much is modular in your Java application should be an explicit choice. How do you decide?

We hear people talking about modular Java. We see books on modular Java. Does that mean that everyone should start developing with a modular architecture? No, you decide if modular is right for you.

Monolithic Java
A monolithic class library is where all classes are part of a single, monolithic namespace. While there may be separate collections of Java archives, the namespace is reduced to a single list.

Simplicity. The monolithic class library is the original model. It is a simple model. All classes are available all of the time.

Very large namespace. The monolithic class library is a viable alternative for large business applications because Java supports a very large namespace. Hundreds of thousands of classes can be used in a business application without loading two classes with the same name at the same time.

In other words, many programming languages prior to Java technologies have been limited by a small namespace. The name of a dynamic link library on a well-known operating system, for example, was limited to just eight characters. Java technology has a limitation, too; but, it is sufficient to say that it is more than a hundred characters.

Static class path. When a class path that is static, it never changes throughout the lifetime of your Java application. This means that the potential list of available classes never changes. Classes are neither added nor removed during the lifetime of an OS process.

Modular Java
A modular class library is where there are multiple, concurrent namespaces. The namespace becomes a tree rather than a list.

Version. Technically, the Java technologies are quite capable of loading two classes with the same name as long as they are loaded by two different class loaders. This has been true since the first version of Java (JDK 1.0).

Volatile class path. When a class path is volatile, it is capable of changing over the lifetime of an application. Classes are added and removed without starting a new OS process.

Complex. Dynamic loading of a Java class involves a little more complexity. A fully implemented module system involves a lot of complexity and resolving a lot of issues.

Moving from monolithic to modular
Changing a software architecture requires research, investigation and establishing a new set of constraints and rules. When classes have been developed in a monolithic software architecture, they must be redeveloped in a modular software architecture. Fortunately for Java classes, redevelopment uses a lot of the same tools with different techniques.

Is it worth the effort?
The big question is: Is modular worth the effort? The answer is maybe yes, maybe no. It doesn't make sense to move everything written in Java to a modular software architecture. A lot of Java code has been written in a monolithic architecture and is fundamentally incompatible with a modular architecture. In other words, some class libraries should not be modularized.

Each class library needs to be evaluated for the benefits of modular architecture. And, ultimately, the benefit of maintaining a loosely-coupled collection of modules should be evaluated. What do you hope to gain from it?

About OSGi
One of the benefits of developing OSGi modules is running applications in Eclipse Rich Client Platform and one of the many Java application servers, such as IBM WebSphere.

No comments:

Post a Comment