MXPA05003667A - Metodo y aparato para sistema de integracion de servicio. - Google Patents

Abstract

Un sistema distribuido de integracion de servicio implementado por software, que proporciona un entorno abierto para el desarrollo de nuevos servicios y su integracion con la red existente, con la integracion que es efectuada por el administrador del sistema de integracion de servicio, que tambien es el responsable para el desarrollo de servicio. Por lo tanto, el procedimiento de desarrollo e integracion de nuevos servicios es mas corto y mas economico de lo que es comun en los sistemas de integracion de servicio de telefonia. Un ejemplo de un nuevo servicio que es integrado con la infraestructura existente de red incluye el proceso, a traves del desarrollador de servicio, de un servicio sofisticado de facturacion que utiliza una infraestructura de facturacion del operador o compania prestadora de servicio telefonico. El sistema inventivo tambien proporciona, a traves de una politica modificable que es definida por el administrador del sistema, el control de nivel por servicio del flujo de paquete, tanto dentro del sistema de integracion de servicio, como entre el sistema de integracion de servicio y la red de comunicaciones. El sistema inventivo tambien proporciona visibilidad en el proceso de senalizacion a los servicios distribuidos en este, ofreciendo la comunicacion directa con los distintos protocolos tales como IP, SS7, etc., por medio de los componentes de adaptacion de red.

Description

METODO Y APARATO PARA SISTEMA DE INTEGRACION DE SERVICIO Campo de la Invención La presente invención se refiere, de manera general, a servicios de red de comunicaciones. De manera más específica, la presente invención se refiere a un sistema distribuido de integración de servicio para redes de comunicación, el cual es implementado como un servidor de aplicación que permite la distribución, ejecución y manejo de servicios de red. Antecedentes de la Invención Los sistemas modernos de integración y ejecución de servicio tiene la capacidad de proporcionar a los usuarios servicios avanzados de red, servicios que proporcionan algún tipo de funcionalidad especial al usuario durante una sesión de red. Una sesión de red es una secuencia única de eventos que comienza en base a un evento de iniciación y finaliza con un evento de terminación, por ejemplo, una llamada de teléfono, el acceso a una ubicación Web, etcétera. Cuando es iniciada una sesión que involucra la ejecución de un servicio, existen hasta tres posibles tipos básicos de datos que son canalizados o conducidos, a saber, los datos de manejo de sesión, los medios actuales transferidos (por ejemplo, flujos de datos de voz, de video, etcétera), y los datos relacionados con el servicio.

EF. 16 Los datos relacionados con el servicio comprenden activadores o peticiones que requieren la activación de un servicio. En cualquier red que soporta el uso de servicios existe un componente encargado de reconocer estos activadores y peticiones . Una vez que estos componentes reconocen la necesidad para la ejecución de un servicio, el sistema de integración de servicio es contactado con la información requerida para la ejecución y la provisión del servicio requerido . En general, estos sistemas de integración de servicio pueden ser descritos que poseen dos funcionalidades principales: (a) la funcionalidad de aplicación, en la cual es instalada la lógica de servicio de los distintos servicios; (b) un conjunto de funcionalidades de plataforma genérica que son desarrollados por distintos vendedores, los cuales son normalmente los vendedores más grandes de equipo, tales como Alcatel, Nortel, Ericsson y otros, que son utilizados por los distintos servicios. El sistema de integración de servicio, que es el responsable de la ejecución y el manejo de los servicios soportados por una red de comunicación, define qué servicios serán proporcionados por una cierta red. Estos componentes son actualmente suministrados por ciertos proveedores, los cuales como se mencionó con anterioridad, son normalmente los vendedores más grandes de equipo de comunicaciones.

Existen varias _ adversidades o contingencias prácticas con la tecnología actual de integración de servicio. En primer lugar, la tecnología actual normalmente proporciona sistemas unificados de propiedad o patente (es decir, la adición y la distribución de nuevos servicios sólo pueden ser realizadas por los proveedores de estos sistemas de propiedad o patente) . Como resultado, la adición de nuevos servicios, así como también su distribución, es una tarea muy prolongada y costosa. Por ejemplo, si un usuario estuviera interesado en adicionar un nuevo servicio a su red, de acuerdo con la técnica anterior, el usuario tendría que dirigirse al proveedor del sistema de integración de servicio, y tendría que solicitar el desarrollo y distribución del nuevo servicio. Esto es cierto con respecto a cualquier servicio requerido, excepto para los servicios más básicos. Por ejemplo, hasta que las redes de telefonía estén interesadas, desde el momento que sea requerido un cierto servicio hasta que este se vuelva operacional, podrían pasar tanto como dos o más años, y como resultado de la duración prolongada y el procedimiento complicado, esto también origina lo que es un servicio muy costoso. Otras dos implicaciones, que se originan del hecho que los sistemas de integración de servicio, de acuerdo con la técnica anterior, sean sistemas unificados y de propiedad, son: (i) las herramientas de desarrollo en base al software estándar no pueden ser utilizadas; y (ii) la integración con otros componentes en una red es complicada. Por lo tanto, es deseable tener un sistema de integración de servicio abierto basado en software, que sea implementado como un servidor de aplicación y que pueda ser adaptado para tratar con las deficiencias mencionadas con anterioridad de los sistemas de integración de servicio de la técnica anterior y que tenga la capacidad de trabajar en conjunto con los distintos tipos de redes de comunicación, tales como las redes de telefonía, las redes IN, las redes IP y las redes híbridas (es decir, las redes que combinan los distintos tipos de comunicación) . SUMARIO DE LA INVENCIÓN En consecuencia, un objetivo principal de la presente invención es proporcionar un sistema de integración de servicio que suministrará un entorno abierto (es decir, el desarrollo de nuevos servicios, su adición a la red existente y su integración con la red existente será realizada a través del administrador del sistema de integración de servicio, el cual también será responsable del desarrollo del servicio ("desarrollador de servicio" o "administrador de sistema") ) . Como resultado, el procedimiento del desarrollo e integración de nuevos servicios será relativamente más corto y más económico. Todavía otro objetivo de la presente invención es permitir el desarrollo de nuevos servicios que sean integrados con las infraestructuras existentes de -red (por ejemplo, el proceso a través del desarrollador de servicio de un servicio sofisticado de facturación que utiliza una infraestructura de facturación del portador o compañía telefónica prestadora del servicio) . Aún otro objetivo de la presente invención es implementar un componente dentro de un sistema de integración de servicio que controle y regule el flujo de paquete, tanto dentro del sistema de integración de servicio como entre el sistema de integración de servicio y la red de comunicaciones, en donde la regulación es realizada de acuerdo con una política susceptible de ser modificada que es definida por el administrador del sistema. Todavía otro objetivo de la presente invención es implementar un sistema de integración de servicio, los componentes del cual pueden ser configurados por el administrador del sistema. Aún otro objetivo de la presente invención es implementar un sistema de integración de servicio inherente a la red de comunicación, el cual permitirá una mejor visibilidad y control del proceso de señalización. Todavía otro objetivo de la presente invención es permitir que el sistema de integración de servicio se comunique, en forma directa, con distintos protocolos tales como IP, SS7, etcétera, por medio de componentes de adaptación de red.

