Migration and integration - Enterprise OSGi in Action - page 276

need this extra function, and the lighter combination of Karaf and Camel works well
for them. You've already seen Karaf as a testing environment in section 8.3.4, and we'll
be coming back to it as a production environment in section 13.2. Camel is a router.
Karaf on its own certainly isn't an ESB , and Camel on its own doesn't offer OSG i sup-
port, but in combination they make a nice little integration platform. Camel provides
Karaf with features that allow it to be easily installed into a Karaf instance, although you
may need to adjust the JRE properties and OSG i boot delegation in some cases.
This completes our tour of SCA and ESB s. Talking to external services isn't the only
problem you face when trying to start using enterprise OSG i. What do you do with
existing Java EE artifacts if you want to use them in your application?

11.2 Migrating from Java EE

Java EE is an enormously popular and successful programming model for enterprise
applications. If you picked up this topic as someone with Java EE experience, you
might have skipped ahead to this section. If so, we recommend cooling your jets and
taking a step back to some of the earlier content in this topic. Migrating Java EE appli-
cations to OSG i can be surprisingly easy, but it helps to have a good understanding of
OSG i fundamentals before you start. If you try to migrate an application without that
understanding, then things may seem confusing, but for those of you who have read
chapters 2 and 3, you may find that this section reinforces what you thought already.
Java EE offers a huge range of support and integration points for many different
enterprise technologies, so huge that there are few applications that use it all. Most
applications stick to a small subset of the Java EE programming model. Recognizing
this, in Java EE 6 the Java Community decided to allow the Java EE specifications to be
grouped into profiles offering a reduced set of functions. The first profile introduced is
known as the Web profile and unsurprisingly focuses on Java EE web applications
( WAR s) and the technologies most commonly used with them.
Having identified WAR s as the most commonly used Java EE module type, it
makes sense to start by looking at how you can migrate a Java EE WAR file into the
OSG i container.

11.2.1 Moving from WARs to WABs

Unless you've skipped the majority of this topic, you'll certainly have been introduced
to the concept of the OSG i WAB . A WAB , or Web Application Bundle, is defined by the
Web Applications Specification from the OSG i Enterprise Expert Group and is, by
design, a close partner of the Java EE WAR . One of the key requirements for OSG i's
Web Applications Specification was that it must be possible to write any WAB such that
it's also a valid WAR file.
The wonderful thing about this requirement is that it not only dramatically sim-
plifies the description of a WAB file, but that it also makes it trivial to migrate most
Java EE WAR s. Structurally, there's no real difference between a WAB and a WAR file.
Both expect the web deployment descriptor (web.xml to you and me) to be located