Chapter 13. Choosing a stack

This chapter covers

• Your options for running enterprise OSGi applications
• An overview of popular enterprise OSGi platforms

This book is a book about enterprise OSGi, rather than any particular implementation or server. Nonetheless, no one’s going to get far with enterprise OSGi without some sort of implementation to play with! In the examples, you’ve been using a little toy assembly to get you going on the important stuff without getting bogged down in the details of any particular application server.

Now that you’ve got the hang of enterprise OSGi, you’re probably thinking about going into production. We definitely don’t recommend your toy stack for this—as we’ve said several times, Apache Aries on its own isn’t an application server! Working through the examples in this book, you’ve hit several limitations that disappear when you move to a more full-featured application server. What should you be using to run your real applications, when you’ve moved beyond your simple sample stack?

You probably won’t be surprised to hear that the answer is “it depends.” After all, if everyone was running enterprise OSGi applications the same way, we would have shown you that, rather than using the Aries assembly! More and more application server vendors and communities are adding support for OSGi applications to their products. You can go for a minimal runtime, like Apache Karaf, or an enterprise-strength server like WebSphere Application Server, or anything in between. How you choose will depend on how much server you want and also how much enterprise OSGi you want, because some products provide more of the programming model than others.

Let’s start with a high-level view of which servers have the enterprise OSGi features we’ve discussed in this book.

13.1. What’s in what server?

The OSGi function in these servers has different levels of maturity. Some haven’t completed implementing the enterprise OSGi specification yet, whereas others provide the specification and innovations on top of it. Implementations that aren’t complete at the time of writing will continue to improve over time and may be fully mature by the time you’re choosing your stack. It may also be that your application doesn’t require the whole enterprise OSGi programming model, in which case you can choose your server based on other criteria. All of the servers we’ll look at allow you to run OSGi bundles as web applications, and connect bundles together using some form of dependency injection of OSGi services.

Table 13.1 summarizes the features available in the various servers. You should only take this table as a rough guide; some servers might not have had a feature at the time of writing, but it might have been added by the time you’re using the server. Other features might be available in principle, but require configuration to get working in your application!

Table 13.1. Feature comparison of enterprise OSGi servers

Server	Apache Karaf	Apache Geronimo	IBM WebSphere	Eclipse Virgo	GlassFish	JBoss	Paremus Nimble
Blueprint	✓	✓	✓	✓		✓	*
Declarative Services		✓		✓	✓	✓	*
JPA	J	✓	✓	✓	✓	On roadmap	*
JTA	✓	✓	✓	✓	✓	✓	*
JNDI	✓	✓	✓	✓	✓	✓	*
Aggregate applications	Features,.eba archives	.eba archives	.eba, and composite bundles	Plan,.par files
EJBs	T				✓
GUI console	✓	✓	✓	✓	Separate plug-in	✓
Application isolation			✓	✓			✓
JEE container		✓	✓	JEE, Spring	✓	✓	*
SCA			✓
Key ✓—Support available in released version T—Support available in Aries trunk *—Provisioning support available, but third-party implementations must be installed J—Feature files for Aries JPA, but no feature files for JPA engine

Because enterprise OSGi is an open standard, you should find that your applications are generally portable between servers as long as you stick to features that are covered by the specification (and implemented in the server you’re switching to). For maximum portability you might want to avoid aggregate applications and EJB integration, because these aren’t included in the first version of the enterprise specification.

Warning: Watch Out for Wonky Versions

At the time of writing, several of the servers we’ll discuss ship with incorrectly versioned javax.servlet and javax.persistence packages. Although the OSGi Enterprise Specification specifies versions for these packages, these semantic versions aren’t the same as the marketing versions, which caused a few implementation hiccups. If you migrate an application from the little Aries assembly to an affected server, you may find some bundles no longer resolve. If this happens, we’re afraid you’ll have to grit your teeth, forgo semantic versioning temporarily, and import a broad version range for javax.servlet and javax.persistence.

