OSGi made simple - Fuse Application Bundles

FuseSource Technology:
OSGi Made Simple: Introducing Fabric Application Bundles

Rob Davies
CTO
April 2012

1 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

FuseSource : the Gorilla Among Open Source Vendors

 Forrester ESB Wave Report
Q2 2011: FuseSource is the
only open source “Leader”
 Largest market presence –
over 200 customers
 Marquee customers and
good tooling allow us to
compete in the low end
 Weaker solutions cannot
match FuseSource stats:
• 100s of millions transactions a day
• No down time
• 200,000+ downloads a month
• 25+ leaders & committers at Apache


FuseSource : All About Customer Success

 Performance
• Expertise in architecting for performance
• Distribution designed for high-performance computing
• Sabre’s travel gateway is processing over 1.5 billion txn/day
(32,000+ txn/sec) on 13 servers with zero downtime

 Global scalability
• No license fees: can deploy at 1,000s of locations
• Distributed nature of distribution supports scaling out
• SpecSavers deploys in 1,400 global retail stores

 Proven Enterprise Quality of Service
• Proven in mission-critical applications
• CERN is using to run operational grid in Large Hadron Collider
• FAA is using in next-generation air traffic control (SWIM)


Agenda

 Why Fuse Fabric ?
 What does Fuse Fabric do ?
 High level architecture
 Deep dive
 Q&A


What’s good with using WARs ?

 really simple for application developers to create and use
• simple flat classpath which is easy to grok
 single file to deploy
 if it works once in Tomcat/Jetty it usually always does


What is wrong with WARs ?

 not easy to share code across WARs
• usually end up hacking a Tomcat/Jetty distro and hand-copying
jars in shared classloader
 they tend to be pretty huge
 not possible to just update one small service; need to
redeploy entire applications
 each small change to one service often requires a full test
of the entire application


OSGi background

 OSGi originally stood for “Open Services Gateway initiative”
- An initiative focused on deploying Java solutions into “residential
gateways” for smart homes and building controls

 OSGi tackles the problem of deploying and administering Java
modules (aka “bundles”)
- Lifecycle – How to load, start, and stop Java bundles without shutting
down the JVM
- Remote management and administration
- Class-loading
- Versioning
- Dependency management

 The OSGi alliance was founded in 1999 to promote wide scale
adoption of OSGi technology
- You can find them on the web at http://www.osgi.org


Bundles

• A bundle is a Java archive (JAR) with some meta-data
• The meta-data is provided in plain-text in the META-
INF/MANIFEST.MF file

• Bundle meta-data includes the following:
• BundleName – A descriptive, human readable name for the bundle
• Bundle-Symbolic-Name – A unique name for the bundle
• Bundle-Version – The version of the bundle, in the format X.X.X
• Export-Package – A list of Java packages “visible” from the
bundle
• In OSGi, all packages are hidden unless explicitly exported
• Import-Package – A list of the Java packages that this bundles
requires
• Only those packages matching java.* are imported by default
• All other packages must be imported explicitly


Bundle versioning in OSGi

• Bundles are tagged with a Bundle-Version in the MANIFEST.MF
file, for example:
 Bundle-Version: 1.2.3
• When a bundle imports packages from another bundle, it can
specify the version number:
 Import-Package: com.mycompany.stuff;version="1.2.3"
• Note that exported package should have a version too!
• Alternatively, specify a range of compatible versions with brackets:
- Use „[„ or „]‟ to specify a lower or upper limit, and to include the limit
- Use „(„ or „)‟ to specify a lower or upper limit and to exclude the limit
• For example:
Import−Package: com.mycompany.stuff;version=“[1.2.3,1.2.5)”
- Imports version 1.2.3 or 1.2.4, but not 1.2.5
- Note that “1.2.3” for a version means version >= 1.2.3. If you want only 1.2.3
then use “[1.2.3,1.2.3]” or “[1.2.3,1.2.4)”


What’s good about OSGi ?

 ideal micro container for the JVM
• small and modular
• simple and powerful model
– bundle context, listener, registry
 easy to extend to support
• deployment units like WARs, EARs, JBI
• frameworks like spring-dm, OSGi Blueprints, CDI, guice etc
 hot (re) deployment at a fine or course grained level of
