Presentación dada en Software Gurú 09 http://www.sg.com.mx/sg09/ sobre el uso de OSGi como tecnología que habilita el desarrollo de plataformas de software y líneas de producto con atributos de calidad que actualmente no se encuentran en otras tecnologías.

2. 2
Compartir experiencias, retos y soluciones
en el uso de OSGi como tecnología clave
para la creación de plataformas de software
que habilitan el desarrollo de líneas de
productos.

3. 3
• Un problema de diseño.
• Plataformas y Líneas de Productos.
• Diagramas de características.
• Solución de diseño: una plataforma.
• Introducción a OSGi.
• Descripción de la plataforma.
• Futuro de OSGi y la plataforma.
• Preguntas y respuestas

4. 4
Un problema de diseño

5. 5
• Contexto:
– Cliente: 1 de las 5 cadenas de cines más
grandes del mundo, con presencia
internacional y un acelerado ritmo de
crecimiento.
– Una arquitectura empresarial sumamente
distribuída. Software hecho a la medida.
– Una estrategia de integración en marcha.
– Un sistema de ventas por internet que
“le queda chico” a la organización...

6. 6
• Crear una nueva versión del sistema de
ventas por internet (boletosy en un futuro
alimentos), cuidando:
– Habilitar a la organización para el crecimiento
(clientes, productos y servicios, partners).
– Proveer de atributos de calidad específicos
y medibles en los rubros de: disponibilidad,
escalabilidad, confiabilidad, seguridad y
desempeño.

7. 7
• Láminas con el contenido de la sesión

8. 8
• Paquetes (2 tipos):
– Orientados a mercaderías.
– Orientados a venta de boletos
• Venden la infraestructura completa para la
operación, no solo el motor internet.
• Deben ser adaptados al cliente ($$$ + $$$).
• Servicios de boletaje (convenios)
– Genera dependencias al negocio principal de
la organización.
• Tenemos que crear una solución.

9. • Una venta no es nada nuevo.
• Consiste de los siguientes pasos
– Selección de productos.
– Identificación del usuario.
– Configuración de pago.
– Registro de la venta.
• La diferencia principal es el protocolo de
selección de los productos.
– e.g. Es diferente entre boletos y publicaciones
9

10. 10
¿Podemos crear una plataforma para la
venta de productos por internet?
Parece que sí!
Nuevo problema de diseño
Crear una plataforma para la generación de
aplicaciones de venta por internet.

11. 11
Plataformas de Software
y
Líneas de Productos

12. 12
• Definición
“Una plataforma es una capacidad tecnológica
para generar productos derivados”
Wheelwright& Clark
• Ejemplos en Software
– JEE.
– Eclipse
– Amazon Elastic Compute Cloud

13. 13
• ¿Por qué existen?
– Economía.
• Soluciones listas para un dominio de problemas.
• Permiten generar productos de manera más
rápida.
– Soluciones al cumplimiento de atributos de
calidad.
• e.g. escalabilidad, disponibilidad, seguridad.
– Habilitan la innovación.
• Al permitir concentrarse en diferenciadores.

14. 14
• Definición
“Una línea de productos de software es un conjunto de
sistemas intensivos en software que comparten un
conjunto común y administrado de características,
que satisfacen las necesidades específicas de un
segmento particular del mercado y que son
desarrollados a partir de un conjunto central de bienes
(también conocido como “plataforma”) de una manera
prescrita”
Clements & Northrop

15. 15
• Económico.
– Incremento en el costo inicial de desarrollo.
– Ahorro en la generación de nuevos productos.
Costo
Proyecto#1 #2 #3 #4
Costo Total sin
una Línea de
Productos
Costo Total con
una Línea de
Productos

16. 16
• Organizacional.
– Requiere una estructura de organización
enfocada a las tres actividades principales:
• Desarrollo de la plataforma (core assets).
• Desarrollo de productos.
• Administración.
• Tecnológico.
– Nuevos métodos y prácticas de diseño y
construccón.
– Eventualmente se convierte más en una
actividade de configuración.

17. 17
• ¿Cuáles la relación?
– Los artefactos (core assets) a partir de los
cuales son generados nuevos productos
conforman la plataforma de la Línea de
Productos.
– La plataforma es la piedra angular desde el
punto de vista tecnológico.
– Esta plataforma incluye una arquitectura de
software diseñada específicamente para el
dominio que aborda esa línea de
productos.

18. 18
Diagramas de
Características

19. 19
• ¿Qué son?
– Una técnica de modelado que
permiten capturar los puntos de
variación de un sistema.
• De una manera que en UML resulta
difícil de articular.
Concepto
Sub-
Característica
Característica