A table can only tell part of the story, so let’s discuss each of these servers in more detail.

13.2. Apache Karaf

One of the lightest-weight options for running OSGi applications, Apache Karaf is halfway between an OSGi runtime and an application server. Karaf is proving increasingly popular both as an OSGi platform in its own right and as a foundation for other products such as Geronimo and ServiceMix. Several other projects don’t ship with Karaf by default, but do provide Karaf features so they can be installed into a Karaf instance.

13.2.1. Karaf features

One of Karaf’s headline functions is known as Karaf features. A Karaf feature is an XML file that describes a set of bundles that can be installed into a Karaf runtime. (You may recall seeing Karaf features before, in section 8.3.4.) Karaf ships preconfigured with a repository with many useful feature definitions, and new feature repositories can easily be added.

To see the available features, use the features:list command (see figure 13.1).

Figure 13.1. To see the features Karaf can install, use the features:list command.

As a bonus, Maven URLs are supported. This makes installing feature-compliant products and applications as easy as typing (for example) the following:

features:addurl mvn:fancyfoods/fancyfoods.karaf/1.0.0/xml/features
features:install fancyfoods

Maven URLs were used for convenience here, but file and http URLs also work. The feature definition file for the Fancy Foods application would be as follows:

<features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0">
 <feature name="fancyfoods" version="1.0.0">
   <bundle>mvn:fancyfoods/fancyfoods.api/1.0.0</bundle>
   <bundle>mvn:fancyfoods/fancyfoods.web/1.0.0</bundle>
   <bundle>mvn:fancyfoods/fancyfoods.business/1.0.0</bundle>
   <bundle>mvn:fancyfoods/fancyfoods.datasource/1.0.0</bundle>
   <bundle>mvn:fancyfoods/fancyfoods.persistence/1.0.0</bundle>
   <bundle>mvn:fancyfoods/fancyfoods.department.chocolate/1.0.0</bundle>
   <bundle>mvn:fancyfoods/fancyfoods.department.cheese/1.0.0</bundle>
 </feature>
</features>

It’s used here because the content is familiar, but the Fancy Foods application perhaps isn’t the best example of how to use Karaf features. A similar effect can be achieved by packaging all of the Fancy Foods bundles up into a .eba file, as we did in chapter 4. Features are more useful for distributing centrally—or remotely—managed infrastructure bundles. For example, many Apache projects provide Karaf feature files to allow them to be installed into Karaf without any initial download.

If you try to install it, you’ll discover that the Fancy Foods application won’t install correctly on a basic Karaf installation because its dependencies are missing; current releases of Karaf don’t have any ability to provision features based on bundle dependencies. Don’t worry, we’ll show you how to configure Karaf with the right features in a moment.

13.2.2. Installing Aries into Karaf

Despite being a relatively lightweight runtime, Karaf has awareness of, and support for, Aries. Base Karaf ships with the Aries Blueprint implementation. Although not installed by default, the Karaf enterprise repository includes feature definitions for most Aries components. The feature definitions are maintained by the Karaf team and so versions may lag slightly behind the latest Aries releases (see figure 13.2).

Figure 13.2. To install Aries into Karaf, you’ll need to install the war, transaction, jpa, jndi, and application-without-isolation features.

Warning: But Where is the Aries Feature?

None of the Karaf feature definitions for the Aries bundles includes aries in the name, so they’re easy to miss if you’re looking for a feature called aries.

Unfortunately, although there are Karaf feature files for the Aries JPA component, which provides integrations for JPA in an OSGi environment, at the time of writing there are none for the OpenJPA engine itself. You’ll need to install OpenJPA into Karaf manually, either by using the bundles:install command or by writing your own feature for OpenJPA. Because OpenJPA has its own nontrivial dependencies, a feature is probably easier. An example feature definition is as follows:

