Java Reference
In-Depth Information
including Enterprise JavaBeans (
EJB
), Spring Beans, Google Guice, Service Component
Architecture (
SCA
), and Fractal, to name just a few. The variety and variation among
component-oriented approaches is staggering, but one thing is typically common: they
ignore or only pay lip service to modularity issues related to deployment and execution-
time verification and enforcement. This means
OSG
i technology provides a perfect
foundation for integrating existing component approaches or defining new ones.
In this chapter and the next, we'll introduce you to component orientation in gen-
eral and as it relates to
OSG
i technology. This chapter will cover introductory aspects
and present the first
OSG
i standard component framework, called
Declarative Services
,
which is lightweight and fairly representative of how component frameworks are inte-
grated with
OSG
i. In the next chapter, we'll introduce a couple more advanced com-
ponent frameworks. We'll reuse the example paint program to illustrate how these
component frameworks simplify
OSG
i-based development. Let's start with background
information and motivation.
11.1
Understanding component orientation
Although component-oriented programming has been around for a while, there's no
single definition for most of the concepts it embodies (which is similar to module ori-
entation). Therefore, you shouldn't take the discussion in this section as the bible for
all component-oriented approaches. The main questions we intend to address for the
scope of this chapter and the next are, what are components, and why do we want
them? We'll answer these questions in the following two subsections, respectively.
11.1.1
What are components?
A key aspect of all component technologies is that they describe functional building
blocks that are typically more coarse-grained than what we normally associate with
objects (although object orientation isn't required for component orientation).
These building blocks are typically business logic; they provide functionality via inter-
faces. Conversely, components may consume functionality provided by other compo-
nents via their interfaces. Components for a given approach are usually programmed
according to a particular pattern defined by a
component model
. A
component framework
is
used to execute components.
Component model vs. component framework
A component model describes what a component looks like, how it interacts with oth-
er components, and what capabilities it has (such as lifecycle or configuration man-
agement). A component framework implements the runtime needed to support a
component model and execute the components. The relationship between the two
isn't strictly one-to-one. For example, the Common Object Model (COM) defines a
component model that's implemented by different component frameworks for differ-
ent platforms. Likewise, it's also possible for a component framework to support mul-
tiple component models, such as the JBoss Microcontainer.