20. 20
• Vocabulario.
– Un concepto es el conocimiento que tenemos
sobre las propiedades de un objeto y que nos
permite categorizarlo.
– Una característica es una propiedad importante
de un concepto. Un modelo de características
representa características comunes y variables
de un concepto, así como las dependencias entre
las características variables.
– Un diagrama de características es una
representación visual de estos conceptos,
características y relaciones. Captura los puntos
de variación de un sistema.
– El diagrama puede tener tantos niveles como
sea necesario para describir la variación del
dominio que se está modelando.
Concepto
Sub-
Característica
Característica

21. 21
• Modelado básico (1/4)
– Características obligatorias.
• Cada instancia del sistema contiene
ésta característica.
– Características opcionales.
• Pueden o no estar incluídas en una
instancia
Concepto o
Característica
Característica
Requerida
Concepto o
Característica
Característica
Opcional

22. 22
• Modelado básico (2/4)
– Características alternativas.
• En cada instancia, se incluye una y
solo una de las alternativas.
– Características “OR”.
• Cada instancia del sistema contiene
una o más características del
conjunto.
Concepto/
Característica
Carácterística
OR
Carácterística
OR
Concepto/
Característica
Característica
Alternativa
Característica
Alternativa

23. 23
• Modelado básico (3/4)
– Dimensión
• Es un concepto donde todas las
características son alternativas.
– Dimensión con
características opcionales.
• Es un concepto donde todas las
características son alternativas y
opcionales.
Concepto/
Característica
Característic
a Alternativa
Característic
a Alternativa
Característic
a Alternativa
Concepto/
Característica
Característica
Alternativa
Opcional
Característica
Alternativa
Opcional
Característica
Alternativa
Opcional

24. 24
• Modelado básico (4/4)
– Punto de extensión.
• Es un concepto que tiene al menos
una característica opcional o un
conjunto de características “OR”.
– Punto de extensión con
características opcionales.
• Un concepto donde todas las
características son opcionales.
Concepto/
Característica
Característic
a Opcional
Carácterístic
a
OR
Carácterística
OR
Característica
Opcional
Concepto/
Característica
Característica
Opcional
Característica
Opcional

25. 25
¿Qué ventajas ofrece este modelado?
– Identificar las características obligatorias y
opcionales dentro de un dominio de sistema,
asÍ como las relaciones entre éstas.
• De ésta manera se introduce variabilidad solamente
donde es requerido.
– Identificar distintos tipos de variabilidad
• En tiempo de armado del producto,
• Configurable en un producto ya armado.
• En tiempo de ejecución.
– Facilita la definición de un producto.

26. 26
Solución de Diseño:
Una Plataforma

27. 27

28. 28
Modelo de características para el registro de
la venta (simplificado)

29. 29
• Una arquitectura de
micro-kernel.
– Define las API‟s e
implementaciones principales
• Permite que coexistan
múltiples implementaciones
de un servicio
– El servicio a utilizar se localiza
dinámicamente
• Los canales de venta se
montan sobre el motor a
través de conectores.

30. 30
OSGi

31. 31
• Es la especificación de un modelo de
componentes, caracterizado por:
– Orientado a Servicios
– Dinámico
– Tamaño reducido (< 1Mb)
– Alto desempeño (No hay classpath)
– Portable (desde móviles hasta servidores)
– Soporta múltiples versiones de clases y
servicios.

32. 32
• Comenzó como un esfuerzo conjunto en
el mercado de dispositivos embebidos.
– OSGi Alliance fundada en 1999
• Su éxito le permitió ganar adopción en
otros dominios…
– Eclipse 3.0 basó su modelo de plug-ins sobre
OSGi
• Versión 4.2 de la especificación liberada
en Septiembre del 2009.

33. 33
• La unidad de instalación y reutilizaciónes el
„bundle‟ (jar + META-INF especial).
• Los bundles exportan e importan clases y
servicios a través de un service registry.
Sistema Operativo Nativo
Java VM
Entorno de Ejecución
Módulos
Ciclo de Vida
Servicios
Seguridad
Bundles

34. 34
• Miembros de OSGi Alliance:
– Oracle, IBM, Samsung, Nokia, IONA,
Motorola, NTT, Siemens, Hitachi, Deutsche
Telekom, Redhat, Ericsson .. y muchos más.
• Areas de aplicación
– Automatización
– Cómputomóvil
– Cómputo en “La Nube”
– Servidores de aplicaciones

