You are on page 1of 51

IMPLEMENTACIN DE SERVICIOS DE VALOR AGREGADO EN REDES ABIERTAS - JAIN

GERARDO ARISTIZBAL NICOLS ACOSTA

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA

DEPARTAMENTO DE INGENIERIA DE SISTEMAS 2005 IMPLEMENTACIN DE SERVICIOS DE VALOR AGREGADO EN REDES ABIERTAS - JAIN

GERARDO ARISTIZBAL NICOLS ACOSTA

Tesis de grado para optar al ttulo de Ingeniero de Sistemas

Asesor Harold Cruz

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERIA DE SISTEMAS

2005

CONTENIDO
CONTENIDO..............................................................................................................4 LISTA DE TABLAS....................................................................................................5 LISTA DE FIGURAS..................................................................................................5 ...................................................................................................................................5 GLOSARIO................................................................................................................6 RESUMEN.................................................................................................................8 CAPTULO 1............................................................................................................11 PROBLEMTICA DE LAS REDES CERRADAS....................................................11 Falta de portabilidad de los servicios: .................................................................................12 Dependencia de la red: .........................................................................................................12 Capacidad de desarrollo limitado por estndares y tecnologas cerradas: ..........................13 CAPTULO 2............................................................................................................15 INICIATIVAS DE REDES ABIERTAS......................................................................15 SUN JAIN (Java APIs for Integrated Networks)..............................................................16 OMA (Open Mobile Alliance) OMA interfaces...............................................................16 OSA (Open Service Access) - Parlay...................................................................................17 CAPTULO 3............................................................................................................19 JAIN (JAVA APIS FOR INTEGRATED NETWORKS).............................................19 JSLEE (JAIN Service Logic Execution Environment) .......................................................21 Los APIs claves de JAIN en el dominio de las comunicaciones.........................................25 Topologa de red para java en las comunicaciones..............................................................29 Implementaciones actuales ..................................................................................................30 OpenCloud Rhino.........................................................................................................31 jNetX n(X) Network Middleware.................................................................................33 Algunos casos de xito.....................................................................................................34 CAPTULO 4............................................................................................................36 SOLUCIONES BASADA EN JAIN...........................................................................36 Soluciones para JSLEE.........................................................................................................36 Resource Adaptors ..........................................................................................................37 Services............................................................................................................................40 Elementos para el manejo de informacin......................................................................41 Planteamiento de una aplicacin basada en JAIN................................................................42 Ejemplo.................................................................................................................................43 CONCLUSIONES....................................................................................................45 BIBLIOGRAFIA........................................................................................................49

LISTA DE TABLAS
Tabla 1.....................................................................................................................30

LISTA DE FIGURAS
Ilustracin 1 ............................................................................................................22 Ilustracin 2..............................................................................................................23 Ilustracin 3..............................................................................................................29 Ilustracin 4....43

GLOSARIO
API Application Programming Interface Es un conjunto de especificaciones de comunicacin entre componentes de software. () Uno de los principales propsitos de un API consiste en proporcionar una serie de funciones de uso general 1 CBS - (Cell Broadcast Service) es un servicio para el envo de SMS a todos los mviles que se encuentran en una celda de servicio. Permite estrategias de comunicacin masiva pero no ha tenido la acogida esperada por razones de privacidad y confidencialidad. CLDC - (Connected Limited Device Configuration) es una configuracin que define APIs y una mquina virtual Java para dispositivos limitados como telfonos mviles, buscapersonas, y algunas PDAs. Clustering - Clustering es una disposicin de topologa de infraestructura que divide la funcionalidad y la responsabilidad de las aplicaciones entre varios entes reduciendo as la posibilidad de fallos y el nmero de puntos crticos. CONVERGENCIA La convergencia ha devenido prcticamente en un modelo conceptual del que se tienen informaciones desde fines de los aos 70, cuando los japoneses utilizan la expresin para explicar los cambios operados a nivel de las industrias de la informacin / comunicacin con la integracin de la informtica y las telecomunicaciones. () Posteriormente, con los desarrollos de la digitalizacin y la fibra ptica, el concepto convergencia es extendido a la comprensin de la interrelacin telecomunicaciones radiodifusin, especialmente la televisin. [1] LOCALIZACIN Los servicios de localizacin permiten obtener informacin sobre la ubicacin fsica de un telfono mvil para implementar aplicaciones sensibles a la posicin de un dispositivo. OTA - (Over the air) es un trmino para referirse a la instalacin y modificacin del software de un dispositivo a travs de la red mvil sin necesidad de tener acceso fsico a ste. PORTABILIDAD Portabilidad de los servicios se refiere a la capacidad de utilizar una misma aplicacin en diferentes infraestructuras, siendo transparente para la aplicacin.

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

SERVICIOS DE VALOR AGREGADO - Son aquellos que utilizan como soporte servicios bsicos, telemticos, de difusin o cualquier otra combinacin de stos y con ellos proporcionan la capacidad completa para el envo, o intercambio de informacin, agregando otras facilidades al servicio soporte o satisfaciendo necesidades especficas de telecomunicaciones. SS7 (Signaling System 7) Pila de protocolos utilizada para la comunicacin entre recursos de una red de comunicaciones. TCAP - (Transaction Capabilities Application Part) permite el desarrollo de servicios sobre un protocolo no orientado a conexin 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 sesin ofreciendo nuevas y distintas posibilidades para el desarrollo de aplicaciones y servicios.

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 tecnologa por brindar una arquitectura de redes de comunicaciones abierta. A travs de sta se facilitar e impulsar el desarrollo de aplicaciones para estas redes y se generarn nuevos canales de ingresos para todos los participantes del mercado tecnolgico. Esta iniciativa surge a raz 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 carcter propietario de los protocolos de utilizacin de recursos. La iniciativa es bastante nueva e inmadura en materia de desarrollo e implementaciones, pero los esfuerzos que se estn realizando indican que tendr una acogida muy importante en los aos por venir.