<features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0">
    <feature
        name="persistence"

        version="1.0.0">
        <bundle>mvn:commons-collections/
                commons-collections/3.2.1/</bundle>
        <bundle>mvn:commons-lang/commons-lang/2.4</bundle>
        <bundle>mvn:commons-pool/commons-pool/1.5</bundle>
        <bundle>mvn:org.apache.derby/derby/10.8.1.2</bundle>
        <bundle>mvn:org.apache.servicemix.bundles/
                org.apache.servicemix.bundles.serp/1.13.1_2/</bundle>
        <bundle>mvn:org.apache.openjpa/openjpa/2.0.1</bundle>
    </feature>
</features>

Warning: Execution Environments

Some versions of Karaf don’t have the execution environments configured correctly, which means installation of the fancyfoods feature fails. To correct the problem, add the JavaSE-1.6 environment to the list of supported environments in Karaf’s etc/config.properties file.

After the Aries and OpenJPA bundles are installed, your fancyfoods feature should install. Alternatively, because you’ve had practice with features by now, you could take advantage of Karaf’s hot deploy feature and copy your Fancy Foods .eba file into the deploy folder in your Karaf installation. The Fancy Foods application will be accessible on http://localhost:8181/fancyfoods.web/SayHelloShopping.

Warning: Cheese Offer Missing?

The Fancy Foods application has been written to take advantage of some features that were introduced in the 0.4 release of the Aries JPA bundle, and the 0.3.1 release of the transaction wrappers bundle. If you’re using earlier versions of this bundle, you’ll see that the chocolate offer is present, but the cheese offer is missing. To get the cheese offer working, you’ll need to adjust the persistence.xml to use the more verbose JNDI names for the datasources, for example: OSGi:service/javax.sql.DataSource/ (OSGi.jndi.service.name=jdbc/xafancyfoodsdb). You’ll also need to manually enhance your JPA entities.

Depending on what you’re trying to do, you may need to install other bundles into your Karaf runtime. As you’ve seen, the ability to group bundles into features and the support for Maven URLs make this pretty easy. Karaf has another handy protocol handler that simplifies installing normal JARs.

13.2.3. Handling non-OSGi bundles

Karaf ships the Pax Wrap URL handler. This convenient utility allows you to install normal bundles into the Karaf runtime by converting them into OSGi bundles on the fly. Bnd is used to do the generation of the bundles. For example, to install a legacy bundle, the following command could be used (or the URL could be added to a feature definition file):

bundle:install wrap:mvn:company/my.legacy/1.0.0

So far, we’ve shown you two Karaf commands: features:install and bundle:install. These are only scratching the surface of the capabilities of the Karaf shell.

13.2.4. Blueprint-aware console

Karaf has a slick text console based on the Felix Gogo shell, but with lots of improvements and extensions. The Karaf shell allows you to do all the things you could do in a normal OSGi console, like starting, stopping, and querying bundles, but with the welcome benefit of content assist and command history. Importantly for products built on top of Karaf, the console can be dynamically extended with new commands and rebranded. From an enterprise OSGi perspective, though, the most interesting feature of the Karaf console is its Blueprint support. Not only is the console aware of Blueprint, Blueprint is a first-class citizen; the default bundle listing shows the Blueprint status of every bundle (figure 13.3).

Figure 13.3. Out of the box, Karaf shows the Blueprint status when listing bundles. In this case, the datasource JNDI name in the persistence.xml is incorrect, so Blueprint can’t inject an EntityManager into the inventory bean, and reports a failure.

Karaf is a nice integration framework, with many handy extensions to what you get if you run a plain OSGi framework like Felix or Equinox. We like the console and the integrated Blueprint support. But Karaf isn’t an application server; even if you add in lots of Karaf features, it won’t do all the things an application server does.

13.3. Apache Geronimo

If Karaf is too low-level for you, you’ll find many of the same characteristics in Karaf’s bigger cousin, the Apache Geronimo application server. From version 3.0 onwards, Apache Geronimo supports the enterprise OSGi programming model. Geronimo provides a feature-complete and well-integrated enterprise OSGi runtime, based on Apache Aries. As with Karaf, the version of Aries embedded in Geronimo will usually lag slightly behind the leading edge release of Aries itself.