35. 35
• Actualmente es el fundamento de la nueva
generación de servidores de aplicaciones
y plataformas SOA.
– Websphere v6.1 (IBM)
– GlassFish v3 (Sun)
– Weblogic v10.3 (Oracle/BEA)
– JBoss
– Jonas v5
– SpringSource Application Server
– WSO2 Carbon SOA Platform

36. 36
– Modularidad.
• Los servicios de la plataforma JEE
(EJB, Contenedor de servlets, JMS, Mail,
Transacciones, etc) se implementan como
servicios OSGi opcionales.
– Extensibilidad.
• Consecuencia casi directa de la modularidad.
– Dinamismo real.
• Permite instalar / actualizar / desinstalar módulos
al vuelo (sin reinicios).
• Impactando la disponibilidad y flexibilidad de las
aplicaciones

37. 37
– Nativamente orientado a servicios (SOA).
– Permite la coexistencia controlada de
diferentes versiones de una misma clase y
servicio.
• Las clases pueden estar compartidas entre
bundles, o completamente aisladas fuera de un
contexto.
• Cada bundle declara sus dependencias y
opcionalmente rangos soportados de versiones
para las mismas.
– Desempeño
• Llamadas locales de pojo a pojo
• No hay classpath!

38. 38

39. 39
Descripción de la Plataforma

40. 40
• ¿Qué hicimos?
– Implementar la plataforma con OSGi y Spring
• Basado en el diseño de micro-kernel y el modelo
de características.
• Cada componente es un bundle.
• Cada componente importa/exporta servicios.
• El binding entre servicios es dinámico, se localizan
en base a consultas sobre las capacidades de
cada servicio.
• Añadir Terracota para hacer clusters cuando sea
necesario.

41. 41
• ¿Qué problemas encontramos?
– Soporte de transacciones cross-bundle
• Solución: Exportar el Transaction Manager de
spring como un servicio OSGi.
– El servicio de registros no tiene hooks, por
tanto no podíamos usar el sistema nativo para
poner tags a un nuevo servicio al instalarlo.
• Solución: Implementar un servicio de registro con
las capacidades que requerimos.
– Falta de soporte para clusters con Terracota.
• Un feo hack, pero funcionó.
• Actualmente ya hay una mejor solución

42. 42
• ¿Qué tenemos?
– Una plataforma de venta en internet.
• Agnóstica al canal de venta empleado.
• Extensible en cuanto a productos, formas de pago,
sistemas de determinación de precios y programas
de lealtad.
• Que permite distintas implementaciones de los
servicios, y que permite asociar cada
implementación con un conjunto de locaciones
distintas.
• Robusta al agregar/remover en tiempo de
ejecución implementaciones de estos servicios.
• Independiente del dueño de los productos.

43. 43
• Confiabilidad
– El motor tiene control absoluto de la
transacción
• No confía en las aplicaciones cliente
– Operaciones de compensación en la
interacción con sistemas externos.
• Disponibilidad
– Pueden agregarse y removerse servicios sin
necesidad de reiniciar (e.g. procesadores de
pagos).

44. 44
• Escalabilidad
• La modularización subyacente permite hacer
clusters individuales de los módulos con mas
demanda de recursos.
• Al distribuírse la aplicación, se usan mecanismos
de remoting (spring) para la comunicación entre
bundles.

45. 45
Futuro de OSGi

46. 46
• Extensiones del Registro de Servicios.
– Permite crear bundles que observan o
manipulan actividad del registro de servicios.
• Soporte de Transacciones
– Da soporte de operaciones transaccionales
tanto a eventos del ciclo de vida de los
componentes como a las aplicaciones.
• OSGi Distribuido
– Habilita la comunicación entre servicios que
se ejecutan en distintas JVM‟s.

47. 47
• Blueprint Container.
– Estandariza el uso de frameworks como
Spring sobre OSGi para proveer un modelo
de componentes más completo.
• Permisos condicionales
– Mejora la habilidad de restringir la instalación
y uso de bundles a partir de certificados
digitales.

48. 48
Conclusiones

49. 49
• No re-inventes la rueda!
– Pero, si tienes que hacerlo, asegúrate de que
sea la última vez: No te repitas a ti mismo.
– Considera la reutilización como algo
estratégico para la economía de tu
organización, no algo accidental.

50. 50
• Usa modelado de dominio para entender
mejor las partes fijas, opcionalesy variables
de los sistemas que desarrollas.
– Tus diseños serán más enfocados a las partes
que requieren tu mejor esfuerzo.
– Le darás un plus a la mantenibilidad de los
sistemas que desarrolles de esta manera.

51. 51
• Contempla OSGi como alternativa de
implementación de tus
aplicaciones/plataformas.
– Ya estás disfrutando de sus beneficios,
pero no lo habías notado =)