INTRODUCCIN
El avance tecnolgico y la tendencia constante a la convergencia de las diferentes redes portadoras de informacin, ha permitido utilizar las redes de telefona mvil para implementar servicios de valor agregado de comunicaciones basados en Internet. El desarrollo de estos servicios ha sido posible gracias a la integracin entre Internet y las redes mviles. Con esta integracin se hace posible la utilizacin, control, y ejecucin de aplicaciones que interactan y aprovechan las capacidades de las redes mviles para proveer nuevos servicios que complementan el portafolio actual de comunicaciones del mercado. La gran variedad de nuevos servicios como mensajera, transmisin de datos, provisin de contenidos, localizacin etc., el modelo de negocio del mercado en el que la interoperabilidad es vital, y las prioridades actuales de los operadores de telefona que se encuentran representadas en el inters del aumento de su base de suscriptores, han agregado nuevos actores a la cadena de valor de los servicios tecnolgicos. 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, imgenes, etc.; y los proveedores de servicios que desarrollan aplicaciones de valor agregado para diferentes sectores de la economa. Estos actores se han dedicado a suplir necesidades de los mercados corporativos y masivos, consolidando productos y servicios basados en las redes de telefona mvil. La mensajera masiva a travs de SMS (Short Message Service), MMS (Multimedia Message Service), etc. y la localizacin, hacen necesaria una estrecha relacin con los operadores para la integracin tecnolgica que hace posible la prestacin de los servicios. La integracin con las diferentes redes de los operadores de telefona mvil se ha convertido en el cimiento para la prestacin de los servicios de mensajera y de localizacin ya que es la que permite la utilizacin de la red. Sin embargo, la falta de estandarizacin de estas integraciones, la falta de regulacin sobre el tema y la inmadurez del mercado de servicios de mensajera y localizacin, ha generado una problemtica focalizada en tres frentes. Falta de portabilidad de los servicios: los servicios no son portables ya que se manejan estndares diferentes de integracin entre pases y operadores. Dependencia de la red: los servicios no son interoperables entre redes ya que cada una maneja diferentes tecnologas, servicios y modelos de integracin. Capacidad de desarrollo limitado por estndares y tecnologas cerradas: El desarrollo de la mayora de estos servicios se reduce a la utilizacin de APIs propietarios no disponibles al pblico y utilizables slo en componentes especficos de red.

Diferentes comunidades han hecho sus aportes de forma complementaria en busca de solucionar esta problemtica y estandarizar los modelos de integracin. Se busca lograr una portabilidad e interoperabilidad de los servicios en redes abiertas que fomente el desarrollo de servicios, hoy limitado por la problemtica 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 integracin de redes han cobrado importancia. A medida que ha pasado el tiempo y que se ha consolidado el mercado de los servicios mviles se ha observado una evolucin 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 mensajera multimedia y de localizacin de dispositivos mviles. Los expertos coinciden en que estos servicios ganarn importancia con el tiempo y cobrarn una alta participacin en los ingresos de los operadores de telefona mvil. La proyeccin del mercado de servicios de localizacin y mensajera, y la evidencia completa de la problemtica descrita anteriormente en estos servicios, los convierten en un escenario ideal para el estudio de la integracin de redes en busca de un modelo de desarrollo abierto. Esta investigacin estudia el modelo propuesto por la iniciativa JAIN debido a la importancia de su integracin con la plataforma de Java actual. Como componente prctico de la investigacin se plantea un ejemplo de una implementacin para un servicio de localizacin. A partir del estudio del modelo y de la informacin relacionada con el ejemplo se analiza la tecnologa y la arquitectura propuesta por JAIN.

10

CAPTULO 1 PROBLEMTICA 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 estratgicas, optimizar los canales de distribucin y el mismo uso de la infraestructura con el fin de prestar servicios de manera cada vez ms eficiente y con ms alto contenido en cuanto a las aplicaciones y la oferta de servicios. [3] Esa bsqueda de alianzas estratgicas que permiten complementar los portafolios de servicios, ofertas y optimizar canales de distribucin, exige una relacin directa entre los operadores y sus aliados. De forma paralela, el desarrollo tecnolgico de los pases se ha convertido en uno de los focos centrales de la construccin de su infraestructura. Las telecomunicaciones suplen las necesidades de comunicacin entre individuos, esencial para su convivencia social. En este sentido, a lo largo de la historia, los pases que han invertido recursos en el desarrollo de infraestructura han alcanzado un aumento significativo del desarrollo econmico y han potencializado el crecimiento de otros sectores econmicos relacionados.[4] Existe un gran potencial de desarrollo por delante, y las constantes innovaciones motivan la inversin en la adopcin de ellas para actualizar y optimizar la infraestructura de comunicaciones de los pases. El mayor o menor grado de desarrollo de las comunicaciones marcar el futuro de las sociedades. [1] Por lo tanto es de inters general trabajar en este desarrollo para soportar economas competitivas cada da ms exigentes. Las motivaciones descritas anteriormente han obligado a entes regulatorios, operadores, comunidades de investigacin, asociaciones y agremiaciones de tecnologa 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 programacin, planes de colaboracin empresarial con aliados, programas de apoyo a proyectos acadmicos, etc. Sin embargo, y a pesar de los incentivos hacia desarrolladores de servicios y proveedores de contenido, existen grandes limitantes debido al modelo tecnolgico 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 localizacin y mensajera. El problema de interconexin ha generado la necesidad de implementacin de un modelo tecnolgico de redes abiertas para proveer servicios como los de localizacin y mensajera de una manera efectiva. Una de las motivaciones ms

11

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 tecnolgico a la red y los protocolos para la utilizacin de sus servicios son determinados por los proveedores de infraestructura utilizados por los diferentes operadores de telefona mvil. Este hecho genera tres problemas diferentes que se combinan para generar una problemtica de acceso a la red determinada principalmente por falta de portabilidad de servicios, dependencia de la red y capacidad de desarrollo limitada por estndares cerrados:

Falta de portabilidad de los servicios:


El gran nmero 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 tecnolgico est a limitado a especificaciones de interfaces propietarias. Esto incrementa el costo de desarrollo, el tiempo de implementacin en mercados y los requerimientos de mantenimiento. [10] Cada empresa ha desarrollado sus modelos y protocolos de comunicacin propietarios y cerrados debido a la falta de estandarizacin y al inters de las empresas privadas en mantener un control restrictivo sobre el acceso a sus plataformas. La diversidad de estos modelos de comunicacin 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 implementacin y de insercin en el mercado y consecuentemente reduciendo la posible oferta de servicios y soluciones basados en las redes de telefona mvil.

Dependencia de la red:
Los sistemas mviles han evidenciado su mayor desarrollo desde finales del siglo XX. Las primeras tecnologas de transmisin eran incompatibles y saturaron su capacidad en de servicios de voz y datos. Este hecho llev al desarrollo de GSM (Groupe Special Mobile), una unin europea con el objeto de desarrollar un estndar paneuropeo del servicio celular. Simultneamente, en EEUU se desarrollaron los sistemas D-AMPS (posteriormente rebautizado como TDMA) y CDMA mientras que en Japn se implementaba el sistema PDC. Como es evidente, el desarrollo de las redes de comunicaciones se ha realizado de manera

12

independiente en diferentes lugares del mundo. Diferentes corrientes y comunidades han adoptado diferentes estndares que son utilizados en pases y operadores a travs del mundo. En torno a esta diversidad de tecnologas y de adopcin estndares, las redes son diferentes en sus servicios, capacidades e interfaces de integracin. Por lo tanto, los servicios implementados en una red no son portables a otras. Adicionalmente la funcionalidad a travs 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 estndares y tecnologas cerradas:


