Spring, SCA, and OSGi

French paleontologist Pierre Teilhard de Chardin once said: “Tout Ce Qui Monte Converge” or “Everything That Rises Must Converge”. I learned this quotation from my father who mentioned to me that it was the topic of his philosophy dissertation at his university entrance exam.

The quotation accurately describes what I see happening in the world of software development with the rise of Spring, OSGi, and SCA.

During the last 30 years, the software industry has evolved from structured design to object-oriented design, POJO programming, and lately service-oriented design. With the rising complexity and costs of software systems, the ultimate goal of this evolution has been the reuse of software assets through loose coupling and service orientation.

Spring is based on the principle of inversion of control (IoC) or dependency injection. With Spring, objects (simple POJOs) are provided with their dependencies as opposed to the objects managing or looking up those dependencies themselves. Spring relies on aspect-oriented programming (AOP) to declaratively manage cross-cutting concerns such as security, transaction, and logging. From a quality and agile development perspective, one big advantage of Spring-based applications is that they are amenable to unit testing using frameworks such as JUnit or EasyMock.

Service-oriented architecture (SOA) exposes application business logic as a set of services that are remotely accessible and reusable across platforms and programming languages. The Service Component Architecture (SCA) has been designed to facilitate service composition. The SCA Assembly Model consists of one or more service components. Service components provide business functions to other components within or outside the module. A composite contains one or more service components and specifies communication bindings and policies such as security and transactions. Like in Spring, the artifacts and the dependencies between them are described using XML.

The Open Services Gateway initiative (OSGi) defines a dynamic service model where components (packaged as bundles) and their dependencies are specified in a service registry. OSGi standardizes the life cycle management of these bundles including deployment, installation/uninstallation, and updates with full versioning capabilities. Bundles can be dynamically started, stopped, or updated without the need for a reboot. OSGi defines a model for publishing, discovering, and binding to services within the same virtual machine (VM).

Spring, SCA, and OSGi are converging to create an environment that facilitates the design and the lifecycle management of software assets that are exposed as reusable services. Software vendors are actively exploring different opportunities to combine these three technologies. The combination of Spring, SCA, and OSGi is already having a transformative impact not only on service-oriented design and application development in general, but also on the application servers and middleware market as well.