sg09 - osgi como fundamento de lp

Agustín Ramos Fonsecacertum

OSGi como fundamento de líneas de productosy plataformas de software

2

Objetivo

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

Agenda

• 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

Un problema de diseño

5

Problema de diseño

• 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

Requerimiento

• 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

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

8

¿Podemos reutilizar?

• 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

¿Oportunidad? (1/2)

• 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

10

¿Oportunidad? (2/2)

¿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

Objetivo

Plataformas de Softwarey

Líneas de Productos

12

Plataformas de Software

• 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

Plataformas de Software

• ¿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

Lineas de Productos (LP)

• 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

LP – Impactos (1/2)

• 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

LP – Impactos (2/2)

• 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

LP y Plataforma

• ¿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

Diagramas deCaracterísticas

19

Diagramas de Características

• ¿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

Diagramas de Características

• 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

Diagramas de Características

• 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 oCaracterística

Característica Requerida

Concepto oCaracterística

Característica Opcional

22

Diagramas de Características

• 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ísticaOR

Concepto/Característica

Característica Alternativa

Característica Alternativa

23

Diagramas de Características

• 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ística Alternativa

Característica Alternativa

Característica Alternativa

Concepto/Característica

Característica Alternativa Opcional

Característica AlternativaOpcional

Característica AlternativaOpcional

24

Diagramas de Características

• 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ística Opcional

Carácterística

OR

CarácterísticaOR

Característica Opcional

Concepto/Característica

CaracterísticaOpcional

CaracterísticaOpcional

25

Diagramas de Características

¿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

Objetivo

Solución de Diseño:Una Plataforma

27

Diseño de Servicios

28

Modelo de Características

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

29

Arquitectura

• 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

OSGi

31

OSGi - ¿Qué es?

• 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

OSGi - Historia

• 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

OSGi - Arquitectura 1/2

• 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

ServiciosS

eg

urid

ad

Bundles

34

OSGi - Adopción 1/2

• 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

OSGi - Adopción 2/2

• 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

OSGi - Beneficios 1/2

– 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

OSGi - Beneficios 2/2

– 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

OSGi - Implementaciones

39

Descripción de la Plataforma

40

Descripción de la Plataforma

• ¿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

Descripción de la Plataforma

• ¿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

Descripción de la Plataforma

• ¿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

Atributos de la Plataforma

• 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

Atributos de la Plataforma

• 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

Objetivo

Futuro de OSGi

46

Futuro de OSGi (1/2)

• 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

Futuro de OSGi (2/2)

• 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

Objetivo

Conclusiones

49

Conclusiones (1/3)

• 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

Conclusiones (2/3)

• 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

Conclusiones (3/3)

• Contempla OSGi como alternativa de implementación de tus aplicaciones/plataformas.

– Ya estás disfrutando de sus beneficios, pero no lo habías notado =)

aramos@certum.comhttp://machinesareus.blogspot.com

Preguntas y Respuestas