La falta de una arquitectura abierta con interfaces pblicas y estandarizadas que permitan interfaces con soluciones propietarias, previene que las soluciones existentes escalen fcilmente a un entorno global. [6] En el mundo de las redes de comunicaciones los fabricantes mantienen de forma propietaria y privada sus protocolos y estndares de integracin. Actualmente los servicios de valor agregado se encuentran limitados debido a la alta dependencia de la tecnologa provista por el fabricante para la implementacin de stos. Cada operador de comunicaciones tiene diferentes proveedores de plataforma que a su vez realizan implementaciones propietarias de sus servicios para la utilizacin de las capacidades de la red. La falta de entes reguladores, y la ambicin de los proveedores de tecnologa de abarcar tanto mercado como sea posible, ha hecho que desarrollen protocolos de comunicacin 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 estndares tecnolgicos propietarios uno de sus ms grandes limitantes. La oferta de servicios y aplicaciones actual es bastante reducida. En algunos casos es muy difcil conseguir recursos y herramientas para desarrollar servicios utilizando los componentes de las redes y en otros imposible. El servicio de localizacin evidencia todos los factores de la problemtica descrita anteriormente. Existen diferentes estndares utilizados por diferentes fabricantes, y el modelo tecnolgico de los servicios de localizacin hace necesaria la interaccin a bajo nivel con los diferentes componentes de red de los operadores. El desarrollo e implementacin de un servicio masivo, integrado, y unificado de localizacin que sea sostenible desde el punto de vista tecnolgico y comercial es inviable debido a la problemtica de redes cerradas.

13

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 estndares de comunicacin entre las diferentes alternativas como por ejemplo JAIN, PARLAY y la iniciativa de OMA. Estos acercamientos presentan otro reto y por lo tanto otra problemtica que debe ser atendida por las comunidades que estudian las redes abiertas.

14

CAPTULO 2 INICIATIVAS DE REDES ABIERTAS


Como respuesta a la problemtica 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 proliferacin de servicios que utilicen la funcionalidad de las redes de comunicaciones. Las iniciativas de redes abiertas buscan facilitar la adopcin global de los servicios de transmisin de datos a travs de redes de telefona mvil y de comunicaciones en general. Esta adopcin se lograr gracias al desarrollo de nuevos servicios y a la migracin de los actuales a arquitecturas abiertas a travs de interfaces pblicas con las redes de comunicacin. La consolidacin 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 diferenciacin e innovacin. 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 transculturizacin y concentracin de las comunicaciones de manos privadas. [1] Los objetivos generales de las arquitecturas de redes abiertas se relacionan directamente con la problemtica descrita anteriormente y tratan cada uno de sus puntos clave buscando a travs de sus implementaciones: Portabilidad de servicios Permitir la implementacin de los diferentes servicios independientemente de la tecnologa de comunicacin que se encuentre implementada en las redes. Independencia de la red Permitir la implementacin de los diferentes servicios independientemente de la red de comunicacin que soporte el servicio. Estndares y protocolos abiertos para el desarrollo e implementacin de servicios Iniciar la proliferacin 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 tecnologa, se iniciar una proliferacin de nuevos servicios que pueden ser ofrecidos por los operadores de las redes de comunicacin abriendo muchos canales de ingresos. [5] Un breve

15

adelanto ejemplar de estar proliferacin es el desarrollo del servicio del valor agregado SMS, que al encontrar un mercado de comercializacin de contenidos y servicios de interactividad hizo necesario la inclusin de integradores que lo han comercializado y explotado. El mercado de los nuevos servicios impulsar a los operadores a buscar aliados para la prestacin de servicios y a facilitarles el desarrollo de servicios a travs de interfaces y protocolos abiertos. Todos los objetivos descritos anteriormente se buscan alcanzar mediante la implementacin de interfaces pblicas con las redes de telecomunicaciones. Existen varias iniciativas para definir los estndares de redes abiertas que permitirn el desarrollo de estas interfaces y ya se estn realizando pilotos y pruebas. Las tres ms populares son las desarrolladas por SUN, OSA y OMA.

SUN JAIN (Java APIs for Integrated Networks2)


Define estndares para la implementacin 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 aplicacin de Java para las comunicaciones. Estos APIs permiten tanto a integradores, proveedores de contenido y desarrolladores de servicios como a operadores de redes de comunicacin el desarrollo sobre una o ms plataformas Java. Java Container Interfaces for communications Interfaces de contenedores de java para las comunicaciones encargadas de alojar componentes que utilizan las interfaces de aplicacin 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 comunicacin 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 migracin de los sistemas tradicionales propietarios y otros mercados verticales a plataformas disponibles JAVA [9]

OMA (Open Mobile Alliance) OMA interfaces


La misin de la Open Mobile Alliance es facilitar la adopcin global de servicios de datos mviles mediante la especificacin de facilitadores de mercado para servicios de datos y el aseguramiento de la interoperabilidad de servicios a travs
2

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

16

de dispositivos, geografas, proveedores de servicios, operadores, y redes, mientras se permite a los negocios la competencia basada en desarrollo e innovacin.[11] Define interfaces de comunicacin y protocolos basados en Web Services, y por lo tanto utiliza tecnologas 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 prestacin de servicios que permiten el uso de los Service enablers de una forma segura, confiable y fcilmente 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 tecnologa de informacin con las capacidades del mundo de las telecomunicaciones especificando y promoviendo APIs que son seguros, fciles de utilizar y ricos en funcionalidad basado en estndares 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 comunicacin que permita la integracin 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 prximas 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.

17

OSA Framework APIs Framework de interfaces de aplicacin 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 tendrn acceso los desarrolladores y proveedores de servicios para el desarrollo de sus aplicaciones. Las implementaciones de estas interfaces implican una integracin a nivel tecnolgico con los componentes de red de los operadores. Estas implementaciones y las respectivas integraciones estn siendo desarrolladas por diversos fabricantes basndose en lo que deben ofrecer a los desarrolladores que implementen los servicios basados en las redes de comunicaciones segn estas especificaciones. Las comunidades JAIN, OMA y OSA a travs de sus iniciativas aportan en la construccin de redes abiertas. En numerosos ejemplos como los encontrados en [5] se trata de demostrar cmo podran integrarse estas tecnologas y la tendencia anuncia que en un futuro, si no predomina ninguna de las tecnologas sobre las dems, 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 conjugacin de las diferentes tecnologas compondr la arquitectura de redes abiertas.

18

CAPTULO 3 JAIN (JAVA APIS FOR INTEGRATED NETWORKS)


