Java Reference
In-Depth Information
and Mobile Specifications all build on the Core Specification. These three specifica-
tions also have a lot of overlap in terms of their content.
B.2.1
The Core Specification
The Core Specification is the oldest and most important part of
OSG
i. The Core Spec-
ification defines the
API
s for interacting with the framework, the structure of an
OSG
i
bundle, and its manifest metadata. The module layer, lifecycle layer, service layer, and
security layer are all defined by the
OSG
i core. Without these rules it would be impos-
sible to build anything at all.
The Core Specification also defines a handful of value-added services. For exam-
ple, there's a service that allows bundles to be started conditionally based on a
start
level
, and a service that allows bundle wirings to be reflectively explored.
Because it's so fundamental, implementing the Core Specification is required for
something to call itself an
OSG
i framework. It doesn't matter if you're running on a
tiny embedded processor in a car entertainment system or on a gigantic supercom-
puter with terabytes of memory—if it's in there you have to do it to be compliant. As a
result this means the Core Specification tends to change more slowly than some of the
other specifications, and most importantly it has to stay small. New features are only
added when it isn't possible to implement them any other way.
In this topic, when we say that the framework does something, what we mean is
“the
OSG
i Core Specification requires the framework to do
xxx
.” This is likely to be the
only interaction your application has with the Core Specification. Although in many
senses the Core Specification is the most important of all the
OSG
i specifications, it
isn't the main focus of this topic. What we think is exciting is what you can do with the
tools built on top of the Core Specification in the other specifications!
B.2.2
The Compendium Specification
The
OSG
i programming model is extremely service-oriented. Apart from the core
framework, almost every
OSG
i feature is defined as a service. The Core Specification
includes some particularly essential services, but there are many more services that
would be useful. A large number of these are defined in the
OSG
i Service Compen-
dium. The Compendium is an enormous document; at 732 pages, it's almost three
times the size of the Core Specification. It includes services for almost everything,
from preferences, to remote services, to configuration admin, to
HTTP
communica-
tion, to universal plug-and-play devices. It also includes some extensions to the
OSG
i
programming model. For example, it includes a standard for Declarative Services, and
an
API
for tracking services.
Unlike the Core Specification, which lays out a cohesive platform, the Compen-
dium Specification is much more of an amalgamation of bits and pieces. It would be
strange for an implementer to implement only part of the Core Specification, and
there's a Technology Compatibility Kit (
TCK
) that verifies implementations comply
with the entire Core Specification. Most implementations of the Core Specification
