1. Organizing OSGi components
(1) ORGANIZING THE DEPENDENCIES
The WAR Structure:
■ It’s a ZIP file
■ Downloadable resources (images, JavaScript files) are located at the root of the WAR
■ Application classes (servlet, web controllers) are located in WEB-INF/classes
■ Libraries and frameworks (packaged as JAR files) are in WEB-INF/lib
Thanks to OSGi's sophisticated classloading mechanisms, OSGi supports this scenario out of the
box:
different versions of the same library can coexist in a container.
(2) ORGANIZING THE APPLICATION
Some guidelines for developing OSGi applications:
■ Separate the static components from the dynamic components:
(1)Static components are bundles that define APIs by exporting interface-based Java packages.
These bundles don’t contain a Spring application context (or a BundleActivator) and don’t register
or reference any OSGi services.
(2)Dynamic components are bundles that import Java packages from static bundles, provide
implementations, and usually register OSGi services. As this is a Spring DM book, these bundles
are Spring-powered.
■ Design Layered Application: (用SOA设计的思想设计)
Perhaps exporting the packages of data access object (DAO) interfaces is useless, because what
we’re really interested in is the business services. Remember, OSGi is sometimes referred to as
a service-oriented architecture (SOA) in a JVM. We can still define the service API, but the
implementation can hide its inner workings. We can then reorganize our bundles in a simpler way
and gather the service implementation and data access layer in the same bundle—the backend
bundle.
2. Defining interactions between application bundles