IMPLEMENTACIÓN DE SERVICIOS DE VALOR AGREGADO EN REDES ABIERTAS - JAIN

GERARDO ARISTIZÁBALNICOLÁS ACOSTA

UNIVERSIDAD DE LOS ANDESFACULTAD DE INGENIERIA

DEPARTAMENTO DE INGENIERIA DE SISTEMAS2005

IMPLEMENTACIÓN DE SERVICIOS DE VALOR AGREGADO EN REDES ABIERTAS - JAIN

GERARDO ARISTIZÁBALNICOLÁS ACOSTA

Tesis de grado para optar al título de Ingeniero de Sistemas

AsesorHarold Cruz

UNIVERSIDAD DE LOS ANDESFACULTAD DE INGENIERIA

DEPARTAMENTO DE INGENIERIA DE SISTEMAS2005

2

CONTENIDO

CONTENIDO.......................................................................................................3

LISTA DE TABLAS..............................................................................................4

LISTA DE FIGURAS...........................................................................................4

GLOSARIO..........................................................................................................5

RESUMEN..........................................................................................................7

INTRODUCCIÓN................................................................................................8

CAPÍTULO 1.....................................................................................................10

PROBLEMÁTICA DE LAS REDES CERRADAS..............................................10

CAPÍTULO 2.....................................................................................................14

INICIATIVAS DE REDES ABIERTAS...............................................................14

CAPÍTULO 3.....................................................................................................18

JAIN (JAVA APIS FOR INTEGRATED NETWORKS).......................................18

CAPÍTULO 4.....................................................................................................35

SOLUCIONES BASADAS EN JAIN.................................................................35

CONCLUSIONES..............................................................................................44

BIBLIOGRAFIA.................................................................................................48

3

LISTA DE TABLAS

Tabla 1..............................................................................................................29

LISTA DE FIGURAS

Ilustración 1............................................................................................................21

Ilustración 2............................................................................................................22

Ilustración 3............................................................................................................28

Ilustración 4………………………………………….…………………………………...43

4

GLOSARIO

API – Application Programming Interface – “Es un conjunto de especificaciones de comunicación entre componentes de software. (…) Uno de los principales propósitos de un API consiste en proporcionar una serie de funciones de uso general” 1

CBS - (Cell Broadcast Service) es un servicio para el envío de SMS a todos los móviles que se encuentran en una celda de servicio. Permite estrategias de comunicación masiva pero no ha tenido la acogida esperada por razones de privacidad y confidencialidad.

CLDC - (Connected Limited Device Configuration) es una configuración que define APIs y una máquina virtual Java para dispositivos limitados como teléfonos móviles, buscapersonas, y algunas PDAs.

Clustering - Clustering es una disposición de topología de infraestructura que divide la funcionalidad y la responsabilidad de las aplicaciones entre varios entes reduciendo así la posibilidad de fallos y el número de puntos críticos.

CONVERGENCIA – “La convergencia ha devenido prácticamente en un modelo conceptual del que se tienen informaciones desde fines de los años 70, cuando los japoneses utilizan la expresión para explicar los cambios operados a nivel de las industrias de la información / comunicación con la integración de la informática y las telecomunicaciones. (…) Posteriormente, con los desarrollos de la digitalización y la fibra óptica, el concepto convergencia es extendido a la comprensión de la interrelación telecomunicaciones – radiodifusión, especialmente la televisión.” [1]

LOCALIZACIÓN – Los servicios de localización permiten obtener información sobre la ubicación física de un teléfono móvil para implementar aplicaciones sensibles a la posición de un dispositivo.

OTA - (Over the air) es un término para referirse a la instalación y modificación del software de un dispositivo a través de la red móvil sin necesidad de tener acceso físico a éste.

PORTABILIDAD – Portabilidad de los servicios se refiere a la capacidad de utilizar una misma aplicación en diferentes infraestructuras, siendo transparente para la aplicación.

1 Tomado de http://es.wikipedia.org/wiki/API

5

SERVICIOS DE VALOR AGREGADO - Son aquellos que utilizan como soporte servicios básicos, telemáticos, de difusión o cualquier otra combinación de éstos y con ellos proporcionan la capacidad completa para el envío, o intercambio de información, agregando otras facilidades al servicio soporte o satisfaciendo necesidades específicas de telecomunicaciones.

SS7 – (Signaling System 7) Pila de protocolos utilizada para la comunicación entre recursos de una red de comunicaciones.

TCAP - (Transaction Capabilities Application Part) permite el desarrollo de servicios sobre un protocolo no orientado a conexión en SS7.

USSD - (Unstructured Supplementary Service Data) es un servicio de las redes GSM que a diferencia de SMS, realiza el intercambio de mensajes basado en una sesión ofreciendo nuevas y distintas posibilidades para el desarrollo de aplicaciones y servicios.

6

RESUMEN

JAIN (Java APIs for Integrated Networks) representa el papel que juega Java en las telecomunicaciones. Este papel hace parte de una iniciativa conjunta de los proveedores de tecnología por brindar una arquitectura de redes de comunicaciones abierta. A través de ésta se facilitará e impulsará el desarrollo de aplicaciones para estas redes y se generarán nuevos canales de ingresos para todos los participantes del mercado tecnológico. Esta iniciativa surge a raíz de la falta de oferta de aplicaciones de comunicaciones en el mercado debido a la deficiente interoperabilidad de las redes, la ausencia de portabilidad de servicios y al carácter propietario de los protocolos de utilización de recursos. La iniciativa es bastante nueva e inmadura en materia de desarrollo e implementaciones, pero los esfuerzos que se están realizando indican que tendrá una acogida muy importante en los años por venir.

7

INTRODUCCIÓN

El avance tecnológico y la tendencia constante a la convergencia de las diferentes redes portadoras de información, ha permitido utilizar las redes de telefonía móvil para implementar servicios de valor agregado de comunicaciones basados en Internet. El desarrollo de estos servicios ha sido posible gracias a la integración entre Internet y las redes móviles. Con esta integración se hace posible la utilización, control, y ejecución de aplicaciones que interactúan y aprovechan las capacidades de las redes móviles para proveer nuevos servicios que complementan el portafolio actual de comunicaciones del mercado.

La gran variedad de nuevos servicios como mensajería, transmisión de datos, provisión de contenidos, localización etc., el modelo de negocio del mercado en el que la interoperabilidad es vital, y las prioridades actuales de los operadores de telefonía que se encuentran representadas en el interés del aumento de su base de suscriptores, han agregado nuevos actores a la cadena de valor de los servicios tecnológicos. Entre estos actores se encuentran: los integradores, que buscan facilitar la interoperabilidad entre las redes; los proveedores de contenido, que comercializan en el mercado masivo tonos, imágenes, etc.; y los proveedores de servicios que desarrollan aplicaciones de valor agregado para diferentes sectores de la economía. Estos actores se han dedicado a suplir necesidades de los mercados corporativos y masivos, consolidando productos y servicios basados en las redes de telefonía móvil. La mensajería masiva a través de SMS (Short Message Service), MMS (Multimedia Message Service), etc. y la localización, hacen necesaria una estrecha relación con los operadores para la integración tecnológica que hace posible la prestación de los servicios.

La integración con las diferentes redes de los operadores de telefonía móvil se ha convertido en el cimiento para la prestación de los servicios de mensajería y de localización ya que es la que permite la utilización de la red. Sin embargo, la falta de estandarización de estas integraciones, la falta de regulación sobre el tema y la inmadurez del mercado de servicios de mensajería y localización, ha generado una problemática focalizada en tres frentes.

Falta de portabilidad de los servicios: los servicios no son portables ya que se manejan estándares diferentes de integración entre países y operadores.

Dependencia de la red: los servicios no son interoperables entre redes ya que cada una maneja diferentes tecnologías, servicios y modelos de integración.

Capacidad de desarrollo limitado por estándares y tecnologías cerradas: El desarrollo de la mayoría de estos servicios se reduce a la utilización de APIs propietarios no disponibles al público y utilizables sólo en componentes específicos de red.

8

Diferentes comunidades han hecho sus aportes de forma complementaria en busca de solucionar esta problemática y estandarizar los modelos de integración. Se busca lograr una portabilidad e interoperabilidad de los servicios en redes abiertas que fomente el desarrollo de servicios, hoy limitado por la problemática descrita anteriormente. Entre las propuestas se encuentran JAIN (iniciativa se Sun), PARLAY y la iniciativa del OMA (Open Mobile Alliance), que se han venido desarrollando en la medida en que los servicios de valor agregado y los modelos de integración de redes han cobrado importancia.

A medida que ha pasado el tiempo y que se ha consolidado el mercado de los servicios móviles se ha observado una evolución en la oferta de soluciones. Dentro de esta oferta, los servicios de SMS se encuentran consolidados en el mercado, y existen oportunidades de mercado emergentes como servicios de mensajería multimedia y de localización de dispositivos móviles. Los expertos coinciden en que estos servicios ganarán importancia con el tiempo y cobrarán una alta participación en los ingresos de los operadores de telefonía móvil. La proyección del mercado de servicios de localización y mensajería, y la evidencia completa de la problemática descrita anteriormente en estos servicios, los convierten en un escenario ideal para el estudio de la integración de redes en busca de un modelo de desarrollo abierto.

Esta investigación estudia el modelo propuesto por la iniciativa JAIN debido a la importancia de su integración con la plataforma de Java actual. Como componente práctico de la investigación se plantea un ejemplo de una implementación para un servicio de localización. A partir del estudio del modelo y de la información relacionada con el ejemplo se analiza la tecnología y la arquitectura propuesta por JAIN.

9

CAPÍTULO 1

PROBLEMÁTICA DE LAS REDES CERRADAS