Geronimo itself is built on top of Karaf, so it retains many of Karaf’s excellent features, such as the Blueprint-aware console. But unlike Karaf, Geronimo is a full-fledged Java EE–certified application server. This means many features that have to be manually installed or hand-cranked in Karaf work out of the box in Geronimo. (The corollary of this is that Karaf is a lot faster than Geronimo—or almost anything else—to start!) Geronimo ships with a built-in Derby database, EJB container, JMS container, and transaction manager. If you plan to combine Java EE and OSGi components, you’ll be grateful for this extra function. Even if you’re doing a strictly OSGi application, you may find Geronimo’s management and debugging facilities handy. Geronimo’s OSGi application management is more well-integrated and sophisticated than Karaf’s. For example, Geronimo’s console displays the web context root of installed WABs (see figure 13.4).

Figure 13.4. Geronimo lists all installed EBAs and allows you to start, stop, and uninstall them. Conveniently, it also shows the web context root.

The Geronimo web console also provides more general management of installed OSGi bundles. Graphical views of a bundle’s wired bundles, imported and exported services, and manifest are provided by the console (see figure 13.5).

Figure 13.5. The Geronimo console includes a nice graphical bundle viewer that shows a bundle’s package and service dependencies.

Geronimo is one of the most straightforward ways to use Apache Aries; Geronimo contains most of the Apache Aries components you’ve been using through this book, but it wraps them in a proper application server environment, with administration, databases, datasources, JPA entity enhancement, security, and other application-server goodies.

13.4. WebSphere Application Server

An even higher level of application server support is available with WebSphere Application Server. Like Geronimo, WebSphere incorporates and integrates the Apache Aries components. It also provides nice extensions and enhancements to enterprise OSGi support beyond what’s available in Aries. WebSphere support for OSGi applications has been available since WebSphere Application Server version 7. In version 7, the support was shipped as a separate feature pack, whereas in version 8, OSGi application support was included in the base server.

13.4.1. Provisioning and bundle repositories

WebSphere provides good support for application provisioning by shipping with an OBR bundle repository implementation, and allowing users to configure third-party repositories.

Built-In Bundle Repository

WebSphere includes an integral bundle repository with the application server (see figure 13.6). This allows common utility bundles to be provisioned without having to set up a third-party bundle repository. Provisioning bundles, rather than packaging them with applications, reduces application footprint and makes rolling out new versions of common bundles easier.

Figure 13.6. The Fancy Foods bundles installed in the WebSphere bundle repository. This allows them to be automatically provisioned and shared between several applications.

Configurable External Bundle Repository

WebSphere can provision bundles from any bundle repository that complies with the draft RFC112 (OBR) specification (discussed in chapter 7). All that’s required is to configure a name and URL for the external repository.

13.4.2. Module granularity

As well as providing a complete implementation of the enterprise OSGi programming model, WebSphere provides some useful extensions, particularly in the area of module granularity. To some extent, these extensions anticipate developments in the next release of the OSGi Enterprise Specification.

Application Isolation

When running in the WebSphere server, OSGi applications don’t have visibility of bundles belonging to other applications. This ensures applications don’t interfere with each other. Each application runs in its own OSGi framework, instead of all application bundles running in a single flat framework (the normal pattern for OSGi frameworks). This is similar to the normal mode of operation for Java EE applications, where only JARs within the same EAR are on the classpath. Sharing bundles is often convenient, so your applications can include a mix of private content and shared content.

Composite Bundles

WebSphere supports the notion of a composite bundle. A composite bundle is composed of several constituent bundles, but it appears as a single bundle to the outside world. This extra level of granularity makes it easier to distribute coherent collections of bundles and also allows packages to be shared within a composite bundle, but hidden from the outside world.

13.4.3. Managed application update and extension

