Presentation given by Carsten Ziegeler and me at EclipseCon 2014 in Burlingame (CA) about ongoing specification work in OSGi, covering the Core Platform Expert Group (CPEG) and the Enterprise Expert Group (EEG)

1. Carsten Ziegeler
David Bosschaert
What's cool in the new and updated
OSGi Specs
1 of 43

2. Speakers
Carsten Ziegeler (cziegeler@apache.org)
RnD Adobe Research Switzerland
OSGi CPEG and EEG Member
ASF member
David Bosschaert (davidb@apache.org)
RnD Adobe Research Dublin
Co-chair OSGi EEG
Open-source and cloud enthusiast
2 of 43

3. Agenda
Framework updates
Repository update
OSGi/CDI integration
Declarative Services
Cloud
Http Service
Semantic Versioning Annotations
Other spec updates
3 of 43

4. Framework Updates
Service Scopes (RFC 195)
Service Scopes: singleton, bundle, prototyp
Driver: Support for EEG specs (EJB, CDI)
Usage in other spec updates
New PrototypeServiceFactory
4 of 43

5. PrototypeServiceFactory
ppuubblliicc iinntteerrffaaccee PPrroottoottyyppeeSSeerrvviicceeFFaaccttoorryy<S>
eexxtteennddss SSeerrvviicceeFFaaccttoorryy<S> {
S getService(BBuunnddllee bundle,
SSeerrvviicceeRReeggiissttrraattiioonn<S> registration);
vvooiidd ungetService(BBuunnddllee bundle,
SSeerrvviicceeRReeggiissttrraattiioonn<S> registration,
S service);
}
5 of 43

6. New method in BundleContext:
ppuubblliicc iinntteerrffaaccee BBuunnddlleeCCoonntteexxtt {
<S> SSeerrvviicceeOObbjjeeccttss<S> getServiceObjects(SSeerrvviicceeRReeffeerreennccee<S> rreeff);
}
New Interface ServiceObjects:
ppuubblliicc iinntteerrffaaccee SSeerrvviicceeOObbjjeeccttss<S> {
S getService();
vvooiidd ungetService(S service);
}
6 of 43

7. Repository
1.1
7 of 43

8. OSGi Repository today
8 of 43

9. Example Repository namespaces
9 of 43

10. RFC 187 - Repository 1.1
Existing repository powerful
but: limited to queries in a single namespace
New in RFC 187:
Combine requirements spanning multiple namespaces:
RReeppoossiittoorryy repo = ... // Obtain from Service Registry
CCoolllleeccttiioonn<RReessoouurrccee> res = repo.findProviders(
repo.getExpressionCombiner().aanndd(
repo.newRequirementBuilder("osgi.wiring.package").
addDirective("filter","(osgi.wiring.package=foo.pkg1)").
buildExpression(),
repo.newRequirementBuilder("osgi.identity").
addDirective("filter",
"(license=http://opensource.org/licenses/Apache-2.0)").
buildExpression()));
10 of 43

11. OSGi/CDI
integration
11 of 43

12. RFC 193 - CDI Support
Bridging OSGi and standard JavaEE
dependency model
● Publishing CDI beans as OSGi services
● Injecting OSGi services in CDI beans
CDI = Contexts and dependency injection
12 of 43

13. RFC 193 - Examples
● Publishing CDI bean as OSGi service
iimmppoorrtt org.osgi.service.cdi.CCoommppoonneenntt;
@Component
ppuubblliicc ccllaassss MMyyCCoommppoonneenntt iimmpplleemmeennttss MMyyIInntteerrffaaccee { ... }
● Dependency Injection
@Inject
@Service
pprriivvaattee MMyyIInntteerrffaaccee serviceA;
@Inject
@Service(optional = ttrruuee)
pprriivvaattee MMyyIInntteerrffaaccee serviceB;
13 of 43

14. Declarative
Services
14 of 43

15. RFC 190 - Declarative Services
Enhancements
Support of service scopes
Diagnostic API
DTOs
But most importantly...
15 of 43

16. Use annotations for
configuration...
@interface MMyyCCoonnffiigg {
bboooolleeaann enabled() ddeeffaauulltt ttrruuee;
SSttrriinngg[] topic() ddeeffaauulltt {"topicA", "topicB"};
SSttrriinngg userName();
iinntt service_ranking() ddeeffaauulltt 15;
}
16 of 43

17. ...and reference them in
lifecycle methods
@Component
ppuubblliicc ccllaassss MMyyCCoommppoonneenntt {
SSttrriinngg userName;
SSttrriinngg[] topics;
@Activate
pprrootteecctteedd vvooiidd activate(ffiinnaall MMyyCCoonnffiigg config) {
// note: annotation MyConfig used as interface
iiff ( config.enabled() ) {
tthhiiss.userName = config.userName();
tthhiiss.topics = config.topic();
}
}
}
17 of 43

18. ...or even simpler...
@Component
ppuubblliicc ccllaassss MMyyCCoommppoonneenntt {
pprriivvaattee MMyyCCoonnffiigg configuration;
@Activate
pprrootteecctteedd vvooiidd activate(ffiinnaall MMyyCCoonnffiigg config) {
// note: annotation MyConfig used as interface
iiff ( config.enabled() ) {
tthhiiss.configuration = config;
}
}
}
18 of 43

19. Annotation Mapping
Fields registered as component
properties
Name mapping (_ -> .)
Type mapping for configurations
19 of 43

