The OSGi ecosystem - Enterprise OSGi in Action - page 363

(such as Equinox and Felix) also provide a JAR that includes Compendium interfaces.
But not all of these interfaces have backing implementations. For example, the Log
Service and HTTP Service are implemented by Felix and Equinox, and the Wire
Admin Service is implemented by Equinox only. This can make understanding what's
in the compendium and where to get implementations tricky.
We don't refer to the compendium too often in this topic because it isn't within
the scope of what we're discussing. This isn't to say that the compendium services
aren't useful, but describing them is best left to topics on core OSG i. Most of the
things in the Compendium Specification that are useful to the enterprise are also
reproduced in the Enterprise Specification.

B.2.3 The Enterprise Specification

Because it's so broad, the OSG i compendium doesn't stand on its own as a program-
ming model. The Enterprise Specification was introduced to provide a much more
coherent programming model for an enterprise audience. The Enterprise Specifica-
tion is sometimes referred to as a profile, because it selects a subset of specifications. It
also adds some new service definitions that aren't in the compendium to provide
interoperability between Java EE standards and core OSG i.
Because the Enterprise Specification has a tighter focus than the compendium, it's
much more natural for implementers to provide the whole of the specification. For
example, Apache Aries and Eclipse Gemini are both specifically designed as enter-
prise OSG i implementations, and both implement almost the whole specification. But
several of the other servers we described in chapter 13 only implement selected chap-
ters of the Enterprise Specification.
Whereas the OSG i Enterprise Specification is based around enterprise grade ser-
vices, the OSG i compendium focuses on tools, features, and containers that are useful
for OSG i client runtimes. This does lead to some functional overlap between different
services in the two specifications, such as the Http Service and Web Applications, or
Declarative Services and Blueprint. The key point to remember is that the compen-
dium is generally most useful for small-scale work, and the enterprise for large scale
work. For example, the Http Service allows you to register servlets individually, but web
applications can deploy hundreds or thousands of servlets at a time using metadata.
The main purpose of the Enterprise Specification is to provide application devel-
opers with access to enterprise services, the majority of which are already available in
Java EE . One of the guiding rules of the OSG i Enterprise Specification is that where a
enterprise service is already available in Java EE , the OSG i version of that service
should be as similar as possible. This means that it should use the same API , have the
same semantics, and be accessible in a similar way. This isn't always possible, but for
the most part it is. In addition to maintaining the existing behavior of Java EE services,
the Enterprise Specifications also try to make any enterprise service as OSG i-friendly as
possible. One of the more common (and unsurprising) results of this is that OSG i-
enabled enterprise services are usually available in the OSG i Service Registry, which
allows them to be dynamically swapped at runtime.