Another area where WebSphere adds value beyond what’s in the OSGi Enterprise Specification is in the area of application administration. One of the beauties of OSGi is that all OSGi applications are updateable; multiple versions of a bundle can co-exist in a framework, and if the older version is stopped, dependent bundles will rewire to the new version (or the other way around, if you want to downgrade a bundle). WebSphere provides administrative support for application management that allows upgrades to be staged, and then rolled out in a managed way (see figure 13.7).

Figure 13.7. WebSphere Application Server provides management support for updating individual bundles in an EBA. For example, the fancyfoods.department.chocolate bundle may be updated from version 1.0.0 to 1.1.0 after the initial deployment when a new version of the chocolate bundle becomes available.

13.4.4. SCA

WebSphere Application Server also includes an SCA implementation, based on Apache Tuscany. Having both SCA and enterprise OSGi support precanned in one package makes using the two programming models together much easier; it means you can get the significant benefits of SCA for distributed OSGi and legacy integration without any of the platform assembly pain we hit in chapter 10.

Among the servers we’ll discuss, WebSphere is unusual in how many enterprise OSGi features it offers. Not only does it support the whole of the enterprise OSGi programming model, as defined in the specification, it offers several extensions to the model, such as composite bundles and the ability to update components of an application with near-continuous availability. Some of the enhancements are also present in the Apache Aries codebase, but some are unique to WebSphere.

13.5. Eclipse Virgo and Gemini

We’ve discussed Apache Aries extensively throughout this book, but it’s not the only enterprise OSGi implementation in town. One of the great things about standards-based technologies is that there are multiple implementations; as a user, you’re free to pick and choose the one that suits you best. Eclipse Gemini is an Eclipse project with a mission similar to Apache Aries; it provides independently consumable components that implement various sections of the enterprise OSGi specification. Gemini provides the reference implementations for the web application container and Blueprint service parts of enterprise OSGi. Like Apache Aries, the Gemini components are intended to be incorporated into an application server.

The primary consumer of the Gemini components is the Eclipse Virgo application server. Virgo is based on an initial donation from SpringSource of the Spring dm Server. Because of its rich Spring support (it even packages Spring 3), Virgo will appeal to you if you develop for Spring. Virgo’s JPA implementation is written with EclipseLink in mind, rather than OpenJPA, so if you’re using EclipseLink, Virgo may also be a convenient choice—although, in principle, any implementation of the JPA service specification should work with any provider.

13.5.1. Debug support

One of Virgo’s nice features is the ability to collect and view dumps of the system state when OSGi resolution failures occur. This can make debugging missing dependencies easier. Bundles in a plan file are installed transactionally, so if one fails to resolve, any bundles that were already installed will be uninstalled so that the system state remains unchanged. For example, if you try to install the fancyfoods.department.chocolate bundle without first installing the fancyfoods.api bundle, a dump is generated that can be browsed in the dump inspector (see figure 13.8).

Figure 13.8. A dump will be automatically generated for a variety of failures, including OSGi resolution failures. The dump records active threads, the current configuration, repository contents, and a snapshot of the OSGi state of the server.

Clicking on an unresolved bundle in a snapshotted OSGi state shows the resolution failure message shown in figure 13.9.

Figure 13.9. If you install the fancyfoods.department.chocolate bundle before the fancyfoods.api bundle, the chocolate bundle can’t be resolved. Exploring the snapshotted OSGi state shows the reason for the resolution failure.

13.5.2. Application isolation

Like WebSphere, Virgo allows applications to be isolated from the main server runtime. Applications run in a user region that’s insulated from the Virgo kernel. Some parts of the server, such as the web console, also run as applications in the user region. Application bundles do have visibility of bundles from other applications.

13.6. GlassFish

Although Virgo is a well-established alternative to Apache Aries, there are several other independent enterprise OSGi implementations. Since version 3, GlassFish ships with enterprise OSGi support. The support available in version 3 was mostly limited to web applications, but much more complete support, including JPA, JTA, and EJB integration, shipped in version 3.1. GlassFish has coined the term hybrid applications to describe applications that combine the modularity of OSGi with the ability to take advantage of Java EE infrastructure. The hybrid application programming model is the enterprise OSGi programming model, but we think the phrase nicely captures the ideas behind enterprise OSGi.

