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 =)
Top Related