Confidentiel

Joaquín Ruiz Rojas

Introducción a JAIN SLEE

Confidentiel04/10/20062

Í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

Confidentiel04/10/20063

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

Confidentiel04/10/20064

¿Qué es JAIN SLEE?

JAIN = JavaTM APIs for Integrated Networks (API de Java para redes IN)

SLEE = Service Logic Excution Enviroment (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.

Confidentiel04/10/20065

¿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

Confidentiel04/10/20066

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

Confidentiel04/10/20067

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

Confidentiel04/10/20068

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

Confidentiel04/10/20069

SLEE Vs. J2EE

Son tecnologías totalmente complementarias.Otras consideraciones

CentralizadoDistribuidoDespliegue

-Casi tiempo realTiempo Real

De 2 a 3 nuevesDe 3 a 5 nuevesDisponibilidad

Intensiva durante los accesos a BDSó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

J2EEJSLEE

Confidentiel04/10/200610

Arquitectura

Arquitectura definida en Subsistemas

Confidentiel04/10/200611

Arquitectura

Contenedor JAIN SLEE

Timer Facility

Alarm Facility

Trace Facility

AC Naming Facility

Profile Facility

Usage Facility

Servicio

Servicio

Servicio

Resource Adaptor Resource Adaptor Resource Adaptor

Servicios de Operación y Mantenimiento del SLEE

Agente JMX

Profile

Profile

INAP CAP SMPP MM7 AIN WIN MAP SIP ISUP OAM MGCP HTTP Parlay/OSA Web Services SQL JCC

Confidentiel04/10/200612

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

Confidentiel04/10/200613

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).

Confidentiel04/10/200614

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

Confidentiel04/10/200615

Ciclo de Vida SBB Object

NO EXISTE

El Objeto aún no s e ha creado o ha .s ido des truido

POOLED

Se ha creado e l objeto pero aún no s e .le ha as ignado ninguna SBB Entity

READY

El Objeto s e encuentra as ignado a . una SBB Entity Ahora es tá

preparado para rec ibir eventos grac ias a que dis pone los métodos

para manipularlos

Al ser un objeto Java consta de un ciclo de vida:

Confidentiel04/10/200616

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 s er invocados des de

.e l s ervic io

Define los eventos y los ActivityObjects

Los s ervic ios dependen del RA Type y no de la implementac ión

del mismo → Portabilidad

Confidentiel04/10/200617

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”

Confidentiel04/10/200618

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 s e produce un ( ) intercambio de eventos de uno en uno

.entre un recurs o y un SBB

Des de e l punto de vis ta de l recurs o repres enta la máquina de es tados s obre

la que s e emiten los mens ajes o eventos que definen las diferentes trans ic iones

entre los es tados de l recurs o

ACTIVITY OBJECT

( )Es la repres entac ión Java de la actividad en e l recurs o es como el Objeto de l recurs o

Suminis tra la API del recurs o que pos teriormente s erá invocada des de e l SBB

, En e l SLEE s e define una Activity Context para proveer un acces o al Activity Object de es te, ( ).modo el SLEE no tiene vis ibilidad s obre é l s ólo e l recurs o

Confidentiel04/10/200619

Activity Context & ACI

( )ACTIVITY CONTEXT INTERFACE ACI

( ) , Es la vis ión Objeto que tiene e l SBB del Activity Context grac ias al cuál los SBBs pueden leer y es cribir s u es tado en e l mismo

, Determina qué eventos van a cada SBB dado que los SBBs s ólo recogen eventos de s us , ( ) .corres pondientes actividades que dando “s ubs critos ” attachados a la misma

Es creada y e liminada en tiempo de ejecuc ión y puede afectar al c ic lo de vida de nues tro, - s ervic io ya que un SBB no es des truido has ta que no s e encuentra “des attachado” de todas

.s us actividades

.Un SBB puede generar una ACI nueva grac ias a la ACIFactory que le ofrece e l RA

ACTIVITY CONTEXT

( ) Es la entidad lógica s in API que repres enta y encaps ula al Activity Object en e l SLEE

Contiene atributos que permiten compartir información entre los SBBs de un mismo componente