13.6.1. Dependency injection

Uniquely among the servers in this chapter, GlassFish doesn’t include a Blueprint implementation. The assumption is that users will use Java EE’s CDI (Contexts and Dependency Injection) for inversion of control. In its base form, CDI has no awareness of OSGi, but GlassFish has extended it with an @OSGiService annotation that allows services to be injected. This approach has the advantage of being annotation-based, which allows dependencies to be injected concisely. It will also feel natural if you’re already used to using CDI. But because it’s not standards-based, applications written for the GlassFish CDI won’t be portable to other application servers.

If you’d rather use Blueprint, you can install the bundles of a Blueprint implementation (such as Aries) into GlassFish. The set of Aries bundles shipped with Karaf is a good minimal set to get Blueprint working in GlassFish. This is a popular approach.

13.6.2. EJBs

Another area where the GlassFish enterprise OSGi support isn’t entirely standard is its support for EJBs. We’ve already discussed how both Apache Aries and GlassFish can be used to run EJBs in an OSGi environment in section 11.2.3. EJB support is an important part of GlassFish’s hybrid application approach, because it makes more of the normal Java EE programming model accessible from within an OSGi environment. The EJB support in Aries and GlassFish is unrelated, and so portability of OSGi EJBs between the two platforms is limited. If you’re keen on EJBs, it’s worth noting that the GlassFish support made it into a released version before the Aries version, and that it may take a while for the Aries implementation to trickle into releases of consuming servers such as Karaf and Geronimo.

13.6.3. Administration

By default, the GlassFish web console doesn’t have views for OSGi administration, but a console plug-in based on the Felix web console is available as a separate download. GlassFish also ships the Felix Gogo console (see figure 13.10).

Figure 13.10. The Felix Gogo shell, as it appears in GlassFish

Although it has an open source license, a commercial edition of GlassFish is available, known as Oracle GlassFish Server. This edition includes support and bug fixes.

13.7. JBoss

Another well-established application server that has introduced support for OSGi applications in recent editions is JBoss. Like GlassFish, JBoss is open source, but paid support is available. JBoss OSGi is a new feature in JBoss Application Server 7 that provides support for OSGi applications. JBoss provides a Blueprint implementation and WAB support, as well as other OSGi functions like Config Admin and Declarative Services.

In some other areas, JBoss doesn’t include as many enterprise OSGi features as some of the other servers we’ve discussed. At the time of writing, JBoss doesn’t support persistence bundles and has only limited JNDI function. Web application support is also limited, because OSGi web applications run on the Pax Web container rather than the default JBoss web container. Several useful features are missing from the Pax Web container, including integrated security, servlet 3 annotations, and JSP support.

Because of these constraints, the JBoss team currently recommends using Java EE for web applications, with JNDI bridges to OSGi bundles for the rest of the application. These hybrid applications are arguably less modular than pure-OSGi applications, but they allow applications to use JSPs and servlet annotations. Improved JNDI, persistence bundle support, and migration of the WAB support onto the JBoss web container are all on the medium term JBoss roadmap.

Interestingly, JBoss OSGi isn’t based on an existing OSGi framework like Felix or Equinox; instead it leverages and extends existing modularity capabilities within the application server. One implication of this is that JBoss can’t exploit normal OSGi consoles like the Equinox and Felix ones. The JBoss web console allows administration of the base OSGi framework properties and bundles (see figure 13.11). The server also includes a version of the Felix web console that allows more complete management of all the installed bundles, packages, and services, and application bundles can also be managed with a JMX client like JConsole.

Figure 13.11. The JBoss administrative console has an OSGi section that allows you to view and configure the framework properties and server bundles.

OSGi support is relatively new in JBoss, and we’re looking forward to seeing the support continue to develop. In contrast, the last two products we’ll discuss, Paremus Nimble and Service Fabric, have OSGi support baked in.