“La coyuntura actual, marcada por la llegada de grandes jugadores internacionales, plantea una serie de nuevas exigencia a los operadores, especialmente los nacionales; en consecuencia se hace indispensable buscar alianzas estratégicas, optimizar los canales de distribución y el mismo uso de la infraestructura con el fin de prestar servicios de manera cada vez más eficiente y con más alto contenido en cuanto a las aplicaciones y la oferta de servicios.” [3] Esa búsqueda de alianzas estratégicas que permiten complementar los portafolios de servicios, ofertas y optimizar canales de distribución, exige una relación directa entre los operadores y sus aliados.

De forma paralela, el desarrollo tecnológico de los países se ha convertido en uno de los focos centrales de la construcción de su infraestructura. “Las telecomunicaciones suplen las necesidades de comunicación entre individuos, esencial para su convivencia social. En este sentido, a lo largo de la historia, los países que han invertido recursos en el desarrollo de infraestructura han alcanzado un aumento significativo del desarrollo económico y han potencializado el crecimiento de otros sectores económicos relacionados.”[4] Existe un gran potencial de desarrollo por delante, y las constantes innovaciones motivan la inversión en la adopción de ellas para actualizar y optimizar la infraestructura de comunicaciones de los países. “El mayor o menor grado de desarrollo de las comunicaciones marcará el futuro de las sociedades.” [1] Por lo tanto es de interés general trabajar en este desarrollo para soportar economías competitivas cada día más exigentes.

Las motivaciones descritas anteriormente han obligado a entes regulatorios, operadores, comunidades de investigación, asociaciones y agremiaciones de tecnología a buscar formas de incentivar el desarrollo de servicios para complementar su portafolio y fortalecer su cadena productiva. Estas motivaciones se han traducido en actividades como maratones y concursos de programación, planes de colaboración empresarial con aliados, programas de apoyo a proyectos académicos, etc. Sin embargo, y a pesar de los incentivos hacia desarrolladores de servicios y proveedores de contenido, existen grandes limitantes debido al modelo tecnológico sobre el que se basan las redes de comunicaciones cuando se debe interactuar con los componentes de red como en el caso de los servicios de localización y mensajería.

El problema de interconexión ha generado la necesidad de implementación de un modelo tecnológico de redes abiertas para proveer servicios como los de localización y mensajería de una manera efectiva. “Una de las motivaciones más

10

grandes para el desarrollo de interfaces abiertas entre redes de comunicaciones ha sido el deseo de nuevos crecimientos de negocios por parte de los operadores de las redes de comunicaciones.” [5] Actualmente el acceso tecnológico a la red y los protocolos para la utilización de sus servicios son determinados por los proveedores de infraestructura utilizados por los diferentes operadores de telefonía móvil. Este hecho genera tres problemas diferentes que se combinan para generar una problemática de acceso a la red determinada principalmente por falta de portabilidad de servicios, dependencia de la red y capacidad de desarrollo limitada por estándares cerrados:

Falta de portabilidad de los servicios:

El gran número de proveedores de infraestructura de red y la alta demanda de soluciones de infraestructura por parte de los operadores, han hecho que cada operador utilice la plataforma de un proveedor diferente para montar sus servicios. Adicionalmente, la alta oferta de plataformas ha generado una heterogeneidad de proveedores al interior de los operadores y en casos se observan diversos fabricantes que componen la infraestructura de red de un operador. “El desarrollo tecnológico está a limitado a especificaciones de interfaces propietarias. Esto incrementa el costo de desarrollo, el tiempo de implementación en mercados y los requerimientos de mantenimiento.” [10]

Cada empresa ha desarrollado sus modelos y protocolos de comunicación propietarios y cerrados debido a la falta de estandarización y al interés de las empresas privadas en mantener un control restrictivo sobre el acceso a sus plataformas. La diversidad de estos modelos de comunicación y protocolos hace que las soluciones implementadas para comunicarse con alguno de los componentes de red no sea portable a otros impidiendo así un desarrollo único, demorando los tiempos de implementación y de inserción en el mercado y consecuentemente reduciendo la posible oferta de servicios y soluciones basados en las redes de telefonía móvil.

Dependencia de la red:

Los sistemas móviles han evidenciado su mayor desarrollo desde finales del siglo XX. Las primeras tecnologías de transmisión eran incompatibles y saturaron su capacidad en de servicios de voz y datos. Este hecho llevó al desarrollo de GSM (Groupe Special Mobile), una unión europea con el objeto de desarrollar un estándar paneuropeo del servicio celular. Simultáneamente, en EEUU se desarrollaron los sistemas D-AMPS (posteriormente rebautizado como TDMA) y CDMA mientras que en Japón se implementaba el sistema PDC. Como es evidente, el desarrollo de las redes de comunicaciones se ha realizado de manera

11

independiente en diferentes lugares del mundo. Diferentes corrientes y comunidades han adoptado diferentes estándares que son utilizados en países y operadores a través del mundo.

En torno a esta diversidad de tecnologías y de adopción estándares, las redes son diferentes en sus servicios, capacidades e interfaces de integración. Por lo tanto, los servicios implementados en una red no son portables a otras. Adicionalmente la funcionalidad a través de las redes para los mismos servicios es distinta y presenta inconsistencias en implementaciones generales. Esto determina una dependencia directa de las redes limitando el desarrollo y por ende la oferta de servicios de valor agregado.

Capacidad de desarrollo limitado por estándares y tecnologías cerradas:

“La falta de una arquitectura abierta con interfaces públicas y estandarizadas que permitan interfaces con soluciones propietarias, previene que las soluciones existentes escalen fácilmente a un entorno global.” [6] En el mundo de las redes de comunicaciones los fabricantes mantienen de forma propietaria y privada sus protocolos y estándares de integración. Actualmente los servicios de valor agregado se encuentran limitados debido a la alta dependencia de la tecnología provista por el fabricante para la implementación de éstos. Cada operador de comunicaciones tiene diferentes proveedores de plataforma que a su vez realizan implementaciones propietarias de sus servicios para la utilización de las capacidades de la red. La falta de entes reguladores, y la ambición de los proveedores de tecnología de abarcar tanto mercado como sea posible, ha hecho que desarrollen protocolos de comunicación propietarios.

El desarrollo de servicios sobre redes cerradas es en el mejor de los casos costoso. El deseo de incentivar el desarrollo de servicios y aplicaciones encuentra en los estándares tecnológicos propietarios uno de sus más grandes limitantes. La oferta de servicios y aplicaciones actual es bastante reducida. En algunos casos es muy difícil conseguir recursos y herramientas para desarrollar servicios utilizando los componentes de las redes y en otros imposible.

El servicio de localización evidencia todos los factores de la problemática descrita anteriormente. Existen diferentes estándares utilizados por diferentes fabricantes, y el modelo tecnológico de los servicios de localización hace necesaria la interacción a bajo nivel con los diferentes componentes de red de los operadores. El desarrollo e implementación de un servicio masivo, integrado, y unificado de localización que sea sostenible desde el punto de vista tecnológico y comercial es inviable debido a la problemática de redes cerradas.

12

“Muchos acercamientos para proveer interfaces de redes abiertas se encuentran en desarrollo.” [5] Aunque los esfuerzos han hecho lo posible por mantener las diferentes iniciativas como modelos complementarios, se deben establecer protocolos y estándares de comunicación entre las diferentes alternativas como por ejemplo JAIN, PARLAY y la iniciativa de OMA. Estos acercamientos presentan otro reto y por lo tanto otra problemática que debe ser atendida por las comunidades que estudian las redes abiertas.

13

CAPÍTULO 2

INICIATIVAS DE REDES ABIERTAS

Como respuesta a la problemática de redes cerradas, diversas comunidades han trabajado en desarrollar un modelo que permita explotar el potencial de la convergencia entre las redes, y dé paso a la proliferación de servicios que utilicen la funcionalidad de las redes de comunicaciones. Las iniciativas de redes abiertas buscan facilitar la adopción global de los servicios de transmisión de datos a través de redes de telefonía móvil y de comunicaciones en general. Esta adopción se logrará gracias al desarrollo de nuevos servicios y a la migración de los actuales a arquitecturas abiertas a través de interfaces públicas con las redes de comunicación. La consolidación de las arquitecturas de redes abiertas le dará un dinamismo a los servicios basados en las redes de comunicaciones que incentivará una competencia entre negocios basada en la diferenciación e innovación. De la mano de la convergencia, el mercado de servicios y de posibilidades aumentará demandando una oferta mucho mayor a la actual. “La convergencia legitima y actualiza procesos de transculturización y concentración de las comunicaciones de manos privadas.” [1]

Los objetivos generales de las arquitecturas de redes abiertas se relacionan directamente con la problemática descrita anteriormente y tratan cada uno de sus puntos clave buscando a través de sus implementaciones:

- Portabilidad de servicios – Permitir la implementación de los diferentes servicios independientemente de la tecnología de comunicación que se encuentre implementada en las redes.

- Independencia de la red – Permitir la implementación de los diferentes servicios independientemente de la red de comunicación que soporte el servicio.

- Estándares y protocolos abiertos para el desarrollo e implementación de servicios – Iniciar la proliferación de nuevos servicios que permitan incrementar los ingresos de los actores involucrados en la cadena productiva.

“Se cree que proveyendo interfaces de redes abiertas a la funcionalidad “core” de las redes, permitiendo con esto acceso a la tecnología, se iniciará una proliferación de nuevos servicios que pueden ser ofrecidos por los operadores de las redes de comunicación abriendo muchos canales de ingresos.” [5] Un breve

14

adelanto ejemplar de estar proliferación es el desarrollo del servicio del valor agregado SMS, que al encontrar un mercado de comercialización de contenidos y servicios de interactividad hizo necesario la inclusión de integradores que lo han comercializado y explotado. El mercado de los nuevos servicios impulsará a los operadores a buscar aliados para la prestación de servicios y a facilitarles el desarrollo de servicios a través de interfaces y protocolos abiertos.

