Agile and Structured modularity (ii) discussion of OSGi

In the previous article, introducing the relationship between structural modularity and agility, in the second article in this series, we'll discuss OSGi, which plays a central role in implementing Java's structural modularity, and there is a natural link between OSGi and popular agile methodologies.

1 but we have achieved modularity!

The vast majority of developers agree that the program should be modular. Although the requirements for logical modularity were quickly met in the early stages of object-oriented programming (see Http://en.wikipedia.org/wiki/Design_Patterns), it took a long time for the software industry to understand the importance of structural modularity. In particular, structural modularity can improve the maintainability and flexibility of programs, and control and reduce the complexity of the environment.

Just a combination of jar files

In the "Java Application Architecture" (The book has been introduced by the machinery Industry Press, Chinese title for Java Application Architecture design: Modular mode and OSGi-translator) in a book, Kirk Knoernschild explores and studies the structural modularity and establishes a set of optimal design patterns for structured design. Knoernschild that there is no need to develop a modular framework in the context of modularity; The Java,jar file structure is sufficient.

In fact, it is not uncommon for the agile development team to decompose applications into smaller jar files based on the growth of the code base. As the size of the jar file increases, they are decomposed into a collection of smaller jar files. From the point of view of the code, especially if we follow the structured design pattern of knoernschild, we think that from a certain structure layer, the program is modular.

But is it agile?

The application is more agile from the point of view of the team that created the application and the person responsible for the subsequent maintenance. The team understands dependencies and the impact of change. However, this knowledge is not associated with the component. Once a team member leaves the company, the process and the business are likely to be affected immediately. Similarly, for third parties (even the different teams of the same organization), the application may still be a separate large code base.

If there is only one layer of structural module in the program, it must not be self-describing. Because of the lack of metadata describing the intrinsic relationship between modules, the resulting business system is inherently fragile.

So what about maven?

The Maven document (Project object model, MODEL--POM) can also express dependencies between components. These dependencies are defined by the name of the component.

In view of this, MAVEN based modular programs can be easily integrated by any third party. However, as we have mentioned in the previous article, it is flawed to define a dependency relationship by name. Because dependencies between components do not clearly indicate requirements (requirement) and functionality (Capability), third parties cannot infer the existence and substitution of dependencies.

Programs can be consolidated, but not changed. Whether this approach makes the program more "agile" than the previous "JAR file combination" is debatable.

Requirements for OSGi

As Knoernschild in the Java Application Architecture design, once the structural modularity is achieved, it is easy to migrate it into OSGi, the modular standard in the Java domain.

OSGi not only helps us to ensure structural modularity, it also provides the necessary metadata to ensure that the modular architecture we build is also agile.

OSGi expresses dependencies through requirements and functionality. As a result, third parties can immediately know which components may be replaceable. Because OSGi also enables semantic versioning, third parties can immediately speculate on whether a component's changes have the potential to compromise the system.

OSGi also has the ability to demonstrate a structured hierarchy.

At one end of the module, we use a service-oriented architecture (oriented Architecture,soa); On the other end, we use Java packages and classes. However, as Knoernschild stated, there is a lack of necessary levels between the two ends.

Figure 1: Structural hierarchy: Missing the middle part (Kirk knoernschild–2012)