Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

What's cool in the new and updated OSGi Specs (EclipseCon 2014)

1,591 views

Published on

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)

Published in: Technology
  • Be the first to comment

  • Be the first to like this

What's cool in the new and updated OSGi Specs (EclipseCon 2014)

  1. 1. Carsten Ziegeler David Bosschaert What's cool in the new and updated OSGi Specs 1 of 43
  2. 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. 3. Agenda Framework updates Repository update OSGi/CDI integration Declarative Services Cloud Http Service Semantic Versioning Annotations Other spec updates 3 of 43
  4. 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. 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. 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. 7. Repository 1.1 7 of 43
  8. 8. OSGi Repository today 8 of 43
  9. 9. Example Repository namespaces 9 of 43
  10. 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. 11. OSGi/CDI integration 11 of 43
  12. 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. 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. 14. Declarative Services 14 of 43
  15. 15. RFC 190 - Declarative Services Enhancements Support of service scopes Diagnostic API DTOs But most importantly... 15 of 43
  16. 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. 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. 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. 19. Annotation Mapping Fields registered as component properties Name mapping (_ -> .) Type mapping for configurations 19 of 43
  20. 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. 21. RFC 190 - Declarative Services Enhancements Annotation configuration support Support of service scopes Introspection API 21 of 43
  22. 22. HTTP Service 22 of 43
  23. 23. RFC 189 - Http Service Update Update to Servlet API 3+ Whiteboard support and Introspection API 23 of 43
  24. 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. 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. 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. 27. Cloud 27 of 43
  28. 28. Current PaaS offerings... 28 of 43
  29. 29. OSGi Cloud Ecosystems PaaS 29 of 43
  30. 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. 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. 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. 33. FrameworkNodeStatus service properties 33 of 43
  34. 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. 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. 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. 37. Type and Package Annotations 37 of 43
  38. 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. 39. RFC 197 – OSGi Type and Package Annotations Annotations for documenting semantic versioning information Class retention annotations @Version @ProviderType @ConsumerType 39 of 43
  40. 40. Other Enterprise Spec updates 40 of 43
  41. 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. 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. 43. Questions? 43 of 43

×