De acuerdo con una modalidad preferida de la presente invención · se proporciona un sistema distribuido de integración de servicio que es implementado por software (es decir, un software que se ejecuta en una computadora comercial, más que en una máquina de uso especial) , para redes de comunicación, el sistema comprende: por lo menos un módulo para el manejo y el control de los distintos módulos que comprenden el sistema de integración de servicio, la que ejecuta el manejo y del control del mismo, al menos un módulo para el envió y la recepción de mensajes desde y hacia una red, por lo menos un módulo de entorno de ejecución lógica de servicio y al menos un módulo de control de recurso, que optimiza el flujo de datos entre los componentes del sistema de integración de servicio y entre el sistema de integración de servicio y la red, el módulo de control de recurso es conectado al menos con el módulo que envía y recibe los mensajes desde y hacia una red y con el módulo de entorno de ejecución lógica de servicio, de manera que el sistema de integración de servicio sea capaz de realizar por lo menos una de las condiciones siguientes: la adición de servicios, la distribución de servicios y la ejecución de servicios. Las características y ventajas adicionales de la presente invención serán aparentes a partir de la siguiente descripción detallada acompañada con las siguientes figuras.

Breve Descripción de las Figuras Con el fin de entender de manera más completa la invención, a continuación, será descrita en detalle una modalidad de ejemplo, sólo por medio de un ejemplo no limitante, con referencia a las figuras que la acompañan, en las cuales : La Figura 1 es un diagrama de bloque esquemático que ilustra la estructura de la presente invención y las relaciones lógicas entre los componentes de la misma, y entre los componentes de la misma y la red; La Figura 2 ' es un diagrama de bloque esquemático que ilustra un entorno de ejecución lógica de servicio de acuerdo con una modalidad de ejemplo de la presente invención; La Figura 3 es un diagrama de flujo que ilustra la disposición de un proceso de ejecución de servicio de acuerdo con una modalidad de ejemplo de la presente invención; y La Figura 4 es un diagrama de bloque esquemático que ilustra los adaptadores de red del sistema de la presente invención, y las relaciones lógicas y entre los componentes de la misma y otros componentes de la presente invención, todos de acuerdo con una modalidad de ejemplo de la presente invención. Descripción Detallada de la Invención Con referencia a la Figura 1, se describe en este documento una modalidad de ejemplo del sistema de integración de servicio de la presente invención, conocido como sistema "TappS" 10, el cual es un sistema distribuido de integración de servicio para redes de comunicación. El sistema TappS 10 es implementado por software (es decir, el sistema de integración de servicio de la presente invención es un software que se ejecuta en una computadora comercial, más que en una máquina de uso especial) . De este modo, el sistema TappS 10 permite la distribución, ejecución y manejo de los servicios existentes de red y la creación de nuevos servicios de red, los cuales en realidad, de acuerdo con la técnica anterior, no se encuentran disponibles. De acuerdo con la modalidad de ejemplo descrita en este documento, el sistema TappS 10 utiliza una arquitectura distribuida y comprende al menos un módulo de manejo 12, por lo menos un módulo de control 14, al menos un módulo de entorno de ejecución lógica de servicio ("SLEE") 16, por lo menos un módulo de capa de control de recurso ("RCLC") 18, al menos un elemento de módulo funcional 42, por lo menos un módulo de pasarela 40 y al . menos un módulo de servicio de nombramiento 22. Tanto el elemento de módulo funcional 42 como el módulo de pasarela 40 son referidos juntos como los adaptadores de red 20. De acuerdo con la modalidad de ejemplo de la presente invención, cada uno de los módulos mencionados con anterioridad es implementado como una estación distinta de computación ("computadora"] . De acuerdo con una modalidad alternativa de la presente invención, uno o más de los módulos mencionados con anterioridad comparte la misma computadora. La selección de la modalidad que será utilizada está en función del uso de recurso de cada uno de los módulos, del tamaño de la red que Utiliza la presente invención y de la velocidad de tráfico. de las redes. La comunicación entre los distintos componentes del sistema TappS 10 es ejecutada por medio de la Arquitectura Común de Intermediario de Petición de Objeto, que es comúnmente referida como CORBA ("CORBA") . Las conexiones que requieren una velocidad más alta de transportación, tales como entre el elemento de módulo funcional 42 y el RCLC 18 , son realizadas por medio de protocolos que son de propiedad o de patente con el sistema TappS 10 . Estos protocolos de propiedad son transportados por medio de protocolos estándares de red, tales como por ejemplo, TCP y UDP. De manera más especifica, la comunicación entre SLEE 16 y RCLC 18 , entre RCLC 18 y los adaptadores de red 20, y entre RCLC 18 y el servicio de nombramiento 22, sólo en esta dirección, utilizan lo's protocolos de patente del sistema TappS 10 . Todas las otras comunicaciones emplean el protocolo ORB Inter de la Internet CORBA ("IIOP") . A continuación se proporciona un sumario de la descripción de los módulos mencionados con anterioridad del sistema TappS 10_ y sus funciones: _ - El manejador 12 es una interfaz, la cual permite que el administrador del sistema configure cada uno de los módulos que comprenden el sistema TappS 10, como será descrito más adelante. El manejador 12 configura los distintos módulos del sistema TappS 10 mediante el acceso al controlador 14 y lo instruye para configurar los módulos del sistema TappS 10. El manejador 12 es operado por el administrador del sistema, por medio de una interfaz gráfica de usuario. El controlador 14 monitorea y mantiene los distintos módulos del sistema TappS 10. El controlador 14 localiza los malos funcionamientos, además la redundancia de manejos, también proporciona la tolerancia de falla y reemplaza o reinicia cualquiera de los módulos que comprenden el sistema TappS 10, los cuales están descompuestos o tienen un mal funcionamiento. El controlador 14 también actualiza los distintos módulos de sistema del sistema TappS 10 en el caso de una liberación de una nueva versión, en tal caso, el controlador 14 tiene la capacidad de reemplazar todos los módulos del sistema TappS 10, distintos de si mismo. Si el controlador 14 requiriera de reemplazo, el reemplazo seria realizado por medio del manejador 12. El reinicio de un módulo por medio del controlador 14 puede ser comenzado por el administrador del sistema o en forma automática, por el _controlador 14, -ya sea -que este detecte una necesidad para reiniciar un módulo (por ejemplo, cuando el módulo se ha detenido o fallado bruscamente) . Con referencia a la Figura 2, el módulo SLEE 16 es el módulo que proporciona el entorno en el cual se ejecutan los servicios proporcionados por el sistema TappS 10. Los servicios comprenden aplicaciones desplegadas por el desarrollador de servicio, que consisten de un código de programa que modela una máquina de estado. El módulo SLEE 16 comprende al menos un controlador de máquina de estado 30, por lo menos un módulo de memoria 24 y al menos una máquina ejecutable de estado 28, la máquina ejecutable de estado 28 además comprende al menos una máquina de estado 29. El módulo SLEE 16 almacena la lógica de servicio de varios servicios de red 26 en la memoria 24. Los distintos servicios 26 son representados como máquinas de estado. El módulo SLEE 16 es responsable de la ejecución de los distintos servicios proporcionados por del sistema TappS 10. Cada servicios 26 es representado por medio de una gráfica de estado, en donde cada nodo en la gráfica representa un estado del servicio 26. Un estado es una entidad estática, la cual encapsula un conjunto de valores e instrucciones en cuanto a la manera en la cual el servicio debe ser ejecutado y el modo de determinar el estado sucesor del servicio de ejecución. La gráfica de estado define todos los nodos posibles de un servicio 26, y_por lo tanto, describe todas las trayectorias que puede tomar un cierto servicio 26 en base a su ejecución. El segmento de conexión entre cualquiera de dos estados (o nodos) es referido como una transición de estado. La ejecución de un servicio 26 es realizada por medio de la ejecución a través de los nodos de estado de la gráfica de estado que representa el servicio 26. La colección completa de los nodos de estado de un servicio 26 no es requerida en el comienzo de la ejecución de un servicio 26, debido a que cada uno de los nodos de estado que sigue el primer nodo de estado es dinámicamente determinado por el servicio 26, conforme éste se ejecuta. Debe observarse que no todos los nodos de estado deben estar presentes en la memoria cuando comienza a ejecutarse el servicio, no obstante, la gráfica de estado que describe el servicio 26 incluye todas las posibles ramificaciones del servicio y existe en una forma completa e independiente del estado de ejecución. Los servicios 26 (es decir, las gráficas de estado) son ejecutados por medio de máquinas ejecutables de estado 28. Las máquinas ejecutables de estado 28 son máquinas genéricas que ejecutan los servicios 26 que son proporcionados por el sistema TappS 10. El módulo SLEE 16 comprende al menos una máquina ejecutable de estado 28. Los dos componentes principales del módulo SLEE 16 son la máquina ejecutable de estado 28 y el controlador de máquina de estado 30. El controlador de máquina de estado 30 maneja las máquinas libres ejecutables de estado 28 que esperan las nuevas peticiones de servicio. La responsabilidad principal del controlador de máquina de estado 30 es la recepción de las peticiones de entrada, la recuperación de la gráfica de estado que representa el servicio requerido 26 y la asignación de la gráfica de estado para su ejecución en una máquina libre ejecutable de estado 28. El controlador de máquina de estado 30 maneja el contenido de memoria 24, el cual posee todos los servicios válidos 26 (es decir, las gráficas de estado) soportadas por el sistema TappS 10. Cuando el controlador de máquina de estado 30 recibe una petición de un nuevo servicio, éste recupera el servicio de comparación 26 de la memoria 24 y lo asigna para su ejecución en una máquina que estado ejecutable 28. Una vez que sea realizada la asignación, el controlador de máquina de estado 30 ya no se comunica más con el servicio de ejecución 32. Una responsabilidad secundaria del controlador de máquina de estado 30 es mantener los recursos requeridos para la asignación y ejecución de las peticiones de servicio, tales como el monitoreo de la corrección de la ejecución de los objetos de la máquina ejecutable de estado 28, el uso de la memoria de monitoreo, etcétera. Una máquina ejecutable de estado 28 es responsable de la ejecución de un servicio único 26. Entre la máquina ejecutable de estado 28 y un servicio de ejecución 32, existe una capa intermedia que es la máquina de estado 29. La máquina de estado 29 es el componente dentro del cual se desarrolla el servicio la máquina ejecutable de estado 28. La máquina ejecutable de estado 28 también mantiene una conexión entre el servicio de ejecución 32 y el elemento de módulo funcional 42. En muchos casos, los distintos elementos funcionales de módulo 42 podrían ser requeridos por el servicio. La conexión es mantenida por medio de RCLC 18, como será explicado más adelante. A lo largo del proceso de ejecución o desarrollo, el servicio de ejecución registra las tareas para el elemento de módulo funcional 42. Estas tareas contienen los datos requeridos para la ejecución del nodo actual de estado. La operación del elemento de módulo funcional 42, que realiza las tareas registradas por el servicio de ejecución 32 y la operación del servicio de ejecución son asincrónicas. Estas operaciones son asincrónicas en el sentido que una vez que el servicio de ejecución 32 envía una tarea que será desarrollada por el elemento de módulo funcional 42, éste continúa realizando las operaciones relacionadas con el proceso de ejecución de servicio, en forma simultánea, con la operación del elemento de módulo funcional 42 y sin esperar los resultados generados por el elemento de módulo funcional 42. La interacción entre la máquina ejecutable de estado 28 y el elemento de módulo funcional 42 es como sigue, las tareas son enviadas a partir de _ la máquina ejecutable de estado 28 hacia el elemento de módulo funcional 42 por medio de RCLC 18. Una vez que la tarea sea completada por el elemento de módulo funcional 42, el resultado es enviado de regreso a la máquina ejecutable de estado 28. La máquina ejecutable de estado 28 recibe el resultado y lo asigna a la máquina de estado 29 que mantiene el estado actual. Una vez que es recibido el resultado, la máquina de estado 29 se comunica con el nodo actual de estado del servicio de ejecución 32 con el propósito de determinar el nodo siguiente de estado en base a la gráfica de estado del servicio 26. El módulo SLEE 16 tiene al menos una máquina ejecutable de estado 28, y de acuerdo con la modalidad de ejemplo de la presente invención, posee una pluralidad de máquinas ejecutables de estado 28, referidas como un agrupamiento o conjunto. Cuando es recibida una nueva petición de servicio por el controlador de máquina de estado 30, una instancia de máquina ejecutable de estado 28 es asignada para la ejecución de la misma. La máquina asignada ejecutable de estado 28 toma la gráfica de estado del servicio 26 y la ejecuta hasta su terminación. Cuando la máquina asignada ejecutable de estado 28 finaliza la ejecución del servicio, esta es liberada de regreso al agrupamiento de las máquinas libres ejecutables de estado 28, en donde espera por otra asignación. Cada máquina ejecutable de estado 28 que desarrollada un servicio-- tiene su propia referencia única, de acuerdo con la cual son enrutados los mensajes destinados para la máquina ejecutable de estado 28. El enrutamiento de estos mensajes hacia las máquinas ejecutables de estado 28 es realizado del siguiente modo, los módulos externos al módulo SLEE 16 enrutan todos los mensajes destinados para las máquinas ejecutables de estado 28 hacia el controlador de máquina de estado 30. Estos componentes externos conocen la ubicación del controlador de máquina de estado 30 de acuerdo con su dirección CORBA, que es comúnmente referida como la Referencia Interoperable de Objeto ("IOR") , que es comunicada a estos componentes externos a través del controlador de máquina de estado 30 en base a su iniciación. Una vez que un mensaje destinado para una de las máquinas ejecutables de estado 28 alcanza el controlador de máquina de estado 30, el controlador de máquina de estado 30 además enruta el mensaje hacia la máquina ejecutable de estado 28 a la cual corresponde el mensaje. Si el mensaje fuera una nueva petición de servicio, el controlador de máquina de estado 30 determinarla el servicio de combinación 26 a partir de la memoria 24 y lo asignarla para su ejecución por medio de una máquina libre ejecutable de estado 28 (es decir, los módulos externos al módulo SLEE 16 sólo "conoce" el controlador de máquina de estado 30. El controlador de máquina de estado 30 "conoce" las máquinas ejecutables de estado 28), -como además será explicado más adelante. Cada servicio de ejecución 32 conoce su estado actual y también como determinar el siguiente estado de su ejecución. El estado actual es ejecutado o desarrollado por medio de la máquina ejecutable de estado 28. La ejecución de un estado actual es terminada con una tarea enviada hacia el elemento de módulo funcional 42 por medio de RCLC 18. El elemento de módulo funcional 42 ejecuta la tarea y regresa un resultado a la máquina ejecutable de estado 28, una vez más, por medio de RCLC 18. El resultado regresado es la entrada de acuerdo con la cual se determina el siguiente estado del servicio de ejecución 32. El sistema TappS 10 soporta la ejecución determinista de los servicios 26. Cada servicio 26 posee sus plazos limites y las trayectorias críticos que son definidos en el primer nodo de estado. Cuando un servicio es asignado a una máquina ejecutable de estado 28, la máquina ejecutable de estado 28 conoce las trayectorias y los plazos límite críticos antes que comience la ejecución del servicio. Durante la ejecución del servicio 26, todas estas limitaciones críticas deben ser cumplidas, de otro modo, la ejecución del servicio 26 sería terminada, y una excepción es producida. Estas excepciones son captadas y manejadas por el controlador de máquina de estado 30.