El panorama tecnolgico, y en particular la convergencia de las tecnologas de informacin y comunicacin ha hecho que los diferentes proveedores de soluciones tecnolgicas expandan su campo de investigacin y desarrollo para prepararse a una ya anunciada necesidad de incorporar en su portafolio soluciones integrales y no slo de un nicho tecnolgico especfico. La iniciativa de JAIN representa una comunidad de expertos en comunicaciones que se encuentran definiendo las interfaces necesarias de Java como una extensin de la plataforma de Java para migrar redes propietarias de comunicaciones a redes basadas en estndares.[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 comunicacin y la arquitectura necesaria para proveer servicios de telecomunicaciones sobre redes abiertas que permita la implementacin de soluciones de prxima generacin gracias a la remocin de barreras propietarias. Entre estos servicios encontramos control de llamadas, mensajera, informacin de presencia, servicios de localizacin / posicionamiento entre otros. El modelo propuesto por Java busca resolver la problemtica de redes cerradas brindando portabilidad de los servicios, independencia de las redes y estndares y protocolos abiertos para el desarrollo de aplicaciones mediante un nivel de abstraccin que permite la integracin de protocolos de Internet y de telecomunicaciones. Objetivo Crear una cadena de valor abierta a todos los actores participantes en el desarrollo y la comercializacin de aplicaciones de comunicaciones Reducir el gran nmero de tecnologas propietarias de programacin e implementacin a un conjunto estndar que sea manejable y til. Reducir el costo y la complejidad del desarrollo, la implementacin y el mantenimiento de aplicaciones de comunicaciones. Alcance: Unificar las complejas y diversas tecnologas de redes fijas, mviles, y de Internet en un modelo estndar basado en los principios de Java de portabilidad, apertura e integridad.

19

El modelo propuesto por Java busca especificar los diferentes elementos necesarios para la implementacin de una arquitectura integral de redes abiertas. JAIN especifica las interfaces de comunicacin 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 comunicacin y del ambiente de ejecucin, diferentes desarrolladores y empresas implementan aplicaciones y servidores de aplicaciones que son compatibles con JAIN.

20

JSLEE (JAIN Service Logic Execution Environment)


La arquitectura JAIN SLEE define un ambiente dirigido a aplicaciones de comunicaciones. La especificacin incluye un modelo de componentes para estructurar la lgica de las aplicaciones de comunicaciones como una coleccin reusable de componentes orientados a objetos y para componer estos componentes en mayores y ms sofisticados servicios. [13] El JSLEE es la especificacin del ambiente en el que se ejecutan las aplicaciones para utilizar los recursos de las redes de comunicacin. Estos recursos se pueden utilizar gracias a interfaces para comunicacin de Java especificadas igualmente por la iniciativa JAIN. La especificacin del ambiente lgico de ejecucin de servicios para JAIN (JSLEE en ingls) define las caractersticas de un contenedor de componentes bsico para ejecutar aplicaciones de comunicacin orientadas a eventos. Esta arquitectura define un modelo para estructurar la lgica de comunicacin de las aplicaciones como una coleccin reusable e interactuante de componentes orientados a objetos para prestar servicios. La arquitectura JSLEE tambin define la relacin entre los componentes y el contenedor que los alojar en tiempo de ejecucin. [6] Como especificacin de ambiente de ejecucin, trata con todo el ciclo de vida de las aplicaciones incluyendo instalacin, administracin y ejecucin. Las implementaciones de JSLEE son servidores de aplicaciones que a su vez actan como contenedores para componentes de software optimizados para aplicaciones orientadas a eventos, tambin conocidas como aplicaciones asincrnicas. 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 tendrn que entender detalles ni APIs complicados de bajo nivel. Adoptar la filosofa Write Once Run Anywhere (Desarrolle una vez, ejectelo donde sea) del lenguaje de programacin Java Atender los aspectos de instalacin, administracin y ejecucin del ciclo de vida de una aplicacin de comunicaciones Alcance de JSLEE: Atender el ciclo de vida de instalacin, administracin y ejecucin de las aplicaciones3.
3

Este es el alcance de la especificacin actual. En versiones futuras se tratarn temas como el manejo de conexin con otras pilas de protocolos, etc.

21

Generalidades de la especificacin4 La especificacin del JSLEE define un contendedor de componentes para aplicaciones orientadas a eventos tambin conocidas como asincrnicas. En este contenedor se ejecutan las aplicaciones que utilizan las interfaces para comunicaciones de JAIN. La arquitectura SLEE define cmo un aplicacin 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 construccin de las aplicaciones. Cada uno de estos componentes tiene la capacidad de recibir, emitir eventos y ejecutar funciones a partir de stos. La combinacin de componentes, y su interaccin coordinada para cumplir funciones constituyen las aplicaciones que se ejecutan en el contenedor, por lo que una aplicacin puede estar compuesta de uno o ms componentes o SBBs.

EVENTS

SBB SBB SBB APP

JSLEE

Ilustracin 1

Un evento representa una ocurrencia que requiere procesamiento por parte de la aplicacin. Cada evento en el SLEE tiene un Event Type. El Event Type determina cmo se enruta el evento a los diferentes componentes de la aplicacin.[6] Un Event se puede originar desde un recurso externo, desde el interior del ambiente de ejecucin, ya que el contenedor utiliza Events para comunicar cambios en su interior que pueden ser de inters para las aplicaciones, o de una aplicacin que est ejecutndose en el contenedor para sealizar, invocar o comunicarse con otras aplicaciones en el mismo ambiente de ejecucin a travs de los SBB que la componen5.
4

Estas generalidades son un resumen de la especificacin del ambiente de ejecucin 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 comunicacin entre los componentes SBB que componen una aplicacin tambin pueden hacerse de manera sincrnica a travs de una interfaz que define mtodos que no necesariamente deben atender eventos.

22

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 caractersticas puede disparar y atender y con qu otros componentes SBB se comunica para proveer la funcionalidad de la aplicacin. El ambiente de ejecucin es el encargado, a travs de un enrutador lgico, de recibir eventos de todos los productores de eventos, revisar las caractersticas de cada uno, ordenarlos y entregarlos a mltiples instancias de componentes de acuerdo a su candidatura a recibirlos. La atencin de estos eventos es realizada por mtodos 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 aplicacin 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 publicacin / suscripcin. Este modelo separa a los productores de los eventos de las fuentes de los eventos ()[9] La interaccin con recursos externos fuentes de eventos se hace posible a travs 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 comunicacin 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 comunicacin necesarios, muchas veces propietarios y privados.

EVENTS

SBB SBB SBB APP

JSLEELGICO

ENRUTADOR

RESOURCE ADAPTOR

RECURSO EXTERNO

Ilustracin 2

23

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 lgico en el SLEE controla los eventos recibidos en estos Activities y los reenva a los SBBs. El mecanismo de enrutador de eventos describe cmo un evento emitido por un productor es enrutado y entregado a uno o ms 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 operacin del ambiente de ejecucin y de las aplicaciones ejecutndose en ste, la especificacin define interfaces de administracin a travs 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 administracin para administrar el SLEE y los componentes que corren en ste. Estas interfaces le permiten a un Administrador el control de la instalacin administracin a travs de interfaces para agregar remover y modificar datos.[6]

24

Los APIs claves de JAIN en el dominio de las comunicaciones6


Java se encuentra en todos los componentes del dominio de las comunicaciones. La intencin de crear una cadena abierta de valor hace que se deba proponer una solucin integral. Por lo tanto se encuentran APIs para los dispositivos mviles, para los dispositivos de acceso y componentes core, para redes y servidores Web, y para soporte de operaciones y sistemas de facturacin. Existe un gran nmero de APIs desarrollados bajo la iniciativa JAIN, pero no todos han tendido la acogida y la importancia de los presentados a continuacin. Los siguientes son los ms 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 comunicacin se comuniquen entre ellos utilizando el protocolo SIP. JSIP maneja el establecimiento y cierre de las llamadas, manejo de informacin de presencia7 y de mensajera 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 estndar a ese protocolo. SIP for J2ME API SIP para J2ME El API SIP para J2ME es un conector que cumple mltiples propsitos para clientes J2ME. Permite que las aplicaciones que utiliza funcionalidad del protocolo SIP se ejecuten en dispositivos de memoria y capacidad restringida, y est especficamente dirigido a telfonos mviles. JCC - Java Call Control

Estos APIs y agrupaciones de APIs son iniciativas para ordenar las diversas interfaces de servicios de mayor inters que se han desarrollado en base a la iniciativa JAIN segn 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 informacin de presencia busca permitir el desarrollo de aplicaciones basadas en el contexto a travs de informacin de caractersticas del telfono, localizacin, estado del usuario, tendencias, etc. Por lo tanto se desarrollan diversas interfaces y mecanismos para obtener esta informacin de los usuarios.

25

JCC provee a las aplicaciones un mecanismo consistente para comunicarse con redes divergentes8 para el control y la manipulacin 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 slo necesitan comunicarse con un API cuya implementacin se encargar de hacer la integracin necesaria para intercambiar informacin entre las redes divergentes. SAMS - Server APIs for Mobile Systems Los APIs para la implementacin de servicios de mensajera como SMS, MMS, EMS, etc., y servicios de localizacin / posicionamiento se agrupan en SAMS, un conjunto de APIs para sistemas mviles. 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 utilizacin masiva. Por lo tanto, proveen interfaces para comunicacin externa y un alto nivel de abstraccin tanto para la integracin de protocolos IP y de comunicaciones, como para la independencia de protocolos de red y tecnologas de infraestructura. Aunque proveer esta abstraccin limitar algunos escenarios de los servicios debido a la diferencia en la implementacin en diferentes tecnologas 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, estndar y portable para mensajera SMS (Short Message Service) y MMS (Multimedia Message Service) que permite el envo y recepcin de mensajes de texto y de mensajes con imgenes, 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 localizacin para J2ME permite el desarrollo de aplicaciones basadas en localizacin para dispositivos de memoria y capacidad limitada. Estas aplicaciones estn basadas en la posicin del dispositivo en el que se desarrolla la aplicacin y se dirigen a dispositivos que tengan como mnimo una configuracin

Una red divergente es una en la que la implementacin no converge a una nica infraestructura tecnolgica sino que por el contrario es divergente entre estndares.

26

CLDC. El API permite a las aplicaciones utilizar y consultar la ubicacin actual del telfono mvil. DM - Mobile Device Management and Monitoring DM es un API que permite la administracin de dispositivos basados en J2ME independientemente de sus perfiles y configuraciones. Las funciones de la interfaz DM incluyen: Instalacin de sistemas operativos y libreras en el dispositivo Modificacin de configuraciones parmetros del dispositivo Mantenimiento y control de polticas de seguridad Instalacin de software de nivel de aplicacin Monitoreo de la pila del dispositivo mvil de forma remota Monitoreo de indicadores de uso de las aplicaciones

La funcionalidad anterior descrita se podr realizar tanto a travs de conexiones fsicas, como OTA. Actualmente DM no hace parte de SAMS y se est desarrollando como un API independiente. Sin embargo, por sus caractersticas y funcionalidad es un candidato a ser parte de ste. WMA Wireless Messaging API WMA provee acceso estndar a recursos de comunicacin inalmbricos para mensajera desde dispositivos mviles basados en J2ME. La interfaz del WMA permite el desarrollo de aplicaciones que se pueden conectar para el envo y recepcin de mensajes de texto SMS, intercambio de datos utilizando USSD, y la recepcin de mensajes a travs del servicio Cell Broadcast Service o CBS. OSSJ APIs - Operation Services Support APIs Los OSSJ APIs estn dirigidos al soporte de operaciones como activacin de servicios, facturacin, 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 travs 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 administracin de telecomunicaciones sean integradas con sistemas de administracin 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.

27

Trouble Ticket API Este API trata con todo el manejo de atencin de problemas y su seguimiento. Provee un estndar que permite que las aplicaciones de manejo y administracin 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 activacin de servicios permite que las aplicaciones de manejo y administracin de telecomunicaciones sean integradas con sistemas para la administracin de servicios propsito basados en Java. Aplicaciones de administracin como productos para el ingreso, manejo y operacin 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 facturacin permite que las aplicaciones de manejo y administracin de telecomunicaciones sean integradas con sistemas de facturacin basados en Java. Las aplicaciones se pueden utilizar para obtener todo tipo de informacin de facturacin e iniciar los procedimientos relacionados necesarios.

28

Topologa de red para java en las comunicaciones


La comunicacin entre diferentes tecnologas Java como J2EE, J2SE y JSLEE permiten proveer soluciones integrales para el aprovechamiento de las capacidades de las redes de comunicaciones. La interaccin entre stas se puede realizar de muchas formas. El siguiente diagrama muestra una de las topologas 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

Ilustracin 3

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

29

Implementaciones actuales
Muchas implementaciones de servicios han sido realizadas por diferentes fabricantes en diferentes operadores y pases con componentes y piezas del rompecabezas de JAIN. Algunas han sido soluciones completas y otras simplemente pequeas adaptaciones e integraciones para servicios particulares. Las siguientes implementaciones son productos certificados y por lo tanto han pasado un proceso de certificacin sobre una especificacin final de algn componente o API. Productos certificados [7]
Tabla 1

JAIN API (Especificacin implementada) JAIN Call Control 1.0a SIP Servlets 1.0 SIP Servlets 1.0 JAIN SIP 1.1 JAIN SIP 1.0 JAIN SIP 1.0 JAIN SLEE 1.0 JAIN SLEE 1.0 JAIN TCAP 1.1 JAIN TCAP 1.1 JAIN TCAP 1.0

Fabricante Truetel Dynamicsoft Siemens NIST 8x8 Dynamicsoft jNetX OpenCloud HP SS8 Networks 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 inters las implementaciones del JSLEE realizadas por los fabricantes jNetX y OpenCloud, debido a que soportan las dems implementaciones de APIs y adicionalmente demuestran la innovacin en el modelo de integracin y abstraccin de protocolos y estndares. Sin desestimar las dems implementaciones de APIs, a continuacin se profundizar en las iniciativas de JSLEE.

30

OpenCloud Rhino
OpenCloud Rhino es una implementacin de un ambiente de ejecucin de aplicaciones compatible con la especificacin JSLEE. Su propsito es integrar diversos protocolos como SS7, SIP, Parlay, SMPP, etc. en un ambiente nico para el desarrollo de servicios de voz y mensajera sobre una plataforma de alto desempeo. Rhino permite a los operadores y proveedores de servicio la ejecucin de nuevas estrategias de desarrollo de forma rpida, econmica e independiente de la red proveyendo un camino evolutivo hacia la entrega de servicios que generen ingresos.[14] Descripcin general: OpenCloud particip activamente en el desarrollo de la especificacin del ambiente de ejecucin JSLEE 1.0. Rhino fue construido segn esta especificacin y fue el primer ambiente de ejecucin totalmente compatible con JSLEE 1.0. Implementa completamente las secciones mandatorias y opcionales incluidas en la especificacin para la integracin de diferentes protocolos, facilitando el desarrollo de nuevos servicios y aplicaciones y permitiendo el aprovechamiento de recursos e infraestructura existente. Rhino facilita la administracin del ciclo de vida de las aplicaciones y de la plataforma a travs de las interfaces de administracin basadas en JMX definidas en la especificacin de JSLEE 1.0. Adicionalmente permite brindar los niveles de calidad, desempeo, disponibilidad y confiabilidad necesarios en servicios de comunicaciones utilizando Savanna. Savanna es una tecnologa de clustering de servidores de aplicaciones especfica para Rhino a travs de una serie de APIs que pretende brindar al ambiente de ejecucin una alta escalabilidad, disponibilidad y tolerancia a fallos. Desarrollo de aplicaciones y servicios - Service Development Suite Para la creacin 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 comunicacin. Estas herramientas permiten mitigar los riesgos inherentes a la implementacin de servicios de alta exigencia de recursos en ambientes de produccin. Entre estas herramientas se encuentran extensiones a IDEs existentes, ejemplos, integracin con las herramientas actuales de desarrollo y pruebas, simulacin de redes, etc.

31

De la mano de Java y la comunidad de expertos gestores de JAIN, OpenCloud se ha convertido en la organizacin ms importante en el desarrollo viable de la iniciativa de JAIN a travs de sus contribuciones a la especificacin de la versin 1.0, el desarrollo de las herramientas para pruebas de compatibilidad y su implementacin 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.

32

jNetX n(X) Network Middleware


jNetX n(X) es una solucin para operadores de servicios de comunicaciones que facilita el acceso a los recursos de red a travs de protocolos de comunicacin abiertos. El servidor de aplicaciones que permite esta integracin es una implementacin del ambiente de ejecucin JSLEE definido por la iniciativa JAIN. jNetX es un lder en el desarrollo de una nueva generacin de software para redes de telecomunicaciones. La tecnologa puede ser reusada una y otra vez para atender los requerimientos a medida que stos cambian, evolucionan y crecen [15] Descripcin general jNetX desarrolla y lleva al mercado los componentes necesarios para la programacin integrada de redes SS7 e IP. Esta integracin se hace posible a travs del servidor de aplicaciones n(X) que implementa la especificacin del ambiente de ejecucin JSLEE, y de componentes que facilitan el acceso y la administracin de los servicios utilizando tecnologas como Parlay. Entre estos componentes se encuentran herramientas para manejar perfiles de acceso, administrar informacin de presencia y disponibilidad, facilitadores de cobros y facturaciones, control de sesiones, localizacin, etc. Utilizando el servidor de aplicaciones n(X) es posible implementar servicios de control de llamadas, interaccin con usuarios, localizacin, mensajera, facturacin, etc. Adicionalmente, a travs 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 mensajera. 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 implementacin en ambientes de produccin. jNetX es una compaa que ha dirigido sus esfuerzos a impulsar el desarrollo de las aplicaciones para telecomunicaciones a travs de redes abiertas. Sin depender tanto de Java como OpenCloud, el n(X) acta como middleware para la prestacin de servicios abstrayendo la complejidad de los protocolos para sistemas de comunicacin.

33

Algunos casos de xito


Las implementaciones de servicios basados en JAIN en ambientes de produccin 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 adopcin 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 vern en un futuro. Los siguientes casos determinan el punto de partida de la implementacin de servicios sobre redes abiertas utilizando JAIN. stos contribuirn al proceso de culturizacin de los diferentes actores de la cadena de valor para la adopcin de la nueva tecnologa. La adopcin 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 Espaa utiliz los servidores de aplicaciones Rhino y n(X) de OpenCloud y jNetX respectivamente para implementar servicios de voz a travs de dos plataformas independientes. Estas plataformas, adems de ser de fabricantes distintos, corresponden a evoluciones de comunicaciones diferentes (2G y 3G). La implementacin exige la comunicacin con la pila de protocolos SS7 y por lo tanto demuestra un claro ejemplo de la abstraccin de la complejidad de programacin que facilita la tecnologa JAIN. El proyecto es parte de la estrategia de Vodafone de migrar de tecnologa propietaria a estndares que reduzcan los costos de implementacin y disminuyan el tiempo de desarrollo de aplicaciones. Marzo 17 de 2005 Vodafone Espaa de la mano de Netspira Networks complet el perodo de evaluacin de la plataforma EMC MMR (Multimedia Message Relay) para el manejo eficiente de mensajera MMS utilizando Rhino. La evaluacin se complet despus de evaluar el comportamiento de la plataforma en una implementacin 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 unificacin de los centros de atencin (call centers) de todas sus redes a lo largo

34

de Europa. La posibilidad de desarrollar una solucin integrada para la atencin 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 integracin 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 mvil en Lituania aliado de Vodafone, iniciar operaciones en Latvia, un pas 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 implementacin. Bite ya desarroll su propia plataforma de prepago sobre jNetX y se espera que la experiencia de esta implementacin se refleje en el futuro de la red en Lituania.

35

CAPTULO 4 SOLUCIONES BASADA EN JAIN


Soluciones para JSLEE
Los desarrollos para JSLEE buscan prestar soluciones que interactan con redes de comunicaciones, y adems implementan una lgica particular que permite la prestacin de servicios definidos. Las aplicaciones corren en el ambiente de ejecucin JAIN SLEE en el cual se instalan y se administra su ciclo de vida. Las soluciones JSLEE estn orientadas a servicios, y hechas de componentes lgicos 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 solucin 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 informacin, se utilizan Activity Contexts, Events y Profiles.

36

Resource Adaptors
Estos elementos permiten comunicarse con cualquier tipo de recurso externo al JSLEE y consisten bsicamente de un Resource Adaptor y de un Resource Adaptor Type. El Resource Adaptor Type define las caractersticas 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 comunicacin con elementos externos. Los Resource Adaptors Types y Resource Adaptors pueden ser desarrollados en base a las necesidades especficas de comunicacin externa de una solucin, o la aplicacin 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 comunicacin directa con el Resource Adaptor. Tambin definen las Activity Context Interfaces que permiten obtener un Activity Context y recuperar un Activity para compartir informacin 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 implementacin del patrn Factory para Activity Context Interfaces permite crear estos elementos a partir de algn descriptor especfico. <xx>ResourceAdaptorSbbInterface: Esta interfaz brinda funcionalidad para comunicar los componentes del servicio con el Resource Adaptor para la implementacin de mtodos sincrnicos. Descriptores: resource-adaptor-type-jar.xml: Este descriptor incluye informacin sobre el Resource Adaptor para controlar su ejecucin incluyendo nombre, fabricante, versin, menciona los Activity Types con los que interacta, referencia al Activity Context Interface Factory, referencia al Resource Adaptor Interface y cada Event Type que el Resource Adaptor puede disparar.

37

event-jar.xml: Este descriptor define la asociacin de cada tipo de evento que puede disparar el Resource Adaptor con una clase. La especificacin busca que en el JSLEE los tipos de eventos no estn amarrados a sus clases. El JSLEE slo conoce los tipos de eventos que pude disparar un Resource Adaptor a travs 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 instalacin debe ser independiente. En este caso, el empaquetamiento del Resource Adaptor Type contiene dos archivos .jar adentro: <xx>-events.jar y <xx>-resourceadaptor-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 comunicacin con el recurso externo, disparan eventos al JSLEE, y definen caractersticas del Resource Adaptor como el tipo, el nombre, el fabricante y la versin. 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 ejecucin. La implementacin de un Resource Adaptor se puede hacer en una o varias clases. <xx>Activity: Implementa los mtodos de comunicacin entre el SBB y el Resource Adaptor para responder los llamados utilizando la informacin del estado del Resource Adaptor. Esta clase se encuentra referenciada en el por medio de su Activity Context Interface Factory en el resource-adaptortype.xml y provee una serie de mtodos que tanto el Resource Adaptor como el SBB pueden llamar para compartir informacin. 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

38

instalar un Resource Adaptor es necesario que est instalado en el JSLEE un Resource Adaptor Type. Por lo tanto la instalacin debe ser independiente. En este caso, el empaquetamiento del Resource Adaptor contiene un archivo .jar adentro: <xx>-resource-adaptor.jar.

39

Services
Los Services representan las unidades de ejecucin de la aplicacin 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 lgica 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 raz al cual se enviarn los Events que reciba el JSLEE. Clases: Tantas clases como se necesiten para implementar la funcionalidad de la aplicacin. Cada clase que deba atender eventos debe implementar la interfaz javax.slee.Sbb y definir qu eventos puede atender a travs de sus descriptores asociados. En la implementacin de las clases, por cada tipo de evento que un SBB puede manejar debe existir un mtodo on<Evento> en donde se desarrolla la lgica que brinda el SBB. Descriptores: service.xml: Cada aplicacin que se instale en el servidor tiene este descriptor. Contiene informacin sobre toda la aplicacin entre la que est el nombre, el fabricante y la versin. Como una aplicacin puede contener uno o ms SBBs, y estos se puede reutilizar entre diferentes aplicaciones, es necesario comunicarle al JSLEE cul de los SBB estar predeterminado para recibir los eventos dirigidos a la aplicacin, 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, descripcin, fabricante y versin de cada SBB. Adicionalmente contiene referencias a la informacin que utiliza el servicio almacenada en estructuras llamadas Profiles. Adems, cada SBB debe proveer a travs de este descriptor, la informacin 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 aplicacin contiene tantos archivos .jar como SBBs tenga, y un archivo service.xml como se describi anteriormente.

40

Elementos para el manejo de informacin


Adicionalmente, para que una aplicacin pueda funcionar, es necesario definir ciertos elementos que permiten el manejo de la informacin 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 travs de stos compartir informacin entre lo SBBs y los Resource Adaptors. Por lo tanto definen el contexto en el cual se realiza la comunicacin al interior de servidor de aplicaciones. Corresponde a una entidad lgica 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 implementacin de comunicacin asincrnica entre elementos Son la representacin de eventos generados en los recursos externos o en los componentes que son enrutados a la entidad lgica correspondiente para que sean procesados. No son Deployable Units. Profiles Los Profiles almacenan informacin necesaria para que los SBBs puedan prestar el servicio. La informacin almacenada en los Profiles se organiza en tablas que son manejadas a travs de la interfaz de administracin del JSLEE.

41

Planteamiento de una aplicacin basada en JAIN


En el planteamiento de una solucin basada en JAIN se debe seguir una metodologa 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 implementacin. Sin embargo, debido a la inmadurez de la cultura de desarrollo sobre JAIN, no existen metodologas actuales definidas que permitan guiar un proceso. Por lo tanto, definimos una sencilla propuesta metodolgica para planteamiento de aplicaciones utilizando JAIN que incluye: 1) Definicin de requerimientos generales funcionales, donde se modelan los servicios que se van a prestar. 2) Definicin de elementos externos e internos necesarios. stos se obtienen analizando la interaccin que va a tener la solucin 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) Anlisis de componentes y flujo de informacin de la solucin. 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 informacin al interior del servidor entre los componentes identificados como Resource Adaptors y Service Building Blocks. 4) Estudio de reutilizacin y herramientas de programacin. Es necesario evaluar el desarrollo de elementos como los Resource Adaptors, Events, Activities, etc. o si estos se pueden reutilizar a travs de un API existente, y de los elementos existentes para realizar un desarrollo sobre JAIN.