Confidentiel04/10/200620

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)

Confidentiel04/10/200621

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(),..)

Confidentiel04/10/200622

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

Confidentiel04/10/200623

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

. 4 ( Es la herramienta que utilizan los s ervic ios para generar LOGS Es igual que e l log j que ). ( , , ,es lo que us a internamente Permite diferentes nive les 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");...

Confidentiel04/10/200624

Facilities

TIMER FACILITY

Es ta func ionalidad permite programar acc iones periódicamente o inic iar acc iones tras un tiempo .previamente definido

La “Timer Facility” controla un número determinado de timers totalmente independientes entre. 0 .s í Cada Timer puede lanzar ó n eventos tras s u venc imiento

PROFILE FACILITY

( )Es la func ionalidad que da acces o a las Profile Tables por lo tanto a los datos provis ionados

public ProfileTableActivity getProfileTableActivity(String profileTableName)public ProfileTable getProfileTable(String profileTableName)

[1.1]SERVICE LOOKUP FACILITY

Es ta func ionalidad permite a los Res ource Adaptors obtener información s obre los eventos que puede rec ibir un s ervic io ins talado en e l SLEE

Confidentiel04/10/200625

Facilities

[1.1]EVENT LOOKUP FACILITY

Es ta func ionalidad permite a los RA obtener información s obre los tipos de eventos( ) FireableEventType que s e encuentran ins talados en e l SLEE

Se puede us ar para convertir los eventos de l SLEE en “FireableEventType objects ” que s on los que us a e l RA para lanzar eventos des de o hac ia cualquier “End Point”

ALARMFACILITY

, , Es ta func ionalidad permite a SBBs RAs y Profiles activar o limpiar alarmas en e l SLEE

Las notificac iones de las alarmas que s e lancen generarán s u corres pondiente notificac ión en ( )e l AlarmMBean acces ible des de la cons ola de adminis trac ión

( )Cada alarma pos ee un identificador y un nive l de critic idad AlarmLevel

ACTIVITY CONTEXT NAMING FACILITY

La Activity Context Naming Facility fac ilita la etiquetac ión mediante un nombre de los Activity.Contexts

, Permite a un SBB object as ignar un nombre a un Activity Context para que otros SBBs objects .puedan bus car y acceder a dicha Activity

Un Activity Context puede tener cero o más nombres

Confidentiel04/10/200626

Facilities : JNDI Names

Dentro del contexto: “java:comp/env”

Confidentiel04/10/200627

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());

}}

Confidentiel04/10/200628

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 namespublic void incrementFirstCount(long value);public void incrementSecondCount(long value);// sample-type usage parameter namespublic void sampleTimeBetweenNewConnections(long value);public void sampleTimeBetweenErrors(long value);

}

Los Profiles y RAs poseen sus propios interfaces para gestionar sus estadísticas de uso.

Confidentiel04/10/200629

¿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

Confidentiel04/10/200630

Funcionamiento (Síncrono)

La invocación de un SBB padre sobre un hijo es SINCRONA

Veamos un ejemplo:1. El RA lanza un evento, que indica el estado de algún recurso externo.2. 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.

3. El SBB padre va creando los diferentes SBBs hijo que necesita y obteniendo su interfaz local (Ej: EchoChildLocalInterface aChild = (EchoChildLocalInterface) getEchoChildSbbRelation().create();)

4. 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

5. 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.

Confidentiel04/10/200631

Funcionamiento (Asíncrono)

La invocación de un SBB sobre otro, que no sea hijo, es ASINCRONA

Veamos un ejemplo:1. El RA lanza un evento, que indica el estado de algún recurso externo.2. 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.

3. El root SBB va lanzando los eventos que tenga definidos en su lógica al SLEE4. El SLEE recibe los eventos y los envía a los SBBs que tengan definido ese evento como

“initial event”5. 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.

Confidentiel04/10/200632

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)

Confidentiel04/10/200633

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:

o 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)

o Savanna 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.

Confidentiel04/10/200634

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)

Confidentiel04/10/200635

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”

Confidentiel04/10/200636

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)

Confidentiel04/10/200637

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

Confidentiel04/10/200638

www.altran.es