Cada servicio 26 _ tiene su grado -de prioridad. La prioridad de un - servicio es calculada por medio del controlador de máquina de estado 30 antes que sea asignada a una máquina ejecutable de estado 28 para su desarrolló o ejecución. La prioridad es calculada como un factor del tiempo estimado de ejecución de servicio y del tiempo de vida . Para un mejor entendimiento del proceso de ejecución de un servicio por medio del módulo SLEE 16, se proporciona una descripción de un escenario común de ejecución, de acuerdo con la modalidad de ejemplo de la presente invención, la ejecución del servicio comienza con una petición de servicio de entrada que llega al módulo SLEE 16 por medio de RCLC 18. Estas peticiones de servicio de entrada son referidas al controlador de máquina de estado 30, el cual inicia el proceso de ejecución de servicio. El controlador de máquina de estado 30 localiza el servicio requerido en la memoria 24 y lo asigna para su ejecución a una instancia libre de la máquina ejecutable de estado 28, que es seleccionada del agrupamiento de máquina libre ejecutable de estado. En la siguiente etapa, la máquina ejecutable de estado 28 es activada por el controlador de máquina de estado 30. El controlador de máquina de estado 30 activa una máquina ejecutable de estado 28 asignándole un servicio 26 para su ejecución. Una vez que sea activada la máquina ejecutable de estado 28 , esta inicia una nueva instancia de máquina de estado 29, la cual requiere el primer nodo de estado 36 de la gráfica de estado del servicio 26, con lo cual, comienza el proceso de ejecución. Los nodos 36 del servicio de ejecución 32 registran las tareas para el elemento de módulo funcional 42, y manejan los resultados recibidos del elemento de módulo funcional 42. El tráfico entre los nodos de estado 36 y el elemento de módulo funcional 42 es realizado por medio de RCLC 18. La máquina ejecutable de estado 28 recibe los resultados del manejo de las tareas del elemento de módulo funcional 42 y refiere estos resultados al nodo de estado 36 que inició la tarea. Lo que sigue es que el nodo de estado 36 determina el siguiente nodo de estado en base a la gráfica de estado mediante la evaluación de la información disponible en el estado actual junto con el resultado recibido del elemento de módulo funcional 42. La ejecución continúa hasta que sea alcanzado el último nodo de estado 36 de la gráfica de estado del servicio 26, con lo cual finaliza el proceso de ejecución de servicio. Cuando termina la ejecución, la máquina de estado 29 es liberada y la máquina ejecutable de estado 28 regresa a la agrupación de máquina libre ejecutable de estado. Con respecto a la arquitectura del módulo SLEE 16, los dos componentes que reciben invocaciones remotas desde el módulo exterior SLEE 16 son el controlador de máquina de estado 30 y la máquina ejecutable de estado 28. Por lo tanto, de acuerdo con la modalidad de ejemplo- de la -presente invención, la arquitectura de ambos componentes es distribuida. Esto es implementado por medio de CORBA. Por lo tanto, existen en el módulo SLEE 16, dos objetos de propiedad CORBA, el controlador de máquina de estado 30 y la máquina ejecutable de estado 28. Para cada plataforma que ejecuta un módulo SLEE 16 (pueden existir uno o más objetos como se explicó con anterioridad) , se implementa un Intermediario de Petición de Objeto ("ORB", por sus siglas en inglés) de ejecución. Cada uno de los ORBs tiene dos componentes dentro del módulo SLEE 16 de propiedad de este, el controlador de máquina de estado 30 y la máquina ejecutable de estado 28. El entorno ORB canaliza la comunicación de entrada que proviene del módulo SLEE 16 hacia el controlador de máquina de estado 30 y a la máquina ejecutable de estado 28, y les proporciona las distintas funciones tales como el enlace de agrupamiento, persistencia, etc., proporcionado por el entorno ORB. De acuerdo con modalidades alternativas de la presente invención, pueden utilizarse implementaciones distribuidas distintas de CORBA tales como la Invocación Remota de Método ("RMI") , que es parte de la biblioteca del lenguaje de programación Java. Como se mencionó con anterioridad, la comunicación de salida del módulo SLEE 16 a RCLC 18 es realizada por medio de los protocolos de propiedad del sistema TappS 10.