42

Ejemplo
Planteamiento del desarrollo de una aplicacin para servicios de localizacin Descripcin: La informacin a continuacin corresponde al planteamiento de una aplicacin para el servicio de localizacin, que ante una solicitud de una aplicacin externa, hace una consulta en una red de comunicaciones para ubicar la posicin aproximada de un telfono mvil. La aplicacin se basa en una plataforma compatible con una red de telefona mvil a travs de la arquitectura orientada a eventos descrita anteriormente y un servidor de aplicaciones compatible con la especificacin de JSLEE 1.0. Se busca a travs de un ejemplo aclarar la arquitectura propuesta por JAIN para el desarrollo de servicios de comunicaciones y estudiar el estado de desarrollo de la tecnologa. En la aplicacin, y en general en cualquier aplicacin sobre el JSLEE, los componentes bsicos que se deben desarrollar o utilizar son los Resource Adaptors y los SBBs. 1) Definicin de requerimientos generales funcionales, donde se modelan los servicios que se van a prestar. Obtener la posicin de un telfono en trminos de CellID10 a partir de un requerimiento que indique el nmero del mvil a localizar. 2) Definicin de elementos externos e internos necesarios. De forma general, son necesarios: 1- Un elemento para disparar al JSLEE los eventos de solicitudes de localizacin que se reciben de recursos externos. 2- Un elemento que reciba el evento de la solicitud y solicite una localizacin. 3- Un elemento que reciba esta solicitud de localizacin, interacte a travs de un protocolo especfico 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 informacin de respuesta de la red y enve esta informacin al solicitante original.
10

