osgi made simple - fuse application bundles

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

FuseSource Technology:

OSGi Made Simple: Introducing Fabric Application Bundles

Rob DaviesCTOApril 2012


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:

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

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


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:

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

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

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-inFree to redistribute

Enterprise class……..

osgi made simple - fuse application bundles

Technology

fusesource confidential

fusesource technology

bundle bundleversion

bundle bundlesymbolic

osgi background osgi

file bundle metadata

controls osgi

osgi alliance