Con referencia a la Figura 6, - se muestra una disposición común de un proceso de ejecución de servicio. Como se muestra, cada una de las máquinas ejecutables de estado 28, No. 1 y No. 2 está ejecutando o desarrollando un servicio. Para cada servicio de ejecución existe un objeto de máquina de estado 29 que representa el correspondiente contexto de ejecución del servicio 26. Durante la ejecución del servicio, las tareas son registradas en el elemento de módulo funcional 42, una vez más, a través de RCLC 18. El elemento de módulo funcional 42 recibe la tarea, después, la ejecuta y posteriormente, envía el resultado de regreso a la máquina ejecutable de estado 28 a partir de la cual la tarea originada utiliza una llamada CORBA. El elemento de módulo funcional 42 conoce como enviar la respuesta hacia la máquina ejecutable de estado 28 de origen de acuerdo con el IOR recibido con la tarea. A diferencia del IOR, la tarea también contiene datos con respecto a la definición del estado actual 36 y la identidad de la máquina ejecutable de estado 28 que desarrolla o ejecuta el servicio 26. De acuerdo con la modalidad de ejemplo de la presente invención, una pluralidad de controladores de máquina de estado 30 y una pluralidad de máquinas ejecutables de estado 28 son utilizadas. De acuerdo con una modalidad alternativa de la presente invención, sólo es utilizado un controlador de máquina de estado 30. La razón para esto es que el controlador de máquina de estado 30·- es un objeto de reentrada y por lo- tanto, una instancia del mismo puede ser accesada por más de una petición. De acuerdo con la modalidad de ejemplo de la presente invención, tanto el controlador de máquina de estado 30 como la máquina ejecutable de estado 28 se ejecutan en la misma computadora y se interrelacionan con un ORB . Como se mencionó con anterioridad, el elemento de módulo funcional 42 puede ejecutarse en una computadora distinta. Los tres de estos componentes son responsables de la operación funcional del módulo SLEE 16. El componente RCLC 18 es el componente responsable para los requerimientos no funcionales, tal como el control de flujo. Con referencia a la Figura 4, los adaptadores de red 20 están comprendidos de dos módulos principales. El primero es el módulo de pasarela 40 y el segundo es un elemento de módulo funcional 42. El módulo de pasarela 40 es implementado como un servidor, que escucha los mensajes de entrada en una interfaz de red tal como SS7, IP, etc. Los mensajes recibidos por el módulo de pasarela 40 son clasificados en peticiones de servicio y en tareas externas . Las peticiones de servicio son peticiones externas para la ejecución de un nuevo servicio, que son recibidas desde la red, y por lo tanto, conducen hacia la ejecución de un nuevo servicio. Por otro lado, las tareas externas son mensajes externos que se refieren_ a un servicio que ya se está ejecutando y por lo tanto, no provocarán la ejecución de un nuevo servicio, aunque más bien serán canalizadas hacia un servicio que ya se está ejecutando 32. Estas tareas externas son distintas de las tareas mencionadas con anterioridad que se originan desde dentro del sistema TappS 10 en si mismo, por ejemplo, las tareas que se originan desde el módulo SLEE 16, y son destinadas para el elemento de módulo funcional. El elemento de módulo funcional 42 es el responsable para el procesamiento de las tareas recibidas desde el módulo SLEE 16, y además para comunicar los distintos protocolos de red con los resultados del procesamiento. El elemento de módulo funcional 42 es un bloque de construcción que comprende al menos un manej ador de módulo funcional 44 y por lo menos un módulo funcional 46 utilizados para implementar servicios. Un servicio es implementado al invocar una serie de elementos de módulo funcional 42. ün ejemplo de una operación realizada por el elemento de módulo funcional 42 es el registro de una consulta a una base de datos. Por ejemplo, una vez que sean requeridos ciertos datos por un servicio de ejecución 32, el elemento de módulo funcional 42 es contactado por el servicio de ejecución 32, con una petición de los datos. La petición, asi como también otras peticiones, dirigidas hacia el elemento de módulo funcional 42 son generalmente referidas como tareas. Las tareas contienen los parámetros requeridos con los cuales es ejecutada la consulta. Una vez que el elemento de módulo funcional 42 recibe una tarea, este contacta la red adecuada con la consulta. Los resultados de la consulta son recibidos por el componente de pasarela 40 y posteriormente, son canalizados hacia el módulo SLEE 16 (que serán utilizados por el servicio de ejecución 32) después de consultar con el servicio de nombramiento 22 en cuanto a la dirección del servicio de ejecución 32 dentro del módulo SLEE 16. De acuerdo con la modalidad de ejemplo de la presente invención, existen varios tipos de módulos funcionales 46, uno que comunica cada protocolo que es soportado por el sistema TappS 10. Los distintos tipos mencionados con anterioridad de mensajes son transferidos hacia el elemento de módulo funcional 42 por medio de RCLC 18. El componente dentro del elemento de módulo funcional 42 que recibe las peticiones del RCLC 18 es el manej ador de módulo funcional 44. El manej ador de módulo funcional 44 sirve como una interfaz entre RCLC 18 y el módulo funcional 46, que es el responsable del manejo de tarea. Todas las instancias del módulo funcional 46 del tipo especifico son controladas por un mane ador de módulo funcional 44, de modo que para cada tipo de módulo funcional en una plataforma especifica, existe un manejador de módulo funcional 44. De acuerdo con la modalidad de- ejemplo -descrita en este documento, ambas instancias de módulo funcional 46 y el manejador de módulo funcional 44 que las controla, se encuentran situados en la misma computadora. Las instancias del módulo funcional 46 son administradas por el manejador de módulo funcional 44 en la forma de un agrupamiento . El manejador de módulo funcional 44 mantiene una lista de referencia de todas las instancias de módulo funcional 46 del mismo tipo y mantiene un contacto constante con ellas, de modo que el manejador de módulo funcional 44 conoce en toda las ocasiones cuales de las instancias del módulo funcional 46 están libres. El manejador de módulo funcional 44 también controla el número de instancias de módulo funcional 46 que existen en una cierta máquina. La cantidad de módulos funcionales 46 existentes es determinada de acuerdo con la carga de tareas recibidas por el manejador de módulo funcional 44. Cuando sea requerido, el manejador de módulo funcional 44 crea, suprime, activa y niega la entrada de las instancias de módulo funcional 46. El manejador de módulo funcional 44 también administra una linea de espera corta de peticiones no enviadas que esperan su expedición o emisión. Una vez que el manejador de módulo funcional 44 recibe una tarea, su primera prioridad es enrutarla a una instancia libre de módulo funcional 46. Si no existiera esta instancia libre^ la tarea_ seria transferida a la -linea de espera de las peticiones no enviadas y seria requerido un método utilizado para balancear el número de instancias de módulo funcional 46. Con lo cual, las tareas serian asignadas a la instancia de módulo funcional 46 con el propósito de su ejecución. Una vez que la ejecución sea terminada, el estado de la instancia del módulo funcional 46 es cambiado a un estado inactivo, lo cual significa que se encuentra libre para la ejecución de más tareas. En la finalización de cada ejecución de tarea, el manej ador de módulo funcional 44 requiere el método mencionado con anterioridad, que es utilizado para balancear el número de instancias de módulo funcional 46. El método verifica la carga actual y la velocidad de registro de tarea y en consecuencia, reduce o aumenta el número de instancias de módulo funcional 46. Además de lo anterior, el manejador de módulo funcional 44 informa a RCLC 18 en cuanto a la carga sobre las instancias de módulo funcional 46 con relación al número de instancias existentes de módulo funcional 46 y la carga sobre los recursos generales de la plataforma que las ejecuta (por ejemplo, 1/0, CPU, la memoria, etc.). Una vez que una tarea sea distribuida a un módulo funcional libre 46, el módulo funcional 46 ejecuta la tarea.