Tecnologa de posicionamiento que permite obtener la identificacin de la celda en la que se encuentra un telfono mvil

43

3) Anlisis de componentes y flujo de informacin de la solucin 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 comunicacin y cmo interactan los diferentes componentes.

PROTOCLOS PROPIETARIOS O ABIERTOS

Aplicacin externa

HTT P req / resp

1
HTTP RA

2
JSLEE SBB JSLEE

EVENTOS Conn ector

3
Red Locati on RA

METODOS SINCRONICOS

Ilustracin 4

4) Estudio de reutilizacin y herramientas de desarrollo Existen varios elementos candidatos a ser reutilizados para el desarrollo de la aplicacin. 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 ningn elemento reutilizable para el planteamiento de la aplicacin de localizacin, 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 travs del Rhino SDK 1.4.1. Aunque no incluye toda la informacin que permitira independizarla lgica de la ejecucin, cumple con brindar la funcionalidad para desarrollar las aplicaciones para que funcionalmente sean completas.

44

CONCLUSIONES
El proceso de planteamiento de una aplicacin sobre JAIN permiti realizar una caracterizacin del estado de evolucin de la tecnologa en cuanto a la facilidad del modelaje de servicios sobre JAIN y de la conveniencia para el desarrollo de aplicaciones. Esta caracterizacin fue influenciada por la calidad y el acceso a infraestructura, herramientas de programacin, APIs y documentacin a lo largo del desarrollo. La caracterizacin involucr los documentos, la conveniencia del modelo, y la informacin disponible para el planteamiento de aplicaciones sobre JAIN en donde la calidad y disponibilidad de APIs y documentacin fue determinante. El proceso brind informacin sobre la tecnologa 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 continuacin se realiza la caracterizacin de los temas involucrados en el planteamiento. Acerca de la documentacin El planteamiento de la aplicacin est estrechamente ligado a la informacin de referencia y documentacin, y por lo tanto demand un estudio de la tecnologa JAIN y en particular de la especificacin del ambiente de ejecucin. La mayor fuente de esta informacin se halla en la especificacin oficial del JSLEE 1.0 que presenta contradicciones y vacos en algunos temas como por ejemplo la especificacin de la comunicacin de los Resource Adaptors con las Activities. La novedad de la tecnologa se refleja en la escasez de documentacin alternativa como tutoriales, guas, etc. Adems de la especificacin del JSLEE 1.0, no existe una gua clara que presente el estado de las implementaciones de la especificacin actual desde un punto de vista prctico. En conjunto es necesario utilizar la especificacin y un ejemplo implementado para entender la estructura de una aplicacin, el modelo de eventos implementado y los diferentes elementos, que aunque no deberan ser tomados en cuenta para el desarrollo de cada aplicacin, se deben implementar mientras las herramientas y APIs no estn completos. Acerca de las herramientas La herramienta Rhino SDK 1.4.1 contiene un ambiente de ejecucin, 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 pgina oficial del fabricante. Est disponible desde septiembre de 2005 y es de particular inters e indicio de la inmadurez de la tecnologa, el hecho de que sea la

