OSGi as Enterprise Integration Platform

395 views

Published on

Short introduction to OSGi for Java developers.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
395
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OSGi as Enterprise Integration Platform

  1. 1. OSGi as Enterprise Integration Platform Elek Márton @anzix 2014 September DPC Consulting
  2. 2. Agenda Typical question: JavaEE or Spring based application? Our question: Is the OSGi good enough for a third way? ● What is OSGi – Classpath separation – Service definitions – Lifecycle ● How does an OSGi application server looks like? – Felix, Karaf, ServiceMix – JBoss Fuse, Fabric8.io
  3. 3. OSGi
  4. 4. What is OSGi ● Modular system and service platform for Java – Specification (similar to J2EE) – Ecosystem (eg. exams are announced at 2014.09) ● Jigsaw vs. OSGi interoperability ???? – (PoC: project penrose) OSGi R1 2000.05 OSGi R2 2001.10 OSGi R3 2003.03 OSGi R4 2005.10 OSGi R4.1,4.2,4.3 2009.09-2011.04 OSGi R5 2012.06 J2EE 1.2 1999.12 J2EE 1.3 2001.09 J2EE 1.4 2003.11 JavaEE 5 2006.05 JavaEE 6 2009.12 JavaEE 7 2013.06
  5. 5. ● OSGi runtime is collection of bundles ● Bundle: – Plain old jar file – With plain old META-INF/MANIFEST.MF ● With OSGi specific entries in the manifes OSGi bundle
  6. 6. Classpath separation ● Package based ● Bundles explicitly imports and exports packages – META-INF/MANIFEST.MF Bundle1 Export-Package: hu.dpc.helloworld ;version="1.0.0" Bundle2 Import-Package: hu.dpc.helloworld ;version="1.0.0"
  7. 7. Lifecycle management ● Every bundle has a lifecycle. ● Activator in META-INF/MANIFEST.MF Bundle-Name: Hello World Bundle-SymbolicName: hu.dpc.helloworld Bundle-Activator: hu.dpc.Activator
  8. 8. Service definition ● API to publish/use implementation for a specific interface – With optional metadata set ● Programmatic API: there are extensions to use declarative approach – blueprint – DS (declarative services ● Main set of useful interfaces – Logging, Config Admin, Http, ...
  9. 9. Runtime container
  10. 10. Apach Felix OSGi container
  11. 11. Apache Karaf Apach Felix OSGi container Hibernate Spring CXF ● Hot deployment ● Dynamic configuration ○ (etc/*.properties -> OSGi config API) ● Provisioning (feature definition) ● KAR archive ● More advanced shell ● Instance management ○ Parent container/Child container ○ The binaries are shared
  12. 12. Apache Karaf Apach Felix OSGi container Apache ServiceMix Hibernate Spring CXF Camel ServiceMix ● Hot deployment ● Dynamic configuration ○ (etc/*.properties -> OSGi config API) ● Provisioning (feature definition) ● KAR archive ● More advanced shell ● Instance management ○ Parent container/Child container ○ The binaries are shared
  13. 13. Apache Karaf Apach Felix OSGi container Apache ServiceMix JBoss Fuse ● Clustering / auto provisioning ● Microservice management Hibernate Spring CXF Fabric Camel ServiceMix ● Hot deployment ● Dynamic configuration ○ (etc/*.properties -> OSGi config API) ● Provisioning (feature definition) ● KAR archive ● More advanced shell ● Instance management ○ Parent container/Child container ○ The binaries are shared
  14. 14. Apache Karaf Apach Felix OSGi container Apache ServiceMix JBoss Fuse / FABRIC8.IO ● Clustering / auto provisioning ● Microservice management Hibernate Spring CXF Fabric Camel ServiceMix ● Hot deployment ● Dynamic configuration ○ (etc/*.properties -> OSGi config API) ● Provisioning (feature definition) ● KAR archive ● More advanced shell ● Instance management ○ Parent container/Child container ○ The binaries are shared
  15. 15. Summary ● Third way with own strength and weakness ● Strength – Modularity, Modularity, Modularity ● Classloader separation ● Lifecycle management ● Service producer/consumer pattern – Well defined standard service APIs – More control to fine tune the integration ● Weakness – Additional complexity even if the classloader separation and the lifecycle management is not needed – Many different project should be used together – DIY environment, everything is possible, but more knowledge needed about the platform.
  16. 16. Q&A

×