Todos los objetivos descritos anteriormente se buscan alcanzar mediante la implementación de interfaces públicas con las redes de telecomunicaciones. Existen varias iniciativas para definir los estándares de redes abiertas que permitirán el desarrollo de estas interfaces y ya se están realizando pilotos y pruebas. Las tres más populares son las desarrolladas por SUN, OSA y OMA.

SUN – JAIN (Java APIs for Integrated Networks2)

Define estándares para la implementación de APIs de Java que se involucran con todos los aspectos de las redes de comunicaciones. Consiste de los APIs y de los contenedores que alojan las aplicaciones desarrolladas utilizando los APIs.

Java Application Interfaces for communications - Interfaces de aplicación de Java para las comunicaciones. Estos APIs permiten tanto a integradores, proveedores de contenido y desarrolladores de servicios como a operadores de redes de comunicación el desarrollo sobre una o más plataformas Java.

Java Container Interfaces for communications – Interfaces de contenedores de java para las comunicaciones encargadas de alojar componentes que utilizan las interfaces de aplicación descritas arriba. Estos APIs permiten que las aplicaciones desarrolladas tanto por integradores, proveedores de contenido y desarrolladores de servicios como por operadores de redes de comunicación se ejecuten en una forma controlada, administrada y en tiempo real.

“La capacidad que define los principio del JSLEE provee una plataforma robusta y un modelo de componentes y eventos para la aplicaciones. (… ) El JSLEE define una arquitectura que permite la migración de los sistemas tradicionales propietarios y otros mercados verticales a plataformas disponibles JAVA” [9]

OMA (Open Mobile Alliance) – OMA interfaces

“La misión de la Open Mobile Alliance es facilitar la adopción global de servicios de datos móviles mediante la especificación de facilitadores de mercado para servicios de datos y el aseguramiento de la interoperabilidad de servicios a través

2 Existen varias versiones sobre el significado del acrónimo JAIN. Se ha utilizado la encontrada en http://jcp.org/en/jsr/detail?id=32

15

de dispositivos, geografías, proveedores de servicios, operadores, y redes, mientras se permite a los negocios la competencia basada en desarrollo e innovación.”[11]

Define interfaces de comunicación y protocolos basados en Web Services, y por lo tanto utiliza tecnologías de descubrimiento como UDDI (Universal Description, Discovery and Integration) y JWSDP (Java Web Services Developer Pack) entre otras. Estas interfaces permiten el control y acceso a los servidores de la red de comunicaciones para proveer los servicios prestados por ésta. El modelo consiste de:

Service enablers – Interfaces basadas en Web Services de servicios que permiten el desarrollo de aplicaciones por parte de integradores, proveedores de servicios y proveedores de contenido.

Non – Service enablers – Facilitadores basados en Web Services para la prestación de servicios que permiten el uso de los “Service enablers” de una forma segura, confiable y fácilmente descubrible, utilizando componentes existentes de los actuales Web Services como SAML, (Security Assertion Mark-up Language) UDDI (Universal Description, Discovery and Integration) y JWSDP (Java Web Services Developer Pack).

OSA (Open Service Access) - Parlay

“El Grupo Parlay apunta a unir aplicaciones de tecnología de información con las capacidades del mundo de las telecomunicaciones especificando y promoviendo APIs que son seguros, fáciles de utilizar y ricos en funcionalidad basado en estándares abiertos.” [12]

Define interfaces descritas en lenguaje UML (Unified Modelling Language), para que a partir de éstas especificaciones se implementen utilizando Web Services, APIs de Java, etc., y cualquier protocolo de comunicación que permita la integración con los sistemas propietarios existentes como por ejemplo CORBA. Las interfaces permiten el acceso y control de los servidores de la red. El modelo consiste de:

OSA Service APIs – APIs OSA para servicios que pueden ser vistas como interfaces inteligentes para redes de próximas generaciones ya que agrupan diversas funcionalidades de las redes de comunicaciones y permiten tanto el desarrollo de aplicaciones por parte de integradores, proveedores de servicios y proveedores de contenido como de operadores de la red.

16

OSA Framework APIs – “Framework” de interfaces de aplicación que facilita el uso de los APIs de servicios de una forma segura, confiable y descubrible.

Las iniciativas descritas anteriormente describen las interfaces y servicios a los que tendrán acceso los desarrolladores y proveedores de servicios para el desarrollo de sus aplicaciones. Las implementaciones de estas interfaces implican una integración a nivel tecnológico con los componentes de red de los operadores. Estas implementaciones y las respectivas integraciones están siendo desarrolladas por diversos fabricantes basándose en lo que deben ofrecer a los desarrolladores que implementen los servicios basados en las redes de comunicaciones según estas especificaciones.

Las comunidades JAIN, OMA y OSA a través de sus iniciativas aportan en la construcción de redes abiertas. En numerosos ejemplos como los encontrados en [5] se trata de demostrar cómo podrían integrarse estas tecnologías y la tendencia anuncia que en un futuro, si no predomina ninguna de las tecnologías sobre las demás, el desarrollo sobre una estará integrado con las otras. Las comunidades han hecho lo posible por mantener las iniciativas en un modelo complementario en el que la conjugación de las diferentes tecnologías compondrá la arquitectura de redes abiertas.

17

CAPÍTULO 3

JAIN (JAVA APIS FOR INTEGRATED NETWORKS)

El panorama tecnológico, y en particular la convergencia de las tecnologías de información y comunicación ha hecho que los diferentes proveedores de soluciones tecnológicas expandan su campo de investigación y desarrollo para prepararse a una ya anunciada necesidad de incorporar en su portafolio soluciones integrales y no sólo de un nicho tecnológico específico.

“La iniciativa de JAIN representa una comunidad de expertos en comunicaciones que se encuentran definiendo las interfaces necesarias de Java como una extensión de la plataforma de Java para migrar redes propietarias de comunicaciones a redes basadas en estándares.”[10] JAIN representa el papel que juega Java en las comunicaciones. Por lo tanto, la comunidad de expertos en comunicaciones que integra el grupo gestor de la iniciativa, se ha propuesto especificar las interfaces de comunicación y la arquitectura necesaria para proveer servicios de telecomunicaciones sobre redes abiertas que permita la implementación de soluciones de próxima generación gracias a la remoción de barreras propietarias. Entre estos servicios encontramos control de llamadas, mensajería, información de presencia, servicios de localización / posicionamiento entre otros.

El modelo propuesto por Java busca resolver la problemática de redes cerradas brindando portabilidad de los servicios, independencia de las redes y estándares y protocolos abiertos para el desarrollo de aplicaciones mediante un nivel de abstracción que permite la integración de protocolos de Internet y de telecomunicaciones.

Objetivo

Crear una cadena de valor abierta a todos los actores participantes en el desarrollo y la comercialización de aplicaciones de comunicaciones

Reducir el gran número de tecnologías propietarias de programación e implementación a un conjunto estándar que sea manejable y útil.

Reducir el costo y la complejidad del desarrollo, la implementación y el mantenimiento de aplicaciones de comunicaciones.

Alcance: Unificar las complejas y diversas tecnologías de redes fijas, móviles, y de Internet en un modelo estándar basado en los principios de Java de portabilidad, apertura e integridad.

18

El modelo propuesto por Java busca especificar los diferentes elementos necesarios para la implementación de una arquitectura integral de redes abiertas. JAIN especifica las interfaces de comunicación para el desarrollo de aplicaciones y el contenedor de aplicaciones responsable de atender el ciclo de vida de éstas.

En base a estas especificaciones de interfaces de comunicación y del ambiente de ejecución, diferentes desarrolladores y empresas implementan aplicaciones y servidores de aplicaciones que son compatibles con JAIN.

19

JSLEE (JAIN Service Logic Execution Environment)

“La arquitectura JAIN SLEE define un ambiente dirigido a aplicaciones de comunicaciones. La especificación incluye un modelo de componentes para estructurar la lógica de las aplicaciones de comunicaciones como una colección reusable de componentes orientados a objetos y para componer estos componentes en mayores y más sofisticados servicios.” [13]

El JSLEE es la especificación del ambiente en el que se ejecutan las aplicaciones para utilizar los recursos de las redes de comunicación. Estos recursos se pueden utilizar gracias a interfaces para comunicación de Java especificadas igualmente por la iniciativa JAIN.

La especificación del ambiente lógico de ejecución de servicios para JAIN (JSLEE en inglés) define las características de un contenedor de componentes básico para ejecutar aplicaciones de comunicación orientadas a eventos. “Esta arquitectura define un modelo para estructurar la lógica de comunicación de las aplicaciones como una colección reusable e interactuante de componentes orientados a objetos para prestar servicios. La arquitectura JSLEE también define la relación entre los componentes y el contenedor que los alojará en tiempo de ejecución.” [6] Como especificación de ambiente de ejecución, trata con todo el ciclo de vida de las aplicaciones incluyendo instalación, administración y ejecución. Las implementaciones de JSLEE son servidores de aplicaciones que a su vez actúan como contenedores para componentes de software optimizados para aplicaciones orientadas a eventos, también conocidas como aplicaciones asincrónicas.

Objetivos del JSLEE: Permitir el desarrollo de aplicaciones de comunicaciones distribuibles

combinando componentes desarrollados con herramientas de diferentes proveedores

Soportar el desarrollo sencillo de aplicaciones. Los desarrolladores de aplicaciones no tendrán que entender detalles ni APIs complicados de bajo nivel.

Adoptar la filosofía “Write Once Run Anywhere” (Desarrolle una vez, ejecútelo donde sea) del lenguaje de programación Java

Atender los aspectos de instalación, administración y ejecución del ciclo de vida de una aplicación de comunicaciones

Alcance de JSLEE: Atender el ciclo de vida de instalación, administración y ejecución de las aplicaciones3.

