• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Development.in.Jain.Slee.(May.2009)
 

Development.in.Jain.Slee.(May.2009)

on

  • 1,693 views

Presentation about development in JAIN SLEE 1.1. And some comments about the different vendors like OpenCloud, JNetX or Mobicents.

Presentation about development in JAIN SLEE 1.1. And some comments about the different vendors like OpenCloud, JNetX or Mobicents.

Statistics

Views

Total Views
1,693
Views on SlideShare
1,681
Embed Views
12

Actions

Likes
0
Downloads
72
Comments
0

3 Embeds 12

http://www.slideshare.net 9
https://www.linkedin.com 2
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Un desarrollo para España vale para cualquier otro país cambiando parámetros básicos.
  • Permite la convergencia REAL entre el mundo de las Telecomunicaciones y del Desarrollo Software. Todo esto se consigue gracias a JAVA (write-once, run-anywhere) y la definición por parte de Sun de un estándar para el desarrollo de este tipo de aplicaciones. En definitiva se reducen los costes de desarrollo, a la par que se aumenta la potencia de los mismos. Las aplicaciones de Telecomunicaciones quedan reducidas al uso de diferentes componentes de una arquitectura definida. El desarrollo se abstrae del protocolo o la topología de la Red. El mundo de las “Telecos” queda accesible a una enorme cantidad de desarrolladores “expertos” con su correspondientes herramientas y buenas prácticas. Posibilidad de desarrollar servicios de Telecomunicaciones que abarcasen multiples tecnologías y protocolos de Red.
  • 1 SBB puede tener n instancias, la persistencia de cada una de esas instancias se llama SBB Entity. El SBB Object es el objeto Java sobre el que se “cachea” una SBB Entity.
  • PARA LOS MÉTODOS MIRAR EL STANDAR An SBB object can be in one of the following three states - Does Not Exist state. The SBB object does not exist. It may not have been created or it may have been deleted. - Pooled state. The SBB object exists but is not assigned to any particular SBB entity. - Ready state. The SBB object in the Ready state is assigned to an SBB entity. It is ready to receive events through its event handler methods, local method invocations, and various callback method invocations.
  • Incluida la NULL Activity! El Activity Object y la Activity son controlados por el recurso El Activity Context y el ACI son propiedad del SLEE
  • Un Profile es una fila de una ProfileTable

