- 3.1. Defining Architecture
- 3.2. A Software Architecture Story
- 3.3. The Goal of Architecture
- 3.4. Modularity: The Missing Ingredient
- 3.5. Answering Our Questions
- 3.6. Conclusion
- 3.7. References
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.4. Modularity: The Missing Ingredient
Two of the key elements of the architectural definitions are component and composition. Yet there is no standard and agreed-upon definition of component1 (reminding me of architecture, actually), and most use the term loosely to mean “a chunk of code.” But, that doesn’t work, and in the context of OSGi, it’s clear that a module is a software component. Developing a system with an adaptive, flexible, and maintainable architecture requires modularity because we must be able to design a flexible system that allows us to make temporal decisions based on shifts that occur throughout development. Modularity has been a missing piece that allows us to more easily accommodate these shifts, as well as focus on specific areas of the system that demand the most flexibility, as illustrated in Figure 3.5. It’s easier to change a design encapsulated within a module than it is to make a change to the design than spans several modules.
)
Figure 3.5. Encapsulating design
3.4.1. Is It Really Encapsulated?
In standard Java, there is no way to enforce encapsulation of design details to a module because Java provides no way to define packages or classes that are module scope. As a result, classes in one module will always have access to the implementation details of another module. This is where a module framework, such as OSGi, shines because it allows you to forcefully encapsulate implementation details within a module through its explicit import package and export package manifest headers. Even public classes within a package cannot be accessed by another module unless the package is explicitly exported. The difference is subtle, although profound. We see several examples of this in the patterns throughout this book, and I point it out as it occurs. For now, let’s explore a simple example.
3.4.1.1. Standard Java: No Encapsulation
Figure 3.6 illustrates a Client class that depends upon Inter, an interface, with Impl providing the implementation. The Client class is packaged in the client.jar module, and Inter and Impl are packaged in the provider.jar module. This is a good example of a modular system but demonstrates how we cannot encapsulate implementation details in standard Java because there is no way to prevent access to Impl. Classes outside of the provider.jar module can still reach the Impl class to instantiate and use it directly.
)
Figure 3.6. Standard Java can’t encapsulate design details in a module.
In fact, the Impl class is defined as a package scope class, as shown in Listing 3.1. However, the AppContext.xml Spring XML configuration file, which is deployed in the client.jar module, is still able to create the Impl instance at runtime and inject it into Client. The App-Context.xml and Client class are shown in Listing 3.2 and Listing 3.3, respectively. The key element is that the AppContext.xml is deployed in the client.jar module and the Impl class it creates is deployed in the provider.jar module. As shown in Listing 3.2, the AppContext.xml file deployed in the client.jar file violates encapsulation by referencing an implementation detail of the provider.jar module. Because the Spring configuration is a global configuration, the result is a violation of encapsulation.
Listing 3.1. Impl Class
package com.p2.impl;
import com.p2.*;
class Impl implements Inter {
public void doIt() { . . . /* any implementation */ }
}
Listing 3.2. AppContext.xml Spring Configuration
<beans>
<bean id="inter" class="com.p2.impl.Impl"/>
</beans>
Listing 3.3. Client Class
package com.p1;
import com.p2.*;
import org.springframework.context.*;
import org.springframework.context.support.*;
public class Client {
public static void main(String args[]) {
ApplicationContext appContext = new
FileSystemXmlApplicationContext(
"com/p1/AppContext.xml");
Inter i = (Inter) appContext.getBean("inter");
i.doIt();
}
}
3.4.1.2. OSGi and Encapsulation
Now let’s look at the same example using OSGi. Here, the Impl class in the provider.jar module is tightly encapsulated, and no class in any other module is able to see the Impl class. The Impl class and Inter interface remain the same as in the previous examples; no changes are required. Instead, we’ve taken the existing application and simply set it up to work with the OSGi framework, which enforces encapsulation of module implementation details and provides an intermodule communication mechanism.
Figure 3.7 demonstrates the new structure. It’s actually an example of the Abstract Modules pattern. Here, I separated the Spring XML configuration into four different files. I could have easily used only two configuration files, but I want to keep the standard Java and OSGi framework configurations separate for each module. The provider.jar module is responsible for the configuration itself and exposing its capabilities when it’s installed. Before we describe the approach, here is a brief description of each configuration file:
)
Figure 3.7. Encapsulating design with OSGi
- client.xml: Standard Spring configuration file that describes how the application should be launched by the OSGi framework
- client-osgi.xml: Spring configuration file that allows the Client class to consume an OSGi μService
- provider.xml: Spring configuration with the provider.jar module bean definition
- provider-osgi.xml: Spring configuration that exposes the bean definition in provider.xml as an OSGi μService
Before we look at how the two modules are wired together, let’s look at the provider.jar module, which contains the Inter interface, Impl implementation, and two configuration files. Again, Inter and Impl remain the same as in the previous example, so let’s look at the configuration files. The provider.xml file defines the standard Spring bean configuration and is what was previously shown in the AppContext.xml file in Figure 3.7. Listing 3.4 shows the provider.xml file. The key is that this configuration is deployed with the provider.jar module. Attempting to instantiate the Impl class outside of the provider.jar module will not work. Because OSGi enforces encapsulation, any attempt to reach the implementation details of a module will result in a runtime error, such as a ClassNotFoundException.
Listing 3.4. provider.xml Configuration File
<beans>
<bean id="inter" class="com.p2.impl.Impl"/>
</beans>
How does OSGi prevent other classes from instantiating the Impl class directly? The Manifest.mf file included in the provider.jar module exposes classes only in the com.p2 package, not the com.p2.impl package. So, the Inter interface registered as an OSGi μService is accessible by other modules but not by the Impl class. Listing 3.5 shows the section of the Manifest.mf illustrating the package export.
Listing 3.5. provider.xml Configuration File
Export-Package: com.p2
The provider-osgi.xml file is where things get very interesting, and it is where we expose the behavior of the provider.jar module as an OSGi μService that serves as the contract between the Client and Impl classes. The configuration for the provider.jar module lives within the provider.jar module, so no violation of encapsulation occurs.
Listing 3.6 shows the configuration. The name of the μService we are registering with the OSGi framework is called interService, and it references the Impl bean defined in Listing 3.4, exposing its behavior as type Inter. At this point, the provider.jar module has a interService OSGi μService that can be consumed by another module. This service is made available by the provider.jar module after it is installed and activated in the OSGi framework.
Listing 3.6. provider.xml Configuration File
<osgi:service id="interService" ref="inter"
interface="com.p2.Inter"/>
Now, let’s look at the client.jar module. The client.xml file configures the Client class. It effectively replaces the main method on the Client class in Listing 3.3 with the run method, and the OSGi framework instantiates the Client class, configures it with an Inter type, and invokes the run method. Listing 3.7 shows the client.xml file, and Listing 3.8 shows the Client class. This is the mechanism that initiates the process and replaces the main method in the Client class of the previous example.
Listing 3.7. Client.xml Configuration File
<beans>
<bean name="client" class="com.p1.impl.Client"
init-method="run">
<property name="inter"
ref="interService"/>
</bean>
</beans>
Listing 3.8. The Client Class
package com.p1.impl;
import com.p2.*;
import com.p1.*;
public class Client {
private Inter i;
public void setInter(Inter i) {
this.i = i;
}
public void run() throws Exception {
i.doIt();
}
}
The Inter type that is injected into the client class is done through the client-osgi.xml configuration file. Here, we specify that we want to use a μService of type Inter, as shown in Listing 3.9.
Listing 3.9. Client.xml Configuration File
<osgi:reference id="interService" interface="com.p2.Inter"/>
The Manifest.mf file for the client.jar module imports the com.p2 packages, which gives it access to the Inter μService. Listing 3.10 shows the section of Manifest.mf showing the package imports and exports for the client.jar module.
Listing 3.10. Client.xml Configuration File
Import-Package: com.p2
This simple example has several interesting design aspects.2 The provider.jar module is independently deployable. It has no dependencies on any other module, and it exposes its set of behaviors as a μService. No other module in the system needs to know these details.
The design could have also been made even more flexible by packaging the Impl class and Inter interface in separate modules. By separating the interface from the implementation, we bring a great deal of flexibility to the system, especially with OSGi managing our modules.
At first glance, it might also appear to contradict the External Configuration pattern. When defining the external configuration for a module, we still want to ensure implementation details are encapsulated. External configuration is more about allowing clients to configure a module to its environmental context and not about exposing implementation details of the module.
The key takeaway from this simple demonstration is that the classes in the provider.jar module are tightly encapsulated because the OSGi framework enforces type visibility. We expose only the public classes in the packages that a module exports, and the μService is the mechanism that allows modules to communicate in a very flexible manner. The μService spans the joints of the system, and because OSGi is dynamic, so too are the dependencies on μServices. Implementations of the μService can come and go at runtime, and the system can bind to new instances as they appear.
Again, we’ll see several more examples of this throughout the remainder of the discussion. Even though you can’t enforce encapsulation of module implementation using standard Java, it’s still imperative to begin designing more modular software systems. As we’ll see, by applying several of the techniques we discuss in this book, we put ourselves in an excellent position to take advantage of a runtime module system.