1. FuseSource Technology:
OSGi Made Simple: Introducing Fabric Application Bundles
Rob Davies
CTO
April 2012
1 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

2. 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
2 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

3. 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)
3 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

4. Agenda
 Why Fuse Fabric ?
 What does Fuse Fabric do ?
 High level architecture
 Deep dive
 Q&A
4 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

5. 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
5 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

6. 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
6 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

7. 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
7 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

8. 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
8 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

9. 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)”
9 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

10. 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
10 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

11. 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
11 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

12. 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
12 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

13. 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
13 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

14. 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
14 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

15. What you find in a Maven built jar
15 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

16. 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
16 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

17. 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!
17 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

18. 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.
18 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

19. 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>
19 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

20. 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:*
20 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

21. 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.
21 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential

22. Any Questions?
No vendor lock-in
Free to redistribute
Enterprise class……..
22 © 2012 FuseSource Corp. All rights reserved. FuseSource Confidential