Con el propósito^ de ejecutar la tarea, el módulo funcional 46 se conecta, si fuera requerido, con dispositivos que son externos al sistema TappS 10, tal como una tarjeta de interfaz de red, etc. Como un principio general, el módulo funcional 46 está constituido de tres capas (i) una capa de interfaz, por medio de la cual el módulo funcional 46 es comunicado y se comunica con otros componentes; (ii) una capa de lógica, la cual proporciona la lógica actual de servicio del módulo funcional 46, la lógica de servicio es implementada por separado para cada tipo de módulo funcional 46; (iii) la capa de adaptación de hardware, la cual existe sólo en los tipos de módulo funcional 46 que utilizan hardware, tal como tarjetas de interfaz de red. Esta tercera capa es utilizada por la capa de lógica para comunicarse con el hardware relacionado con el módulo funcional. Con el propósito de mantener la independencia del vendedor, los módulos funcionales que se conectan con distintos tipos de dispositivos de hardware, tienen capas de adaptación de hardware que son implementadas en forma independiente. El manejador de módulo funcional 44 y el RCLC 18 son conectados por medio de un protocolo de red de propiedad. La conexión entre los dos componentes es creada por medio del servicio de nombramiento de consulta 22. Cada módulo funcional 46, en base a su creación, consulta con el servicio de nombramiento 22 para la _localización de su correspondiente RCLC 18 y el puerto designado del mismo. Una vez que los datos son obtenidos por el módulo funcional 46 recientemente creado, el módulo funcional 46 hace contacto con RCLC 18 con el propósito de notificar a RCLC 18 de su existencia. En un modo similar, en base a la creación, un RCLC 18 recientemente generado consulta el servicio de nombramiento 22 para la localización de todos los módulos funcionales existentes 46 y se conecta con ellos. Una vez que sea realizado el contacto, todo el tráfico siguiente entre RCLC 18 y el módulo funcional 46 es realizado a través del puerto especifico, utilizando un protocolo predefinido. Una vez que sea establecida la conexión, el módulo funcional 46 abre un entrelazado o enlace que constantemente escucha en el puerto y que define las peticiones que son canalizadas a partir de RCLC 18. Los distintos tipos de eventos, diferentes en la forma de las tareas mencionadas con anterioridad, son eventos activados de tiempo, tal como tener que verificar la carga del RCLC 18 dentro del elemento de módulo funcional 42, y que el elemento de módulo funcional tiene que informar al RCLC 18 en cuanto a su estado de carga. Estos eventos activados de tiempo son manejados por otro enlace que identifica el evento activado de tiempo y necesita el método requerido. La función principal de RCLC 18 es monitorear las cargas de tráfico dentro del sistema TappS 10 y entre el sistema TappS 10 y la red. El RCLC 18 conoce estos estados de carga en cualquier tiempo dado, aprende el comportamiento del consumo de recurso de los distintos servicios proporcionados por el sistema TappS 10 y canaliza el tráfico de los mensajes de entrada y de salida de acuerdo con el mismo. El RCLC 18 también funciona de acuerdo con una política predeterminada, que es preestablecida por el administrador del sistema. Por ejemplo, el administrador del sistema puede definir ciertas prioridades con respecto al grado de importancia de los distintos servicios 26 que son proporcionados por el sistema TappS 10, por lo tanto, la ejecución de servicios 26 de una importancia más alta recibirá prioridad con respecto a la ejecución de servicios 26 de una importancia más baja. El servicio de nombramiento 22 mantiene una lista de computadoras SLEE 16 y sus IORs, y de los servicios que actualmente se están ejecutando en las mismas. Cuando un mensaje llega a partir de la red, la pasarela 40 hace contacto con el servicio de nombramiento 22 en busca del destino hacia el cual debe ser enrutado el mensaje de entrada. El servicio de nombramiento 22 regresa a la pasarela 40 un IOR del SLEE 16 correcto, hacia el cual el mensaje debe ser enrutado. Otros componentes del sistema TappS 10 también consultan al servicio de nombramiento 22 para enrutar la información en un modo similar al que se describió con anterioridad.

