Advanced component frameworks - OSGi in Action - page 400

a thread accesses it and while the thread executes inside the component. Suppose you
have a method that does something like this:

@Requires
private Foo m_foo;
public void statelessAccess() {
m_foo.doA()
m_foo.doB()
m_foo.doC()
}
Accesses to m_foo always return the same service instance at the time of the first access
to m_foo . This allows i POJO to simplify the task of dealing with stateful services in the
dynamic service environment provided by OSG i. This is cool, but it doesn't mean you
don't have to worry about anything! Due to dynamism, accessing a service is similar to
using remote services, which means they can throw exceptions for unknown reasons.
For example, if Foo represents some device that becomes physically disconnected, its
service methods are likely to throw exceptions when you access them. In short, you
still need to code defensively, just as in distributed computing.
You now know how to describe your components' provided and required services.
Like the other component frameworks you've seen, your components' lifecycles are
controlled and managed according to these component characteristics. We'll look
more deeply at the i POJO component lifecycle next.

12.2.4 iPOJO component lifecycle

As with the other component frameworks, i POJO component instances are either valid
or invalid depending on whether their mandatory service dependencies are satisfied.
When a component is valid, i POJO can publish its provided services in the OSG i ser-
vice registry. When a component is invalid, i POJO must remove its provided services
from the service registry and release the associated component instance if one was
created. At execution time, the i POJO runtime watches for bundles containing compo-
nents to be installed into the running OSG i framework. After these bundles are acti-
vated, i POJO takes over their management.
Overall, the component lifecycle is fairly straightforward. i POJO provides a number
of additional ways to impact or hook into a component lifecycle, such as service-
dependency binding policy, temporal service dependencies, lifecycle callback meth-
ods, component lifecycle participation, and bundle context access. We'll look into
each of these.

SERVICE-DEPENDENCY BINDING POLICY
In addition to treating all service dependencies as either mandatory or optional,
i POJO treats them as either static or dynamic; this is called a binding policy . This con-
cept is also present in Declarative Services and has the same meaning here. The best
way to understand the difference between a static and dynamic service dependency is
to consider a specific service dependency, such as an aggregate dependency on the
SimpleShape service.