Software AG Application Modularity - OSGi and JPMS (Jigsaw)

© 2018 Software AG. All rights reserved. For internal use only
OSGi AND JPMS (JIGSAW)
Todor Boev
Common Runtime Project
APPLICATION MODULARITY

© 2018 Software AG. All rights reserved. For internal use only2
AGENDA
• Use Case
• Module Layer
• Runtime Layer
• JPMS (Jigsaw)
• OSGi
• Conclusion
• Q & A

 
TRIED HARD TO BE UNBIASED
• Requirements
1. Defined generic use case
2. Defined common sense measure of quality
3. Requirements maximize quality
• Evaluation
– Implemented the same simple greenfield applications on both
– No frameworks
– But evaluated how well frameworks can be supported
• JPMS / Jigsaw
– Applied the best practices recommended by Oracle

| © 2018 Software AG. All rights reserved. For internal use only4
USE CASE

• Modules are consumed
– In large numbers
– From multiple release streams
– The release streams are uncoordinated
– The release streams are independent
USE CASE
COMPOSE APPLICATIONS FROM MODULES

USE CASE
COORDINATED RELEASE
Lib 1.0 Lib 1.1 Lib 2.0
Log4j 2.0 Log4J 2.1 Log4J 3.0
App 1.1App 1.0 App 2.0

USE CASE
UNCOORDINATED RELEASE
Lib 1.0 Lib 1.1 Lib 2.0
Log4j 2.0 Log4J 2.1 Log4J 3.0 Log4J 3.1
App 1.2App1.0 App 1.3

 
USE CASE
• Measures resilience to change
• Where change are the differences between
– The environment at compile time
– VS the environment at runtime
MEASURE MODULARITY
A module’s usefulness increases
- with the number of environments where it can run
- without requiring a rebuild

USE CASE
• Resilience to change over time (current modules)
– Functionality
– Refactoring
• Resilience to change of scale (add modules)
– Complexity
REQUIREMENTS

USE CASE
• Module Layer
– Handles time
– Module artifact
– Dependency model (sharing of classes)
• Runtime Layer
– Handles scale
– Module lifecycle (runtime state)
– Service Model (sharing of objects)
MODULAR SYSTEM STRUCTURE
Modular Layer
(Classes)
Runtime Layer
(Objects)

MODULE LAYER

MODULE LAYER
VERSION CHANGES
Modules that execute the application meet for the first time at runtime
Lib 1.0 Lib 1.1 Lib 2.0
App 1.2App1.0
compile
run

MODULE LAYER
VERSION CHANGES
Lib 1.0 Lib 1.1 Lib 2.0
App 1.2App1.0 App 1.3
compile
run
Tolerate functionality changes
- for as long as possible (1.1.0 → 1.2.0 → 1.3.0)
- and then no more (2.0.0)

MODULE LAYER
• Refactoring
- Improves quality of implementation
- Does not affect consumers
• Modules should tolerate changes to dependency
– IDs
• Improve structure: add, remove, rename, merge, split modules
– Dependencies
• Internal: improve structure
• Transitive: e.g. reduce codebase
VERSION CHANGES
Tolerate refactoring forever (1.0.0 → 1.0.1 → 1.0.2 → 1.0.3 …)

RUNTIME LAYER

RUNTIME LAYER
Consumer API Provider
compile
run
compile
• A shared API module exports the interface
• A consumer module imports the API in order to call it
• A provider module imports the API in order to implement it
DISTRIBUTE COMPLEXITY
Modules should bind to interfaces not to other modules

RUNTIME LAYER
• The Consumer has to obtain objects
• … that implement the interface
• ... without importing the implementation classes from the Provider
Consumer API Provider
load interface load interface
get impl object?

RUNTIME LAYER
1. Publish: provider advertises implementation
2. Find: consumer selects implementation
3. Bind: consumer gets implementation object
Consumer ProviderService
(1) publish(3) bind
(2) find
Service – communication mechanism provided by the modular system

RUNTIME LAYER
Library
Library
Library
Application
Library
factory
factory
factory
factory
object
object
object
• At the end of the exchange who owns the object?
• Consumer
– Complexity is Concentrated
– Libraries

• At the end of the exchange who owns the object?
• Provider
– Complexity is Distributed
– Dependency Injection
– Services
Module
Module
Module
Module
Module
object
object
object
object
RUNTIME LAYER

JPMS / JIGSAW

JPMS
• Minimal
– Define features required to boot
• Familiar
– Quickly transition to Java Code
– Use traditional patterns
PHILOSOPHY - SIMPLICITY

JPMS 
MODULE LAYER

