What's cool in the new and updated OSGi Specs (EclipseCon 2014)
43
Carsten Ziegeler David Bosschaert What's cool in the new and updated OSGi Specs 1 of 43
-
Upload
david-bosschaert -
Category
Technology
-
view
1.074 -
download
0
description
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)
Transcript of What's cool in the new and updated OSGi Specs (EclipseCon 2014)
Carsten Ziegeler
David Bosschaert
What's cool in the new and updated
OSGi Specs
1 of 43
Speakers
Carsten Ziegeler ([email protected])⦿ RnD Adobe Research Switzerland⦿ OSGi CPEG and EEG Member⦿ ASF member
David Bosschaert ([email protected])⦿ RnD Adobe Research Dublin⦿ Co-chair OSGi EEG⦿ Open-source and cloud enthusiast
2 of 43
Agenda⦿ Framework updates⦿ Repository update⦿ OSGi/CDI integration⦿ Declarative Services⦿ Cloud⦿ Http Service⦿ Semantic Versioning Annotations⦿ Other spec updates
3 of 43
Framework UpdatesService Scopes (RFC 195)⦿ Service Scopes: singleton, bundle, prototype⦿ Driver: Support for EEG specs (EJB, CDI)⦿ Usage in other spec updates⦿ New PrototypeServiceFactory
4 of 43
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
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
Repository1.1
7 of 43
OSGi Repository today
8 of 43
Example Repository namespaces
9 of 43
RFC 187 - Repository 1.1Existing 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
OSGi/CDIintegration
11 of 43
RFC 193 - CDI SupportBridging OSGi and standard JavaEEdependency model● Publishing CDI beans as OSGi services● Injecting OSGi services in CDI beans
CDI = Contexts and dependency injection
12 of 43
RFC 193 - Examples● Publishing CDI bean as OSGi serviceiimmppoorrtt 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
DeclarativeServices
14 of 43
RFC 190 - Declarative ServicesEnhancements⦿ Support of service scopes⦿ Diagnostic API⦿ DTOs⦿ But most importantly...
15 of 43
Use annotations forconfiguration...@interface MMyyCCoonnffiigg {
bboooolleeaann enabled() ddeeffaauulltt ttrruuee;
SSttrriinngg[] topic() ddeeffaauulltt {"topicA", "topicB"};
SSttrriinngg userName();
iinntt service_ranking() ddeeffaauulltt 15;
}
16 of 43
...and reference them inlifecycle 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
...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
Annotation Mapping⦿ Fields registered as componentproperties⦿ Name mapping (_ -> .)⦿ Type mapping for configurations
19 of 43
Additional MetatypeSupport (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
RFC 190 - Declarative ServicesEnhancements⦿ Annotation configuration support⦿ Support of service scopes⦿ Introspection API
21 of 43
HTTPService
22 of 43
RFC 189 - Http ServiceUpdate⦿ Update to Servlet API 3+⦿ Whiteboard support⦿ and Introspection API
23 of 43
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
Whiteboard Servlet FilterRegistration@Component(service = javax.servlet.FFiilltteerr.ccllaassss,
scope="PROTOTYPE",
pprrooppeerrttyy={
"osgi.http.whiteboard.filter.pattern=/products/*",
})
ppuubblliicc ccllaassss MMyyFFiilltteerr iimmpplleemmeennttss FFiilltteerr {
...
}
25 of 43
Additional Support⦿ Most listener types are supportedRegister with their interface⦿ Error Pages and Resources⦿ Shared HttpContexts⦿ Target Http Service
26 of 43
Cloud
27 of 43
Current PaaS offerings...
28 of 43
OSGi Cloud Ecosystems PaaS
29 of 43
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
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
RFC 183 - Cloud EcosystemsFFrraammeewwoorrkkNNooddeeSSttaattuuss service:
information about each Cloud nodeaccessible as a Remote Servicethroughout the ecosystem
Information such as:Hostname/IP addressLocation (country etc)OSGi and Java version runningA REST management URL
Runtime metadataAvailable memory / disk spaceLoad measurement
... you can add custom metadata too ...
32 of 43
FrameworkNodeStatus service properties
33 of 43
RFC 182 - REST APIA cloud-friendly remote management APIworks 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
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
Current OSGi cloud workProvides 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 nodesthrough OSGi services
36 of 43
Type andPackageAnnotations
37 of 43
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 majorNote: not always used for bundle versions
38 of 43
RFC 197 – OSGi Type andPackage Annotations⦿ Annotations for documenting semanticversioning information⦿ Class retention annotations
⦿ @Version⦿ @ProviderType⦿ @ConsumerType
39 of 43
OtherEnterpriseSpecupdates
40 of 43
▻ 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
When can I get it?RFCs available to everyone today:https://github.com/osgi/design(https://github.com/osgi/design)
42 of 43
Questions?
43 of 43
