This session will look at new and updated OSGi specs that are in the works. Developing components has never been easier. Learn more about the new Prototype Service Factory, OSGi/CDI integration and the improved annotation support for Declarative Services. Many people are realizing that OSGi is a great foundation technology for fluid cloud-computing architectures where the deployments change dynamically and applications don't simply scale by duplicating the entire VMs but by providing extra capacity exactly to those components that need it. Work is being done to create standards that facilitate such a portable OSGi cloud in ‘Cloud Ecosystems’ and the REST API specs. Learn more about these and other upcoming specs during this talk. Bios: David Bosschaert David Bosschaert works for Adobe Research and Development. He spends the much of his time on technology relating to OSGi in Apache and other open source projects. He is also co-chair of the OSGi Enterprise Expert Group and an active participant in the OSGi Cloud efforts. Before joining Adobe, David worked for Red Hat/JBoss and IONA Technologies in Dublin, Ireland. Carsten Ziegeler Carsten Ziegeler is working at Adobe Research Switzerland and spends most of his time on architectural and infrastructure topics. Working for over 25 years in open source projects, Carsten is a member of the Apache Software Foundation and heavily participates in several Apache communities including Sling, Felix and ACE. He is a frequent speaker on technology and open source conferences. Carsten participates in the OSGi Core Platform and Enterprise Expert Groups and is a member of the OSGi Alliance board.

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

2. Speakers
Carsten Ziegeler (cziegeler@apache.org)
RnD Adobe Research Switzerland
OSGi Board, 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 53

3. Agenda
Framework updates
Repository update
Asynchronous Services & Promises
Declarative Services
Http Service
Cloud
Semantic Versioning Annotations
Other spec updates
3 of 53

4. OSGi Core R6 Release
Service Scopes
Package and Type Annotations
Data Transfer Objects
Native Namespace
WeavingHook Enhancements
System Bundle Framework Hooks
Extension Bundle Activators
Framework Wiring
4 of 53

5. Framework Updates
Service Scopes (RFC 195)
OSGi R5 supports two service scopes:
Singleton
Bundle (ServiceFactory)
Transparent to the client
S getService(SSeerrvviicceeRReeffeerreennccee<S> rreeff)
vvooiidd ungetService(SSeerrvviicceeRReeffeerreennccee<S> rreeff)
5 of 53

6. Framework Updates
Service Scopes (RFC 195)
Third Scope: prototype
Driver: Support for EEG specs (EJB, CDI)
Usage in other spec updates
Clients need to use new API / mechanisms
6 of 53

7. Framework Updates
Service Scopes (RFC 195)
New BundleContext Methods API
S getServiceObjects(SSeerrvviicceeRReeffeerreennccee<S> rreeff).getService()
vvooiidd getServiceObjects(SSeerrvviicceeRReeffeerreennccee<S> rreeff).ungetService(S)
Transparent to the client
7 of 53

8. Framework Updates
Service Scopes (RFC 195)
New PrototypeServiceFactory
interface
Managed service registration properties
for inspection
Support in component frameworks (DS,
Blueprint)
8 of 53

9. Data
Transfer
Objects
9 of 53

10. RFC 185 – Data Transfer Objects
Defines a DTO model for OSGi
Serializable/Deserializable objects
Use cases: REST, JMX, Web Console...
To be adopted by other specs
10 of 53

11. RFC 185 – Data Transfer Objects
Getting DTOs: adapter pattern
ppuubblliicc ccllaassss BBuunnddlleeDDTTOO eexxtteennddss org.osgi.dto.DTO {
ppuubblliicc lloonngg id;
ppuubblliicc lloonngg lastModified;
ppuubblliicc iinntt state;
ppuubblliicc SSttrriinngg symbolicName;
ppuubblliicc SSttrriinngg version;
}
11 of 53

12. RFC 185 – Data Transfer Objects
DTOs for the OSGi framework
FrameworkDTO
BundleDTO
ServiceReferenceDTO
BundleStartLevelDTO, FrameworkStartLevelDTO
CapabilityDTO, RequirementDTO, ResourceDTO
BundleWiringsDTO, etc
12 of 53

13. Repository
1.1
13 of 53

14. OSGi Repository today
14 of 53

15. Example Repository namespaces
15 of 53

16. 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()));
16 of 53

17. Asynchronous
Services
&
Promises
17 of 53

18. Async Services
● Asynchronously invoke services
existing service
new ones, written for async access
● Client invokes the service via a mediator
● Invocation returns quickly
result can be obtained later
18 of 53

19. Async Services - example
A typical service:
ppuubblliicc iinntteerrffaaccee CCaallccSSeerrvviiccee {
BBiiggIInntteeggeerr factorial(iinntt num);
}
Invoke it asynchronously:
CCaallccSSeerrvviiccee mySvc = ... // from service registry
AAssyynncc asyncService = ... // from service registry
CCaallccSSeerrvviiccee myMediator = asyncService.mediate(mySvc);
ffiinnaall PPrroommiissee<BBiiggIInntteeggeerr> p = asyncService.call(
myMediator.factorial(1000000));
// ... factorial invoked asynchronously ...
// callback to handle the result when it arrives
p.onResolve(nneeww RRuunnnnaabbllee() {
ppuubblliicc vvooiidd run() {
SSyysstteemm.oouutt.println("Found the answer: " + p.getValue());
}
});
19 of 53