JPMS MODULE LAYER
• A module is
– A jar
– That contains additional metadata
– And an optional main() method
• The metadata is binary
– /module-info.class
• The metadata is authored by humans
– Compiled from source: /module-info.java
– Compiler options: --module-version 1.2.3
ARTIFACT

JPMS MODULE LAYER
ARTIFACT
import org.example.hello.HelloFactory;
import
org.example.hello.provider.en.EnJsonHelloFactory;
module org.example.hello.provider.en {
requires org.example.hello.api;
provides HelloFactory with EnJsonHelloFactory;
}
• /module-info.java

JPMS MODULE LAYER
• Modules provide java packages
• Modules can be versioned at compile time
– Versions are ordered
– Version number tokens have no assigned meaning:  
3.14.159.256.358+irrational-pi
MODULES PROVIDE
// May pass --module-version 1.2.3 to javac
module org.example.hello.api {
exports org.example.hello;
}

JPMS MODULE LAYER
• Modules require other modules by their ID
– The ID becomes part of the module API
• Require a module only as a compile dependency
• Runtime dependencies must be handled by the build
MODULES REQUIRE
module org.example.hello.consumer {
// May capture 1.2.3
// Can’t declare that max acceptable is 2.0.0
// Can’t say I want an impl of the API
//requires org.example.hello.provider.en;
// Can’t say a want a framework, not packages
//requires dependency.injection.fw;
}

JPMS MODULE LAYER
• Build:
– Resolve dependency graph: compile, runtime
– Select compatible versions
• Runtime:
– Check dependency graph: compile
– Trust versions are compatible
• Module metadata is the build script
– Of arbitrary quality, artifact repository, versioning policy:
• ant + /lib, make, maven + pom.xml, gradle + ivy.xml
• JPMS does not enforce nor define compatibility
– Nothing for builds to coordinate on
FUNCTIONALITY CHANGES
/module-
info.java
pom.xml build.gradle

JPMS MODULE LAYER
• Improving modular structure
– Adding a module is a minor change: 1.0 -> 1.1
– Removing a module is a major change: 1.0 -> 2.0
– Even if the functionality is only redistributed
• Offsetting via façade is a minor change: 1.0 -> 1.1
REFACTORING CHANGES
module org.example.hello.api {
requires transitive refactored.one;
requires transitive refactored.two;
}

JPMS RUNTIME LAYER
• Minimal
– Define features required to boot
• Describes class isolation boundary to JVM:
• Familiar
requires
org.example.hello.api;
/module-info.java
/module-info.java

JPMS 
RUNTIME LAYER

JPMS RUNTIME LAYER
• Provider publishes:
• Best practice requires to publish a factory rather than the service class itself
SERVICES - PUBLISH
import org.example.hello.provider.en.EnJsonHelloFactory;
module org.example.greeter.provider.en {
provides HelloFactory with EnJsonHelloFactory;
}
(service factory interface, service factory
class)

JPMS RUNTIME LAYER
SERVICES - FIND
module org.example.hello.consumer {
uses HelloFactory;
}
// The factory must be very cheap to make
Iterable<HelloFactory> hellos = ServiceLoader.load(HelloFactory.class);
for (HelloFactory hf : hellos) {
// The factory must provide info methods
if ("en".equals(hf.getLanguage()) && "json".equals(hf.getFormat())) {
...
}
}
• Matching done by best practice
– Must be followed by both 
provider and consumer

JPMS RUNTIME LAYER
SERVICES - BIND
• The consumer controls the service object lifecycle
HelloFactory hf = ...
// Bind: create, configure, start, stop, destroy
Hello greeter = hf.createHello();
greeter.setPrettyPrint(true);
// Use
String msg = greeter.message(“OSGi”);
System.out.println(msg);

JPMS RUNTIME LAYER
• One module can have a main() method
– Control flows from there
– Set by compiler option:  
--main-class org.example.hello.consumer.Greeting
LIFECYCLE

JPMS RUNTIME LAYER
• Minimal
– Define features required to boot:
• Start from:
• A map of interface-to-class:
• Familiar
• Find, Bind done by arbitrary code
• Publish class
• Publish factory class
void main(String[]
args)
provides HelloFactory with
EnJsonHelloFactory;
ServiceLoader.load(HelloFactory.clas
s);

JPMS 
SUMMARY

JPMS SUMMARY
PHILOSOPHY
Library
Library
Library
Application
Library
factory
factory
factory
factory
object
object
object
An application is composed of user code and libraries
• A library provides classes to applications
• The app code composes the 
library classes
• As libraries are added  
the app code complexity 
grows unchecked

JPMS SUMMARY
FRAMEWORKS
• Standardizes publish, half of find, no bind
– Hard to make code that
– … can access objects from another module
– … using a framework neutral mechanism
• Framework fragmentation/lock in
– Frameworks spread over multiple modules
– Can’t consume modules that don’t use your 
framework
Guice
CDI