20. Additional Metatype
Support (RFC 208)
@ObjectClassDefinition(label="My Component",
description="Coolest component in the world.")
@interface MMyyCCoonnffiigg {
@AttributeDefinition(label="Enabled",
description="Topic and user name are used if enabled")
bboooolleeaann enabled() ddeeffaauulltt ttrruuee;
@AttributeDefinition(...)
SSttrriinngg[] topic() ddeeffaauulltt {"topicA", "topicB"};
@AttributeDefinition(...)
SSttrriinngg userName();
iinntt service_ranking() ddeeffaauulltt 15; // maps to service.ranking
}
20 of 43

21. RFC 190 - Declarative Services
Enhancements
Annotation configuration support
Support of service scopes
Introspection API
21 of 43

22. HTTP
Service
22 of 43

23. RFC 189 - Http Service
Update
Update to Servlet API 3+
Whiteboard support
and Introspection API
23 of 43

24. Whiteboard Servlet Registration
@Component(service = javax.servlet.SSeerrvvlleett.ccllaassss,
scope="PROTOTYPE",
pprrooppeerrttyy={
"osgi.http.whiteboard.servlet.pattern=/products/*",
})
ppuubblliicc ccllaassss MMyySSeerrvvlleett eexxtteennddss HHttttppSSeerrvvlleett {
...
}
24 of 43

25. Whiteboard Servlet Filter
Registration
@Component(service = javax.servlet.FFiilltteerr.ccllaassss,
scope="PROTOTYPE",
pprrooppeerrttyy={
"osgi.http.whiteboard.filter.pattern=/products/*",
})
ppuubblliicc ccllaassss MMyyFFiilltteerr iimmpplleemmeennttss FFiilltteerr {
...
}
25 of 43

26. Additional Support
Most listener types are supported
Register with their interface
Error Pages and Resources
Shared HttpContexts
Target Http Service
26 of 43

27. Cloud
27 of 43

28. Current PaaS offerings...
28 of 43

29. OSGi Cloud Ecosystems PaaS
29 of 43

30. An OSGi cloud ecosystem...
Many frameworks
○ hosting a variety of deployments
Together providing The Application
Not a bunch of replicas
○ rather a collection of different nodes
○ with different roles working together
○ some may be replicas
Load varies over time
... and so does your cloud system
○ topology
○ configuration
○ number of nodes
○ depending on the demand
30 of 43

31. To realize this you need...
Information!
○ need to know what nodes are available
○ ability to react to changes
Provisioning capability
Remote invocation
○ inside your cloud system
○ to get nodes to communicate
○ either directly...
○ ... or as a means to set up communication channels
31 of 43

32. RFC 183 - Cloud Ecosystems
FFrraammeewwoorrkkNNooddeeSSttaattuuss service:
information about each Cloud node
accessible as a Remote Service
throughout the ecosystem
Information such as:
Hostname/IP address
Location (country etc)
OSGi and Java version running
A REST management URL
Runtime metadata
Available memory / disk space
Load measurement
... you can add custom metadata too ...
32 of 43

33. FrameworkNodeStatus service properties
33 of 43

34. RFC 182 - REST API
A cloud-friendly remote management API
works great with FrameworkNodeStatus
Example:
addingService(SSeerrvviicceeRReeffeerreennccee<FFrraammeewwoorrkkNNooddeeSSttaattuuss> rreeff) {
// A new Node became available
SSttrriinngg url = rreeff.getProperty("org.osgi.node.rest.url");
RReessttCClliieenntt rc = nneeww RReessttCClliieenntt(nneeww URI(url));
// Provision the new node
rc.installBundle(...);
rc.startBundle(...);
}
34 of 43

35. Additional ideas in RFC 183
Special Remote Services config type
・ osgi.configtype.ecosystem
・ defines supported Remote Service data types
・ not visible outside of cloud system
Ability to intercept remote service calls
・ can provide different service for each client
・ can do invocation counting (quotas, billing)
Providing remote services meta-data
・ quota exceeded
・ payment needed
・ maintenance scheduled
35 of 43

36. Current OSGi cloud work
Provides a base line
○ to build fluid cloud systems
○ portability across clouds
Where everything is dynamic
○ nodes can be repurposed
... and you deal with your cloud nodes
through OSGi services
36 of 43

37. Type and
Package
Annotations
37 of 43

38. Semantic Versioning...
... is a versioning policy for exported packages.
OSGi versions: <major>.<minor>.<micro>.<qualifier>
Updating package versions:
● fix/patch (no change to API):
update micro
● extend API (affects implementers, not clients):
update minor
● API breakage:
update major
Note: not always used for bundle versions
38 of 43

39. RFC 197 – OSGi Type and
Package Annotations
Annotations for documenting semantic
versioning information
Class retention annotations
@Version
@ProviderType
@ConsumerType
39 of 43

40. Other
Enterprise
Spec
updates
40 of 43

41. ▻ Asynchronous Services
▻ Promises API
▻ Blueprint 1.1
・ Non-damped service references
・ Grace period enhancements
・ Many small fixes
▻ Remote Service Admin 1.1
・ Remote Service registration modification
▻ Subsystems 1.1
・ Provide Deployment Manifest separately
・ Many small enhancements
▻ DTOs
41 of 43

42. When can I get it?
RFCs available to everyone today:
https://github.com/osgi/design
(https://github.com/osgi/design)
42 of 43

43. Questions?
43 of 43