3 Este es el alcance de la especificación actual. En versiones futuras se tratarán temas como el manejo de conexión con otras pilas de protocolos, etc.

20

Generalidades de la especificación4

La especificación del JSLEE define un contendedor de componentes para aplicaciones orientadas a eventos también conocidas como asincrónicas. En este contenedor se ejecutan las aplicaciones que utilizan las interfaces para comunicaciones de JAIN.

“La arquitectura SLEE define cómo un aplicación puede estar compuesta de componentes. Estos componentes se conocen como Service Building Blocks (SBB).”[6] En el contenedor, una serie de componentes denominados SBBs (Service Building Blocks) constituyen los bloques de construcción de las aplicaciones. Cada uno de estos componentes tiene la capacidad de recibir, emitir eventos y ejecutar funciones a partir de éstos. La combinación de componentes, y su interacción coordinada para cumplir funciones constituyen las aplicaciones que se ejecutan en el contenedor, por lo que una aplicación puede estar compuesta de uno o más componentes o SBBs.

Ilustración 1

Un evento representa una ocurrencia que requiere procesamiento por parte de la aplicación. “Cada evento en el SLEE tiene un Event Type. El Event Type determina cómo se enruta el evento a los diferentes componentes de la aplicación.”[6] Un Event se puede originar desde un recurso externo, desde el interior del ambiente de ejecución, ya que el contenedor utiliza Events para comunicar cambios en su interior que pueden ser de interés para las aplicaciones, o de una aplicación que esté ejecutándose en el contenedor para señalizar, invocar o comunicarse con otras aplicaciones en el mismo ambiente de ejecución a través de los SBB que la componen5.

4 Estas generalidades son un resumen de la especificación del ambiente de ejecución JSLEE. Pretende dar una idea inicial del funcionamiento de éste. Para conocer en detalle los componentes y su funcionalidad se debe revisar [6].5 La comunicación entre los componentes SBB que componen una aplicación también pueden hacerse de manera sincrónica a través de una interfaz que define métodos que no necesariamente deben atender eventos.

JSLEE

APP SBB

SBB

SBB

EVENTS

21

Un SBB está compuesto por una serie de clases de Java y un descriptor que define entre otras cosas, qué tipos de eventos, con qué características puede disparar y atender y con qué otros componentes SBB se comunica para proveer la funcionalidad de la aplicación. El ambiente de ejecución es el encargado, a través de un enrutador lógico, de recibir eventos de todos los productores de eventos, revisar las características de cada uno, ordenarlos y entregarlos a múltiples instancias de componentes de acuerdo a su candidatura a recibirlos. La atención de estos eventos es realizada por métodos en el SBB que son llamados para transmitir el evento. En la funcionalidad implementada en éstos, el SBB involucrado inspecciona el evento y ejecuta acciones que pueden disparar nuevos eventos, actualizar el estado de la aplicación o interactuar con el recurso externo que emitió el evento, o con otros.

“El modelo de eventos del JSLEE está basado en un modelo de publicación / suscripción. Este modelo separa a los productores de los eventos de las fuentes de los eventos (…)“[9] La interacción con recursos externos fuentes de eventos se hace posible a través de unos elementos llamados “Resource Adaptors” o Adaptadores de Recursos. Un recurso representa un sistema que es externo al JSLEE. Ejemplo de éstos son bases de datos, pilas de protocolos, dispositivos de red, servidores de comunicaciones etc. que pueden o no tener APIs de Java para utilizar su funcionalidad. Los Resource Adaptors permiten la comunicación con estos elementos externos ya que brindan APIs de Java para ser utilizados por los componentes e internamente se comunican con los éstos mediante los protocolos y mecanismos de comunicación necesarios, muchas veces propietarios y privados.

Ilustración 2

JSLEE

APP SBB

SBB

SBB

EVENTS

ENRUTADOR LÓGICO

RESOURCE ADAPTOR

RECURSO EXTERNO

22

Todos los eventos que son emitidos por los productores, entre ellos los Resource Adaptors, son disparados a unos elementos llamados Actividades o Activities. Un enrutador lógico en el SLEE controla los eventos recibidos en estos Activities y los reenvía a los SBBs. “El mecanismo de enrutador de eventos describe cómo un evento emitido por un productor es enrutado y entregado a uno o más componentes interesados en el evento.” [9] Una Activity representa una secuencia relacionada de eventos. Estos eventos son ocurrencias significativas que pueden ser atendidas por los diferentes componentes SBB. Los componentes SBB se pueden adjuntar a estas Activities y recibir por lo tanto todos los eventos emitidos por éstas para atenderlos como su funcionalidad lo determine. Un ejemplo de una Activity puede ser una llamada. Esta llamada se compone de una serie relacionada de eventos que pueden ser atendidos por los componentes que lo deseen de forma independiente.

Para controlar la operación del ambiente de ejecución y de las aplicaciones ejecutándose en éste, la especificación define interfaces de administración a través de JMX (Java Management Extensions) que permiten entre otras iniciar y detener el JSLEE, instalar y desinstalar aplicaciones e iniciar y detener aplicaciones. “La arquitectura del JSLEE define interfaces de administración para administrar el SLEE y los componentes que corren en éste. Estas interfaces le permiten a un Administrador el control de la instalación administración a través de interfaces para agregar remover y modificar datos.”[6]

23

Los APIs claves de JAIN en el dominio de las comunicaciones6

Java se encuentra en todos los componentes del dominio de las comunicaciones. La intención de crear una cadena abierta de valor hace que se deba proponer una solución integral. Por lo tanto se encuentran APIs para los dispositivos móviles, para los dispositivos de acceso y componentes “core”, para redes y servidores Web, y para soporte de operaciones y sistemas de facturación. Existe un gran número de APIs desarrollados bajo la iniciativa JAIN, pero no todos han tendido la acogida y la importancia de los presentados a continuación. Los siguientes son los más importantes y se espera que los desarrollos futuros se puedan integrar a estas iniciativas y se acomoden a estas generalizaciones.

JSIP - JAIN SIP (Session Initiation Protocol)

JSIP permite que puertas de enlace de voz sobre IP, PBX, y otros sistemas de comunicación se comuniquen entre ellos utilizando el protocolo SIP. JSIP maneja el establecimiento y cierre de las llamadas, manejo de información de presencia7 y de mensajería en redes basadas en IP.

Similar al protocolo HTTP, el protocolo SIP es un protocolo cliente-servidor con requerimientos hechos por los clientes y respuestas atendidas por los servidores. El protocolo SIP permite el desarrollo de aplicaciones para conferencias de llamadas, comunicaciones masivas (broadcast), etc., y el API JSIP brinda una interfaz estándar a ese protocolo.

SIP for J2ME – API SIP para J2ME

El API SIP para J2ME es un conector que cumple múltiples propósitos para clientes J2ME. Permite que las aplicaciones que utiliza funcionalidad del protocolo SIP se ejecuten en dispositivos de memoria y capacidad restringida, y está específicamente dirigido a teléfonos móviles.

JCC - Java Call Control

6 Estos APIs y agrupaciones de APIs son iniciativas para ordenar las diversas interfaces de servicios de mayor interés que se han desarrollado en base a la iniciativa JAIN según su funcionalidad. Existe una gran cantidad de especificaciones que se espera sean agrupadas y ordenadas en estos APIs y agrupaciones. Basado en [5].7 La información de presencia busca permitir el desarrollo de aplicaciones basadas en el contexto a través de información de características del teléfono, localización, estado del usuario, tendencias, etc. Por lo tanto se desarrollan diversas interfaces y mecanismos para obtener esta información de los usuarios.

24

JCC provee a las aplicaciones un mecanismo consistente para comunicarse con redes divergentes8 para el control y la manipulación de llamadas. Incluye las facilidades requeridas para iniciar observar, responder, detener, procesar y manipular llamadas en donde éstas pueden incluir comunicaciones multimedia o conferencias. Las aplicaciones sólo necesitan comunicarse con un API cuya implementación se encargará de hacer la integración necesaria para intercambiar información entre las redes divergentes.

SAMS - Server APIs for Mobile Systems

Los APIs para la implementación de servicios de mensajería como SMS, MMS, EMS, etc., y servicios de localización / posicionamiento se agrupan en SAMS, un conjunto de APIs para sistemas móviles. Estos APIs deben estar disponibles para servidores Web debido a que su funcionalidad es provista para ser accedida y utilizada por integradores, proveedores de servicios y proveedores de contenido para el desarrollo de aplicaciones de utilización masiva. Por lo tanto, proveen interfaces para comunicación externa y un alto nivel de abstracción tanto para la integración de protocolos IP y de comunicaciones, como para la independencia de protocolos de red y tecnologías de infraestructura. Aunque proveer esta abstracción limitará algunos escenarios de los servicios debido a la diferencia en la implementación en diferentes tecnologías y proveedores, los APIs de SAMS ofrecen la mayor parte de la funcionalidad. El primer SAMS API aceptado y establecido como parte del grupo de interfaces es el siguiente:

SAMS Messaging

El SAMS Messaging API provee un protocolo general, estándar y portable para mensajería SMS (Short Message Service) y MMS (Multimedia Message Service) que permite el envío y recepción de mensajes de texto y de mensajes con imágenes, audio y texto. El API SAMS Messaging es una interfaz que debe estar disponible a integradores, proveedores de servicios y proveedores de contenido y por lo tanto puede ser utilizado para enviar y recibir mensajes hacia y desde plataformas basadas en J2EE, J2SE, al igual que JSLEE.

Location for J2ME

El API de localización para J2ME permite el desarrollo de aplicaciones basadas en localización para dispositivos de memoria y capacidad limitada. Estas aplicaciones están basadas en la posición del dispositivo en el que se desarrolla la aplicación y se dirigen a dispositivos que tengan como mínimo una configuración

