Upload
mfrancis
View
465
Download
4
Embed Size (px)
DESCRIPTION
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.
Citation preview
Carsten Ziegeler
David Bosschaert
What's cool in the new and updated
OSGi Specs
1 of 53
Speakers
Carsten Ziegeler ([email protected])⦿ RnD Adobe Research Switzerland⦿ OSGi Board, 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 53
Agenda⦿ Framework updates⦿ Repository update⦿ Asynchronous Services & Promises⦿ Declarative Services⦿ Http Service⦿ Cloud⦿ Semantic Versioning Annotations⦿ Other spec updates
3 of 53
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
Framework UpdatesService Scopes (RFC 195)OSGi R5 supports two service scopes:⦿ Singleton⦿ Bundle (ServiceFactory)Transparent to the clientS getService(SSeerrvviicceeRReeffeerreennccee<S> rreeff)
vvooiidd ungetService(SSeerrvviicceeRReeffeerreennccee<S> rreeff)
5 of 53
Framework UpdatesService Scopes (RFC 195)⦿ Third Scope: prototype⦿ Driver: Support for EEG specs (EJB, CDI)⦿ Usage in other spec updatesClients need to use new API / mechanisms
6 of 53
Framework UpdatesService Scopes (RFC 195)New BundleContext Methods APIS getServiceObjects(SSeerrvviicceeRReeffeerreennccee<S> rreeff).getService()
vvooiidd getServiceObjects(SSeerrvviicceeRReeffeerreennccee<S> rreeff).ungetService(S)
Transparent to the client
7 of 53
Framework UpdatesService Scopes (RFC 195)⦿ New PrototypeServiceFactoryinterface⦿ Managed service registration propertiesfor inspection⦿ Support in component frameworks (DS,Blueprint)
8 of 53
DataTransferObjects
9 of 53
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
RFC 185 – Data Transfer ObjectsGetting DTOs: adapter patternppuubblliicc 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
RFC 185 – Data Transfer ObjectsDTOs for the OSGi framework⦿ FrameworkDTO⦿ BundleDTO⦿ ServiceReferenceDTO⦿ BundleStartLevelDTO, FrameworkStartLevelDTO⦿ CapabilityDTO, RequirementDTO, ResourceDTO⦿ BundleWiringsDTO, etc
12 of 53
Repository1.1
13 of 53
OSGi Repository today
14 of 53
Example Repository namespaces
15 of 53
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()));
16 of 53
AsynchronousServices &Promises
17 of 53
Async Services● Asynchronously invoke services
existing servicenew ones, written for async access
● Client invokes the service via a mediator● Invocation returns quickly
result can be obtained later
18 of 53
Async Services - exampleA 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
OSGi Promises● Inspired by JavaScript Promises
Make latency and errors explicit
● Provide async chaining mechanismBased on callbacks
● Promises are Monads● Works with many (older) Java versions● Designed to work with Java 8
CompletableFuture and Lambdas
● Used with Async ServicesAlso useful elsewhere
20 of 53
OSGi Promises - exampleSSuucccceessss<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
DeclarativeServices
22 of 53
RFC 190 - Declarative ServicesEnhancements⦿ Support of prototype scope⦿ Introspection API⦿ DTOs⦿ But most importantly...
23 of 53
Simplify Component Dvlpmnt@Component(pprrooppeerrttyy={
MMyyCCoommppoonneenntt.PROP_ENABLED + ":Boolean=" + MMyyCCoommppoonneenntt.DEFAULT_ENABLED
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
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
Use annotations forconfiguration...@interface MMyyCCoonnffiigg {
bboooolleeaann enabled() ddeeffaauulltt ttrruuee;
SSttrriinngg[] topic() ddeeffaauulltt {"topicA", "topicB"};
SSttrriinngg userName();
iinntt service_ranking() ddeeffaauulltt 15;
}
26 of 53
...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();
}
}
}
27 of 53
...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
Annotation Mapping⦿ Fields registered as componentproperties⦿ Name mapping (_ -> .)⦿ Type conversion for configurations
29 of 53
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
}
30 of 53
RFC 190 - Declarative ServicesEnhancements⦿ Annotation configuration support⦿ Support of prototype scope⦿ Introspection API⦿ DTOs
31 of 53
HTTPService
32 of 53
Http Whiteboard ServiceRFC 189⦿ Whiteboard support⦿ Servlet API 3+ Support⦿ and Introspection API
33 of 53
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
Whiteboard Servlet FilterRegistration@Component(service = javax.servlet.FFiilltteerr.ccllaassss,
scope="PROTOTYPE",
pprrooppeerrttyy={
"osgi.http.whiteboard.filter.pattern=/products/*",
})
ppuubblliicc ccllaassss MMyyFFiilltteerr iimmpplleemmeennttss FFiilltteerr {
...
}
35 of 53
Additional Support⦿ Most listener types are supportedRegister with their interface⦿ Error Pages and Resources⦿ Shared and segregated HttpContexts⦿ Target Http Service
36 of 53
Cloud
37 of 53
Current PaaS offerings...
38 of 53
OSGi Cloud Ecosystems PaaS
39 of 53
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
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
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 ...
42 of 53
FrameworkNodeStatus service properties
43 of 53
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(...);
}
44 of 53
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
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
46 of 53
Type andPackageAnnotations
47 of 53
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
48 of 53
RFC 197 – OSGi Type andPackage Annotations⦿ Annotations for documenting semanticversioning information⦿ Class retention annotations
⦿ @Version⦿ @ProviderType⦿ @ConsumerType
49 of 53
OtherEnterpriseSpecupdates
50 of 53
▻ 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
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
Questions?
53 of 53