13.8. Paremus Nimble and Paremus Service Fabric

With the possible exception of Apache Karaf, which is more of a platform than a server, all the products that we’ve discussed so far are relatively conventional Java EE application servers. The last product we’ll discuss, Paremus Service Fabric, is rather different. The main feature of Service Fabric is its cloudiness—it provides a private cloud that can run Java EE, web, or OSGi applications. The Service Fabric cloud is built on an OSGi platform, Paremus Nimble. Nimble is in many ways analogous to Apache Karaf; it provides a layer on top of the basic OSGi runtime with significant improvements to the shell, logging, and deployment.

13.8.1. Provisioning and deployment

One difference between Karaf and Nimble is Nimble’s provisioning support. One of the main focuses of the Service Fabric platform is sophisticated provisioning and deployment of applications, and this support is built into the Nimble kernel. When an application is deployed or fresh function is exercised, Nimble automatically downloads and installs appropriate runtimes and containers (see figure 13.12). For example, Service Fabric’s Java EE support is based on the GlassFish Java EE container, but this container isn’t loaded until a Java EE application is deployed. When the application is undeployed, GlassFish is unloaded.

Figure 13.12. The bundle IDs show that the core Nimble distribution includes only a handful of bundles. When the fancyfoods.api and fancyfoods.web bundles are installed, more bundles are provisioned, including the jetty web container and a few GlassFish bundles.

Nimble can provision a wide range of stacks—as well as web and Java EE containers, it can handle all the dependency injection frameworks we covered in chapter 6: Blueprint, Declarative Services, iPojo, Peaberry, and Guice. Nimble can even provision runtimes for non-Java JVM–based languages such as Scala and Groovy. If a requirement can be satisfied in more than one way (for example, a web application could be run using either Tomcat or Jetty), the Nimble resolver can be configured with a policy for choosing between the two.

Warning: Getting Repository Indexes Right

Not all versions of Nimble automatically check for requirements like Blueprint in the indexes. This is presumably a performance optimization, because finding and parsing Blueprint files does have a cost. But this can catch you out if you’re not careful, because it’s not well documented, and a Blueprint implementation won’t be installed unless Nimble spots bundles that need it. The same goes for JTA, JPA, and JNDI providers. To ensure enterprise OSGi requirements are indexed, add the --enable-ee-spotters flag to your indexing command.

This kind of resolution is more comprehensive than the OBR-based resolution of OSGi dependencies we discussed in chapter 7. We definitely didn’t cover Scala in chapter 7! The power of Nimble provisioning demonstrates the flexibility of OBR resolution; it can handle OSGi applications, steamed puddings, and Scala. Although the Nimble resolver is OBR-based, Nimble repositories do include extra metadata not found in most public OBR repositories. Nimble can convert a normal OBR repository to a Nimble one by re-indexing it. Nimble also hosts handy re-indexed versions of popular OBR repositories (see figure 13.13).

Figure 13.13. A repository that contains the Fancy Foods application can be generated by indexing a built copy of the source tree. If the --enable-ee-spotters flag is added, the resulting OBR index will include extra requirements for enterprise OSGi function. The index can be viewed from within the Posh shell using the more command.

As with the other platforms we’ve discussed, Nimble resolution can be controlled by specifying what repositories are used. You’ll probably need to add a few repositories to the default repositories to install and provision your application.

13.8.2. Remote services

Nimble includes an implementation of the OSGi Remote Services Specification (chapter 10). If you’re interested in remote services, you may find it convenient to use a runtime with integrated support, particularly because the Nimble implementation is stable and well respected.

13.8.3. Console

One of the nicest features of Nimble is its shell, the Paremus OSGi shell, or Posh. It’s built on the Felix Gogo shell, but the Felix foundation is pretty unrecognizable! The inspiration for the Posh shell is Unix’s bash, and Posh includes some commands more usually associated with Unix shells than OSGi consoles, such as pwd, more, and grep. It also includes command completion and history, as you’d expect, and the ability to run scripts with loops and conditions, which you might not expect.