8 Una red divergente es una en la que la implementación no converge a una única infraestructura tecnológica sino que por el contrario es divergente entre estándares.

25

CLDC. El API permite a las aplicaciones utilizar y consultar la ubicación actual del teléfono móvil.

DM - Mobile Device Management and Monitoring

DM es un API que permite la administración de dispositivos basados en J2ME independientemente de sus perfiles y configuraciones. Las funciones de la interfaz DM incluyen:

Instalación de sistemas operativos y librerías en el dispositivo Modificación de configuraciones parámetros del dispositivo Mantenimiento y control de políticas de seguridad Instalación de software de nivel de aplicación Monitoreo de la pila del dispositivo móvil de forma remota Monitoreo de indicadores de uso de las aplicaciones

La funcionalidad anterior descrita se podrá realizar tanto a través de conexiones físicas, como OTA. Actualmente DM no hace parte de SAMS y se está desarrollando como un API independiente. Sin embargo, por sus características y funcionalidad es un candidato a ser parte de éste.

WMA – Wireless Messaging API

WMA provee acceso estándar a recursos de comunicación inalámbricos para mensajería desde dispositivos móviles basados en J2ME. La interfaz del WMA permite el desarrollo de aplicaciones que se pueden conectar para el envío y recepción de mensajes de texto SMS, intercambio de datos utilizando USSD, y la recepción de mensajes a través del servicio “Cell Broadcast Service” o CBS.

OSSJ APIs - Operation Services Support APIs

Los OSSJ APIs están dirigidos al soporte de operaciones como activación de servicios, facturación, control de calidad, etc. para aplicaciones basadas en J2EE. OSSJ es una iniciativa general para proveer a los operadores una interfaz de control de operaciones de soporte a través de un API.

QoS API - Quality of service API

El API para el control de la calidad de servicio permite que las aplicaciones de manejo y administración de telecomunicaciones sean integradas con sistemas de administración de la calidad del servicio basados en Java. Estas aplicaciones pueden obtener y calcular datos de calidad de servicio como datos de soporte, operabilidad, disponibilidad de servicio, y seguridad.

Trouble Ticket API

26

Este API trata con todo el manejo de atención de problemas y su seguimiento. Provee un estándar que permite que las aplicaciones de manejo y administración de telecomunicaciones sean integradas con sistemas de manejo de problemas y seguimiento basados en Java. Estas aplicaciones pueden crear, modificar y eliminar tiquetes de servicio.

Service Activation API

El API para el control de activación de servicios permite que las aplicaciones de manejo y administración de telecomunicaciones sean integradas con sistemas para la administración de servicios propósito basados en Java. Aplicaciones de administración como productos para el ingreso, manejo y operación de órdenes, pueden directamente, crearlas, editarlas y administrarlas. Las órdenes determinan el inicio y registro de servicios para su tratamiento operativo.

IP Billing API

El API para el servicio de facturación permite que las aplicaciones de manejo y administración de telecomunicaciones sean integradas con sistemas de facturación basados en Java. Las aplicaciones se pueden utilizar para obtener todo tipo de información de facturación e iniciar los procedimientos relacionados necesarios.

27

Topología de red para java en las comunicaciones

La comunicación entre diferentes tecnologías Java como J2EE, J2SE y JSLEE permiten proveer soluciones integrales para el aprovechamiento de las capacidades de las redes de comunicaciones. La interacción entre éstas se puede realizar de muchas formas. El siguiente diagrama muestra una de las topologías de red que permite integrar las diferentes plataformas para este fin. Como se muestra en la figura, el componente central que da acceso a la funcionalidad de las redes de comunicaciones es JSLEE

9

Ilustración 3

9 Tomado de [5] Sun Microsystems Inc. JAIN TM and Open Networks.

28

Implementaciones actuales

Muchas implementaciones de servicios han sido realizadas por diferentes fabricantes en diferentes operadores y países con componentes y piezas del rompecabezas de JAIN. Algunas han sido soluciones completas y otras simplemente pequeñas adaptaciones e integraciones para servicios particulares. Las siguientes implementaciones son productos certificados y por lo tanto han pasado un proceso de certificación sobre una especificación final de algún componente o API.

Productos certificados [7]

Tabla 1

JAIN API (Especificación implementada) FabricanteJAIN Call Control 1.0a Truetel SIP Servlets 1.0 Dynamicsoft SIP Servlets 1.0 SiemensJAIN SIP 1.1 NISTJAIN SIP 1.0 8 x 8JAIN SIP 1.0 DynamicsoftJAIN SLEE 1.0 jNetXJAIN SLEE 1.0 OpenCloudJAIN TCAP 1.1 HPJAIN TCAP 1.1 SS8 NetworksJAIN TCAP 1.0 Ulticom

Tabla 1. Productos de JAIN certificados por JAVA

Las diferentes iniciativas se dividen en implementaciones de dos áreas de JAIN. Los APIs y el contenedor de componentes JSLEE. Son de particular interés las implementaciones del JSLEE realizadas por los fabricantes jNetX y OpenCloud, debido a que soportan las demás implementaciones de APIs y adicionalmente demuestran la innovación en el modelo de integración y abstracción de protocolos y estándares. Sin desestimar las demás implementaciones de APIs, a continuación se profundizará en las iniciativas de JSLEE.

29

OpenCloud – Rhino

OpenCloud Rhino es una implementación de un ambiente de ejecución de aplicaciones compatible con la especificación JSLEE. Su propósito es integrar diversos protocolos como SS7, SIP, Parlay, SMPP, etc. en un ambiente único para el desarrollo de servicios de voz y mensajería sobre una plataforma de alto desempeño.

“Rhino permite a los operadores y proveedores de servicio la ejecución de nuevas estrategias de desarrollo de forma rápida, económica e independiente de la red proveyendo un camino evolutivo hacia la entrega de servicios que generen ingresos.”[14]

Descripción general:

OpenCloud participó activamente en el desarrollo de la especificación del ambiente de ejecución JSLEE 1.0. Rhino fue construido según esta especificación y fue el primer ambiente de ejecución totalmente compatible con JSLEE 1.0. Implementa completamente las secciones mandatorias y opcionales incluidas en la especificación para la integración de diferentes protocolos, facilitando el desarrollo de nuevos servicios y aplicaciones y permitiendo el aprovechamiento de recursos e infraestructura existente.

Rhino facilita la administración del ciclo de vida de las aplicaciones y de la plataforma a través de las interfaces de administración basadas en JMX definidas en la especificación de JSLEE 1.0. Adicionalmente permite brindar los niveles de calidad, desempeño, disponibilidad y confiabilidad necesarios en servicios de comunicaciones utilizando Savanna. Savanna es una tecnología de “clustering” de servidores de aplicaciones específica para Rhino a través de una serie de APIs que pretende brindar al ambiente de ejecución una alta escalabilidad, disponibilidad y tolerancia a fallos.

Desarrollo de aplicaciones y servicios - Service Development Suite

Para la creación de aplicaciones OpenCloud ofrece una serie de herramientas, conocidas como el Service Development Suite que busca impulsar y popularizar el desarrollo de servicios basados en JAIN en un ambiente de desarrollo controlado enfocado a aplicaciones de comunicación. Estas herramientas permiten mitigar los riesgos inherentes a la implementación de servicios de alta exigencia de recursos en ambientes de producción. Entre estas herramientas se encuentran extensiones a IDEs existentes, ejemplos, integración con las herramientas actuales de desarrollo y pruebas, simulación de redes, etc.

30

De la mano de Java y la comunidad de expertos gestores de JAIN, OpenCloud se ha convertido en la organización más importante en el desarrollo viable de la iniciativa de JAIN a través de sus contribuciones a la especificación de la versión 1.0, el desarrollo de las herramientas para pruebas de compatibilidad y su implementación de referencia para el JSLEE. Adicionalmente se encuentra comprometida en difundir y promover el uso de JAIN para el desarrollo de aplicaciones de telecomunicaciones mediante herramientas de desarrollo, pruebas, etc.

31

jNetX – n(X) Network Middleware

jNetX n(X) es una solución para operadores de servicios de comunicaciones que facilita el acceso a los recursos de red a través de protocolos de comunicación abiertos. El servidor de aplicaciones que permite esta integración es una implementación del ambiente de ejecución JSLEE definido por la iniciativa JAIN.

“jNetX es un líder en el desarrollo de una nueva generación de software para redes de telecomunicaciones. La tecnología puede ser reusada una y otra vez para atender los requerimientos a medida que éstos cambian, evolucionan y crecen” [15]

Descripción general

jNetX desarrolla y lleva al mercado los componentes necesarios para la programación integrada de redes SS7 e IP. Esta integración se hace posible a través del servidor de aplicaciones n(X) que implementa la especificación del ambiente de ejecución JSLEE, y de componentes que facilitan el acceso y la administración de los servicios utilizando tecnologías como Parlay. Entre estos componentes se encuentran herramientas para manejar perfiles de acceso, administrar información de presencia y disponibilidad, facilitadores de cobros y facturaciones, control de sesiones, localización, etc.

Utilizando el servidor de aplicaciones n(X) es posible implementar servicios de control de llamadas, interacción con usuarios, localización, mensajería, facturación, etc. Adicionalmente, a través de uno de sus componentes, permite administrar las sesiones entre los recursos y las aplicaciones para el monitoreo en tiempo real de los servicios como llamadas y mensajería. Desarrollo de aplicaciones y servicios - jNetX Telecom Service Studio

El jNetX Telecom Service Studio es una serie de herramientas que permite a operadores y terceros el desarrollo de aplicaciones. Utiliza herramientas como emuladores para realizar pruebas en ambientes controlados con las redes simuladas mitigando así el riesgo de implementación en ambientes de producción.