OSGI

OSGI
• Simple textual protocols (HTTP headers)
– Closed format (REST verbs)
– Open semantics (REST message mime type)
• Public contracts (mime type registry)
• Self contained (REST self descriptive messages)
PHILOSOPHY – COMPOSABILITY

OSGI 
MODULE LAYER

OSGI MODULE LAYER
• A bundle (module) is
– A jar
– That contains additional metadata
– And an optional start/stop hook
• The metadata is textual
– /META-INF/MANIFEST.MF
• The metadata is generated (semi)automatically from the application code
ARTIFACT

• package-info.java
OSGI MODULE LAYER
ARTIFACT
package org.example.hello;
// Guides importers: [1.2, 2)
@ProviderType
public interface Hello {
String message(String who);
}
@Export
@Version("1.2.3")
package org.example.hello;
• Hello.java

• Extract Modular Pattern
– Namespace ←
– Capability ←
– Requirement ←
– Resolver ←
OSGI MODULE LAYER
• Identity (coupled, brittle)
–
• Capability (decoupled, modular)
–
–
–
IDENTITY VS CAPABILITY
provides HelloFactory with
EnJsonHelloFactory
uses HelloFactory
HelloFactory hf = new
EnJsonHelloFactory();
interface
HelloFactory
provides ... with
EnJsonHelloFactory
uses
HelloFactory
java.util.ServiceLoade
r
java.util.ServiceLoade
r

OSGI MODULE LAYER
• Bundles provide Capabilities
– Namespace
– Set of attributes (Fixed set of data types)
• The Version type is semantic:
– <major>.<minor>.<micro>-<qualifier>
• Java package capabilities have shorthand syntax:
MODULES PROVIDE
osgi.wiring.package
osgi.wiring.package:String = org.example.hello
version:Version = 1.2.3
Export-Package: org.example.hello; version=1.2.3

OSGI MODULE LAYER
• Bundles declare Requirements
– Namespace
– A filter to match the attributes of a Capability
• Java package requirements have shorthand syntax:
MODULES REQUIRE
osgi.wiring.package
(&(osgi.wiring.package = org.example.hello)
(version >= 1.2)
(!(version >= 2)))
Import-Package: org.example.hello; version=“[1.2, 2)”

OSGI MODULE LAYER
• Semantic version range
FUNCTIONALITY CHANGES
Import-Package: org.example.hello; version=“[1.2, 2)”
[1.2, 2)
Hello 1.2 Hello 1.5 Hello 1.9
Consumer Consumer Consumer
Hello 2.0
run
compile

OSGI MODULE LAYER
• Capabilities have open semantics
• Resolver resolves symbolically any dependency you care to invent
• (Your) Bundles introspect the dependency graph and act
– The core does the same for packages
REFACTORING CHANGES
Provide-Capability: osgi.service;
objectClass:List<String> = "org.example.hello.Hello"
Provide-Capability:
osgi.extender;
osgi.extender = "osgi.jpa";
version:Version = "1.1"

OSGI MODULE LAYER
• Requirements have open semantics
REFACTORING CHANGES
Require-Capability: osgi.service;
filter := "(objectClass=org.example.hello.Hello)"
Require-Capability: osgi.extender;
filter := "(&(osgi.extender=osgi.jpa)(version>=1.1))"
Require-Capability: osgi.native;
filter := "(&
(osgi.native.osname ~= win32)
(osgi.native.processor ~= x86-64)
(osgi.native.language ~= en))"

OSGI MODULE LAYER
• Simple textual protocols
– Closed format
• Provide:
• Require:
– Open semantics
• references an external description
• Public contracts
– E.g the OSGi alliance maintains the osgi.wiring.package namespace
• Defines that capabilities have a package name and a version
• Defines how implementations (the OSGi core) use these to direct class loading
• Self contained
– A bundle describes everything it provides and everything it requires to run
PHILOSOPHY - COMPOSABILITY
(namespace,
attributes)
(namespace,
filter)
/META-INF/MANIFEST.MF
Semantic Versioning Semantic Dependencies
namespace

OSGI 
RUNTIME LAYER

OSGI RUNTIME LAYER
• Provider publishes:
• Provider manages the service object’s lifecycle
– I.e. this is a service architecture
SERVICES - PUBLISH
public void start(BundleContext bc) {
// Arbitrary code. Inject with other services and
configuration
Hello service = new HelloImpl();
// Impl description
Dictionary<String, Object> props = new Hashtable<>();
props.put("lang", "en");
props.put("format", "json");
// Publish under the service interface. Impl is private.
bc.registerService(Hello.class, service, props);
}
(service interface, service object,
attributes)

