What’s cool in the new and updated OSGi specs (DS, Cloud and more) - C Ziegeler & D Bosschaert
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

What’s cool in the new and updated OSGi specs (DS, Cloud and more) - C Ziegeler & D Bosschaert

  • 486 views
Uploaded on

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......

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.

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
486
On Slideshare
485
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
18
Comments
0
Likes
0

Embeds 1

https://twitter.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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