Como se mencionó con anteriorid-ad, el sistema TappS 10 tiene las capacidades de adicionar nuevos servicios en las redes de comunicación, además, distribuir servicios y manejar las peticiones de servicio que son recibidas desde las redes de comunicación. A continuación, se encuentra una descripción general del método en el cual el sistema TappS 10 maneja las peticiones de servicio. Una vez que sea reconocido por una red que una cierta sesión requiere la ejecución de un servicio, es enviado un mensaje que requiere la provisión del servicio solicitado hacia el sistema TappS 10. El componente dentro del sistema TappS 10 que es responsable de la detección de los mensajes de entrada es la pasarela 40. Un mensaje podría ser, cualquiera de una nueva petición de servicio o un evento externo que se refiere a un servicio que ya se está ejecutando. Una vez que el mensaje sea recibido por el sistema TappS 10, la pasarela 40 consulta al servicio de nombramiento 22 con el objeto de enterarse si el mensaje se refiere a un servicio en ejecución o si es una nueva petición de servicio. Si el mensaje fuera un evento externo que se refiere a un servicio que ya se está ejecutando, la localización _de los servicios en ejecución- 32 es conseguida, y el evento externo es canalizado por medio de RCLC 18 como un parámetro que será utilizado por el servicio de ejecución 32 que se desarrolla dentro de SLEE 16. Si el mensaje fuera una nueva petición de servicio, este seria canalizado por medio de RCLC 18 a SLEE 16, en donde seria determinado el servicio requerido 26 y comenzaría la ejecución del servicio. El servicio de ejecución 32, que se desarrolla dentro de SLEE 16, el cual recibe los mensajes que son eventos externos, que llega desde la red, procesa estos eventos externos y envía las tareas de regreso hacia el elemento de módulo funcional 42, una vez más, por medio de RCLC 18. El elemento de módulo de función 42 procesa estas tareas, lo cual origina una de dos consecuencias, cualquiera de los cambios en el estado del elemento de módulo funcional 42 o en uno o más mensajes de red que están siendo enviados de regreso hacia el servicio de ejecución 32. En un escenario común, la ejecución de tarea provoca que uno o más mensajes sean enviados hacia la red y/o el servicio en ejecución. Una vez que el elemento de módulo funcional 42 envía los mensajes hacia la red y/o hacia el servicio de ejecución 32, este recibe las respuestas que provienen de la red -y/o las- nuevas tareas del servicio de ejecución 32. Este proceso toma lugar hasta que sea terminada la ejecución del servicio. Un requisito previo para la ejecución de los servicios 26 por medio del sistema TappS 10, es tener los servicios requeridos 26 distribuidos con el sistema TappS 10. El sistema TappS 10 permite que el desarrollador de servicio ejecute y distribuya nuevos servicios 26 que serán requeridos por los usuarios de una red y que son ejecutados por el sistema TappS 10. De acuerdo con la presente invención, el desarrollo de nuevos servicios es conseguido por medio de lenguajes de computadora de alto nivel (por ejemplo, Java, etc.) . El sistema TappS 10 proporciona al administrador del sistema una Interfaz para Programas de Aplicación ("API") en la parte superior del cual es desarrollado el código fuente de los nuevos servicios. Una vez que ha finalizado el desarrollo de un nuevo servicio, el código fuente es compilado y una vez que este sea compilado, el código binario es transferido hacia SLEE 16 por medio de un controlador 14 (el controlador 14 es operado por el administrador del sistema que distribuye el nuevo servicio a través del manejador 12, el cual como se mencionó con anterioridad, proporciona al administrador del sistema un GÜI del TappS 10) . En la siguiente etapa, el código binario es entonces enlazado hacia el SLEE 16 utilizando las instalaciones de carga de clase Java (que son similares a las bibliotecas dinámicamente cargadas) . Después de estas etapas, el nuevo servicio puede ser activado por el administrador del sistema y tiene acceso total a las instalaciones del sistema TappS 10. Una vez distribuido, el servicio es adicionado en la memoria 24 dentro de SLEE 16, y posteriormente se convierte de manera inmediata en un servicio válido proporcionado por el sistema TappS 10 y por lo tanto, se encuentra listo para su ejecución. Toda la materia descrita con anterioridad es la que proporciona capacidades únicas al sistema TappS 10. Una de estas capacidades es la habilidad para crear una sesión única fuera por lo menos de una sesión de control de llamada y otras sesiones (por ejemplo, las sesiones Web y las conexiones de base de datos) . Además, la arquitectura distribuida del sistema TappS 10 permite el duplicado de la totalidad de sus elementos, puesto que es necesario conseguir las propiedades tales como la tolerancia mejorada de falla, un nivel más alto de funcionamiento y capacidades má s grandes de manejo de- capacidad. El sistema TappS 10 también es independiente de la red y el protocolo, con respecto a las redes de telefonía (es decir, el mismo servicio puede ejecutarse en PSTN, a través de INAP, en PSTN a través de ISÜP, o en una red de siguiente generación a través de SIP sin efectuar cambios de código) . Además, debe señalarse en específico que el sistema TappS 10 no es limitado a la red de telefonía como lo son algunos de los sistemas de integración de servicio de la técnica anterior y por lo tanto, las sesiones de servicio pueden ser iniciadas en respuesta a eventos sin telefonía tales como las peticiones HTTP, las peticiones de autentificación RADIUS, así como también por medio de otros protocolos. Otra característica perceptible del sistema TappS 10 es que éste mantiene una visión completa de los recursos que están siendo consumidos por todas las sesiones activas y por lo tanto, puede dar prioridad y disminuir el consumo de recursos, tanto para los recursos internos (dentro del sistema TappS 10) como los recursos externos tal como el ancho de banda de red, etc. Esta última característica es la que también permite el control de tráfico determinista, tanto dentro del sistema TappS 10 como entre el sistema TappS 10 y la red. En conclusión, debe entenderse obviamente que la descripción precedente de una modalidad de ejemplo de la presente invención simplemente es de ejemplo. Se anticipa y se espera que una persona de experiencia en la técnica pueda realizar muchas alteraciones y modificaciones de la modalidad de ejemplo y que todavía se encuentren dentro del espíritu y alcance de la presente invención, la cual solamente es determinada con referencia a las reivindicaciones adjuntas a la misma. Se hace constar que con relación a esta fecha el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims (26)

1. REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones : 1. Un sistema distribuido de integración de servicio para redes de comunicación, que es implementado como un servidor de aplicación, caracterizado porque comprende: (a) al menos un módulo que maneja y controla el sistema de integración de servicio, interactuando con cada uno de los módulos que incluyen el sistema de integración de servicio con el prepósito de ejecutar el manejo y el control del mismo; (b) al menos un módulo que envía y recibe mensajes desde y hacia una red; (c) al menos un módulo de entorno de ejecución lógica de servicio; y (d) al menos un módulo de control de recurso, que optimiza el flujo de datos tanto entre los componentes del sistema de integración de servicio, como entre el sistema de integración de servicio y la red, de manera que el elemento de control de recurso sea conectado por lo menos con el módulo que envía y recibe los mensajes desde y hacia una red y con el módulo de entorno de ejecución lógica de servicio; en donde todos los módulos anteriores están interactuando con el equipo requerido del hardware correspondiente con el propósito de ejecutar sus respectivas funciones.
2. 2. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque al menos un módulo, que maneja y controla el sistema de integración de servicio, es separado al menos en un módulo que maneja el sistema de integración de servicio y por lo menos en un módulo que controla el sistema de integración de servicio .
3. 3. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque al menos un módulo, que envía y recibe mensajes desde y hacia una red, es separado por lo menos en un módulo de pasarela y al menos en un elemento de módulo funcional.
4. 4. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque soporta la ejecución asincrónica de los servicios de red.
5. 5. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque la arquitectura distribuida permite la duplicación de los elementos que comprenden el sistema de integración de servicio a fin de proporcionar al menos una condición de las siguientes, que es seleccionada a partir del grupo que consiste de: (a) tolerancia de falla; (b) desempeño; y (c) capacidad.
6. 6. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque se percata, en forma constante, de los recursos consumidos por todas las sesiones manejadas.
7. 7. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque controla la cantidad de recursos distribuidos hacia las distintas sesiones que son manejadas por el sistema de integración de servicio.
8. 8. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque permite el control determinista de tráfico tanto dentro del sistema TappS, como entre el sistema TappS y la red.
9. 9. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque la red es una red de comunicación en tiempo real que transporta el tráfico sensible de tiempo.
10. 10. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque la red es una red de comunicación de datos .
11. 11. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque la red es una red de comunicación híbrida que combina al menos comunicación de voz con comunicación de datos. •
12. 12. El sistema de integración de servicio de conformidad con la reivindicación 3, caracterizado porque al menos un elemento de módulo funcional además comprende: (a) por lo menos un manejador de módulo funcional; y (b) por lo menos un módulo funcional.
13. 13. El sistema de integración de servicio de conformidad con la reivindicación 3, caracterizado porque al menos un módulo de entorno de ejecución lógica de servicio además comprende : (a) por lo menos un controlador de máquina de estado; (b) por lo menos una memoria; y (c) por lo menos una máquina ejecutable de estado.
14. 14. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque al menos un elemento de control de recurso además optimiza el flujo de tráfico de acuerdo con una política predeterminada que es definida por el administrador del sistema.
15. 15. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque al menos un elemento de control de recurso además analiza y almacena las velocidades históricas de consumo de recurso del sistema de los distintos servicios proporcionados por el sistema de integración de servicio y utiliza los datos almacenados para_ la optimización del flujo.
16. 16. El sistema de integración de servicio de conformidad con la reivindicación 1, caracterizado porque tiene la capacidad de realizar al menos una condición de las siguientes, que es seleccionada partir del grupo que consiste de : (a) la distribución de servicios; (b) la ejecución de servicios; y (c) el manejo de servicios.
17. 17. El sistema de integración de servicio de conformidad con la reivindicación 13, caracterizado porque al menos una máquina ejecutable de estado además comprende por lo menos una máquina de estado.
18. 18. Un sistema distribuido de integración de servicio de arquitectura para redes de comunicación, que es implementado como servidor de aplicación, caracterizado porque comprende: (a) al menos un medio que maneja y controla el sistema de integración de servicio, interactuando con una pluralidad de los medios que comprenden el sistema de integración de servicio con el propósito de ejecutar el manejo y el control del mismo; (b) al menos un medio que envía y recibe mensajes desde y hacia una red; (c) al menos un medio que proporciona un entorno de ejecución lógica de servicio con el propósito de ejecutar un servicio; y (d) al menos un medio que optimiza el flujo de datos, tanto entre los componentes del sistema de integración de servicio, como entre el sistema de integración de servicio y la red, de manera que el medio que optimiza el flujo es conectado por lo menos con el medio que envía y recibe mensajes desde y hacia una red y con el medio que proporciona un entorno de ejecución lógica de servicio.
19. 19. El sistema de integración de servicio de conformidad con la reivindicación 18, caracterizado porque tiene la capacidad de al menos realizar una condición de las siguientes, que es seleccionada a partir del grupo que consiste de: (a) la distribución de servicios; (b) la ejecución de servicios; y (c) el manejo de servicios.
20. 20. Un método que proporciona servicios en una red de comunicación, caracterizado porque comprende las etapas de : (a) recibir un nuevo mensaje de la red de comunicación; (b) verificar con un recurso independiente de red centralizada si el nuevo mensaje es una nueva petición de servicio o si es un mensaje que se refiere a un servicio ya en ejecución; _ (c) si el nuevo mensaje se refiere a un servicio ya en ejecución, canaliza el nuevo mensaje hacia el servicio en ejecución al cual pertenece; (d) si el nuevo mensaje es una nueva petición de servicio, canaliza el nuevo mensaje hacia un entorno de ejecución lógica de servicio para la ejecución del servicio requerido, y realizaría las etapas (e) y (f) ; (e) determinar el servicio requerido de los servicios soportados por el sistema de integración de servicio; y (f) ejecutar el servicio determinado.
21. 21. El método de conformidad con la reivindicación 20, caracterizado porque la etapa (f) además comprende las etapas de: (a) registrar las tareas por medio del servicio de ejecución para su desarrollo por el sistema de integración de servicio; (b) procesar las tareas a través del sistema de integración de servicio; y (c) recibir nuevos mensajes por medio del servicio de ejecución desde la red de comunicación y el sistema de integración de servicio.
22. 22. El método de conformidad con la reivindicación 21, caracterizado porque la etapa (b) además comprende las etapas de: - (a) enviar mensajes hacia la red de comunicación; y (b) enviar mensajes hacia el servicio de ejecución.
23. 23. Un método que distribuye nuevos servicios para redes de comunicación, caracterizado porque comprende las etapas de: (a) implementar el nuevo servicio por medio de un código fuente de lenguaje de computadora de alto nivel; (b) compilar el código fuente; y (c) integrar el código compilado de fuente con la red de comunicación por medio de la instalación del código compilado de fuente en una memoria, en donde el nuevo servicio ya está listo para ser ejecutado.
24. 24. Un método que controla el flujo de tráfico, tanto dentro de un sistema de integración de servicio como entre un sistema de integración de servicio y entre el sistema de integración de servicio y una red de comunicación, caracterizado porque comprende las etapas de: (a) determinar las necesidades esperadas de consumo de recurso de una tarea recibida; (b) determinar el nivel de la carga de recurso de los canales externos de red; (c) determinar el nivel de carga de recurso de los canales internos de red; y (d) transmitir un mensaje hacia un canal seleccionado de red de acuerdo con los resultados -recibidos de la realización de las etapas (a) , (b) y (c) .
25. 25. El sistema de integración de servicio de conformidad con la reivindicación 9, caracterizado porque el tráfico sensible de tiempo es tráfico de voz.
26. 26. El sistema de integración de servicio de conformidad con la reivindicación 9, caracterizado porque el tráfico sensible de tiempo es tráfico de video.