45

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 an no son pblicas. El plugin para Eclipse simplemente asiste en la creacin estructural de SBBs, Profile, Events, sus interfaces y sus descriptores y cumpli con su funcionalidad en la asistencia del desarrollo de la aplicacin. El servidor de aplicaciones no cumple completamente con los requerimientos para implementar el modelo orientado a eventos descrito en la especificacin, ya que no implementa APIs con Activities y Events que no deben ser manejadas por el desarrollador, pero trata de manera adecuada la funcionalidad bsica 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 bsicas como Activites y Events, sus tipos, etc. Estos elementos se deberan 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 implementacin de diversos servicios como mensajera, localizacin o aplicaciones generales no se han desarrollado totalmente ni se encuentra documentacin sobre los elementos que implementan, lo que obliga a desarrollar eventos y actividades propios para suplir fines especficos. Los desarrollos especficos de elementos se deben instalar en el servidor de aplicaciones para poder utilizarlos. Por lo tanto el proceso de instalacin demanda una serie de actividades, que deberan omitirse debido a la implementacin de los elementos en los APIs incluidos en el servidor de aplicaciones. La tecnologa JAIN es bastante novedosa y atractiva desde el punto de vista tecnolgico pero todava falta un proceso de maduracin y desarrollo que concluya las intenciones de brindar una plataforma para impulsar la proliferacin del desarrollo de servicios de valor agregado sobre las redes de comunicaciones. La tecnologa actual se puede caracterizar como inmadura y altamente potencial. A medida que esta maduracin se vaya dando, se estandarizarn los procesos de desarrollo, se definirn los APIs necesarios para la creacin de servicios y se generar documentacin que complementar los ejemplos y referencias actuales y guiar la creacin de nuevas aplicaciones. Muestra de la maduracin constante de la tecnologa y el dinamismo es el inicio de la especificacin del JSLEE 1.1 con intenciones de promover la bsqueda de una arquitectura de redes abiertas. Actualmente las implementaciones han seguido una especificacin y debern tender a facilitar la adopcin de la tecnologa desde el punto de vista de los desarrolladores. La investigacin y el trabajo realizado demuestran especficamente:

