OSGi revealed - OSGi in Action - page 21

application server (since eliminated in JB oss 5). Nowadays, JMX isn't (and shouldn't
be) confused with a module system.

1.4.5 Lightweight containers

Around 2003, lightweight or inversion of control (IoC) containers started to appear,
such as PicoContainer, Spring, and Apache Avalon. The main idea behind this crop
of IoC containers was to simplify component configuration and assembly by eliminat-
ing the use of concrete types in favor of interfaces. This was combined with depen-
dency injection techniques, where components depend on interface types and
implementations of the interfaces are injected into the component instance. OSG i
services promote a similar interface-based approach but employ a service-locator pat-
tern to break a component's dependency on component implementations, similar to
Apache Avalon.
At the same time, the Service Binder project was creating a dependency injection
framework for OSG i components. It's fairly easy to see why the comparisons arose.
Regardless, OSG i's use of interface-based services and the service-locator pattern long
predated this trend, and none of these technologies offer a sophisticated dynamic
module layer like OSG i. There is now significant movement from IoC vendors to port
their infrastructures to the OSG i framework, such as the work by VM ware (formerly
SpringSource) on the OSG i Blueprint specification (discussed in chapter 12).

1.4.6 Java Business Integration

Java Business Integration ( JBI ) was developed in the JCP and released in 2005. Its goal
was to create a standard SOA platform for creating enterprise application integration
( EAI ) and business-to-business ( B2B ) integration solutions.
In JBI , plugin components provide and consume services after they're plugged in
to the JBI framework. Components don't directly interact with services, as in OSG i;
instead, they communicate indirectly using normalized Web Services Description Lan-
guage ( WSDL )-based messages.
JBI uses a JMX -based approach to manage component installation and lifecycle and
defines a packaging format for its components. Due to the inherent similarities to
OSG i's architecture, it was easy to think JBI was competing for a similar role. On the
contrary, its fairly simplistic modularity mechanisms mainly addressed basic compo-
nent integration into the framework. It made more sense for JBI to use OSG i's more
sophisticated modularity, which is ultimately what happened in Project Fuji from Sun
and ServiceMix from Apache.

1.4.7 JSR 277

In 2005, Sun announced JSR 277 (“Java Module System”) to define a module system
for Java. JSR 277 was intended to define a module framework, packaging format, and
repository system for the Java platform. From the perspective of the OSG i Alliance,
this was a major case of reinventing the wheel, because the effort was starting from
scratch rather than building on the experience gained from OSG i.