Con el tiempo, OSGi ha evolucionado más allá de un simple uso para redes domésticas (como fue concebido inicialmente) a un modelo de contenedor capaz de solucionar muchos de los problemas que existen actualmente en los servidores de aplicaciones (empaquetado, abstracción de los paquetes, carga dinámica de los mismos, dependencias, gestión del ciclo de vida, versionados, etc…).

En OSGi, un paquete o componente es poco más que un jar tradicional de Java, con sus interfaces, implementaciones y un fichero manifiesto. Dicho componente se podrá definir por cierta meta-información de su fichero manifiesto que especificará los servicios exportados y los permisos necesarios para poder ser reutilizados por otros componentes.
Además, OSGi nos permitirá la gestión del ciclo de vida del software (tales como instalación, parada, redespliegue, arranque o desinstalación de paquetes) chequeando las dependencias existentes para el paquete tratado y evitando conflictos de ejecución.
Nos permite también la gestión de versiones de los paquetes, permitiendo la coexistencia de distintas versiones según necesidades y dependencias establecidas.
Por último, OSGi nos permite un modelo de Programación Orientado a Servicios (aquí basa su modelo en SOA), ya que (al contrario de EJB o RMI que necesita definir interfaces remotas) los servicios son publicados y registrados en el contenedor automáticamente durante la carga de los mismos.

Actualmente, todos los que usamos el framework de Eclipse 3.0, estamos usando OSGi de manera indirecta (Eclipse lo adoptó y de hecho fue uno de los mayores propulsores de OSGi en su momento; ahora evolucionado al Proyecto Equinox).
Lo importante, es la adopción de este modelo como parte de las estrategias para los productos de diversos fabricantes (Apache Felix, Newton, BEA mSA, etc…) y principalmente en el lado del servidor (que es donde OSGi puede sacar su mayor potencial a relucir como parte de los servidores de aplicaciones).

Algunos hablan de OSGi como el próximo middleware universal, las posibilidades de descubrimiento y reutilización de servicios y las posibles alianzas entre OSGi y Spring (suma todas las características enunciadas sobre OSGi a la facilidad de uso de Spring a base de inyección de dependencias y la programación orientada a aspectos) o entre OSGi y SCA (en este sentido OASIS tiene pendiente la estandarización de SCA).

Links interesantes:

OSGi Alliance
An Introduction to OSGi on the Server Side
Interesante discusión sobre si OSGi es SOA
Power Combination: SCA, OSGi and Spring
On SOA, OSGi and More
Universal Middleware: What’s Happening With OSGi and Why You Should Care

Cuando hablamos de SOA hablamos de una arquitectura que nos permite conectar unidades funcionales; esto es, servicios, a través de contratos bien definidos (WSDL) además de toda una serie de características propias e intrínsecas a la definición de un Servicio Web. Una de las ventajas principales es el débil acoplamiento y la independencia con carencia de estado de los servicios; que permite acometer cambios minimizando el impacto sobre el resto de componentes de la Arquitectura.
SOA no es nuevo, muchas empresas llevan varios años intentando (con más o menos acierto) construir arquitecturas de este tipo; ahora es cuando SCA aparece como un modelo diseñado para desarrollar SOA. SCA nos va a permitir encapsular o modificar aplicaciones ya existentes utilizando una "abstracción SOA". Se va a encargar de los temas relacionados con el ensamblaje de servicios heterogeneos; que a su vez dan lugar a servicios nuevamente reutilizables y siguiendo dichos principios.
SCA no es incompatible con los Servicios Web, todo lo contrario; SCA define la manera de ensamblarlos (incluso con otros elementos que no sean Servicios Web como EJB’s, CORBA, etc…)

El modelo de ensamblaje SCA consiste en una serie de Artefactos (o "Artifacts") definidos por medio de ficheros XML. El artefacto base es una Composición (o "Composite") que define los servicios que pueden ser accedidos. La composición a su vez, se define por medio de uno o más Componentes (o "Components") que contienen las funciones u operaciones de negocio provistas por el módulo a través de sus "entry points" (las implementaciones de los mismas pueden ser con cualquier lenguaje/plataforma que se quiera). Las dependencias que existan con respecto a otros componentes (ya bien sean del mismo módulo o de otros externos) son llamadas Referencias (o "References"). Y las uniones entre referencias y servicios son definidos por medio de cables (o "Wires").

Por mi propia experiencia en desarrollo de aplicaciones SCA (concretamente con la herramienta Websphere Process Server de IBM) tengo que decir que facilita bastante las cosas a la hora de componer distintos elementos. En mi caso, partiendo de servicios web ya existentes, estos se descomponen en interfaces y puntos de acceso (url endpoints independiente del protocolo a utilizar) que pueden ser utilizados para crear otros componentes (que utilizarán dichas interfaces ya existente como referencias ("References") a los servicios para así componer nuevos componentes como procesos bpel o módulos java). Además, se pueden exponer nuevamente dichas interfaces (u otras nuevas como composición de las anteriores) para ser accedidas como si de un servicio web nuevo se tratara (o bien como un componente SCA sin más).

Por último comentar, que al igual que SCA nos permite construir arquitecturas SOA de una manera más sencilla y "componible", existe otro elemento importante que es SDO (Service Data Object); un modelo para representar datos de manera universal y que se suele utilizar con arquitecturas SCA para el intercambio de información entre elementos… pero esto será tema para otro post…

Links interesantes:

Introducción a SCA de David Chappell
OSOA : SCA Project
Especificaciones SCA