OSGi revealed - OSGi in Action - page 22

In 2006, many OSG i supporters pushed for the introduction of JSR 291 (titled
“Dynamic Component Support for Java”), which was an effort to bring OSG i technol-
ogy properly into JCP standardization. The goal was twofold: to create a bridge
between the two communities and to ensure OSG i technology integration was consid-
ered by JSR 277. The completion of JSR 291 was fairly quick because it started from the
OSG i R4 specification and resulted in the R4.1 specification release. During this
period, OSG i technology continued to gain momentum. JSR 277 continued to make
slow progress through 2008 until it was put on hold indefinitely.

1.4.8 JSR 294

During this time in 2006, JSR 294 (titled “Improved Modularity Support in the Java
Programming Language”) was introduced as an offshoot of JSR 277. Its goal was to
focus on necessary language changes for modularity. The original idea was to intro-
duce the notion of a superpackage into the Java language—a package of packages.
The specification of superpackages got bogged down in details until it was scrapped
in favor of adding a module-access modifier keyword to the language. This simplifica-
tion ultimately led to JSR 294 being dropped and merged back into JSR 277 in 2007. But
when it became apparent in 2008 that JSR 277 would be put on hold, JSR 294 was pulled
back out to address a module-level access modifier.
With JSR 277 on hold, Sun introduced an internal project, called Project Jigsaw , to
modularize the JDK . The details of Jigsaw are still evolving after the acquisition of Sun
by Oracle.

1.4.9 Service Component Architecture

Service Component Architecture ( SCA ) began as an industry collaboration in 2004
and ultimately resulted in final specifications in 2007. SCA defines a service-oriented
component model similar to OSG i's, where components provide and require services.
Its component model is more advanced because it defines composite components (com-
ponents made of other components) for a fully recursive component model.
SCA is intended to be a component model for declaratively composing compo-
nents implemented using various technologies (such as Java, Business Process Execu-
tion Language [ BPEL ], EJB , and C++) and integrated using various bindings (such as
SOAP / HTTP , Java Message Service [ JMS ], Java EE Connector Architecture [ JCA ], and
Internet Inter-Orb Protocol [ IIOP ]). SCA does define a standard packaging format,
but it doesn't define a sophisticated module layer like OSG i provides. The SCA specifi-
cation leaves open the possibility of other packaging formats, which makes it possible
to use OSG i as a packaging and module layer for Java-based SCA implementations;
Apache Tuscany and Newton are examples of an SCA implementation that use OSG i.
In addition, bundles could be used to implement SCA component types, and SCA
could be used as a mechanism to provide remote access to OSG i services.

1.4.10 .NET

Although Microsoft's . NET (released in 2002) isn't a Java technology, it deserves men-
tion because it was largely inspired by Java and did improve on it in ways that are similar