jNetX es una compañía que ha dirigido sus esfuerzos a impulsar el desarrollo de las aplicaciones para telecomunicaciones a través de redes abiertas. Sin depender tanto de Java como OpenCloud, el n(X) actúa como middleware para la prestación de servicios abstrayendo la complejidad de los protocolos para sistemas de comunicación.

32

Algunos casos de éxito

Las implementaciones de servicios basados en JAIN en ambientes de producción se encuentran en una etapa exploratoria. Actualmente los casos de éxito se realizan como pilotos de servicios que se espera implementar completamente en un futuro cercano. El proceso de adopción de la cultura de redes abiertas por parte de operadores, desarrolladores y fabricantes se encuentra en una etapa temprana y los casos de éxito son implementaciones preliminares de los servicios que se verán en un futuro.

Los siguientes casos determinan el punto de partida de la implementación de servicios sobre redes abiertas utilizando JAIN. Éstos contribuirán al proceso de culturización de los diferentes actores de la cadena de valor para la adopción de la nueva tecnología. La adopción será lenta en un principio, pero a medida que se demuestren casos de éxito y que sea evidente la conveniencia de las implementaciones de servicios y soluciones sobre redes abiertas, aumentará para modificar el comportamiento de la cadena de valor de servicios sobre redes de comunicaciones.

Proyectos implementados

Julio 5 de 2005 - Vodafone España utilizó los servidores de aplicaciones Rhino y n(X) de OpenCloud y jNetX respectivamente para implementar servicios de voz a través de dos plataformas independientes. Estas plataformas, además de ser de fabricantes distintos, corresponden a evoluciones de comunicaciones diferentes (2G y 3G). La implementación exige la comunicación con la pila de protocolos SS7 y por lo tanto demuestra un claro ejemplo de la abstracción de la complejidad de programación que facilita la tecnología JAIN. El proyecto es parte de la estrategia de Vodafone de migrar de tecnología propietaria a estándares que reduzcan los costos de implementación y disminuyan el tiempo de desarrollo de aplicaciones.

Marzo 17 de 2005 – Vodafone España de la mano de Netspira Networks completó el período de evaluación de la plataforma EMC – MMR (Multimedia Message Relay) para el manejo eficiente de mensajería MMS utilizando Rhino. La evaluación se completó después de evaluar el comportamiento de la plataforma en una implementación comercial utilizando servicios que se ejecutaron sobre Rhino 1.2.

Proyectos en curso

Noviembre 14 de 2005 – BT (British Telecom) ha lanzado un proyecto para la unificación de los centros de atención (call centers) de todas sus redes a lo largo

33

de Europa. La posibilidad de desarrollar una solución integrada para la atención de todas sus redes reduce significativamente los costos y permite un control centralizado de bastantes procesos que optimizan la eficiencia operacional. BT ha decidido realizar la integración de sus diversas redes utilizando el middleware n(X) de jNetX, y ya se han realizado pruebas simuladas en emuladores.

Agosto 10 de 2005 – Bite Lietuva, un operador móvil en Lituania aliado de Vodafone, iniciará operaciones en Latvia, un país vecino. En vez de implementar servicios sobre redes cerradas de forma tradicional, Bite se prepara para implementar una infraestructura de redes abiertas utilizando el middleware n(X) de jNetX que le dará la posibilidad de desarrollar sus propios servicios y reducir costos de implementación. Bite ya desarrolló su propia plataforma de prepago sobre jNetX y se espera que la experiencia de esta implementación se refleje en el futuro de la red en Lituania.

34

CAPÍTULO 4

SOLUCIONES BASADA EN JAIN

Soluciones para JSLEE

Los desarrollos para JSLEE buscan prestar soluciones que interactúan con redes de comunicaciones, y además implementan una lógica particular que permite la prestación de servicios definidos. Las aplicaciones corren en el ambiente de ejecución JAIN SLEE en el cual se instalan y se administra su ciclo de vida.

Las soluciones JSLEE están orientadas a servicios, y hechas de componentes lógicos que consumen y producen eventos, para así interactuar con unos recursos externos de las redes de comunicaciones, aplicaciones o sistemas externos.

Los elementos que componen una solución para prestar un servicio en general sobre una red de telecomunicaciones son los Resource Adaptors y los Services. Adicionalmente, como elementos para el manejo de información, se utilizan Activity Contexts, Events y Profiles.

35

Resource Adaptors

Estos elementos permiten comunicarse con cualquier tipo de recurso externo al JSLEE y consisten básicamente de un Resource Adaptor y de un Resource Adaptor Type. El Resource Adaptor Type define las características del Resource Adaptor y varios Resource Adaptors pueden implementar un Resource Adaptor Type. Cada uno de estos es un archivo .jar que se instala en el servidor para en conjunto proveer la funcionalidad de comunicación con elementos externos.

Los Resource Adaptors Types y Resource Adaptors pueden ser desarrollados en base a las necesidades específicas de comunicación externa de una solución, o la aplicación puede utilizar los suministrados por fabricantes de infraestructura o del servidor de aplicaciones. Es importante notar que a la fecha no hay una oferta definida de los fabricantes de equipos de red de Resource Adaptors ni de Resource Adaptor Types.

El Resource Adaptor Type está compuesto por una serie de descriptores y clases de Java que en conjunto determinan los tipos de eventos que los Resource Adaptors de ese tipo pueden disparar y la interfaz de comunicación directa con el Resource Adaptor. También definen las Activity Context Interfaces que permiten obtener un Activity Context y recuperar un Activity para compartir información entre el Resource Adaptor y los componentes del servicio.

Clases:

<xx>ActivityContextInterfaceFactory: Un Activity Context Interface Factory permite crear Activity Context Interfaces para recuperar un Activity para que un SBB pueda comunicarse con un Resource Adaptor. Esta implementación del patrón Factory para Activity Context Interfaces permite crear estos elementos a partir de algún descriptor específico.

<xx>ResourceAdaptorSbbInterface: Esta interfaz brinda funcionalidad para comunicar los componentes del servicio con el Resource Adaptor para la implementación de métodos sincrónicos.

Descriptores:

resource-adaptor-type-jar.xml: Este descriptor incluye información sobre el Resource Adaptor para controlar su ejecución incluyendo nombre, fabricante, versión, menciona los Activity Types con los que interactúa, referencia al Activity Context Interface Factory, referencia al Resource Adaptor Interface y cada Event Type que el Resource Adaptor puede disparar.

36

event-jar.xml: Este descriptor define la asociación de cada tipo de evento que puede disparar el Resource Adaptor con una clase. La especificación busca que en el JSLEE los tipos de eventos no estén amarrados a sus clases. El JSLEE sólo conoce los tipos de eventos que pude disparar un Resource Adaptor a través del resource-adaptor-type.xml, y estos pueden estar implementados en diferentes clases.

deployable-unit.xml: Cada elemento que se debe instalar en el JSLEE debe tener un archivo descriptor con este nombre que haga referencia a los archivos que el JSLEE debe utilizar para instalar el elemento. Para poder instalar un Resource Adaptor es necesario que esté instalado en el JSLEE un Resource Adaptor Type. Por lo tanto la instalación debe ser independiente. En este caso, el empaquetamiento del Resource Adaptor Type contiene dos archivos .jar adentro: <xx>-events.jar y <xx>-resource-adaptor-type.jar

Un Resource Adaptor implementa un Resource Adaptor Type para disparar los tipos de eventos especificados en éste. Está compuesto por una serie de descriptores y clases de Java que en conjunto implementan la funcionalidad de comunicación con el recurso externo, disparan eventos al JSLEE, y definen características del Resource Adaptor como el tipo, el nombre, el fabricante y la versión.

Clases:

<xx>ResourceAdaptor: Esta clase es la responsable de atender las ocurrencias de los recursos externos al JSLEE, transformarlas en eventos de uno de los tipos que tiene definido y disparar estos eventos al ambiente de ejecución. La implementación de un Resource Adaptor se puede hacer en una o varias clases.

<xx>Activity: Implementa los métodos de comunicación entre el SBB y el Resource Adaptor para responder los llamados utilizando la información del estado del Resource Adaptor. Esta clase se encuentra referenciada en el por medio de su Activity Context Interface Factory en el resource-adaptor-type.xml y provee una serie de métodos que tanto el Resource Adaptor como el SBB pueden llamar para compartir información.

Descriptores:

resource-adaptor-jar.xml: Contiene la referencia al conjunto de clases que implementen el Resource Adaptor.

deplorable-unit.xml: Cada elemento que se debe instalar en el JSLEE debe tener un archivo descriptor con este nombre que haga referencia a los archivos que el JSLEE debe utilizar para instalar el elemento. Para poder instalar un Resource Adaptor es necesario que esté instalado en el JSLEE

37

un Resource Adaptor Type. Por lo tanto la instalación debe ser independiente. En este caso, el empaquetamiento del Resource Adaptor contiene un archivo .jar adentro: <xx>-resource-adaptor.jar.

38

Services

Los Services representan las unidades de ejecución de la aplicación compuesta por uno o varios Service Building Blocks SBBs. Estos son clases de Java que pueden generar o atender ciertos eventos entregados por el JSLEE. Como tales, lo SBB definen qué tipos de eventos atienden para implementar la lógica de las aplicaciones, actualizar su estado o interactuar con otros elementos. Así como el Resource Adaptor Type y el Resource Adaptor, cada SBB está compuesto por una serie de clases y descriptores. Un Service se determina utilizando un descriptor que define un SBB raíz al cual se enviarán los Events que reciba el JSLEE.

Clases:

Tantas clases como se necesiten para implementar la funcionalidad de la aplicación. Cada clase que deba atender eventos debe implementar la interfaz javax.slee.Sbb y definir qué eventos puede atender a través de sus descriptores asociados. En la implementación de las clases, por cada tipo de evento que un SBB puede manejar debe existir un método on<Evento> en donde se desarrolla la lógica que brinda el SBB.