46

Actualmente existe una problemtica en las redes de comunicaciones caracterizada por la falta de portabilidad entre los servicios, la dependencia de la red y la limitacin tecnolgica para el desarrollo de servicios sobre las redes de comunicaciones. Para enfrentar la problemtica 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 expansin de base de usuarios y saturen el mercado de voz, debern empezar a buscar aliados para desarrollar soluciones e incrementar el uso de servicios de valor agregado y mantener una situacin comercial viable. La convergencia permite la integracin tecnolgica de las diferentes redes como Internet y las de comunicaciones para la prestacin de un gran nmero de servicios novedosos a travs 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 proliferacin del desarrollo de servicios de valor agregado mediante un ambiente de ejecucin y unos APIs para el desarrollo de aplicaciones orientadas a eventos. JAIN es una tecnologa muy nueva y por lo tanto inmadura cuyas implementaciones estn incompletas y con reducida documentacin con mucho potencial por desarrollar y se presenta como uno de los actores ms importantes en el desarrollo tecnolgico de las comunicaciones en los aos por venir. A medida que se desarrolle JAIN ser ms fcil 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 adopcin de tecnologas de redes abiertas como JAIN impulsar el desarrollo de nuevos servicios, que de la mano de escenarios viables desde el punto de vista tecnolgico y comercial generarn nuevos canales de

47

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

48

BIBLIOGRAFIA
Referencias [1] Safar, Elizabeth. La convergencia tecnolgica y sus perspectivas en la regin. Humnitas. Portal telemtico en humanidades. Recuperado de Internet: 7 de noviembre de 2005 http://www.revele.com.ve/pdf/anuario_ininco/vol1-n5/pag13.pdf [2] Repblica de Colombia, Ministerio de Comunicaciones. Decreto 600 por el cual se expiden normas sobre los servicios de valor agregado y telemticos, y se reglamenta el decreto ley 1900 de 1990. Presidencia de la Repblica. Recuperado de Internet: 7 de noviembre de 2005 http://www.presidencia.gov.co/decretoslinea/2003/marzo/14/dec600030314.pdf [3] Repblica de Colombia, Comisin de Regulacin 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] Repblica de Colombia, Comisin de Regulacin 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] ODoherty, 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] ODoherty, 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 .

49

[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 . ODoherty, 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 .

50

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 bsicos www.jnetx.com www.opencloud.com www.ericson.com/mobilityworld www.mobicents.org

51

You might also like