The Posh shell is extensible, so that new commands can be added. The backing bundles for new commands can even be automatically provisioned. As you run commands, you can see new bundles being installed into the runtime, which gives a good feel for what’s going on under the hood.

13.8.4. Installing Aries

Like Karaf, Nimble requires third-party implementations of enterprise programming models such as JPA and JTA. Unlike Karaf, it also requires an external Blueprint implementation. Nimble knows about Blueprint to the extent that it can recognize bundles that require Blueprint, but none of the built-in repositories include a Blueprint implementation.

Either Aries or Gemini components can be installed into Nimble. You can build an enterprise OSGi repository by indexing Aries bundles (for example, from your Maven repository). You’ll also need to hand-crank some extra repository rules that declare that the Aries bundles provide JTA, JPA, JNDI, and Blueprint implementations. The Nimble OBR indexer can identify enterprise OSGi requirements, but not enterprise OSGi capabilities. This isn’t too surprising, because spotting an implementation is much harder than spotting a consumer!

Because you’ll need to generate your own Aries repositories and rules, you may find getting enterprise OSGi working in Nimble is more effort than it is in Karaf or the higher-level application servers. Java EE support is also provisioned into the server as a distinct component, and so you may find that Java EE isn’t as thoroughly integrated as it is in servers that are built as Java EE servers.

Another difference between Nimble and many of the other servers we’ve discussed is the licensing. In common with WebSphere Application Server, Nimble is a commercial product, with no open source license. This has some—obvious—costs and also some advantages. Both Nimble and WebSphere Application Server are free to use for evaluation and development, so you’ll only need to buy a license when you move into production. Because of their commercial nature, both Nimble and WebSphere Application Server come with professional support. Two of the other servers we discussed, GlassFish and JBoss, have the option of paid support with premium editions. And Karaf, Geronimo, and Virgo have active mailing lists and helpful development communities.

13.9. Summary

With so many products to choose from, how on earth do you choose one? It may be your choice is already made for you because you’re working in an Apache shop, or a JBoss shop, or a WebSphere shop. The good news is that with so many products supporting enterprise OSGi, you’ve got a good chance of having a platform on which you can write modular applications, even if the decision about what application server to use has already been settled.

If you’re starting from scratch, there are a few factors to consider. Do you want an open source license, an open source license with paid support, or a commercial license? Are you willing to get under the hood and bolt bits together, or do you want something that works out of the box? Do you want a super-light OSGi platform, or a full-featured server? Do you need the whole enterprise OSGi programming model, or will web applications or dependency injection do? Ultimately, how much server do you need? Table 13.2 shows how the various stacks compare to each other in terms of cost and scale.

Table 13.2. Feature comparison of enterprise OSGi servers

Server	Apache Karaf	Apache Geronimo	IBM WebSphere	Eclipse Virgo	GlassFish	JBoss	Paremus Nimble
Vendor	Apache Software Foundation	Apache Software Foundation	IBM	Eclipse	Oracle	Red Hat	Paremus
License	Apache license	Apache license	Proprietary license (free restricted license for developers)	Eclipse Public License	Dual license: Common Development and Distribution License (CDDL) and GNU General Public License (GPL)	GNU Lesser General Public License (LGPL)	Proprietary license (Nimble only available with a free restricted license for developers)
Support	Community	Community	Included with license	Community	Commercial support available	Commercial support available	Included with license
Type	Provisionable framework	Application server	Application server	Application server	Application server	Application server	Provisionable framework
Enterprise OSGi technology	Aries	Aries	Aries	Gemini	In-house	In-house	Unspecified

Some of the platforms we’ve discussed have rich enterprise OSGi support, whereas others are rolling out the basics. What excites us about all of these servers is the general recognition that building modular applications is great. The industry is investing in enterprise OSGi and the range of options available to you, as an enterprise OSGi developer, is getting bigger and better.