Este documento presenta una introducción a JAIN SLEE, incluyendo una descripción de su arquitectura y componentes principales como SBBs, RAs y eventos. También explica los beneficios de SLEE como un estándar portable e independiente de la red que permite el desarrollo de servicios convergentes.

1. Joaquín Ruiz Rojas Introducción a JAIN SLEE

9. SLEE Vs. J2EE Son tecnologías totalmente complementarias. Otras consideraciones Centralizado Distribuido Despliegue - Casi tiempo real Tiempo Real De 2 a 3 nueves De 3 a 5 nueves Disponibilidad Intensiva durante los accesos a BD Sólo procesa si hay invocación de recursos o eventos Computación De BBDD (lenta finalización y de menor frecuencia) Ligeras (para la replicación del estado, rápidas y más frecuentes) Transacciones Servidores de BB.DD. Y otros sistemas de Back-end. Una única copia persistente. Múltiples (Información del contexto, datos provisionados, cacheados sin persistencia) Data Sources Objetos pesados con ciclos de vida largos Objetos ligeros con ciclos de vida muy cortos e interfaces fuertemente tipados (los crea la plataforma no el desarrollador) Componentes Principalmente síncrono (cliente - servidor) Principalmente asíncrono (dirigido a eventos) Invocación J2EE JSLEE

11. Arquitectura

19. Activity Context & ACI ACTIVITY CONTEXT INTERFACE (ACI) Es la visión (Objeto) que tiene el SBB del Activity Context, gracias al cuál los SBBs pueden leer y escribir su estado en el mismo Determina qué eventos van a cada SBB, dado que los SBBs sólo recogen eventos de sus correspondientes actividades, que dando “subscritos” (attachados) a la misma. Es creada y eliminada en tiempo de ejecución y puede afectar al ciclo de vida de nuestro servicio, ya que un SBB no es destruido hasta que no se encuentra “des-attachado” de todas sus actividades. Un SBB puede generar una ACI nueva gracias a la ACIFactory que le ofrece el RA. ACTIVITY CONTEXT Es la entidad lógica (sin API) que representa y encapsula al Activity Object en el SLEE Contiene atributos que permiten compartir información entre los SBBs de un mismo componente

24. Facilities TIMER FACILITY Esta funcionalidad permite programar acciones periódicamente o iniciar acciones tras un tiempo previamente definido. La “Timer Facility” controla un número determinado de timers totalmente independientes entre sí. Cada Timer puede lanzar 0 ó n eventos tras su vencimiento. PROFILE FACILITY Es la funcionalidad que da acceso a las Profile Tables (por lo tanto a los datos provisionados) public ProfileTableActivity getProfileTableActivity(String profileTableName) public ProfileTable getProfileTable(String profileTableName) SERVICE LOOKUP FACILITY [1.1] Esta funcionalidad permite a los Resource Adaptors obtener información sobre los eventos que puede recibir un servicio instalado en el SLEE

25. Facilities EVENT LOOKUP FACILITY [1.1] Esta funcionalidad permite a los RA obtener información sobre los tipos de eventos (FireableEventType) que se encuentran instalados en el SLEE Se puede usar para convertir los eventos del SLEE en “FireableEventType objects” que son los que usa el RA para lanzar eventos desde o hacia cualquier “End Point” ALARM FACILITY Esta funcionalidad permite a SBBs, RAs, y Profiles activar o limpiar alarmas en el SLEE Las notificaciones de las alarmas que se lancen generarán su correspondiente notificación en el AlarmMBean (accesible desde la consola de administración) Cada alarma posee un identificador y un nivel de criticidad (AlarmLevel) ACTIVITY CONTEXT NAMING FACILITY La Activity Context Naming Facility facilita la etiquetación mediante un nombre de los Activity Contexts. Permite a un SBB object asignar un nombre a un Activity Context, para que otros SBBs objects puedan buscar y acceder a dicha Activity. Un Activity Context puede tener cero o más nombres

38. www.altran.es