OSGI RUNTIME LAYER
• Consumer searches by:
SERVICES - FIND
// Ask directly for a business object
// Filter matched against business object publication attributes
// The ServiceLoader of OSGi
ServiceTracker<Hello,Hello> greeters = new ServiceTracker<>(
bc, Hello.class, "(&(lang=en)(format=json))");
(service interface,
filter)

OSGI RUNTIME LAYER
• Since the provider manages it’s published object
• The consumer binds directly to a business object
– I.e. this is a service architecture
SERVICES - BIND
// Find
ServiceTracker<Hello,Hello> greeters = new ServiceTracker<>(
bc, Hello.class, "(&(lang=en)(format=json))");
// Bind: No further setup needed
Hello greeter = greeters.getService();
// Use
String msg = greeter.message(“OSGi”);
System.out.println(msg);

OSGI RUNTIME LAYER
• Each bundle has an independent lifecycle
– Creates, configures, activates, deactivates, destroys
– … it’s own internal structure
– … so it can publish objects rather than classes
• The application behavior emerges from the combined activity of peer bundles
LIFECYCLE

OSGI RUNTIME LAYER
• Simple (semi)textual protocols
– Closed format
• Publish (Provide):
• Find (Require):
– Open semantics
• The (namespace) can represent anything
• Public contracts
– The provider defines the API: packages, classes, allowed attributes
• Self contained
– Each bundle has a dedicated lifecycle
PHILOSOPHY - COMPOSABILITY
(service interface, service object,
attributes)
(service interface,
filter)
service interface

OSGI 
SUMMARY

OSGI SUMMARY
• Each bundle manages part of the 
total state and lifecycle
• Initial bundle complexity is higher 
then a library
• As bundles are added the 
individual bundle complexity remains 
constant
PHILOSOPHY
A complex application is composed of simple collaborating applications
Module
Module
Module
Module
Module
object
object
object
object

OSGI SUMMARY
FRAMEWORKS
• Standardizes publish, find, bind
– Possible to make code that
– … can access objects from another module
– … using a framework neutral mechanism
• Enables framework interoperation
– Multiple frameworks within one application
– Even multiple JVM languages
CDI
CDI
Guice

OSGI SUMMARY
FRAMEWORKS – DECLARATIVE SERVICES
// Publish
@Lang("en") // Part of hello API
@Format("text") // Part of hello API
@Component
public class HelloImpl implements Hello
{
@Override
public String message(String who) {
return "Hello " + who;
}
}
// Find + Bind
@Component(immediate = true)
public class Greeter {
@Activate
public void activate(@Reference Hello hello)
{
System.out.println(hello.message("OSGi"));
}
}
• Frameworks dramatically lower bundle complexity

CONCLUSION

CONCLUSION
PIVOTAL DECISIONS
Decision OSGi JPMS
Philosophy Composability Simplicity
Module Style Self-Contained Library
Module Layer
Compatibility Semantic Versions
Require Capability Identity
Runtime Layer
Share Services / Objects Factories / Classes
Lifecycle Module Application

Module
(Dependency Injection)
object
object
object
object
Process
(OSGi)
module
module
module
module
System
(Micro Services)
process
process
process
process
CONCLUSION
SERVICES ALL THE WAY DOWN

CONCLUSION
GOING FORWARD
• Both can be a powerful combination
– OSGi: efficient modular application
– JPMS: efficient JRE to match the application
• OSGi R7
– Enable jars to work as either a Bundle or a JPMS module
– Detect the modules of the underlying JRE at runtime
• Next Step
– Provisioning: automatically assemble an OSGi + JPMS runtime

RESOURCES
• OSGi
– Architecture: https://www.osgi.org/developer/architecture/
– Service Layer: http://enroute.osgi.org/doc/215-sos.html
• JPMS
– Module Layer (Alex Buckley): https://youtu.be/gtcTftvj0d0
– Service Layer (Alex Buckley): https://youtu.be/RjVjm4uuMvc
• OSGi interop with JPMS
– http://blog.osgi.org/2018/02/osgi-r7-highlights-java-9-support.html
– http://blog.osgi.org/2017/09/letter-to-our-osgi-user-community-re.html
• JPrime on Modularity
– https://youtu.be/NKS5VU_r7Bo

Q & A

Software AG Application Modularity - OSGi and JPMS (Jigsaw)

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to Software AG Application Modularity - OSGi and JPMS (Jigsaw)

Similar to Software AG Application Modularity - OSGi and JPMS (Jigsaw) (20)

More from mfrancis

More from mfrancis (20)

Recently uploaded

Recently uploaded (20)

Software AG Application Modularity - OSGi and JPMS (Jigsaw)