Development.in.Jain.Slee.(May.2009) Development.in.Jain.Slee.(May.2009) Presentation Transcript

  • Joaquín Ruiz Rojas Introducción a JAIN SLEE
  • Índice
    • 1. ¿Qué es JAIN SLEE?
        • ¿Por qué surge?
        • Beneficios
        • SLEE Vs. J2EE
    • 2. Arquitectura.
    • 3. Componentes.
    • 4. Plataformas:
        • OpenCloud
        • RhinoJnetX N(x)
        • Mobicents
    • 5. Conclusiones
  • ¿Quién soy yo? y qué esperar de esta charla…
    • Ing. Sup. en Informática con un año y medio trabajando en desarrollos de software en ALTRAN
    • Mi experiencia en JAIN SLEE:
      • Julio 2008 : Developing Services for Open Cloud Rhino
      • Diciembre 2008: Curso obligatorio para el desarrollo en JNetX
      • Ofertas para servicios simples como ICW o Calling Cards.
    • No he trabajado con ello
    • Mi mundo es el software, no las telecomunicaciones
    • No soy ni experto ni Gurú, aunque si… ALTSLEE
    • Esta charla es un resumen de lo que he podido aprender en estos cursos y ofertas, y que no es más que una introducción a la tecnología JAIN SLEE desde el punto de vista del desarrollador.
  • ¿Qué es JAIN SLEE?
    • JAIN = J avaTM A PIs for I ntegrated N etworks (API de Java para redes IN)
    • SLEE = S ervice L ogic E xcution E nviroment (Entorno para ejecución de la Lógica de Servicios)
    • En la práctica, JSLEE especifica un entorno de ejecución asíncrono en el que los sistemas de telecomunicaciones se pueden modelar como máquinas de estados finitos conectados a sistemas externos señalizados por protocolos asíncronos.
    • Especificaciones JSR 22 y JSR 240. Actualmente versión 1.1 Final Release.
  • ¿Por qué surge?
    • En el mundo de la Telecomunicaciones nos encontrábamos con la siguiente situación:
      • Multitud de redes de comunicaciones con sus nodos y demás componentes físicos:
        • Redes 2G y 2.5G
        • Redes 3G
        • Redes convergentes
      • Múltiples protocolos:
        • INAP, CAP, AIN, WIN, MAP, SIP, ISUP, OAM, MGCP
      • Cualquier desarrollo era dependiente del “Vendor” o propietario de los nodos o elementos físicos de la Red de Telecomunicaciones. Esto era MUY caro
  • Beneficios
    • Es un estándar :
      • Hay una comunidad de desarrolladores colaborando para la definición de un API estándar
      • Al ser un API, la implementación de la misma es libre
    • Es reusable :
      • La portabilidad de JAVA (write-once, run-anywhere) permite que el desarrollo de cualquier servicio sea global.
      • Al ser una Arquitectura Orientada a Objetos
    • Es independiente de la Red :
      • El desarrollo basado en un modelo de componentes es independiente de cualquier protocolo de red, API o topología
      • Permite la integración de cualquier tecnología de red
    • Permite la implementación de Servicios Convergentes :
      • Los Servicios pueden combinar múltiples tecnologías de red y recursos variados, lo que permite una gran cantidad de oportunidades de Negocio
      • Permite invocaciones sincronas de otros servicios o componentes
  • Beneficios
    • Permite desarrollos globales .
      • Un servicio implementado aquí es perfectamente adaptable a cualquier otro Operador o País
    • Robusto :
      • Es fuertemente tipado por lo que reducen errores de programación
      • El SLEE gestiona la “sesión” o “llamada” asociada al estado de la aplicación
    • Fiable :
      • Al basarse en un modelo de transacciones.
        • Posee un modelo de respuesta a fallos bien definido
        • Integrado con aplicaciones tanto síncronas como asíncronas
    • Escalable :
      • Gracias a su configuración en Cluster (frente a la clásica de primaria-secundarias)
    • Facilidad en su operación y mantenimiento :
      • Interfaces JMX que permiten su control, configuración y provisionamiento
  • Algunos Servicios
    • Push To Talk
    • Audio/Video Conferencia
    • Mensajes Multimedia
    • Mensajería instantánea (IM)
    • Servicios Prepago
    • Servicio de “Tono de espera”
    • Compartir contenidos
    • Servicios de conferencia multimedia (Multi-party calls, instant conferencing)
    • Click to Call
    • VPN
    • Reconocimiento de Voz
    • Calls Centers distribuidos
    • Control inteligente de llamada (call forwarding, web based calls logs) – integrando directorios corporativos
    • IP PBX
    • Convergencia sobre servicios wireless (usando SS7 y SIP internetworking) como 900, LNP,…
    • Envío de SMS/MMS
    • Oficina Móvil
    • IP Centrex
    • Multi SIM
    • Push-to-X Applications (emails, pictures, contacts, locations, and other information to compatible phones)
    • Roaming
    • etc
  • 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
  • Arquitectura
    • Arquitectura definida en Subsistemas
  • Arquitectura
  • Modelo de Componentes & Conceptos
    • SBBs (Service Buildings Blocks)
      • SBB Entity
      • SBB Object
    • RAs (Resource Adaptors)
    • Eventos SLEE
    • Activity
      • AC (Activity Context)
      • ACI (Activity Context Interface)
    • Profiles
    • Servicio
  • Service Buildings Blocks (SBB)
    • Son los componentes esenciales de la arquitectura del SLEE. Un servicio contiene una o más instancias de diferentes SBBs. Un SBB se puede reutilizar en múltiples servicios, aunque un solo SBB sólo puede procesar un evento a la vez, varios SBBs si pueden procesar eventos en paralelo dentro de un mismo servicio.
    • Contienen la lógica del servicio, ya que tienen definidas las acciones para los diferentes eventos que se reciben.
    • El contenedor SLEE se encarga de controlar su ciclo de vida y de configurar su entorno de ejecución.
    • En el se definen:
      • Los eventos recibidos y generados por el componente SBB, así como las acciones que se ejecutan en la recepción de cada uno de ellos.
      • La persistencia del estado en que se encuentra se almacena en el CMP (Container Managed Persistent)
      • Interfaz Local. Define el conjunto de operaciones del componente SBB que pueden ser invocadas de forma síncrona.
      • Relaciones Hijo. Un SBB puede tener cero o más SBBs hijos.
    • Su interfaz se encuentra definido en la especificación del SLEE ( javax.slee.Sbb )
    • Son como EJBs pero con la diferencia de que se encuentran subscritos (“attached”) a una actividad dinámica (Activity Context).
  • Service Buildings Blocks (SBB)
    • SBB Entity :
      • Instancia lógica de un componente SBB. Es una entidad lógica que representa el estado persistente de una instancia determinada del SBB
      • A grandes rasgos hay una SBB Entity por cada instancia de un servicio
      • Es el estado persistente de cada instancia del SBB según se define en los campos del CMP de la clase (abstracta) del SBB del componente.
      • Mantiene las relaciones con las otras entidades padre e hijo (SBB entity tree)
      • Es la entidad que se encuentra “subscrita” a la Activity Context
    • SBB Object :
      • Es la instancia de una clase SBB
      • Es un objeto Java sobre el que se “cachea” una SBB Entity
      • Cada Host del Cluster tiene un pool de estos objetos, esperando a “cachear” el estado de una SBB Entity, por lo tanto, esta asociado a una JVM concreta.
      • Puede “cachear” diferentes SBB Entities a lo largo de su ciclo de vida
  • Ciclo de Vida SBB Object
    • Al ser un objeto Java consta de un ciclo de vida:
    NO EXISTE El Objeto aún no se ha creado o ha sido destruido. POOLED Se ha creado el objeto pero aún no se le ha asignado ninguna SBB Entity. READY El Objeto se encuentra asignado a una SBB Entity. Ahora está preparado para recibir eventos gracias a que dispone los métodos para manipularlos
  • Resource Adaptors
    • Es la representación que tiene el SLEE de un recurso externo, tales como elementos de Red (HLR, MSC, etc), pilas de protocolos, directorios y BBDD
    • Su función es adaptar mediante una API cualquier recurso para su uso por parte del SLEE
    • Envían y reciben eventos, interactuando con los SBBs en ambas direcciones (un SBB invoca un método de la API del RA y el RA lanza – fire – eventos que serán tratados en los métodos definidos para tal tipo de evento en los SBBs)
    • Los eventos que puede lanzar un RA se definen en su DD (Deployment Descriptor)
    RA TYPE Es la API que define los métodos que pueden ser invocados desde el servicio. Define los eventos y los Activity Objects Los servicios dependen del RA Type y no de la implementación del mismo -> Portabilidad
  • Eventos
    • SLEE diferencia los Eventos según los tipos de Eventos (request, response, error, etc) Ej:
      • En JAIN SIP los eventos se clasifican según RequestEvents, ResponseEvents y TimeoutsEvents. Cada una de estas categorías incluye numerosos “tipos de eventos” como por ejemplo la Request del tipo INVITE (javax.sip.message.Request.INVITE)
    • Se representa como un objeto Java, en dónde se encapsula la información necesaria
    • Se procesan en los métodos “Event Handler” de cada SBB (un método sólo procesa un evento)
    • Todos los eventos se distribuyen dentro de un canal denominado “Activity”
  • Activity & Activity Object
    • Un flujo de eventos relacionados se representa como una Actividad .
    • La representación en el SLEE de una actividad es la Activity Context Interface (ACI) . Representa el canal dinámico en que se produce un intercambio de eventos (es lo más parecido a la sesión de HTTP).
    ACTIVITY Entidad lógica en la que se produce un intercambio de eventos (de uno en uno) entre un recurso y un SBB. Desde el punto de vista del recurso representa la máquina de estados sobre la que se emiten los mensajes o eventos que definen las diferentes transiciones entre los estados del recurso ACTIVITY OBJECT Es la representación Java de la actividad en el recurso (es como el Objeto del recurso) Suministra la API del recurso que posteriormente será invocada desde el SBB En el SLEE se define una Activity Context para proveer un acceso al Activity Object, de este modo, el SLEE no tiene visibilidad sobre él (sólo el recurso).
  • 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
  • Relación entre SBB y Activities
    • Las Activities representan “cosas” que son externas al SLEE
    • Un Activity Object es la representación Java de una Activity (Rel. 1 a 1)
    • Una Activity Context es la representación de una Activity en el SLEE (Rel. 1 a 1)
    • Los SBBs se subscriben (“attachan”) a los Activities Contexts (Rel. 0..n a 0..n)
  • Profiles
    • Contiene los datos provisionados a los SBBs para la ejecución de su lógica.
    • Son de lectura /escritura y se precargan en la memoria de la JVM al arrancar el SLEE. Son globales a todo el SLEE.
    • Se organizan como esquemas de atributos – valor (Ej: un número de teléfono o un email serían dos atributos de un Profile)
    • Cada Profile dispone un “Profile Specification” en donde se define el interfaz para modificarlo.
    • Se pueden definir en el despliegue (DD) o desde la consola de administración, en dónde se pueden modificar “en caliente”
    • Se identifican con un ProfileID (#{ProfileTableName, ProfileName})
    • Se acceden obligatoriamente a través del CMP (Ej: getVPNProfile(ProfileID id))
    • La “Profile Facility” proporciona los métodos para su uso (Ej: getProfileByIndexedAtributte, getProfiles(),..)
  • CMP (Container Managed Persistent)
    • Son un conjunto de atributos o campos que se definen en un SBB para que almacene/acceda a ciertos datos persistentes durante su ejecución
    • Los “ CMP fields ” pueden almacenar:
      • Cualquier tipo de objeto serializable (java.io.Serializable) [1.0]
      • Tipos primitivos de Java [1.0]
      • El interfaz local de los SBBs (javax.slee.SbbLocalObject) [1.0]
      • ACI y derivados (javax.slee.ActivityContextInterface) [1.1]
      • Event Context interfaces (javax.slee.EventContext) [1.1]
      • Profile Local interfaces (javax.slee.profile.ProfileLocalObject) [1.1]
    • Estos atributos son accesibles desde los SBBs a través de los métodos abstractos “getter” y “setter” que se deben definir para cada campo y que son implementados en tiempo de despliegue, es decir, no se encuentran implementados hasta que se levanta la primera instancia del SBB.
    • La persistencia de los datos almacenados en el CMP es tolerante a fallos
  • Facilities
    • La especificación del SLEE define una serie de funcionalidades para gestionar de forma eficiente el uso de la aplicación, sus servicios, flujo de eventos y recursos. Además de ayudar a medir el rendimiento de la plataforma y su estado (alarmas, estadísticas, logs, etc)
    TRACE FACILITY Es la herramienta que utilizan los servicios para generar LOGS. Es igual que el log4j (que es lo que usa internamente). Permite diferentes niveles de traza (ERROR, INFO, FINEST,…) import javax.slee.Sbb; import javax.slee.SbbContext; import javax.slee.facilities.Tracer; public abstract class MySbb implements Sbb { private Tracer tracer; private SbbContext context; public void setSbbContext(SbbContext context) { this .context = context; this .tracer = context.getTracer( "MySbb" ); } ... // Generate an INFO trace tracer.info( "An event has occurred" ); ...
  • 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
  • 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
  • Facilities : JNDI Names
    • Dentro del contexto: “ java:comp/env ”
  • Facilities (Código)
    • public void setSbbContext(SbbContext context) {
    • this .context = context;
    • try {
    • sbbEnv = ( Context ) new InitialContext ().lookup( "java:comp/env" );
    • id = context.getSbb();
    • timerFacility = (TimerFacility) sbbEnv.lookup( "slee/facilities/timer" );
    • ACNFacility = ( ActivityContextNamingFacility )sbbEnv.lookup ( " slee/facilities/activitycontextnaming " );
    • profileFacility = (ProfileFacility) sbbEnv.lookup(" slee/facilities/profile ");
    • alarmFacility = (AlarmFacility) sbbEnv.lookup( "slee/facilities/alarm" );
    • nullACIFactory = (NullActivityContextInterfaceFactory)sbbEnv.lookup( "slee/nullactivity/activitycontextinterfacefactory" );
    • nullActivityFactory = (NullActivityFactory)sbbEnv.lookup( "slee/nullactivity/factory" );
    • fp = ( SipFactoryProvider ) sbbEnv.lookup( "slee/resources/jainsip/1.1/provider" );
    • provider = fp.getSipProvider();
    • addressFactory = fp.getAddressFactory();
    • headerFactory = fp.getHeaderFactory();
    • messageFactory = fp.getMessageFactory();
    • } catch ( NamingException ne) {
    • System .out.println( "Could not set SBB context: " + ne.toString());
    • }
    • }
  • Estadísticas de Uso
    • Un estadística de uso es un parámetro que puede ser modificado por cualquier objeto del SLEE para suministrar al Administrador, a través de la consola de administración del sistema, información sobre el funcionamiento del mismo.
    • Hay 2 tipos:
      • Contadores: únicamente se pueden incrementar y decrementar
      • “ Samples”: almacenan valores numéricos sobre los que pueden obtener a posteriori sus valores máximos, mínimos, medias…
    • Ejemplos:
      • public interface FooSbbUsageParameters {
      • // counter-type usage parameter names
      • public void incrementFirstCount(long value);
      • public void incrementSecondCount(long value);
      • // sample-type usage parameter names
      • public void sampleTimeBetweenNewConnections(long value);
      • public void sampleTimeBetweenErrors(long value);
      • }
    • Los Profiles y RAs poseen sus propios interfaces para gestionar sus estadísticas de uso.
  • ¿Qué es un Servicio?
    • Un servicio es un conjunto de SBBs (como su propio nombre indica)
    • La instancia de un servicio puede incluir una o más instancias de SBBs de diferentes tipos. Un servicio es un grafo acíclico de SBBs
    • Se define a partir de un “ Initial Event ” que arranca un SBB root.
    • “ SBB root ” es el único SBB padre, todos los demás SBBs que arranquen su ejecución serán SBBs hijos del “SBB root”
    • La comunicación entre los diferentes SBBs puede ser de 2 modos:
      • Síncrona : A través del SbbLocalObject del otro SBB, ya que posee los métodos que puede ejecutar
      • Asíncrona : Lanzando eventos a través del SLEE
  • Funcionamiento (Síncrono)
    • La invocación de un SBB padre sobre un hijo es SINCRONA
    • Veamos un ejemplo:
      • El RA lanza un evento, que indica el estado de algún recurso externo.
      • El evento es recibido por el SLEE que lo procesa en aquellos SBBs que tengan definido dicho evento como “initial event”. Cada uno de estos SBBs es un “root SBB” del servicio en el cual han sido desplegados. El SLEE arranca una instancia para cada SBB y los “attacha” a la ACI del evento. Esto se produce en los “event handler” de cada SBB.
      • El SBB padre va creando los diferentes SBBs hijo que necesita y obteniendo su interfaz local (Ej: EchoChildLocalInterface aChild = (EchoChildLocalInterface) getEchoChildSbbRelation().create();)
      • El SBB padre “attacha” al SBB hijo a la ACI y procede a “des-attacharse” de la misma. Anteriormente transfiere toda la información que necesite al hijo
      • El SBB ha terminado su función y al no estar “attachado” a ninguna actividad, su ejecución ha finalizado y se puede eliminar su SBB Entity.
  • Funcionamiento (Asíncrono)
    • La invocación de un SBB sobre otro, que no sea hijo, es ASINCRONA
    • Veamos un ejemplo:
      • El RA lanza un evento, que indica el estado de algún recurso externo.
      • El evento es recibido por el SLEE que lo procesa en aquellos SBBs que tengan definido dicho evento como “initial event”. Cada uno de estos SBBs es un “root SBB” del servicio en el cual han sido desplegados. El SLEE arranca una instancia para cada SBB y los “attacha” a la ACI del evento. Esto se produce en los “event handler” de cada SBB.
      • El root SBB va lanzando los eventos que tenga definidos en su lógica al SLEE
      • El SLEE recibe los eventos y los envía a los SBBs que tengan definido ese evento como “initial event”
      • El root SBB ha terminado su función y si no está “attachado” a ninguna actividad, su ejecución ha finalizado y se puede eliminar su SBB Entity.
  • Vendor - OpenCloud
    • OpenCloud es una empresa de Nueva Zelanda creada en el año 2000
    • Es la mejor plataforma de JAIN SLEE, además de ser los únicos “fully compliant” con las versión 1.1 (de echo participan activamente en el desarrollo del estándar con SUN)
    • Poseen el mayor portal con información referente a JSLEE: OpenCloud Dev Portal! https :// developer.opencloud.com
    • Su desarrollo se basa en el estándar con pequeños “matices”
    • La FSM Tool persigue el desarrollo de aplicaciones de JSLEE a partir de la especificación de su máquina de estados finitos con un DSL (domain specific lenguaje)
  • Plataforma - Rhino OpenCloud
    • Punto fuerte: robusta configuración en cluster
    • Punto débil:
      • consola de administración visual poco desarrollada (hay una por comandos)
      • catálogo de aplicaciones bastante limitado
      • Pruebas basadas en scripts muy tediosos
    • Los elementos más característicos de su Rhino Core Platform son:
    • Rhino Service Interaction Layer – Proporciona un entorno para la composición, orquestación e interacción de los servicios existentes, tanto dentro del propio Rhino, como los servicios que se puedan encontrar alojados en un servidor de aplicaciones tradicional o un IN SCP (Service Control Point)
    • S avanna Carrier-grade framework – Es el elemento que proporciona la escalabilidad y los 5 9´s de disponibilidad de la plataforma. Es el responsable del fail-over de la plataforma y los servicios, de la actualización on-line, además de controlar el clustering, la gestión de la memoria distribuida, etc.
  • Vendor – JNetX N(x)
    • Empresa americana (desarrollo ruso) creada en 2001, con mas de 175 empleados localizados en unas 6 sedes
    • Líder del mercado en el desarrollo de servicios basados en estándares de telecomunicaciones
    • Partner de las empresas más importantes del sector IT. Tiene implantados servicios en la mayoría de los grandes operadores globales.
    • Aporta un gran catalogo de aplicaciones (+100) agrupadas en su DNA (Developers Network Area)
  • Plataformas – JNetX N(x)
    • Puntos fuertes:
      • Entorno de desarrollo, ejecución y pruebas totalmente integrado en su TSS
      • Pruebas más rápidas y visuales
      • Consola de administración mas completa
    • Puntos débiles:
      • El código generado no es comprensible
      • Dependencia absoluta del TSS
      • Orientado a un desarrollo más “teleco”
  • Plataformas – Mobicents JAIN SLEE
    • Es la solución OpenSource que cuenta con el respaldo de RedHat
    • Básicamente su plataforma es un JBoss “dopado” para trabajar en clustering
    • Actualmente sólo son certificados en SLEE 1.0
    • Posee gran cantidad de código y ejemplos, especialmente para SIP (SIP Servlets y SIP Presence Service)
    • Posee una comunidad de desarrolladores bastante amplia y organizada ( http://groups.google.com/group/mobicents-public )
    • Implementaron el EclipSLEE ( http:// mobicents - public.googlegroups.com / web / EclipSLEEDemo.html )
  • Conclusiones
    • Hay que trabajar con ello
    • Aún no hay conocimiento experto (y menos en castellano)
    • Este tipo de plataformas están empezando a adoptar todo tipo de arquitecturas (SIP Servlets, Servicios Web,…)
    • Hace falta un conocimiento muy fuerte en protocolos para el desarrollo de cualquier servicio. IMS ayuda con su simplicidad.
    • El desarrollo es básicamente usar APIs propietarias, las de los RAs, por lo que aún no es posible un desarrollo independiente de la plataforma a pesar del esfuerzo de la versión 1.1 por conseguirlo
    • No es el futuro, que es IMS, pero sí el presente
  • www.altran.es