Descriptores:

service.xml: Cada aplicación que se instale en el servidor tiene este descriptor. Contiene información sobre toda la aplicación entre la que está el nombre, el fabricante y la versión. Como una aplicación puede contener uno o más SBBs, y estos se puede reutilizar entre diferentes aplicaciones, es necesario comunicarle al JSLEE cuál de los SBB estará predeterminado para recibir los eventos dirigidos a la aplicación, y esto se hace en este descriptor. Si un evento no está referenciado acá, no recibirá eventos directamente del JSLEE.

sbb-jar.xml: El descriptor indica el nombre, descripción, fabricante y versión de cada SBB. Adicionalmente contiene referencias a la información que utiliza el servicio almacenada en estructuras llamadas Profiles. Además, cada SBB debe proveer a través de este descriptor, la información sobre qué tipo de eventos puede atender y generar.

deployment-unit.xml: Cada elemento que se debe instalar en el JSLEE debe tener un archivo descriptor con este nombre que haga referencia a los archivos que el JSLEE debe utilizar para instalar el elemento. En este caso, el empaquetamiento de la aplicación contiene tantos archivos .jar como SBBs tenga, y un archivo service.xml como se describió anteriormente.

39

Elementos para el manejo de información

Adicionalmente, para que una aplicación pueda funcionar, es necesario definir ciertos elementos que permiten el manejo de la información al entre los Resource Adaptors y los SBBs que componen un servicio.

Activities - Activity Contexts

Los Activity Contexts proveen una herramienta para acceder a los Activities y a través de éstos compartir información entre lo SBBs y los Resource Adaptors. Por lo tanto definen el contexto en el cual se realiza la comunicación al interior de servidor de aplicaciones. Corresponde a una entidad lógica que no es un Deployment Unit (no es instalable en el JSLEE) como los elementos mencionados anteriormente, pero define el alcance de los servicios ofrecidos.

Events

Los Events son sencillas clases de Java que permiten la implementación de comunicación asincrónica entre elementos Son la representación de eventos generados en los recursos externos o en los componentes que son enrutados a la entidad lógica correspondiente para que sean procesados. No son Deployable Units.

Profiles

Los Profiles almacenan información necesaria para que los SBBs puedan prestar el servicio. La información almacenada en los Profiles se organiza en tablas que son manejadas a través de la interfaz de administración del JSLEE.

40

Planteamiento de una aplicación basada en JAIN

En el planteamiento de una solución basada en JAIN se debe seguir una metodología que permita realizar una propuesta estructurada y consecuente con el modelo orientado a eventos. El modelaje del sistema es un aspecto fundamental para su exitosa implementación.

Sin embargo, debido a la inmadurez de la cultura de desarrollo sobre JAIN, no existen metodologías actuales definidas que permitan guiar un proceso. Por lo tanto, definimos una sencilla propuesta metodológica para planteamiento de aplicaciones utilizando JAIN que incluye:

1) Definición de requerimientos generales funcionales, donde se modelan los servicios que se van a prestar.

2) Definición de elementos externos e internos necesarios. Éstos se obtienen analizando la interacción que va a tener la solución con los componentes de la red de comunicaciones y con aplicaciones externas y estudiando la funcionalidad que se debe prestar. Ej. Un componente que reciba peticiones y las convierta en eventos, y otro que reciba eventos y modifique una base de datos, etc.

3) Análisis de componentes y flujo de información de la solución. Se debe identificar cada componente como un elemento en la arquitectura de JAIN tomando en cuenta si es un productor o consumidor de eventos. En base a esto se toma en cuenta el modelo orientado a eventos y se define el ciclo de la información al interior del servidor entre los componentes identificados como Resource Adaptors y Service Building Blocks. 4) Estudio de reutilización y herramientas de programación. Es necesario evaluar el desarrollo de elementos como los Resource Adaptors, Events, Activities, etc. o si estos se pueden reutilizar a través de un API existente, y de los elementos existentes para realizar un desarrollo sobre JAIN.

41

Ejemplo

Planteamiento del desarrollo de una aplicación para servicios de localización

Descripción: La información a continuación corresponde al planteamiento de una aplicación para el servicio de localización, que ante una solicitud de una aplicación externa, hace una consulta en una red de comunicaciones para ubicar la posición aproximada de un teléfono móvil. La aplicación se basa en una plataforma compatible con una red de telefonía móvil a través de la arquitectura orientada a eventos descrita anteriormente y un servidor de aplicaciones compatible con la especificación de JSLEE 1.0. Se busca a través de un ejemplo aclarar la arquitectura propuesta por JAIN para el desarrollo de servicios de comunicaciones y estudiar el estado de desarrollo de la tecnología.

En la aplicación, y en general en cualquier aplicación sobre el JSLEE, los componentes básicos que se deben desarrollar o utilizar son los Resource Adaptors y los SBBs.

1) Definición de requerimientos generales funcionales, donde se modelan los servicios que se van a prestar.

Obtener la posición de un teléfono en términos de CellID10 a partir de un requerimiento que indique el número del móvil a localizar.

2) Definición de elementos externos e internos necesarios.

De forma general, son necesarios:

1- Un elemento para disparar al JSLEE los eventos de solicitudes de localización que se reciben de recursos externos.

2- Un elemento que reciba el evento de la solicitud y solicite una localización.

3- Un elemento que reciba esta solicitud de localización, interactúe a través de un protocolo específico de comunicaciones, con la red, y espere una respuesta para disparar al JSLEE como un evento.

4- Un elemento que reciba el evento con la información de respuesta de la red y envíe esta información al solicitante original.

10 Tecnología de posicionamiento que permite obtener la identificación de la celda en la que se encuentra un teléfono móvil

42

3) Análisis de componentes y flujo de información de la solución

El siguiente diagrama muestra como los elementos identificados en el punto anterior se modelan como componentes de la arquitectura JAIN en el JSLEE. Adicionalmente se muestran los canales de comunicación y cómo interactúan los diferentes componentes.

Ilustración 4

4) Estudio de reutilización y herramientas de desarrollo

Existen varios elementos candidatos a ser reutilizados para el desarrollo de la aplicación. Entre estos se encuentran los Resource Adaptors, los Events y los Activities – ActivityContexts, etc. Estos elementos se deben buscar en las implementaciones de los servidores de aplicaciones, o en APIs para JAIN existentes.

Nota: No se encontró ningún elemento reutilizable para el planteamiento de la aplicación de localización, por lo tanto en el evento de un desarrollo se deben implementar.

Existe un fabricante que provee un conjunto de herramientas completa para el desarrollo de aplicaciones sobre JAIN que es OpenCloud a través del Rhino SDK 1.4.1. Aunque no incluye toda la información que permitiría independizarla lógica de la ejecución, cumple con brindar la funcionalidad para desarrollar las aplicaciones para que funcionalmente sean completas.

PROTOCLOS PROPIETARIOS O

ABIERTOS

JSLEEAplicación

externa

Red

HTTPRA

JSLEESBB

HTTP

req /resp

LocationRA

Conne-ctor

EVENTOS

METODOS SINCRONICOS

3

2

4

43

1

CONCLUSIONES

El proceso de planteamiento de una aplicación sobre JAIN permitió realizar una caracterización del estado de evolución de la tecnología en cuanto a la facilidad del modelaje de servicios sobre JAIN y de la conveniencia para el desarrollo de aplicaciones. Esta caracterización fue influenciada por la calidad y el acceso a infraestructura, herramientas de programación, APIs y documentación a lo largo del desarrollo.

La caracterización involucró los documentos, la conveniencia del modelo, y la información disponible para el planteamiento de aplicaciones sobre JAIN en donde la calidad y disponibilidad de APIs y documentación fue determinante. El proceso brindó información sobre la tecnología para encontrar en JAIN una arquitectura inmadura pero con gran potencial que poco a poco se abre espacio en el mercado de los servicios de comunicaciones y valor agregado. A continuación se realiza la caracterización de los temas involucrados en el planteamiento.

Acerca de la documentación

El planteamiento de la aplicación está estrechamente ligado a la información de referencia y documentación, y por lo tanto demandó un estudio de la tecnología JAIN y en particular de la especificación del ambiente de ejecución. La mayor fuente de esta información se halla en la especificación oficial del JSLEE 1.0 que presenta contradicciones y vacíos en algunos temas como por ejemplo la especificación de la comunicación de los Resource Adaptors con las Activities. La novedad de la tecnología se refleja en la escasez de documentación alternativa como tutoriales, guías, etc. Además de la especificación del JSLEE 1.0, no existe una guía clara que presente el estado de las implementaciones de la especificación actual desde un punto de vista práctico. En conjunto es necesario utilizar la especificación y un ejemplo implementado para entender la estructura de una aplicación, el modelo de eventos implementado y los diferentes elementos, que aunque no deberían ser tomados en cuenta para el desarrollo de cada aplicación, se deben implementar mientras las herramientas y APIs no estén completos.

Acerca de las herramientas

La herramienta Rhino SDK 1.4.1 contiene un ambiente de ejecución, un Plugin para Eclipse, y otras herramientas adicionales que facilitan el desarrollo de aplicaciones para JAIN. El SDK se puede descargar de forma sencilla desde la página oficial del fabricante. Está disponible desde septiembre de 2005 y es de particular interés e indicio de la inmadurez de la tecnología, el hecho de que sea la

44

única empresa que ofrece una Suite completa para el desarrollo de aplicaciones. Otros fabricantes como jNetX anuncian herramientas de desarrollo como el Telecom Service Studio, pero aún no son públicas.