services at runtime
• awesome for developers of JEE servers and ESBs
• Apache Karaf &
ServiceMix, JBoss, GlassFish, WebSphere, WebLogic etc


What’s wrong with OSGi ?

 bundles are very fine grained and use package level metadata
 import and exports with version ranges required on every
package
• usually quite a few packages per jar
• typical applications have 10s or 100s of jars
• lots and lots of packages and metadata to get wrong!
 package level metadata often a bit too low level for developers
 folks who just wanna get stuff done fast!
 writing bundles is easy
• installing and actually starting bundles together so they actually work is
much harder


Its not just a tooling problem

 developers have to spend a lot of time messing about
either
• making new osgi bundles for existing jars
• messing around with whatever tool they use to generate the OSGi
metadata to tweak it all
• keeping the metadata/imports up to date as dependencies
change
 requires all developers learn all the OSGi metadata and
the OSGi metadata geneartion tools
• then using some other mechanism to figure out which bundles to
actually install
• Karaf Features, scripting, tarballs etc
 using 50-100 bundles; life soon becomes very difficult


Fabric Bundles

 Easy to deploy and control which classes are shared across
deployment units
 A common model of class loaders across build tools, IDE
and OSGi container
 how many times does code work in isolation, only to fail
to deploy to the container using OSGi ?
 developers can concentrate on solving business
problems, instead resolving OSGi bundle hell


What is a Fabric Bundle ?

 Any jar containing a pom.xml - which defines the transitive
dependencies for that jar
 This is the default for the more popular build tools
 maven
 SBT
 Others (Ant, Ivy, Gradle etc) - just need to make a jar with
a pom.xml inside


What you find in a Maven built jar


How do you use Fab ?

 Use Fuse ESB - a flexible, standards-based enterprise
service bus - it fully supports fabric bundles!

 You simply install any FAB as if it were a WAR or Karaf
feature:

install fab:mvn:<groupId>/<artifactId>/<version>

 OR - deploy your FAB archive (a jar postfixed with .fab) to
the Fuse ESB deploy directory


How do Fabric Bundles work ?

 When a FAB is installed, Fuse ESB converts it into a
regular OSGi bundle
 By default, Fuse ESB will automatically install all the
transitive dependencies, if they are not already loaded
into the container
 A FAB can depend on regular jars or real OSGi bundles!


Configuring Fabric Application Bundles

 By default, FAB uses a regular flat class loader:
 This means what you build and test outside the Fuse
ESB OSGi container will typically work inside Fuse ESB.
 Because a FAB is converted into a regular OSGi
bundle, you still benefit from been able to install and
deploy multiple versions of the same FAB or use different
versions of dependencies
 However, this does negate some of the benefits of
OSGi, the ability to share code across multiple bundles
 So you can start simple, and iteratively get more complex
code sharing deployments through configuring your FAB.


Provided dependencies

To share an existing dependency (and its transitive
dependencies) you declare a dependency as provided in the
pm.xml - e.g:

<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
<version>${camel-version}</version>
<scope>provided</scope>
</dependency>


Provided dependencies (continued)

You can alternatively, use the Fabric-Provided-Dependency
in the jar manifest header, to specify zero to many shared
dependencies:

Fabric-Provided-Dependency: <grpId1>:<artifactId1> ....

You can also use wild cards - e.g. if you want to share all spring
and camel dependencies:

Fabric-Provided-Dependency: org.apache.camel:* org.springframework:*


Conclusion

 Using OSGi as a component framework has a great many
benefits
 modularity and sharing of code
 dynamic updates
 versioning
 reuse
 However, deployments in OSGi containers can be hard
 FuseSource has created Fabric bundles to make deploying in
OSGi extremely simple, but also flexible, so you can still gain all
the benefits of OSGi when you want to
 Fuse ESB ships with Fabric bundles by default, another reason
Fuse ESB is the most popular enterprise open source solution
today.


Any Questions?

No vendor lock-in
Free to redistribute
Enterprise class……..

OSGi made simple - Fuse Application Bundles

More Related Content

What's hot (20)

Similar to OSGi made simple - Fuse Application Bundles (20)

More from Rob Davies (6)

Recently uploaded (20)

OSGi made simple - Fuse Application Bundles