20. OSGi Promises
● Inspired by JavaScript Promises
Make latency and errors explicit
● Provide async chaining mechanism
Based on callbacks
● Promises are Monads
● Works with many (older) Java versions
● Designed to work with Java 8
CompletableFuture and Lambdas
● Used with Async Services
Also useful elsewhere
20 of 53

21. OSGi Promises - example
SSuucccceessss<SSttrriinngg,SSttrriinngg> transformResult = nneeww SSuucccceessss<>() {
ppuubblliicc PPrroommiissee<SSttrriinngg> call(PPrroommiissee<SSttrriinngg> p) {
rreettuurrnn PPrroommiisseess.resolved(toHTML(p.getValue()));
}
};
PPrroommiissee<SSttrriinngg> p = asyncRemoteMethod();
p.tthheenn(validateResult)
.tthheenn(transformResult)
.tthheenn(showResult, showError);
21 of 53

22. Declarative
Services
22 of 53

23. RFC 190 - Declarative Services
Enhancements
Support of prototype scope
Introspection API
DTOs
But most importantly...
23 of 53

24. Simplify Component Dvlpmnt
@Component(pprrooppeerrttyy={
MMyyCCoommppoonneenntt.PROP_ENABLED + ":Boolean=" + MMyyCCoommppoonneenntt.DEFAULT_ENABL
MMyyCCoommppoonneenntt.PROP_TOPIC + "=" + MMyyCCoommppoonneenntt.DEFAULT_TOPIC_1,
MMyyCCoommppoonneenntt.PROP_TOPIC + "=" + MMyyCCoommppoonneenntt.DEFAULT_TOPIC_2,
"service.ranking:Integer=15"
})
ppuubblliicc ccllaassss MMyyCCoommppoonneenntt {
ssttaattiicc ffiinnaall SSttrriinngg PROP_ENABLED = "enabled";
ssttaattiicc ffiinnaall SSttrriinngg PROP_TOPIC = "topic";
ssttaattiicc ffiinnaall SSttrriinngg PROP_USERNAME = "userName";
ssttaattiicc ffiinnaall bboooolleeaann DEFAULT_ENABLED = ttrruuee;
ssttaattiicc ffiinnaall SSttrriinngg DEFAULT_TOPIC_1 = "topicA";
ssttaattiicc ffiinnaall SSttrriinngg DEFAULT_TOPIC_2 = "topicB";
24 of 53

25. Simplify Component Dvlpmnt
@Activate
pprrootteecctteedd vvooiidd activate(ffiinnaall MMaapp config) {
ffiinnaall bboooolleeaann enabled =
PPrrooppeerrttiieessUUttiill.toBoolean(config.ggeett(PROP_ENABLED),
DEFAULT_ENABLED);
iiff ( enabled ) {
tthhiiss.userName =
PPrrooppeerrttiieessUUttiill.toString(config.ggeett(PROP_USERNAME), nnuullll
tthhiiss.topics =
PPrrooppeerrttiieessUUttiill.toStringArray(config.ggeett(PROP_TOPIC),
nneeww SSttrriinngg[] {DEFAULT_TOPIC_1, DEFAULT_TOPIC_2});
}
}
25 of 53

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

27. ...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();
}
}
}
27 of 53

28. ...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;
}
}
}
28 of 53

29. Annotation Mapping
Fields registered as component
properties
Name mapping (_ -> .)
Type conversion for configurations
29 of 53

30. 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
}
30 of 53

31. RFC 190 - Declarative Services
Enhancements
Annotation configuration support
Support of prototype scope
Introspection API
DTOs
31 of 53

32. HTTP
Service
32 of 53

33. Http Whiteboard Service
RFC 189
Whiteboard support
Servlet API 3+ Support
and Introspection API
33 of 53

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

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

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

37. Cloud
37 of 53

38. Current PaaS offerings...
38 of 53

39. OSGi Cloud Ecosystems PaaS
39 of 53

40. 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
40 of 53

41. 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
41 of 53

42. 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 ...
42 of 53

43. FrameworkNodeStatus service properties
43 of 53

44. 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(...);
}
44 of 53

45. 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
45 of 53

46. 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
46 of 53

47. Type and
Package
Annotations
47 of 53

48. 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
48 of 53

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

50. Other
Enterprise
Spec
updates
50 of 53

51. ▻ Remote Service Admin 1.1
・ Remote Service registration modification
▻ Subsystems 1.1
・ Provide Deployment Manifest separately
・ Many small enhancements
▻ Portable Java SE/EE Contracts
51 of 53

52. Where can I get it?
Core R6 spec released this week:
http://www.osgi.org/Specifications/HomePage
(http://www.osgi.org/Specifications/HomePage)
Enterprise R6 draft released this week:
http://www.osgi.org/Specifications/Drafts
(http://www.osgi.org/Specifications/Drafts)
RFCs 189, 190, 208 included in zip
All current RFCs at https://github.com/osgi/design
(https://github.com/osgi/design)
52 of 53

53. Questions?
53 of 53