El plugin para Eclipse simplemente asiste en la creación estructural de SBBs, Profile, Events, sus interfaces y sus descriptores y cumplió con su funcionalidad en la asistencia del desarrollo de la aplicación. El servidor de aplicaciones no cumple completamente con los requerimientos para implementar el modelo orientado a eventos descrito en la especificación, ya que no implementa APIs con Activities y Events que no deben ser manejadas por el desarrollador, pero trata de manera adecuada la funcionalidad básica que le permitirá extender su infraestructura a éste. APIs y su disponibilidad

En el modelo de eventos sobre el que basan las aplicaciones son muy importantes las estructuras básicas como Activites y Events, sus tipos, etc. Estos elementos se deberían encontrar en los diferentes APIs relacionados con JAIN preinstalados en el servidor de aplicaciones. Aunque existen algunos APIs completos como el JCC, los necesarios para la implementación de diversos servicios como mensajería, localización o aplicaciones generales no se han desarrollado totalmente ni se encuentra documentación sobre los elementos que implementan, lo que obliga a desarrollar eventos y actividades propios para suplir fines específicos. Los desarrollos específicos de elementos se deben instalar en el servidor de aplicaciones para poder utilizarlos. Por lo tanto el proceso de instalación demanda una serie de actividades, que deberían omitirse debido a la implementación de los elementos en los APIs incluidos en el servidor de aplicaciones.

La tecnología JAIN es bastante novedosa y atractiva desde el punto de vista tecnológico pero todavía falta un proceso de maduración y desarrollo que concluya las intenciones de brindar una plataforma para impulsar la proliferación del desarrollo de servicios de valor agregado sobre las redes de comunicaciones. La tecnología actual se puede caracterizar como inmadura y altamente potencial. A medida que esta maduración se vaya dando, se estandarizarán los procesos de desarrollo, se definirán los APIs necesarios para la creación de servicios y se generará documentación que complementará los ejemplos y referencias actuales y guiará la creación de nuevas aplicaciones. Muestra de la maduración constante de la tecnología y el dinamismo es el inicio de la especificación del JSLEE 1.1 con intenciones de promover la búsqueda de una arquitectura de redes abiertas. Actualmente las implementaciones han seguido una especificación y deberán tender a facilitar la adopción de la tecnología desde el punto de vista de los desarrolladores. La investigación y el trabajo realizado demuestran específicamente:

45

Actualmente existe una problemática en las redes de comunicaciones caracterizada por la falta de portabilidad entre los servicios, la dependencia de la red y la limitación tecnológica para el desarrollo de servicios sobre las redes de comunicaciones.

Para enfrentar la problemática de redes cerradas han surgido iniciativas de redes abiertas que buscan proveer portabilidad de los servicios, interoperabilidad de las redes y protocolos de desarrollo abierto para fomentar nuevos canales de ingresos en el mercado de comunicaciones.

Los operadores, una vez concluyan su expansión de base de usuarios y saturen el mercado de voz, deberán empezar a buscar aliados para desarrollar soluciones e incrementar el uso de servicios de valor agregado y mantener una situación comercial viable.

La convergencia permite la integración tecnológica de las diferentes redes como Internet y las de comunicaciones para la prestación de un gran número de servicios novedosos a través de los operadores interesados en un alto grado de desarrollo de servicios.

Las diferentes iniciativas de redes abiertas se deben combinar para ofrecer una red unificada de servicios

JAIN (Java APIs for Integrated Networks) representa el papel de Java en las comunicaciones y busca generar un escenario para la proliferación del desarrollo de servicios de valor agregado mediante un ambiente de ejecución y unos APIs para el desarrollo de aplicaciones orientadas a eventos.

JAIN es una tecnología muy nueva y por lo tanto inmadura cuyas implementaciones están incompletas y con reducida documentación con mucho potencial por desarrollar y se presenta como uno de los actores más importantes en el desarrollo tecnológico de las comunicaciones en los años por venir.

A medida que se desarrolle JAIN será más fácil desarrollar aplicaciones de comunicaciones y aumentará la oferta de servicios y la calidad de los mismos debido a la competencia logrando un mejor portafolio de servicios para los usuarios finales.

La adopción de tecnologías de redes abiertas como JAIN impulsará el desarrollo de nuevos servicios, que de la mano de escenarios viables desde el punto de vista tecnológico y comercial generarán nuevos canales de

46

ingresos para los actores de la cadena de valor del mercado de las comunicaciones.

47

BIBLIOGRAFIA

Referencias

[1] Safar, Elizabeth. La convergencia tecnológica y sus perspectivas en la región. Humánitas. Portal telemático en humanidades. Recuperado de Internet: 7 de noviembre de 2005 – http://www.revele.com.ve/pdf/anuario_ininco/vol1-n5/pag13.pdf

[2] República de Colombia, Ministerio de Comunicaciones. Decreto 600 por el cual se expiden normas sobre los servicios de valor agregado y telemáticos, y se reglamenta el decreto ley 1900 de 1990. Presidencia de la República. Recuperado de Internet: 7 de noviembre de 2005 –http://www.presidencia.gov.co/decretoslinea/2003/marzo/14/dec600030314.pdf

[3] República de Colombia, Comisión de Regulación de Telecomunicaciones. Informe sectorial de Telecomunicaciones - 2004. Bogotá D.C. Febrero 2005. Recuperado de Internet: 5 de agosto de 2005 – http://www.crt.gov.co

[4] República de Colombia, Comisión de Regulación de Telecomunicaciones. Informe sectorial de Telecomunicaciones No. 5 (Julio de 2005). Bogotá D.C. Julio 2005. Recuperado de Internet: 5 de agosto de 2005 – http://www.crt.gov.co

[5] Sun Microsystems Inc. JAIN TM and Open Networks. 2003. Recuperado de Internet: 17 de agosto de 2005 – http://java.sun.com/products/jain/reference/whitepapers/index.html.

[6] Sun Microsystems Inc. & Open Cloud Limited. JAIN SLEE 1.0 Specification, Final Release. 2001 - 2002. Recuperado de Internet: 17 de agosto de 2005 – http://java.sun.com/products/jain.

[7] Sun Microsystems Inc. JAIN Certified Products Table. Recuperado de Internet: 5 de noviembre de 2005 – http://java.sun.com/products/jain/certprod_table.html .

[8] O’Doherty, Phelim. Sun Microsystems Inc. JAIN SLEE performance Analysis. Recuperado de Internet: 5 de noviembre de 2005 –http://java.sun.com/products/jain/JSLEE_Performance_Analysis.html .

[9] O’Doherty, Phelim. Sun Microsystems Inc. JAIN SLEE principles. Recuperado de Internet: 5 de noviembre de 2005 –http://java.sun.com/products/jain/article_slee_principles.html .

48

[10] Sun Microsystems Inc. JAIN and Java in Communications. 2003. Recuperado de Internet: 17 de agosto de 2005 – http://java.sun.com/products/jain/reference/whitepapers/index.html. [11] Oma Home. About OMA (Open Mobile Alliance) Recuperado de Internet el 20 de agosto de 2005. http://www.openmobilealliance.org/ .

[12] Parlay Home. Welcome to the Parlay Group Recuperado de Internet el 20 de agosto de 2005. http://www.parlay.org/ .

[13] University of Otago in Association with OpenCloud, JAIN SLEE Fundamentals. Recuperado de Internet el 17 de agosto de 2005. http://www.jainslee.org/slee/fundamentals.html .

[14] OpenCloud Rhino. Introduction. Recuperado de Internet el 8 de septiembre de 2005. http://www.opencloud.com/slee/intro.html .

[15] OpenCloud Rhino. Solutions. Recuperado de Internet el 8 de septiembre de 2005. http://www.jnetx.com/index.php?id=370 .

Consultas

Maretzke, Michael. Implementing a JSLEE Resource Adaptor. 30 Septiembre de 2005. Recuperado de Internet 5 de noviembre de 2005 –http://mobicents.org .

O’Doherty, Phelim. Sun Microsystems Inc. JAIN SLEE principles. Recuperado de Internet: 5 de noviembre de 2005 –http://java.sun.com/products/jain/SIP-and-Java.html

Sasaki, Hiroshi. Sun Microsystems Inc . Java Call Control to Session Initiation Protocol Mapping. Recuperado de Internet: 5 de agosto de 2005 – http://java.sun.com/products/jain/JCC2SIP.pdf

Sun Microsystems Inc. Code Certification. Recuperado de Internet: 20 de septiembre de 2005 – http://java.sun.com/products/jain/certification.html .

University of Otago in Association with OpenCloud, Factors Influencing the design of JAIN SLEE Recuperado de Internet el 17 de agosto de 2005. http://www.jainslee.org/slee/fundamentals.html .

49

University of Otago in Association with OpenCloud, Application Requirements drive container design. Recuperado de Internet el 17 de agosto de 2005. http://www.jainslee.org/slee/application-characteristics.html

University of Otago in Association with OpenCloud, JAIN SLEE and the Java Community Process. Recuperado de Internet el 17 de agosto de 2005.http://www.jainslee.org/slee/sleeandjcp.html

University of Otago in Association with OpenCloud, Using JCC for Portable, Network Independent JSLEE Services. Recuperado de Internet el 17 de agosto de 2005. http://www.jainslee.org/application/sleeandjcc.html

University of Otago in Association with OpenCloud, JAIN SLEE for Messaging Applications. Recuperado de Internet el 17 de agosto de 2005. http://www.jainslee.org/application/sleeandmessaging.html

University of Otago in Association with OpenCloud, JAIN SLEE and OSA Parlay. Recuperado de Internet el 17 de agosto de 2005. http://www.jainslee.org/othertechnologies/osaandslee.html

University of Otago in Association with OpenCloud, A SLEE for all seasons. Recuperado de Internet el 17 de agosto de 2005. http://www.opencloud.com/slee/downloads/asfas.pdf

Sitios de consulta y referencia básicos

www.jnetx.com

www.opencloud.com

www.ericson.com/mobilityworld

www.mobicents.org

50