OSGi Enterprise Expert Group (OSGi Users Forum Germany)


Published on

Presentation given at the German OSGi Users Forum meeting in Cologne, Germany on December 6th, 2012

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

OSGi Enterprise Expert Group (OSGi Users Forum Germany)

  1. 1. OSGiEnterprise Expert Group David Bosschaert Principal Engineer, JBoss/Red Hat david@redhat.com December 2012
  2. 2. Agenda● What is the EEG?● New specs in OSGi Enterprise R5● Work in progress for OSGi Enterprise R6
  3. 3. What is the EEG● One of the 3 active expert groups in the OSGi Alliance, others are CPEG and REG● Works on OSGi Specifications that are applicable to Enterprise use-cases – but are potentially useful in other contexts too● Active members include: IBM, RedHat, TIBCO, Adobe, Oracle, Luminis, Paremus and others● Previous releases: – R4.2 (first Enterprise Release, 2010) – R5 (second Enterprise Release, 2012)
  4. 4. New specs in theEnterprise R5 release
  5. 5. Repository Spec (Enterprise R5)Find resources in a repository...● based on capabilities – (not just their name) – osgi-defined capabilities (exported packages, bsn) – user-defined capabilities (e.g. passed QA)● E.g. “find a bundles that provides package org.acme.foo in version range [1.2, 2)”● API, can be implemented over existing repos public Map<Requirement,Collection<Capability>> findProviders(Collection<Requirement> requirements)● Can be used with any resource, not just bundles● Implementation at JBoss (github: jbosgi-repository)
  6. 6. Resolver spec (Enterprise R5)● Resolve on behalf of a framework – Given a framework with existing bundles... – Will a set of bundles resolve? – What else is needed? – Transitive dependencies● Can be used to prepare bundles to-be-installed● Run what-if scenarios● Can work seamlessly with the Repository API● Implementation at Apache Felix
  7. 7. Subsystems (Enterprise R5)● Allows definition of OSGi Applications – made up of a number of bundles – other coarse-grained components also possible ● e.g. a library that consists of many bundles – either an archive that contains bundles (.esa file) – or just a subsystem desc ● bundles obtained from Repository● subsystems can be nested● version ranges can be frozen in a deployment descriptor
  8. 8. Subsystems (Enterprise R5)● Sharing models – Feature (everything shared) – Application (nothing shared out, libraries shared in) – Composite (custom sharing)
  9. 9. Subsystem examples (Enterprise R5)Two example subsystem definitionsMyZippedApplication.esa: MyDeclarativeApplication.esa:META-INF/SUBSYSTEM.MF: META-INF/SUBSYSTEM.MF: Subsystem-SymbolicName: foo Subsystem-SymbolicName: bar Subsystem-Version: 1.0.0 Subsystem-Type: osgi.subsystem.feature Subsystem-Type: Subsystem-Content: osgi.subsystem.application org.acme.b1;bundle1.jar type=osgi.bundle;bundle2.jar version=[1.1, 2),bundle3.jar org.acme.s2;subsystem4.esa type=osgi.subsystem.feature META-INF/DEPLOYMENT.MF: Deployed-Content: org.acme.b1; deployed-version=1.7.2, org.acme.s2; deployed-version=1.0.2Implementation at Apache Aries
  10. 10. Migration Support (Enterprise R5)ServiceLoader Mediator specification● Enables java.util.ServiceLoader in OSGi● Implementation at Apache Aries http://aries.apache.org/modules/spi-fly.htmlFor any OSGi spec, find the available implementations onWikipedia: http://en.wikipedia.org/wiki/OSGi_Specification_Implementations
  11. 11. Capability Namespaces (Enterprise R5)For use by Framework Resolver, Repository or tools● osgi.extender – allows a bundle to say I need this extender to run – or I am this extender – prevents system from resolving if extender not there – can prevent multiple extenders from extending the same● osgi.contract – a shorthand for a group of imports (e.g. Servlet, JPA, JAXB) – primarily for use by tools● osgi.service – express that a bundle needs/provides a service – primarily for use with the Repository
  12. 12. Work in progress for R6● Tentative release date: early 2014● Current themes: – Cloud – JavaEE Integration – Updating existing specs
  13. 13. R6 – CloudREST management API (RFC 182)● A remote management API for OSGi frameworks over REST (JSON or XML)● Install/Uninstall/Start/Stop bundles● Inspect the framework, services etc...Cloud Ecosystems (RFC 183)● A fluid, multi-node, service-based PaaS – deployments can dynamically scale up/down – move around – be repurposed
  14. 14. R6 – JavaEE integration (1)● CDI integration (RFC 193) – Use the CDI programming model to work with OSGi services – Integrate across JavaEE and OSGi boundaries using CDI● JCA integration (RFC 146) – Use JCA Resource Adapters in OSGi
  15. 15. R6 – JavaEE integration (2)● EJB integration (RFC 194) – Deploy and use EJBs in OSGi● JavaEE Package Versions (RFC 180) – projects developed for OSGi use semantic versioning on their Java Packages – but what versions do I use when I need to import something from javax.xxx / JSR spec? – This RFC aims at providing a solution to this
  16. 16. R6 – Other Spec Updates● Blueprint 1.1, Blueprint transactions and possibly other Blueprint updates● HttpService is being updated (RFC 189) – to include support for newer Servlet features – Whiteboard pattern support● Declarative Services update (RFC 190) – a number of updates including an administrative API and enhanced Annotation support
  17. 17. Interested? Come and help out!● If youre interested in any of the R6 EEG topics, come and help out! – the OSGi Alliance is always open for new members: http://www.osgi.org/Join – if your employer is already a member, talk to me (david at redhat.com) or any other co-chair on how to get involved● If youre not a member – regular Early Access Drafts are released for feedback