MXPA03006025A

MXPA03006025A - Intercambio de mensajes electronicos entre un sistema de computadora central y un sistema distribuido de computadoras.

Info

Publication number: MXPA03006025A
Application number: MXPA03006025A
Authority: MX
Inventors: Virmani Raviv
Original assignee: Delta Air Lines Inc
Priority date: 2001-01-02
Filing date: 2002-01-02
Publication date: 2005-02-14
Also published as: WO2002057942A1; US20040153511A1; WO2002057942A9; EP1348169A1; CA2434258A1

Abstract

Se expone un intercambio de mensajes electronicos entre un sistema de computadora central para procesamiento de transacciones en linea (102) y un sistema distribuido de computadoras (122) sobre una red de comunicaciones (106). Este intercambio de comunicaciones abarca tanto el suministro garantizado de mensajes electronicos como el suministro no garantizado de mensajes para pantalla terminal nativa e impresora, utilizando un equipo para puesta en cola de mensajes. Se utiliza una arquitectura de dos planos para todas las traducciones, bloqueo y reensamble, puesta en cola, reconocimientos y retransmisiones de mensajes, reduciendo en general el procesamiento de mensajes necesario y reduciendo el uso de recursos del sistema.

Description

MENSAJES ELECTRONICOS DE INTERCAMBIO ENTRE UN SISTEMA DE COMPUTADORA CENTRAL Y UN SISTEMA DISTRIBUIDO DE COMPUTADORAS CAMPO TÉCNICO La presente invención en general se relaciona con mensajes electrónicos de intercambio, en un formato definido, entre un sistema de computadora central y un sistema distribuido de computadoras. Más específicamente, la invención soporta tanto el suministro garantizado como el suministro no garantizado de mensajes entre un sistema central de procesamiento de transacción en línea y un sistema distribuido de computadoras utilizando una arquitectura de dos planos y una puesta en cola de mensajes.

ANTECEDENTES DE LA INVENCIÓN La competencia aumentada en la industria de aerolíneas está estimulando el desarrollo de nuevas aplicaciones de tecnología de información, entre las que se incluyen un nuevo enfoque estratégico sobre el comercio electrónico. Además, el viaje por avión se está convirtiendo en un método popular en aumento de viajar para las personas hoy en día. Esta 2 popularidad, junto con la competencia aumentada, ha provocado que el número de viajantes por avión aumente de manera importante dando por resultado en un gran volumen de viajeros que pasan por los aeropuertos de hoy en dia. Por consiguiente, las aerolíneas necesitan formas más eficientes para manejar a sus viajeros, entre las que se incluyen, la implementación más amplia de aplicaciones de comercio electrónico . Tradicionalmente, la- evaluación de grandes compañías en la industria de aerolíneas se ha basado en la utilización de grupos de computadoras centrales que corren software de sistemas de información interna. Por ejemplo, algunas compañías se basan en grupos de computadoras internas IBM S/390 que corren IBM TPF (Equipo para Procesamiento de Transacciones o TPF") (o incluso sistemas anteriores que corren IBM MVS (Almacenamiento Virtual Múltiple o "MVS") ) , ambos sistemas de operación especializados. Estos sistemas para procesamiento de transacción en línea tradicionales ("OLTP", por sus siglas en inglés) soportan aplicaciones que automatizan la mayoría de servicios operacionales de las aerolíneas. Las arquitecturas de sistemas, tales como por ejemplo TPF y MVS, han probado ser bastante escalables y 3 disponibles, y estos sistemas se han operado exitosamente a través de los últimos treinta años y a través de la alerta "de errores" del software Y2K. ? pesar de su confiabilidad y escalabilidad, sin embargo, es difícil modificar estas aplicaciones de software OLTP existentes para adaptarse a una industria cambiante. Muchas de las aplicaciones del software utilizadas en los sistemas OLTP se desarrollaron en lenguaje simbólico de programas y han evolucionado durante un periodo de más de treinta años. Originalmente, estas aplicaciones se diseñaron para implementar modelos de negocios específicos y actualmente ofrecen poca flexibilidad para soportar nuevos modelos de negocios y procesos. Específicamente, estas aplicaciones mantienen la propiedad de conjuntos de datos definidos rígidamente, y sus formatos de datos legados ofrecen poca oportunidad para crear nuevas relaciones con datos provenientes de otras aplicaciones. Adicxonalmente, los nuevos modelos de negocios han dado por resultado en el desarrollo de nuevas aplicaciones del software, algunas de las cuales influyen en la Internet. Estos nuevos modelos de negocios y nuevas aplicaciones de software exponen los sistemas legados a tipos, formatos y volúmenes de 4 transacción imprevistos. En respuesta a estas limitaciones, una estrategia novedosa ha sido la adición de sistemas distribuidos de computadora con base en tecnología más reciente y nuevas aplicaciones' de software. La riqueza de información en los sistemas OLTP existentes se recolecta mediante transacciones estratégicas "de agarre" a medida que se presentan en wtiem o real variable", es decir, prácticamente tiempo real. Estas transacciones luego se transfieren a los sistemas distribuidos de computadora y a las aplicaciones de software distribuido. En este nuevo entorno, los datos resultantes de las transacciones se mapean en formatos desarrollables alternativos y se correlacionan con la información no relacionada anteriormente, así como también, con la información proveniente de fuentes distintas a las de los sistemas OLTP. La correlación intermedia estimula los eventos, que se derivan de los historiales de transacción. Esto permite una clase totalmente nueva de aplicaciones con base en eventos en tiempo real, que ha probado mejorar radicalmente la eficacia de las operaciones de computación en las aerolíneas. El sistema distribuido de computadoras más reciente, 5 considerado conjuntamente con el sistema OLTP legado, sirve como la base por construir nuevas aplicaciones y mejorar las operaciones de los negocios de aerolínea . Sin embargo, el uso de un sistema de distribuido de computadoras con untamente con un sistema OLTP legado, se ve obstaculizado por el hecho de sistemas centrales OLTP nativos actuales estables solos, tales como por ejemplo, aquellos con base en IBM TPF, sólo tienen la capacidad de entablar comunicación con sistemas distribuidos de computadora que utilizan formatos de mensaje ya sea para terminal o impresora. Estos formatos son corrientes de datos de caracteres de texto, en donde los datos se formatean para que se exhiban en una pantalla de la terminal del usuario o para que se impriman en una impresora terminal. Si el usuario final de los datos es realmente una aplicación de software de no sea OLTP, entonces se debe analizar programáticamente una corriente de datos OLTP para que la información crítica necesite utilizar la técnica bien conocida denominada en este campo, "fragmentación en pantalla" . Esta situación es problemática debido a que una aplicación de software en la central OLTP y una 6 aplicación de software ubicada en una estación de trabajo individual o terminal en un sistema distribuido de computadoras será extraer datos específicos con base en su posición dentro de una corriente de datos de caracteres de texto. Ambas aplicaciones también deben entender una variedad de respuestas del error y entender la forma en que responderán programáticamente a estas respuestas. La provisión de este tipo de funcionalidad a cada aplicación distribuida de computadora ha probado ser consumidora de tiempo e ineficiente. ün problema adicional con este tipo de sistemas de f agmentación en pantalla de la técnica convencional existe debido a que los mensajes de la pantalla terminal en general se limitan a la cantidad de información que se pueden exhibir en una pantalla de una terminal de un computador central. Una pantalla terminal de un computador central normalmente se limita en tamaño ya sea a doce (12) o veinticinco (25) líneas de texto por sesenta y cuatro (64) columnas de texto. La transferencia de datos mayor en el formato de mensaje en pantalla terminal requiere de transferencias de mensaje múltiples entre una aplicación central y aplicaciones distribuidas. Otro problema con la comunicación IBM TPF nativa es 7 que los mensajes en la terminal no se consideran por aquellos expertos en la técnica que sean confiables, a medida que no existe un protocolo de mensaje garantizado entre las aplicaciones centrales y las aplicaciones de terminal distribuidas. Como resultado, las aplicaciones distribuidas que utilizan mensajes terminales se ven obligadas a ser diseñadas para que proporcionen una conflabilidad de mensajes. Un sistema exclusivo de la técnica convencional soporta comunicaciones mejoradas de mensajes de sistema central/distribuido al enfrentar algunos de los problemas descritos anteriormente. Este sistema permite que los sistemas centrales IBM TPF y los sistemas distribuidos de computadora intercambien datos en cualquier formato pre-seleccionado utilizando un equipo para puesta en cola de mensajes, confiable, garantizado. El formato de datos pre-seleccionados se coordina entre el sistema central la aplicación distribuida y puede ser, de manera enunciativa texto delimitado, estructurado, de cualquier conjunto de caracteres, datos binarios estructurados y/o alguna combinación de estos formatos y corrientes de datos terminales de texto nativo. Este sistema también proporciona un mecanismo para intercambiar grandes mensajes entre 8 las aplicaciones centrales y distribuidas al fragmentar grandes mensajes provenientes de una aplicación emisora en pequeños bloques de datos para la transmisión y reensamble del mensaje antes de suministrarlo a una aplicación receptor. Debido a que este sistema de la técnica convencional soporta nuevos formatos de mensajes y grandes tamaños de mensaje, se permite que los sistemas centrales y los sistemas distribuidos de computadora . se comuniquen de manera más eficiente, se evita el uso de "fragmentación en pantalla" y se permiten múltiples transferencias de mensaje. Además, el sistema soporta la puesta en cola de mensajes y un protocolo asociado para un suministro garantizado de mensajes, disminuyendo con esto las aplicaciones individuales de esta sobrecarga. De esta forma, una copia de cualquier mensaje particular se mantiene en una cola de mensajes en el envió secundario del sistema hasta que al finalizar la recepción el sistema envía nuevamente un mensaje de reconocimiento. Si el reconocimiento se recibe, el mensaje puesto en cola se suprime. Si el reconocimiento no se recibe, el envío secundario del sistema vuelve a enviar el mensaje puesto en cola. Sin embargo, la arquitectura de este sistema 9 de la técnica convencional requiere de un proceso de acceso ubicado entre el componente para transmisión de mensajes ubicado dentro del sistema de computadora central y el componente para transmisión de mensajes ubicado en diversas computadoras distribuidas, con el fin de permitir alguna de sus características claves. El acceso del sistema se requiere para llevar a cabo los procesos de bloqueando y reensamble de mensajes, traducción de mensajes y puesta en cola de mensajes, y para proporcionar protocolos confiables para la comunicación entre los entornos del sistema central y distribuidos. De esta forma, el acceso del sistema, junto con los componentes del sistema central y distribuido, comprende una arquitectura de tres planos para el suministro garantizado de mensajes electrónicos, en cualquier formato definido entre un sistema central y un sistema distribuido de computadoras. El requerimiento del acceso del sistema agrega un componente adicional a la arquitectura del sistema, requiriendo con esto componentes de hardware y software adicionales y un procesamiento aumentado de cada mensaje electrónico dentro del acceso del sistema. Esto da por resultado en un desempeño del sistema más lento, una operación menos confiable y un sistema menos escalable. 10 También, el proceso de acceso del sistema, junto con la interfaz del programa del sistema para aplicaciones distribuidas, se creó en primer lugar para la plataforma DOS de una computadora personal IBM y luego migró al sistema de operación MICROSOFT WINDOWS y a diversas plataformas UNIX. Como resultado, estos componentes de sistema se estructuraron utilizando técnicas de programación menos eficientes de lo que fueron el común para la naturaleza de tareas individuales del entorno DOS.

Este hecho también limitó el desempeño y escalabilidad de esta solución de la técnica convencional cuando migró a entornos de computación modernos similares al sistema de operación MICROSOFT WINDOWS y a diversas plataformas ÜNIX. También se desarrolló otra interfaz de programación de sistema distribuido exclusiva para utilizarse' con una terminal nativa y corrientes de datos para impresora en combinación con sistemas distribuidos de computadora. La interfaz se diseñó para que funcione con el protocolo para Control de Enlace de Aerolíneas (^ALC", por sus siglas en inglés) que es un protocolo de 6 bitios síncrono, dúplex completo que se soporta por el Sistema para Reservación Programada en Aerolíneas ("PARS", por sus 11 siglas en inglés) de la industria estándar y en el Sistema para Reservación Programada Internacional en Aerolínea de la industria estándar ("IPARS", por sus siglas en inglés) . De esta forma, hasta la fecha, los creadores de aplicaciones distribuidas en la industria de aerolíneas se han visto forzados a seleccionar entre la utilización de la interfaz del primer sistema de mensaje de la técnica convencional observado anteriormente o la interfaz de programa ALC de la técnica convencional. Esta elección presentó un problema para los creadores de estas dos interfaces, mientras que tuvo alguna funcionalidad de traslapamiento, también tuvo alguna f ncionalidad diferente . Por consiguiente, existe una necesidad en la técnica por un método y un sistema que mejorarán adicionalmente la comunicación entre los sistemas centrales OLTP y los sistemas distribuidos de computadoras sobre los sistemas de mensajes de tres planos existentes y la interfaz ALC de la técnica convencional. También existe una necesidad por un sistema que abarcará tanto el suministro no garantizado de mensajes para terminal nativa e impresora y el suministro en el formato de mensaje de la técnica convencional existente a través de un 12 equipo de puesta en cola para mensajes, garantizado, confiable. También existe una necesidad por un sistema que reemplazará la interfaz del primer sistema de mensajes de la técnica convencional y la interfaz del programa ALC de la técnica convencional de tal forma que los creadores de aplicaciones distribuidas para computadora ya no se verán forzados a seleccionar entre dos interfaces diferentes para envió de mensajes. Existe una necesidad adicional en la técnica por un método y un sistema para mensajes electrónicos de ¦ intercambio entre un sistema central sistemas distribuidos para computadora que utilicen técnicas modernas de programación para alcanzar un mejor desempeño y una mayor escalabilidad. Estas técnicas podrían incluir la utilización de mecanismos conducidos por eventos, contra sondeo o lógica de estilo bucle por eventos, y cesiones de comunicación múltiple por multiplexión a través de una conexión física entre los sistemas, central y el distribuido. Por último, existe una necesidad adicional en la técnica por un método y un sistema que elimine la necesidad de un proceso de acceso entre los sistemas central y distribuido con el fin de utilizar de manera más eficiente las fuentes del sistema. 13 SUMARIO DE LA INVENCIÓN La presente invención resuelve los problemas mencionados anteriormente que existen en la técnica convencional al proporcionar un método y un sistema para mensajes electrónicos de intercambio entre un sistema central y los sistemas distribuidos de computadoras que abarca el envió de mensajes tanto a la terminal nativa como a la impresora, asi como también, los formatos para envió de mensajes de la técnica convencional. La presente invención proporciona una elección entre el suministro de mensajes electrónicos garantizado, confiable, via un equipo para puesta en cola de mensajes y un suministro de mensajes electrónicos no garantizado. La presente invención también puede eliminar la necesidad de un proceso de acceso entre los sistemas centrales y distribuido al proporcionar todas las traducciones bloqueo y reensamble de mensajes, puesta en cola, reconocimientos y retransmisiones en los puntos finales de los sistemas central y distribuido, en general reduciendo el proceso para envió de mensajes necesario. Como resultado, la presente invención soporta la funcionalidad que reside dentro del sistema central y 14 el sistema distribuido dando por resultado en una arquitectura para envió de mensajes de dos planos, novedosa. Además, la presente invención proporciona una funcionalidad que soporte tanto la interfaz del sistema para envió de mensajes de tres planos de la técnica convencional como la interfaz ALC de tal forma que los creadores de una aplicación distribuida ya no tengan que elegir entre interfaces para envió de mensa es . La presente invención también puede utilizar técnicas de programación modernas que permitan proporcionar un mejor desempeño y una mayor escalabilidad . Como resultado, la presente invención puede permitir mejores velocidades de rendimiento para envió de mensajes y tiempos de respuesta con la utilización aumentada de recursos de red existentes. Las técnicas de programación utilizadas por la presente invención pueden incluir la " utilización de mecanismos conducidos por eventos contra sondeo o lógica de estilo bucle por eventos y cesiones de comunicación múltiples de multiplexión a través de una conexión física individual entre los sistemas central y el distribuido. La presente invención puede utilizar un sistema de computadora central para procesamiento de 15 transacciones en linea, que incluye al menos una aplicación de programa para computadora central, un sistema distribuido de computadoras, incluyendo al menos una estación de trabajo distribuida para computadoras y al menos una aplicación de programa distribuido para computadoras, y una red que conecte los sistemas de computadora central y distribuida. Además, la presente invención puede utilizar una aplicación para transmisión de mensajes electrónicos central, que incluye una puesta en cola de mensajes y una aplicación para transmisión de mensajes electrónicos de computadora distribuida, que también incluye una puesta en cola de mensajes. La presente invención también utiliza una interfaz de programa distribuido para computadoras, que funciona como una interfaz entre la aplicación para transmisión de mensajes electrónicos distribuidos en la computadora y la aplicación del programa distribuido en la computadora . Utilizando los componentes anteriores, la presente invención soporta un proceso para suministrar mensajes electrónicos entre aplicaciones de programas para computadora central y aplicaciones de programas distribuidos en computadoras. Este proceso se puede iniciar por la generación de un 16 mensaje electrónico en cualquier aplicación de programa para computadora central o una aplicación de programa distribuido para computadoras. Si el proceso requiere un suministro garantizado y el mensaje se inicia en la central, el mensaje se puede hacer pasar a la aplicación para transmisión de mensajes electrónicos central, en donde se procesa antes de transmitirse a través de la red de comunicaciones hacia la aplicación para transmisión de mensajes electrónicos distribuidos en computadora, en donde el mensaje se procesa nuevamente. Además, la aplicación para transmisión central puede utilizar una puesta en cola de mensajes que conserva una copia del mensaje hasta que la recepción se reconoce por la aplicación para transmisión distribuido en computadoras. Si no se recibe un reconocimiento, la central vuelve a enviar el mensaje hasta que sea reconocido. Después, el mensaje se hace pasar a la intexfaz de programas distribuidos en computadora, que a su vez pasa el mensaje a la aplicación del programa distribuido en computadoras. Si el proceso se inicia en la aplicación distribuida en computadoras, el proceso simplemente se invierte, con la aplicación para transmisión distribuida en computadoras que conserva 17 una copia del mensaje en su cola. Cuando el proceso no requiere un suministro garantizado, los mensajes electrónicos se pueden suministrar en un formato para pantalla terminal y/o impresora. En estos casos, el sistema central y los sistemas distribuidos no conservan copias de los mensajes después de que envían desde sus aplicaciones de transmisión respectivas.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 es un diagrama de bloques funcional que ilustra la arquitectura y los componentes de una modalidad de ejemplo de la presente invención. La Figura 2 es un diagrama de flujo lógico que ilustra la interacción y* funcionalidad de la arquitectura y los componentes de la presente invención . La Figura 3 es un diagrama de flujo lógico que ilustra un proceso de ejemplo para el intercambio de un mensaje de petición en formato definido electrónico entre una aplicación de sistema distribuido en computadoras y una aplicación de sistema de computadora central y para garantizar el suministro del mismo. 18 La Figura 4A es una ilustración de los componentes de una petición o mensaje de respuesta en formato definido electrónico de ejemplo utilizado por una modalidad de ejemplo de la presente invención. La Figura 4B es una ilustración de un registro de datos de ejemplo que será intercambiado entre una aplicación de sistemas distribuido en computadoras y una interfaz de programa de ejemplo utilizada por una modalidad de ejemplo de la presente invención. La Figura 4C es una ilustración de un registro de datos de ejemplo que será intercambiado entre una interfaz de programa de ejemplo y una aplicación para transmisión de mensajes del sistema distribuido en computadoras utilizado por una modalidad de ejemplo de la presente invención. La Figura 5 es un diagrama de bloques funcional que ilustra la arquitectura y los componentes utilizados en un proceso para suministro de mensajes de petición en formato definido electrónico llevado a cabo por una modalidad de ejemplo de la presente invención. La Figura 6 es un diagrama de bloques funcional que ilustra la arquitectura y los componentes utilizaron en un proceso para suministro 19 de mensajes de respuesta en formato definido electrónico llevado a cabo por una modalidad de ejemplo de la presente invención. La Figura 7 es una ilustración de los componentes de una petición o bloque de datos de respuesta en formato definido electrónico de ejemplo que serán transferidos entre una aplicación para transmisión de mensajes electrónicos del sistema de computadora central y una aplicación para transmisión distribuida de mensajes utilizados por una modalidad de ejemplo de la presente invención. La Figura 8 es un diagrama de flujo lógico que ilustra un proceso de ejemplo para el intercambio de un mensaje de respuesta en formato definido electrónico entre una aplicación de sistemas de computadora central y una aplicación de sistema distribuido en .computadoras y para garantizar el suministro del mismo. La Figura 9 es un diagrama de flujo lógico que ilustra un proceso de ejemplo para intercambiar una secuencia de petición/respuesta de mensajes electrónicos en un formato de pantalla terminal nativa entre una aplicación de sistema de computadora central y una aplicación de sistema distribuido en computadoras. 20 La Figura 10 es una ilustración de los componentes de un mensaje de respuesta en pantalla terminal electrónica de ejemplo que será transferido entre una aplicación de sistema de computadora central y una aplicación de sistema distribuido en computadoras utilizado por una modalidad de ejemplo de la presente invención. La Figura 11A es una ilustración de los componentes de un bloque de datos para petición en pantalla terminal nativa o impresora electrónica de ejemplo que será transferido entre una aplicación para transmisión de mensajes distribuida y el sistema de computadora central utilizado por una modalidad de ejemplo de la presente invención. La Figura 11B es una ilustración de los componentes de un bloque de datos para respuesta electrónicos en pantalla terminal o impresora que será transferido entre una aplicación de sistema de computadora central y una aplicación para transmisión de mensajes distribuida utilizada por una modalidad de ejemplo de la presente invención. La Figura 12 es un diagrama de bloques funcional que ilustra la arquitectura y los componentes utilizados en un proceso para suministro de mensajes de respuesta en pantalla terminal 21 electrónica llevado a cabo por una modalidad de ejemplo de la presente invención. La Figura 13 es una ilustración de los componentes de un mensaje para petición o respuesta en pantalla terminal electrónica o impresora de ejemplo que será transferido entre una interfaz de programa de ejemplo y la aplicación del sistema distribuido en computadoras utilizada por una modalidad de ejemplo de la presente invención. La Figura 14 es un diagrama -de flujo lógico que ilustra un proceso de ejemplo para el intercambio de un mensaje electrónico en un formato de impresora nativa entre una aplicación de sistema de computadora central y una aplicación de impresora de sistema distribuido en computadoras. La Figura 15 es una ilustración de los componentes de un mensaje de respuesta en impresora electrónica de ejemplo que será transferido entre la aplicación de sistema de computadora central y una aplicación para impresora del sistema distribuido en computadoras utilizada por una modalidad de ejemplo de la presente invención. La Figura 16 es un diagrama de bloques funcional que ilustra la arquitectura y los componentes utilizados en un proceso para suministro 22 de mensajes de respuesta en impresora electrónica llevado a cabo por una modalidad de ejemplo alternativo de la presente invención. La Figura 17 es un diagrama de bloques funcional que representa una arquitectura y los componentes de la interfaz del programa distribuido en computadoras de una modalidad de ejemplo de la presente invención. La Figura 18 es un diagrama de flujo que representa un proceso de ejemplo para procesar un mensaje recibido desde una aplicación. La Figura 19 es un esquema de bloques que representa a una estructura de red distribuida en computadoras semejante a semejante. La Figura 20 es un diagrama de bloques que representa una estructura de red distribuida en computadoras cliente-servidor de ejemplo. La Figura 21 es un diagrama de bloques que representa una estructura de red distribuida en computadoras de cliente-servidor de área amplia de ej emplo . La Figura 22 es un diagrama de bloques que representa un servicio de procesamiento de mensajes solicitados con respuesta síncrona de ejemplo. La Figura 23 es un diagrama de bloques que 23 representa un servicio para procesamiento de mensajes solicitados con respuesta asincrona de ejemplo. La Figura 24 es un diagrama de bloques que representa un servicio para procesamien o de mensajes de enviar y olvidar de ejemplo. La Figura 25 es un diagrama de bloques que representa un servicio para procesamiento de mensajes de publicación-suscripción de ejemplo.

DESCRIPCIÓN DETALLADA DE LAS MODALIDADES DE EJEMPLO La presente invención proporciona un intercambio mejorado de mensajes electrónicos, en cualquier formato definido o en un formato para pantalla terminal o impresora TPF nativo, entre un sistema de computadora central OLTP y un sistema de distribuido en computadoras. Adicionalmente , esto permite el suministro garantizado de mensajes en formato definido utilizando un mecanismo para puesta en cola de mensajes. La presente invención también proporc'iona un suministro no garantizado cuando es conveniente este resultado. En una modalidad de ejemplo, la presente invención proporciona un intercambio de estos mensajes a través de una arquitectura de dos planos que es una mejora con respecto a los sistemas de tres planos de la técnica 24 convencional . Aunque las modalidades de ejemplo descritas en la presente incluyen descripciones generales de módulos de software que corren en un entorno de computación distribuido generalizado, aquellos expertos en la técnica reconocerán que la presente invención se puede implementar en una variedad de configuraciones de hardware y software. En un entrono de computación distribuida, los módulos del programa se pueden ubicar físicamente en diferentes dispositivos de almacenamiento de memoria local y remota. La ejecución de los módulos de programa se puede presentar localmente de una forma independiente o remotamente de una forma cliente/servidor. Ejemplos de estos entornos de computación distribuida incluyen redes de área local de una oficina, redes de computadoras en grandes empresas y la Internet mundial . Haciendo referencia ahora a los dibujos, en los cuales números similares representan elementos similares en todas las diversas figuras, se describirán los aspectos de la presente invención y el entorno de operación preferido. La Figura 1 ilustra la arquitectura y los componentes de una modalidad de ejemplo de la presente invención. En 25 esta modalidad, el sistema 100 comprende un sistema de computadora central 102, un sistema distribuido en computadoras 104 y una red de comunicaciones 106. El sistema de computadora central 102 también comprende al menos una aplicación para programa de computadora central 108, en donde los mensajes electrónicos se pueden generar y/o recibir para procesamiento. El sistema de computadora central 102 también incluye una aplicación para transmisión de mensajes central 110, que también comprende una puesta en- cola de mensajes 112 con el fin de ensamblar y desensamblar mensajes, convertir formatos de mensajes, traducciones de mensajes, puesta en cola, reconocimientos y retransmisiones dentro del sistema de computadora central 102. Además, el sistema de computadora central 102 incluye una aplicación para formateo de salida 114, también comprende una puesta en cola de mensajes 116 y un analizador de mensajes de entrada 118, ambos de los mismos proporcionan funcionalidad para la salida y entrada de mensajes de petición/respuesta en pantalla terminal electrónica. También, el sistema de computadora central incluye una puesta en cola 120 para utilizarse con la transmisión de mensajes electrónicos de respuesta para impresora. 26 El sistema distribuido en computadoras 104 también comprende al menos una estación de trabajo del sistema distribuido en computadoras 122. La estación de trabajo distribuida en computadoras 122 incluye una aplicación para transmisión distribuida de mensajes 124, que comprende además una puesta en cola de mensajes 126, con el fin de ensamblar y desensamblar mensajes, convertir formatos de mensajes, traducciones de mensajes, puesta en cola, reconocimientos y retransmisiones dentro del sistema distribuido en computadoras 104. la estación de trabajo distribuida en computadoras 122 también incluye al menos una aplicación distribuida 128 y una aplicación distribuida en impresoras 130, junto con una impresora terminal 131. Además, la estación de trabajo distribuida en computadoras 122 incluye una interfaz del programa distribuido en computadoras 132 para operar dentro de la aplicación distribuida 128 y la aplicación para transmisión distribuida de mensajes 124. Una de las mejoras de la presente invención con respecto a la técnica convencional que se puede observar en la Figura 1A es la ausencia de un proceso de acceso contenido dentro de la red de comunicaciones 106 y la utilización de la aplicación 27 para transmisión distribuida de mensajes 124 dentro de la estación de trabajo distribuida en computadoras 122. De esta forma, la presente invención comprende una arquitectura de dos planos, es decir, una arquitectura en donde las funciones de ensamblar y desensamblar mensajes se presentan 'únicamente en aplicaciones de programa en dos computadoras 110, 124 dentro del sistema de transferencia total de mensajes según se opone a una arquitectura de tres planos en donde estas funciones se presentan en aplicaciones en tres computadoras. Específicamente, todas las traducciones bloqueo y reensamble de mensajes, puesta en cola, reconocimientos y retransmisiones se presentan en los puntos de origen y término para el suministro de mensajes a través de la red de comunicaciones 106. Los puntos de origen y término incluyen la aplicación para transmisión de mensajes central 110 o el analizador de mensajes de entrada 118 en el sistema de computadora central 102 y la aplicación para transmisión distribuida de mensajes 124 en la estación de trabajo del sistema distribuido en computadoras 122. Esta arquitectura novedosa en general reduce a la mitad la cantidad del procesamiento de mensajes según los sistemas de la técnica convencional requieran el procesamiento de 28 mensajes tanto en un proceso de acceso contenido dentro de la red de comunicación 106 como a través de una aplicación para transmisión de mensajes en el sistema distribuido para computadoras de la técnica convencional. La aplicación para transmisión distribuida de mensajes 124 es una aplicación distribuida por separado y es el punto final de envió de mensajes para la estación de trabajo distribuida en computadoras 122. Todos los mensajes de petición y respuesta electrónicos que se transfieren entre cualquier numero de otras aplicación distribuidas 128 y que corresponden a aplicaciones centrales 108 pasan a través de la aplicación para transmisión distribuida de mensajes 124. La aplicación para transmisión distribuida de mensajes 124 se puede unir a cada una de las otras aplicaciones distribuidas 128 a través de conexiones de comunicación individual para ejemplos múltiples de la interfaz del programa distribuido en computadoras 132 estructurado en cada aplicación distribuida 128. La aplicación para transmisión distribuida de mensajes 124 también se puede unir a la red de comunicación 106 a través de conexiones de comunicación con dispositivos de conexión para red de 29 comunicaciones dentro de la red de comunicación 106 que son bien conocidos en la técnica. Los dispositivos para conexión de la red de comunicaciones son responsables de concentrar mensajes desde muchas estaciones de trabajo distribuidas en computadora 122 sobre conexiones de comunicación de capacidad mayor para el sistema de computadora central TPF 102. La aplicación para transmisión distribuida de mensajes 124 puede tener varias conexiones de comunicación para los dispositivos de conexión de red de comunicaciones según se requiera por las estaciones de trabajo distribuidas en computadora 122 para redundancia o balanceo de carga. Las aplicaciones distribuidas 128 pueden llamar la interfaz del programa distribuido en computadoras 132 para iniciar una cesión para envío de mensajes con el sistema de computadora central 102 creando indirectamente con esto las conexiones de comunicación para los dispositivos de conexión en red de comunicación observados anteriormente. La aplicación para transmisión distribuida de mensajes 124 también comprende una puesta en cola del envío de mensajes 126 que almacena mensajes electrónicos para suministro garantizado dentro de la aplicación 30 distribuida 128 y la aplicación para transmisión de mensajes electrónicos 110 para la retransmisión , en el caso de que un mensaje electrónico se pierda o de otra manera se desconozca por el sistema de computadora central 102. La aplicación para transmisión distribuida de mensajes 124 también proporciona funcionalidad para la traducción y conversión de mensajes de pantalla terminal nativa e impresora entre las aplicaciones distribuidas 128 y las aplicaciones centrales 108. La traducción describe el proceso de convertir caracteres ASCII a EBCDIC (Código de Intercambio Binario-Codificado Decimal Extendido) en campos de texto. EBCDIC es un código IBM para representar caracteres como números. Aunque se utiliza ampliamente en grandes computadoras centrales IBM, la mayoría de las otras computadoras, entre las que se incluyen computadoras personales y computadoras Macintosh con base en MICROSOFT WINDOWS, utilizan códigos ASCII. Sin embargo, aquellos expertos en la técnica apreciarán que esta traducción se podría presentar entre cualquier código utilizado comúnmente, similar a ASCII, y cualquier código exclusivo utilizado por los sistemas OLTP. Específicamente, en una modalidad de ejemplo de la 31 presente invención, la traducción describe el proceso de convertir los caracteres de texto de ASCII a EBCDIC en mensajes de petición electrónica desde las aplicaciones distribuidas 128 para las aplicaciones centrales 108 y convertir los caracteres de texto de EBCDIC a ASCII en mensajes de respuesta electrónica desde las aplicaciones centrales 108 para las aplicaciones distribuidas 128. La conversión describe el proceso de reformar los mensajes de petición electrónica desde el formato distribuido para computadoras de la aplicación distribuida 128 a un formato del sistema de computadora central TPF nativa 102 y reformatear los mensajes de respuesta electrónica provenientes del formato del sistema de computadora central TPF nativa 102 para el formato de interfaz del programa distribuido en computadoras de la aplicación distribuida 128. Una funcionalidad dentro de la aplicación para transmisión distribuida de mensajes 124 soporta su funcionalidad para envió de mensajes electrónicos e incluye la capacidad de configurar la aplicación para transmisión distribuida de mensajes 124 a partir de los archivos de computadora y/o a través de una interfaz electrónica y la capacidad de registrar la actividad para envió de mensajes electrónicos y 32 proporcionar estadísticas a través de archivos de computadora y/o a través de una interfaz electrónica. Además, esta modalidad de ejemplo utiliza una interfaz del programa distribuido en computadoras 132 y envia un mensaje de recepción. La interfaz del programa distribuido en computadoras 132 elimina el requerimiento de que las aplicaciones distribuidas 128 proporcionen ya sea una interfaz para transmisión de mensajes de la técnica convencional o una interfaz ALC al proporcionar una funcionalidad de traducción para cada tipo de formato de la técnica convencional. La interfaz del programa distribuido en computadoras 132, en combinación con la aplicación para transmisión distribuida de mensajes 124, también proporciona la flexibilidad de enviar mensajes con suministro garantizado o suministro no garantizado. De esta forma, la presente invención ahora puede interactuar con el sistema de computadora central 102 utilizando ya sea una terminal central TPF nativa no garantizada o envío de mensajes a impresora y/o envío de mensajes garantizado utilizando mensajes en formato definido, cada uno en donde sea adecuado. La funcionalidad de la interfaz del programa distribuido en computadoras 132 se proporciona a través de un conjunto de funciones de programa de computadora 33 llamado por las aplicaciones distribuidas 128. Las funciones del programa "créate", "send", "sendRequest", "cali", "subscribe", "unsubscribe" , "startMonitor", " stopMonitor" , "isActive", y "destroy", y la función de retro-llamada del programa de aplicación distribuida 128, "handle", comprenden la funcionalidad de la interfaz del programa distribuido en computadoras 132 y se describen en la presente. En una modalidad de ejemplo, la aplicación distribuida 128 llama la función del programa "créate" para iniciar una cesión de envió de mensajes con el sistema de computadora central TPF 102 a través de la aplicación para transmisión distribuida de mensajes 124 y la red de comunicaciones 106. Los detalles de la configuración de la cesión para envió de mensajes se aislan de la aplicación distribuida 128, lo cual simplemente utiliza un nombre de texto para identificar la cesión de envió de mensajes. La interfaz del programa distribuido en computadoras 132 utiliza un archivo para configuración de la computadora, ubicado dentro de la estación de trabajo distribuida en computadoras 122, para hacer referencia a los detalles de configuración de la cesión de envío de mensajes con base en el nombre proporcionado por la aplicación distribuida 128. Los 34 detalles de la configuración de la cesión para envió de mensajes incluyen la información que pertenece al recurso central especifico utilizado durante la cesión de envió de mensajes, incluyendo si la cesión de envió de mensajes es una cesión para terminal o impresora del sistema de computadora central TPF nativa 102, la forma en que la porción central de la cesión para envió de mensajes mapea para un recurso y/o detalles de la red de comunicaciones 106 sobre la creación de conexiones de comunicación entre la interfaz del programa distribuido en computadoras 132 y la aplicación para transmisión distribuida de mensajes 124, y también entre el dispositivo de conexión en red de comunicación y la aplicación para transmisión distribuida de mensajes 124. Las cesiones para envío de mensajes de la terminal del sistema de computadora central terminal TPF nativa se pueden utilizar ya sea para mensajes de petición y respuesta en pantalla terminal nativa o para mensajes de petición y respuesta en formato definido. Los mensajes de petición y respuesta en formato definido se identifican para el sistema de computadora central TPF 102 y la aplicación para transmisión distribuida de mensajes 124 por la presencia de un indicador especial sobre la parte 35 frontal de cada mensaje de petición o respuesta en formato definido. La aplicación distribuida 128, después de preparar un mensaje de petición, puede llamar varias funciones del programa, entre las que se incluyen una función del programa "send", wsendRequest", o "cali" para enviar el mensaje a la aplicación central 108 a través de la aplicación para transmisión distribuida de mensajes 124. La función del programa "send" se utiliza por la aplicación distribuida 128 para enviar mensajes en un solo sentido hacia la aplicación central 108 en donde no se espera ningún mensaje de respuesta. Las funciones del programa "sendRequest" y "cali" se utilizan por la aplicación distribuida 128 para enviar mensajes de petición a la aplicación central 108 en donde se espera un mensaje de respuesta. Las funciones del programa "sendRequest" "cali" difieren en su interacción con la aplicación distribuida 128. Específicamente, la función del programa "sendRequest" es una función asincrona con lo cual la aplicación distribuida 128 proporciona una función de retro-llamada del programa "handle", que se llama por la interfaz del programa distribuido en computadoras 132 para suministrar el mensaje de respuesta después de recibirlo desde la aplicación 36 central 108. La naturaleza asincrona de la función del programa "sendRequest" proporciona un mecanismo para que la aplicación distribuida 128 envié un mensaje' de petición, inmediatamente sigue procesando otras tareas, y será notificada por la interfaz del programa distribuido en computadoras 132, a través de la llamada de la función del programa "handle" de la aplicación distribuida 128, cuando se recibe el mensaje de respuesta desde la aplicación central 108. La función del programa "cali" es una función síncrona. Cuando la función 'del programa "cali" se llama por la aplicación distribuida 128, la aplicación distribuida 128 simultáneamente proporciona un mensaje de petición y una referencia inicializada a un almacenador intermedio de memoria dentro de la estación de trabajo distribuida en computadoras 122 para un mensaje de respuesta correspondiente. Por lo tanto, la interfaz del programa distribuido en computadoras 132 regresará a la referencia del almacenador intermedio de memoria una dirección de memoria para el mensaje de respuesta correspondiente antes de regresar de la función del programa "cali" a la aplicación distribuida 128. La naturaleza síncrona de la función del programa "cali" proporciona un mecanismo para que la aplicación 37 distribuida 128 envíe un mensaje de petición y reciba un mensaje de respuesta a través de una llamada de la interfaz del programa distribuido en computadoras 132 sin utilizar la función de retro-llamada del programa "handle". La función del programa "subscribe" de la interfaz del programa distribuido en computadoras 132 se utiliza por la aplicación distribuida 128 para permitir la recepción de mensajes unidireccionales desde las aplicaciones centrales 108 a través de una función de retro-llamada del programa "handle" proporcionada por la aplicación distribuida 128 cuando se llama la función del programa "subscribe". Este mensaje se suministra y la aplicación distribuida 128 se notifica por la interfaz del programa distribuido en computadoras 132, a través de la llamada de la función del programa "handle" de la aplicación distribuida 128, cuando se recibe un mensaje unidireccional desde la aplicación central 108. La aplicación distribuida 128 puede llamar la función del programa "subscribe" múltiples veces para permitir la recepción de los mensajes en formato definido, los mensajes en pantalla terminal nativa, y/o mensajes en impresora nativa. La función del programa "unsubscribe" se utiliza por la aplicación 38 distribuida 128 para deshabilitar la recepción de los mensajes unidireccionales desde las aplicaciones centrales 108. Las funciones del programa "startMonitor" y "stopMonitor" de la interfaz del programa distribuido en computadoras 132 se utilizan por la aplicación distribuida 128 para permitir y deshabilitar la recepción de mensajes de estado de la interfaz del programa distribuido en computadoras 132 a través de una función de retro-llamada del programa "handle" proporcionada por la aplicación distribuida 128 cuando se llama la función del programa "startMonitor" . Estos mensajes de estado se suministran por la aplicación distribuida 128 y la misma se notifica por la interfaz del programa distribuido en computadoras 132, a través de la llamada de la función de retro-llamada del programa "handle" de la aplicación distribuida 128, cuando el estado de la conexión de comunicación entre la interfaz del programa distribuido en computadoras 132 y la aplicación para transmisión distribuida de mensajes 124 cambia. Estos mensajes de estado informan a la aplicación distribuida 128 si la conexión de comunicación entre la aplicación para transmisión distribuida de mensajes 124 y la interfaz 39 del programa distribuido en computadoras 132 es funcional o no y proporciona a la aplicación distribuida 128 un mecanismo para la notificación del estado actual. La función del programa "isActive" es un mecanismo más directo para que la aplicación distribuida 128 obtenga información de estado que se relaciona con la conexión de comunicación entre la aplicación para transmisión distribuida de mensajes 124 y la interfaz del programa distribuido en computadoras 132 debido a que no proporciona una notificación distinta al simple regreso de una indicación verdadera si la conexión de comunicación es funcional o una indicación falaa si la conexión de comunicación no es funcional. La función del programa "destroy" de la interfaz del programa distribuido en computadoras 132 utilizado por la aplicación distribuida 128 para finalizar una cesión de envío de mensajes con el sistema de computadora central TFP 102. En una modalidad de ejemplo de la presente invención, la aplicación para transmisión distribuida de mensajes 124 y la interfaz del programa distribuido en computadoras" 132 ambas utilizan técnicas modernas de programación que permiten un 40 mejor desempeño y una mayor escalabilidad que los sistemas de la técnica convencional. Una de estas mejoras de programación utilizada por la aplicación para transmisión distribuida de mensajes 124 y la interfaz del programa distribuido en computadoras 132 es el uso de los mecanismos "conducidos por evento" disponibles en las plataformas de sistemas modernos de computadoras. Un ejemplo de un mecanismo conducido por eventos es una notificación del sistema de operación (o función "callback" ) para un programa de computadora cuando ha ocurrido un cierto evento, tal como por ejemplo, el término de un temporizador o la llegada de un mensaje desde una conexión de comunicación, permitiendo que una aplicación permanezca latente hasta que se presente el evento. Los sistemas de la técnica convencional se desarrollaron originalmente para utilizarse con la plataforma DOS de computadoras personales IBM, lo cual no proporcionó mecanismos conducidos por eventos. Como tal, los sistemas de la técnica convencional requieren de un bucle de eventos del programa ejecutado constantemente para determinar si ha expirado un temporizador, si existieron mensajes para envió o recepción, o si existieran otras tareas que serán realizadas. De esta forma, los sistemas de 41 la técnica convencional ocupan constantemente un tiempo de procesamiento distribuido en computadoras que se podría utilizar por otros programas de computadoras cuando los sistemas de la técnica convencional realmente no tienen trabajo de envío de mensajes por realizar. El sistema de operación MICROSOFT WINDOWS y diversos sistemas de operación con base UNIX utilizados por las modalidades de ejemplo de la presente invención proporcionan mecanismos conducidos por eventos de tal forma que la aplicación para transmisión distribuida de mensajes 124 y la interfaz del programa distribuido en computadoras 132 se notifican por el sistema de operación cuando existe un trabajo de envío de mensajes que debe ser realizado, haciendo a la presente invención más eficiente que los sistemas de la técnica convencional. Además, la lógica de estilo bucle de eventos no se utiliza ya sea en la aplicación para transmisión distribuida de mensajes 124 o la interfaz del programa distribuido en computadoras 132, que podría ocupar innecesariamente un tiempo de procesamiento distribuido en computadoras. Todos los procesos funcionales dentro de ambos componentes se conducen mediante notificaciones o funciones de retro-llamada de 42 programas a partir del sistema de operación de la estación de trabajo distribuida en computadoras, dando por resultado en una capacidad de procesamiento en computadora aumentada dentro de la estación de trabajo distribuida en computadoras 122. Otra técnica moderna de programación utilizada por las modalidades de ejemplo de la aplicación para transmisión distribuida de mensajes 124 de la presente invención es la multiplexión de las cesiones de envió de mensajes de la aplicación distribuida múltiple con el sistema de computadora central TPF 102 a través de una conexión de comunicación individual entre la aplicación para transmisión distribuida de mensajes 124 y los dispositivos dentro de la red de comunicaciones 106.

Los sistemas de la técnica convencional se requieren típicamente para crear una conexión de comunicación para cada aplicación del sistema distribuido en ' computadoras/cesión para envío de mensaje central. Como resultado de utilizar las conexiones de comunicación múltiples entre las estaciones de trabajo distribuido en computadoras 122 y los dispositivos de la red de comunicaciones 106, estos dispositivos de conexión en red de comunicaciones soportan estación de trabajo mucho menos distribuidas 43 en computadoras 122, que requieren el uso de dispositivos para conexión en red de comunicación adicional dentro de la red de comunicación 106 dando por resultado en un gasto aumentado para la operación de los sistemas de la técnica convencional. Por el contrario, la aplicación para transmisión distribuida de mensajes 124 mantiene únicamente una conexión de comunicación para cualquier dispositivo de conexión en red de comunicación individual dentro de la red de comunicaciones 106 para todas las cesiones de envió de mensajes del sistema de computadora central asociadas con ese dispositivo individual proveniente de todas las aplicaciones del sistema distribuido en computadoras 128 dentro de una estación de trabajo distribuida en computadoras 122 determinada. La Figura 3 es un diagrama de flujo lógico de un proceso 150 de ejemplo que ilustra la interacción y funcionalidad de la arquitectura de los componentes de la presente invención. En el paso 152, se genera un mensaje electrónico en la aplicación distribuida 128 operando dentro del sistema en computadoras 104. En el paso 154, se convierte una copia del mensaje electrónico en un formato aceptable para transferencia a la aplicación para transmisión distribuida de mensajes 124 por la 44 interfaz del programa distribuido en computadoras 132. En el paso 156, se coloca una copia del mensaje electrónico en una cola de mensajes 126 por la aplicación para transmisión distribuida de mensajes 124. En el paso 158, se transmite el mensaje electrónico sobre la red de comunicaciones 106 entre la aplicación distribuida 128 y la aplicación central 108 por medio de la aplicación para transmisión distribuida de mensajes 124. En el paso 160, se recibe el mensaje electrónico por parte de la aplicación para transmisión de mensajes central 110. En el paso 162, se transmite un mensaje de reconocimiento de recepción electrónica a la aplicación para transmisión distribuida de mensajes 124. En el paso 164, se traduce el mensaje electrónico en un formato de aplicación central pre-seleccionado . En el paso 166, se suministra el mensaje electrónico a la aplicación central 108. la Figura 3 es un diagrama de flujo lógico que ilustra un proceso de ejemplo 200 para intercambiar un mensaje de petición de formato definido electrónico entre la aplicación distribuida 128 y una aplicación central 108 y para garantizar el suministro del mismo. Aunque varios de los procesos de ejemplo descritos en la presente se relacionan con 45 mensajes de pregunta/respuesta, aquellos expertos en la técnica apreciarán que los detalles de una petición proveniente de la aplicación distribuida 128 a la aplicación central 108 y una respuesta proveniente de la aplicación central 108 a la aplicación distribuida 128 cada una también representan el proceso y el flujo de mensajes para el envió de mensajes unidireccionales en cada dirección. En el paso 202, la aplicación distribuida 128 inicia el proceso de ejemplo 200 cuando ya sea un usuario del sistema o la aplicación distribuida 128 inicia una acción que requiere que la información sea intercambiada entre la aplicación central 108 y la aplicación distribuida 128, que necesita una interacción de petición/respuesta entre la aplicación distribuida 128 y la aplicación central 108. En el paso 204, la aplicación distribuida 128 llama la interfaz del programa distribuido en computadoras 132, utilizando la función del programa "créate" para iniciar una cesión de envió de mensajes con el sistema de computadora central TPF 102. La aplicación distribuida 128 especifica un nombre de cesión con base en texto en la función del programa "créate", que luego se utiliza por la interfaz del programa distribuido en computadoras 132 para tener 46 acceso a un archivo de configuración, localizado dentro de la estación de trabajo distribuida en computadoras 122 , con los detalles de la configuración acerca de la cesión para envió de mensajes central. Los detalles de la configuración de la cesión para envió de mensajes central incluyen información que pertenece al recurso central especifico tal como una designación para una cesión para envió de mensajes en la terminal del sistema de computadora central TPF nativa 102, la forma en que la cesión mapea para un recurso de red de comunicaciones, y los detalles sobre la creación de las conexiones de comunicación entre la interfaz del programa distribuido en computadoras 132 y la aplicación para transmisión distribuida de mensajes 124, y también entre el dispositivo de conexión en red de comunicaciones y la aplicación para transmisión distribuida de mensajes 124.

Alternativamente, la cesión para envió de mensajes central se podría iniciar durante el arranque de la aplicación distribuida 128 o en algún otro momento adecuado. Una vez iniciada, la cesión para envío de mensajes central se puede mantener durante la duración de la ejecución de la aplicación distribuida 128 o únicamente para una serie de transferencias de 47 mensajes. Además, la disponibilidad de una cesión para envió de mensajes central se puede proporcionar exclusivamente para la aplicación distribuida 128 o se puede asignar desde un agrupamiento de cesiones centrales disponibles para utilizarse por cualquier aplicación distribuida 128 dentro de la estación de trabajo distribuida en computadoras 122. En el paso 206, la aplicación distribuida 128 prepara un mensaje de petición para obtener información proveniente de la aplicación central 108 utilizando una entrada de datos por el usuario o generada por la aplicación distribuida 128. Como se muestra en la Figura 4A, la cantidad de datos que comprenden una petición en formato definido o mensaje de respuesta puede ser de cualquier tamaño y se representa lógicamente como un archivo de datos 300 con uno o más registros 302a-n, aunque la mayoria de mensajes de petición en el modelo de petición/respuesta únicamente comprenderán un registro. Como se muestra en la Figura 4B, cada uno de los registros individuales 302a-n, o alternativamente el archivo de datos 300 completo, presentados a la interfaz del programa distribuido en computadoras 132 contiene datos de activación relevantes 304 a partir de la aplicación distribuida 48 128 junto con un indicador de secuencia de registro 303, un identificador de aplicación 305, un número de serie 306 para identificar únicamente la petición, un identificador de tipo bloque 307, y un indicador de la longitud de datos de aplicación 308. Los datos de aplicación distribuidos 304 se representan típicamente por cualquier combinación de caracteres ASCII y campos de datos binarios. La aplicación y los identificadores del tipo bloque central 305, 307 son valores previamente acordados por las aplicaciones tanto de envío como de recepción para identificar el contenido del mensaje de petición, es decir, el tamaño y el formato del bloque de datos, y para identificar las aplicaciones centrales y distribuidas 108, 128 para · el enrutamiento de mensajes. El indicador de secuencias de registro 303 indica los registros ''primero", "medio", "último", y/o "únicamente" de un mensaje de petición 300. Los mensajes mayores pueden tener más de un registro con un indicador de secuencia de registro 303 "medio". El número de serie 306 proporciona una forma para que la aplicación de envío haga coincidir un mensaje de respuesta 300 con su mensaje de petición 300 correspondiente. El indicador de longitud de datos de aplicación 308 contiene el número de caracteres 49 dentro de los datos de aplicación 304. La aplicación distribuida 128 puede crear registros de mensaje 302a-n como una corriente de caracteres de datos incluyendo los atributos de identificación 303, 305, 306, 307, 308 y los datos de aplicación distribuida 304. En la alternativa, los registros de mensajes 302a-n se pueden crear al utilizar una funcionalidad proporcionada por la interfaz del programa distribuido en computadoras 132. Para esta modalidad alternativa, la aplicación distribuida 128 simplemente proporciona los datos de aplicación distribuida 304 y los atributos de identificación 303, 305, 306, 307, y 308 a la interfaz del programa distribuido en computadoras 132 como porciones de datos por separado. Regresando a la Figura 3, en el paso 208, la aplicación distribuida 128 nuevamente llama una interfaz del programa distribuido en computadoras 132, utilizando cualquiera de las funciones del programa "send", "sendRequest", o "cali", con el fin de enviar el mensaje de petición 300 completo, o alternativamente,1 cada registro 302a-n de un mensaje de petición 300 al sistema de computadora central 102 y posteriormente a una aplicación central 108. En el paso 210, la interfaz del programa distribuido en 50 computadoras 132 recibe los datos de mensajes desde la aplicación distribuida 128. En el paso 212, la interfaz del programa distribuido en computadoras 132 convierte los datos de mensaje en un formato aceptable a la aplicación para transmisión distribuida de mensajes 124. Como se observa en la Figura 4C, el paso de conversión implica agregar un carácter de comando 310 a la parte frontal del mensaje de petición, que informa a la aplicación para transmisión distribuida de mensajes 124 que éste es un mensaje de petición en formato definido, y agregar un indicador de longitud total 309 a la parte frontal del mensaje de petición para representar la longitud total de la transmisión a la aplicación para transmisión distribuida de mensajes 124. Regresando a la Figura 3, en el paso 213, la interfaz del programa distribuido en computadoras 132 envía el mensaje de petición reformateado a la aplicación para transmisión distribuida de mensajes 124. En el paso 214, la aplicación para transmisión distribuida de mensajes 124 convierte los mensajes de petición 300 que son mayores que el tamaño de registro máximo en varios registros 302a-n. En el paso 215, la aplicación para transmisión distribuida 51 de mensajes 124 segmenta los registros mayores 302a-n en bloques de datos múltiples si el tamaño de registro individual excede el tamaño de bloque de transmisión máximo en la red de comunicación 106. En el paso 216, la aplicación para transmisión distribuida de mensajes 124 encapsula cada bloque de datos en un bloque de datos terminal central TPF nativo 330, como se muestra en la Figura 7, al agregar un indicador de mensajes en formato definido 332 en la parte frontal de cada bloque de datos y un carácter de fin de mensaje 336 en la parte final de cada bloque de datos. En el paso 217, la aplicación para transmisión distribuida de mensajes 124 coloca el mensaje de petición 300 convertido en la puesta en cola 126. En el paso 218, la aplicación para transmisión distribuida de mensajes 124 comienza a enviar una copia de los bloques de datos almacenados en la puesta en cola 126 hacia la aplicación para transmisión de mensajes central 110. En el paso 219, la aplicación para transmisión dé mensajes central 110 elimina los bloques de datos agregados en el paso 216 provenientes del formato de bloques de datos de la terminal central TPF nativa, reensambla cada uno de los bloques de datos en un registro 302a-n y se prepara para hacerlos pasar hacia la aplicación del 52 sistema central 108 adecuado. En el paso 220, la aplicación para transmisión de mensajes central 110, en el momento de la recepción de un registro 302a-n completo, genera y envía un mensaje de reconocimiento a la aplicación para transmisión distribuida de mensajes 124. En el paso 224, la aplicación para transmisión distribuida de mensajes 124 pregunta si ha recibido un mensaje de reconocimiento proveniente de la aplicación para transmisión de mensajes central 110. Si es así, en el paso 225 la aplicación para transmisión distribuida de mensajes 124 pregunta si el registro 302a-n "último" del mensaje de petición 300 se ha transmitido exitosamente al buscar un indicador de secuencia de registro 303 "último". Si se localiza el indicador de secuencia de registro 303 "último", en el paso 226 la aplicación para transmisión distribuida de mensajes 124 suprime el mensaje de petición 300 de la puesta en cola 126. Si no se localiza el indicador de secuencia de registro "último", en el paso 228 el proceso de ejemplo 200 entonces repite las tareas en los pasos 218, 219, 220 para cada registro 302a-n posterior hasta que todos los registros se hallan transmitido. Si, en el paso 224, no se recibe ningún reconocimiento para ningún 53 registro 302a-n determinado, en el paso 230 el proceso 200 regresa nuevamente al paso 218 y la aplicación para transmisión distribuida de mensajes 124 vuelve a enviar el registro no reconocido hacia la aplicación' para transmisión de mensajes central 110. La Figura 5 es un diagrama de bloques del proceso para transferencia de mensaje de petición entre la aplicación para transmisión distribuida de mensajes 124 y la aplicación para transmisión de mensajes central 110. En este caso, la aplicación para transmisión distribuida de mensajes 124 ya recibió un mensaje de petición 300 proveniente de la interfaz del programa distribuido en computadoras 132 que consiste de varios registros 302a-n que se han almacenado en la puesta en cola 126. La aplicación para transmisión distribuida de mensajes 124 luego desensambla el "primer" registro 302a en varios bloques de datos 316, que se transmiten sobre la red de comunicaciones 106 hacia la aplicación para transmisión de mensajes central 110. Como se observó anteriormente, un registro 302a-n se segmenta en pequeños bloques de datos 316 cuando el tamaño del registro excede el tamaño de bloque de transmisión máximo de la red de comunicación 106. Una- vez que la 54 aplicación para transmisión de mensajes central 110 ha recibido y reensamblado los bloques de datos 316 en un registro 302a-n completo, y ha colocado el registro en la puesta en cola 112, la aplicación para transmisión de mensajes central 110 genera y envía un mensaje de .reconocimiento 318 a la aplicación para transmisión distribuida de mensajes 124. Si el mensaje de reconocimiento 318 no se recibe por la aplicación para transmisión distribuida de mensajes 124, el registro 302a-n relevante se vuelve a transmitir a la aplicación para transmisión de mensajes central 110. El proceso se repite para cada registro 302a-n del mensaje de petición 300. Una vez que todos los registros 302a-n se suministran exitosamente, la aplicación para transmisión distribuida de mensajes 124 suprime el mensaje de petición 300 de la puesta en cola 126. La Figura 6 es una ilustración de un diagrama de bloques del proceso de transferencia de mensajes de respuesta entre la aplicación para transmisión de mensajes central 110 y la aplicación para transmisión distribuida de mensajes 124. En este caso, la aplicación para transmisión de mensajes central 110 ya ha recibido un mensaje de respuesta 300 desde una aplicación central 108 que consiste de 55 varios registros 302a-n que se han almacenado en la puesta en cola 112. La aplicación para transmisión de mensajes central 110 luego desensambla el "primer" registro 302a en varios bloques de datos 320, que se transmiten sobre la red de comunicaciones 106 hacia la aplicación para transmisión distribuida de mensajes 124. Como se observó anteriormente, un registro 302a-n se segmenta en pequeños bloques de datos 320 cuando el tamaño de registro excede el tamaño del bloque de transmisión máximo de la red de comunicaciones 106. Una vez que la aplicación para transmisión distribuida de mensajes 124 ha recibido y reensamblado los bloques de datos 320 en un registro completo 302a-n, y ha colocado el registro en la puesta en cola 126, la aplicación para transmisión distribuida de mensajes 124 genera y envia un mensaje de reconocimiento 322 hacia la aplicación para transmisión de mensajes central 110. Si el mensaje de reconocimiento 322 no se recibe por la aplicación para transmisión de mensajes central 110, el registro 302a-n se vuelve a transmitir a la aplicación para transmisión distribuida de mensajes 124. El proceso se repite para cada registro 302a-n del mensaje de petición 300. Una vez que todos los registros 302a-n se suministran exitosamente, la aplicación para 56 transmisión central 110 suprime el mensaje de petición 300 de la puesta en cola 112. La Figura 8 es un diagrama de flujo lógico que ilustra un proceso de ejemplo para intercambiar un mensaje de respuesta en formato definido electrónico entre un sistema de computadora central 102 y una aplicación del sistema distribuido en computadoras 104 y para garantizar el suministro del mismo. En el paso 401, la aplicación para transmisión de mensajes central 110 recibe bloques de datos 330 desde la aplicación para transmisión distribuida de mensajes 124. En el paso 402, la aplicación para transmisión de mensajes central 110 reensambla los bloques de datos 330 en registros 302a-n individuales y da reconocimiento a cada registro para la aplicación para transmisión distribuida de mensajes 124. En el paso 404, la aplicación para transmisión de mensajes central 110 evalúa el identificador de la aplicación central 305 para determinar la identidad de la aplicación central 108 relevante. En el paso 406, la aplicación para transmisión de mensajes central 110 traduce los datos de la aplicación distribuida 304 en un formato que se puede utilizar por la aplicación central 108 57 relevante. Esta traducción normalmente incluye la traducción de caracteres ASCII para EBCDIC (Código de Intercambio Binario-Codificado Decimal Extendido) en campos de texto. EBCDIC es un código IBM para representar caracteres como números. Aunque se utiliza ampliamente en grandes computadoras centrales IBM, la mayoría de las otras computadoras, entre las que se incluyen computadoras PC y Macintosh con base en MICROSOFT WINDOWS, utilizan códigos ASCII. Sin embargo, aquellos expertos en la técnica apreciarán que esta traducción podría presentarse entre cualquier código utilizado comúnmente, similar a ASCII, y cualquier código exclusivo utilizado por sistemas OLTP. Además, esta traducción normalmente requiere permutar el orden de los caibos binarios de caracteres múltiples en el sistema de computadora central 102 y los datos binarios almacenados en la aplicación distribuida 128 de manera diferente. En el paso 408, los registros 302a-n traducidos se colocan en la puesta en cola 112. En el paso 410, la aplicación para transmisión de mensajes central 110 comienza a suministrar los registros 302a-n a la aplicación central 108 relevante con base en el análisis de la aplicación para transmisión de mensajes central del 58 identificador de aplicación central 305. En el paso 412, después de recibir el mensaje de petición 300 completo, la aplicación central 108 relevante procesa el mensaje de petición 300. En el paso 414, la aplicación central 108 relevante crea un mensaje de respuesta para la transmisión hacia la aplicación distribuida 128. En el paso 416, la aplicación central 108 relevante llama la aplicación para transmisión de mensajes central 110 para que manipule la transmisión del mensaje de respuesta 300. En el paso 418, la aplicación central 108 relevante transmite el mensaje de respuesta a la aplicación para transmisión de mensajes central 110. En el paso 420, la aplicación para transmisión de mensajes central 110 traduce el mensaje de respuesta 300 en el formato requerido por la aplicación distribuida 128. En el paso 422, la aplicación para transmisión de mensajes central 110 coloca el mensaje de respuesta 300 traducido en la puesta en cola 112. El mensaje de respuesta 300 normalmente comprenderá múltiples registros 302a-n, cada uno conteniendo datos de aplicación central 304, el indicador de secuencia de registros 303, el identificador de aplicación distribuida 305, el número de serie 306 y la longitud de los datos de 59 aplicación 308. En el paso 424, después de colocar en la puesta en cola los registros 302a-n, la aplicación para transmisión de mensajes central 110 segmenta los registros mayores en bloques de datos 330 múltiples, más pequeños, cuando el tamaño de registro excede el tamaño del bloque de transmisión máximo de la red de comunicaciones 106. En el paso 425, la aplicación para transmisión de mensajes central 110 encapsula cada uno de los bloques de datos en un bloque de datos para terminal central TPF nativa, como se muestra en la Figura 7, al agregar un indicador de mensajes en formato definido 332 en la parte frontal de cada uno de los bloques de datos y un carácter para fin de mensaje 336 al final de cada uno de los bloques de datos. En el paso 426, la aplicación para transmisión de mensajes central 110 comienza a enviar los bloques de datos 330 secuencialmente a la aplicación para transmisión distribuida de mensajes 124. En el paso 428, la aplicación para transmisión distribuida de mensajes 124 elimina cada uno de los bloques de datos agregados en el paso 425 del formato de bloque de datos terminal central TPF nativa, reensambla los bloques de datos 330 en un registro 302a-n, y coloca el registro 302a-n en la puesta en 60 cola 126. En el paso 430, la aplicación para transmisión distribuida de mensajes 124, en el momento de la recepción de un registro 302a-n completo, genera y envía un mensaje de reconocimiento hacia la aplicación para transmisión de mensajes central 110. En el · paso 432, la aplicación para transmisión de mensajes central 110 pregunta si ha recibido un mensaje de reconocimiento desde la aplicación para transmisión distribuida de mensajes 124. Si es así, en el paso 433 la aplicación para transmisión de mensajes central 110 pregunta si el "último" registro 302a-n del mensaje de respuesta 300 se ha transmitido exitosamente al buscar un "ultimo" indicador de secuencia de registro 303. Si se localiza un "ultimo" indicador de secuencia de registro, en el paso 436 la aplicación para transmisión de mensajes central 110 suprime el mensaje de respuesta 300 de la puesta en cola 112. Si no se localiza un "último" indicador de secuencia de registro 303, en el paso 435, el proceso de ejemplo 400 entonces repite las tareas en los pasos 426, 428, y 430 para cada registro 302a-n posterior hasta que todos los registros se hayan transmitido. Si, en el paso 432, no se recibe ningún 61 reconocimiento para ningún registro 302a-n determinado, en el paso 431 el proceso 400 nuevamente regresa al paso 426 y la aplicación para transmisión de mensajes central 110 vuelve a enviar el registro no reconocido hacia la aplicación para transmisión distribuida de mensajes 124. En el paso 436, la aplicación para transmisión distribuida de mensajes 124 convierte el mensaje de respuesta en un formato aceptable para la interfaz del programa distribuido en computadoras 132. El paso de conversión implica agregar un carácter de comando 310 a la parte frontal del mensaje, que informa a la interfaz del programa distribuido en computadoras 132 que éste es un mensaje de respuesta en formato definido, y agregar un indicador de longitud total 309 a la parte frontal del mensaje de petición para representar la longitud total de la transmisión hacia la interfaz del programa distribuido en computadoras 132. En el paso 438, la aplicación para transmisión distribuida de mensajes 124 envía cada registro 302a-n del mensaje de respuesta 300 hacia la interfaz del programa distribuido en computadoras 132. En el paso 440, la interfaz del programa distribuido en computadoras 132 pasa cada uno de los registros 302a-n del mensaje de 62 respuesta 300 a la aplicación distribuida 128. Los registros 302a-n se pasan a la aplicación para completar la función del programa "cali" de la interfaz del programa distribuido en computadoras 132 o a través de la función de retro-llamada del programa de manipulación de la aplicación distribuida 128 utilizada con las funciones del programa "sendRequest" o "subscribe". Una vez que cada uno de los registros 302a-n del mensaje de respuesta 300 se haya suministrado a la aplicación distribuida 128, el proceso de ejemplo 400 termina. La Figura 9 es un diagrama de flujo lógico que ilustra un proceso de ejemplo 500 para el intercambio de una secuencia de mensajes de petición/respuesta electrónicos en un formato de pantalla terminal nativa entre una aplicación de sistema distribuido en computadoras 128 y un sistema de computadora central 102 sin suministro garantizado del mismo. Aunque varios de los procesos de ejemplo descritos en la presente se relacionan con mensajes de petición/respuesta, aquellos expertos en la técnica apreciarán que los detalles de una petición proveniente de la aplicación distribuida 128 hacia la aplicación central 108 y una respuesta proveniente de la aplicación central 108 hacia la aplicación 63 distribuida 128 cada uno también representan el proceso y el flujo de mensajes para el envió de mensajes unidireccionales en cada dirección. En el paso 502, la aplicación distribuida 128 inicia el proceso de ejemplo 500 cuando ya sea un usuario de sistema o la aplicación distribuida 128 inicia una acción que requiere que la información se intercambie entre la aplicación distribuida 128 y la aplicación central 108, que necesita una interacción de petición/respuesta entre la aplicación distribuida 128 y la aplicación central 108. En el paso 504, la aplicación distribuida 128 llama la interfaz del programa distribuido en computadoras 132, utilizando la función del programa "créate", para iniciar una cesión de envío de mensajes con el sistema de computadora central TPF 102. La aplicación distribuida 128 especifica un nombre para la cesión basada en texto en la función del programa "créate", que la interfaz del programa distribuido en computadoras 132 utiliza para tener acceso a un archivo de configuración, localizado dentro de la estación de trabajo distribuida en computadoras 122, con detalles de configuración acerca de la cesión para envío de mensajes central. Los detalles de configuración de la cesión para envío de mensajes 64 central incluye información que pertenece al recurso especifico tal como por ejemplo una designación para una cesión de envió de mensajes a la terminal del sistema de computadora central TPF nativa 102, la forma en que la cesión mapea para un recurso de red de comunicación, y los detalles sobre la creación de las conexiones de comunicación entre la interfaz del programa distribuido en computadoras 132 y la aplicación para transmisión distribuida de mensajes 124, y también entre un dispositivo de conexión red de comunicación y la aplicación para transmisión distribuida de mensajes 124. Alternativamente, la cesión para envió de mensajes central se podria iniciar durante el arranque de la aplicación distribuida 128 o en algún otro momento adecuado.

Una vez iniciada, la cesión central se puede mantener durante la duración de la ejecución de la aplicación distribuida 128 o únicamente para una serie de transferencias de mensajes. Además, la disponibilidad de una cesión para envió de mensajes central se puede proporcionar exclusivamente para la aplicación distribuida 128 o distribuir desde un agrupamiento de cesiones para envió de mensajes central disponible para utilizarse por cualquier aplicación distribuida 128 dentro de la estación de 65 trabajo distribuida en computadoras 122. En el paso 508, la aplicación distribuida 128 prepara un mensaje de petición 640, como se observa en la Figura 13, para obtener la información proveniente de la aplicación central 108 utilizando una entrada de datos por parte del usuario o generada por la aplicación distribuida 128. En este proceso de ejemplo 500, el mensaje de petición 640 puede ser ya sea una pantalla terminal de datos (en general hasta 12 lineas de caracteres por 65 columnas de caracteres o 768 caracteres en total) o un tipo especial de petición codificada que consta de un carácter individual. Como se observa en la Figura 13, ambos tipos de mensajes de petición constan de un mensaje individual que contiene un indicador de secuencia de registro 644, los datos para la pantalla terminal 642, y un indicador de longitud de datos de aplicación 649. Los caracteres para control de pantalla 646, 648 no se utilizan para mensajes de petición. ün indicador de secuencia de registro 644 para mensajes de pantalla terminal siempre es el indicador "único" a medida que los mensajes para petición en pantalla terminal se limitan a un mensaje individual. El indicador de secuencia de registro 644 para el mensaje de petición codificado siempre es 66 el indicador "medio" según se requiera por la aplicación central 108 que procesa estos tipos de peticiones. Los datos para ambos tipos de peticiones son caracteres en texto ASCII. En el paso 512, la aplicación distribuida 128 nuevamente llama la interfaz del programa distribuido en computadoras 132, utilizando cualquiera de las funciones del programa "send", "sendRequest", o "cali", con el fin de envía el mensaje de petición en pantalla terminal 640 a la interfaz del programa distribuido en computadoras 132. En el paso 514, la interfaz del programa distribuido en computadoras 132 convierte el mensaje de petición 640 en un formato aceptable con la aplicación para transmisión distribuida de mensajes 124. El paso de conversión implica agregar un carácter de . comando 310 a la parte frontal del mensaje de petición, que informa a la aplicación para transmisión distribuida de mensajes 124 que el mensaje de petición es un mensaje de petición de terminal nativa, y agregar un indicador de longitud total 309 a la parte frontal del mensaje de petición para que represente la longitud total de la transmisión hacia la aplicación para transmisión distribuida de mensajes 124. En el paso 515, la 67 interfaz del programa distribuido en computadoras 132 envia el mensaje de petición reformateado a la aplicación para transmisión distribuida de mensajes 4 124. En el paso 516, la aplicación para transmisión distribuida de mensajes 124 traduce el mensaje de petición de caracteres ASCII a EBCDIC, es decir, en el formato del sistema central TPF nativo. En el paso 518, la aplicación para transmisión distribuida de mensajes 124 forma el bloque de datos para petición de la terminal central TPF nativa 610, como se muestra en la Figura 11A, al convertir el indicador de secuencia de registro 644 en un final del carácter de mensaje 614. En el paso 520, la aplicación para transmisión distribuida de mensajes 124 envia el bloque de datos para petición en pantalla terminal nativa 610 sobre la red de comunicaciones 106 hacia el sistema de computadora central 102 para procesamiento. En el paso 522, el sistema de computadora central 102 recibe el bloque de datos 610 en un analizador de mensajes de entrada 118. En el paso 524, el analizador de mensajes de entrada 118 evalúa el contenido del bloque de datos 610 y determina la aplicación central 108 relevante a la cual se enviará el bloque de datos 610. En el paso 526, el analizador de mensajes de entrada 118 68 pasa el bloque de datos de terminal nativa 610 a la aplicación central 108 relevante. En el paso 528, la aplicación central 108 relevante procesa el bloque de datos de petición en terminal nativa 610. En el paso 530, la aplicación central 108 relevante crea un mensaje de respuesta en pantalla terminal. En el paso 532, la aplicación central 108 relevante envía el mensaje de respuesta a una aplicación para formateo de salida 114. En el paso 534, la aplicación para formateo de salida 114 convierte el mensaje de respuesta en una serie de pantallas terminales de datos (en general hasta 12 lineas de caracteres por 65 columnas de caracteres o 768 caracteres en total) como se muestra en la Figura 10. En el paso 536, la aplicación para formateo de salida 114 coloca la serie de pantallas terminales en la cola de mensajes terminales 116. En el paso 537, la aplicación para formateo de salida 114 segmenta grandes respuestas en pantalla en múltiples bloques de datos 620 si el tamaño de la pantalla excede el tamaño de bloque de transmisión máximo sobre la red de comunicación 106. En el paso 538, la aplicación para formateo de salida 114 comienza a enviar los bloques de datos asociados con la primera de la serie de pantallas terminales hacia la aplicación para 69 transmisión distribuida de mensajes 124 a través de la red de comunicaciones 106. En el paso 540, la aplicación para transmisión distribuida de mensajes 124 recibe cada uno de los bloques de datos que comprenden el mensaje de respuesta en pantalla terminal 600. En el paso 544, la aplicación para transmisión distribuida de mensajes EBCDIC 124 traduce los datos del mensaje en pantalla 622 a formato ASCII y convierte el final del carácter de mensaje 624 a un indicador para secuencia de registro 644. El indicador de secuencia de registro 644 indica un bloque de datos "medio" o "último" y/o "único" del mensaje de respuesta distribuido en computadoras 640. El "primer" indicador de secuencia de registro 303 no se utiliza con los mensajes de respuestas en pantalla terminal. En el paso 545, la aplicación para transmisión distribuida de mensajes 124 convierte el mensaje en un formato aceptable para la interfaz del programa distribuido en computadoras 132. El paso de conversión implica agregar un carácter de comando 310 a la parte frontal de cada uno de los bloques de datos, que informa a la interfaz del programa distribuido en computadoras 132 que el mensaje de respuesta es un mensaje de respuesta en pantalla 70 terminal nativa, y agregar un indicador de longitud total 309 a la parte frontal del mensaje de petición para que represente la longitud total de la transmisión hacia la interfaz del programa distribuido en computadoras 132. En el paso 546, la aplicación para transmisión distribuida de mensajes 124 envía los bloques de datos de mensaje de respuesta en pantalla terminal 620 reformateados a la interfaz del programa distribuido en computadoras 132. En el paso 548, la interfaz del programa distribuido en computadoras 132 pasa los mensajes de respuesta en pantalla terminal 640 a la aplicación distribuida 128. Los mensajes de respuestas se pasan a la aplicación para completar la función del programa "cali" de la interfaz del programa distribuido en computadoras 132 o a través de la función de retro-llamada del programa "handle" de la aplicación distribuida 128 utilizada con las funciones del programa "sendRequest" o "subscribe". En el paso 550, la aplicación distribuida 128 utiliza el indicador de secuencia de registro 644 para reconstruir el mensaje para formar un mensaje de respuesta en pantalla terminal 600 completo. En el paso 552, la aplicación distribuida 128 ya sea analiza los datos para uso adicional por parte del 71 usuario o la aplicación o, si se exhibe la información en una pantalla terminal, utiliza los caracteres para control de pantalla 646, 648 para determinar la colocación y comportamiento en pantalla. En el paso 553, la aplicación distribuida 128 pregunta, en el momento de la petición por parte del usuario o por la decisión dentro de la aplicación distribuida 128, si los mensajes en pantalla terminal 600 adicionales son para ser solicitados. En el paso 554, la aplicación distribuida 128 genera un mensaje de petición adicional que se enruta hacia la aplicación para formateo de salida 114 a través de la interfaz del programa distribuido en computadoras 132 y la aplicación para transmisión distribuida de mensajes 124 para solicitar que el siguiente mensaje de respuesta en pantalla terminal se envié desde la aplicación para formateo de salida 114 hacia la aplicación distribuida 128. El proceso de ejemplo 500 entonces regresa al paso 538 y repite los pasos del proceso hasta que todos los mensajes de respuesta en pantalla terminal 600 se hallan transmitido a la aplicación distribuida 128. La Figura 10 ilustra un mensaje de respuesta en pantalla terminal 600, que puede consistir de varios bloques de datos 602a-n en pantalla terminal 72 central TPF nativa. La Figura 11A ilustra un bloque de datos de petición en pantalla terminal nativa 610 entre la aplicación para transmisión distribuida de mensajes 124 y el sistema de computadora central 102. Un mensaje de petición en pantalla terminal proveniente de una aplicación distribuida 128 se limita al tamaño de un bloque de datos en pantalla terminal nativa 610 y consiste de los datos en pantalla terminal 612 representados como caracteres ASCII y un final del carácter de mensaje 614 que indica cualquier mensaje "medio" o "último" y/o "único de una petición. La Figura 11B ilustra un bloque de datos de respuesta para pantalla o impresora terminal nativa 620 entre un sistema de computadora central 102 y la aplicación para transmisión distribuida de mensajes 124. Los bloques de datos de respuesta en pantalla terminal 620 o los bloques de datos de respuesta para impresora 620 consisten de los datos para pantalla o impresora terminal 622 representados como caracteres EBCDIC, un final del carácter de mensaje 624, y dos caracteres para control de pantalla 626, 628. El final del carácter de mensaje 624 para los bloques de datos de respuesta en pantalla o impresora terminal 620 indica cualquier mensaje "medio" o "último" y/o 73 "único" de una respuesta. Los caracteres para control de pantalla 626, 628 se utilizan por una aplicación distribuida en pantalla terminal 124 para determinar la colocación y comportamiento en pantalla para los datos en pantalla terminal 622. La Figura 12 es una ilustración de un diagrama de blogues del proceso para transferencia de mensajes de respuesta en pantalla terminal nativa entre una aplicación central 108 y una aplicación distribuida 128. üna aplicación para formateo de salida central 630 ya ha recibido un mensaje de respuesta proveniente de la aplicación central 108 y ha colocado el mensaje de respuesta en la puesta en cola para mensajes terminal 632. El mensaje de respuesta puede consistir de múltiples pantallas terminales 634a-n. La aplicación para formateo de salida central 630 envía la primera pantalla terminal 634a hacia la aplicación distribuida 128 como un mensaje de respuesta hacia el mensaje para petición en pantalla terminal. Las pantallas terminales 634b-n posteriores se envían a la aplicación distribuida 128 como mensajes de respuesta a los mensajes de respuesta en pantalla terminal adicional que preguntan por las pantallas terminales 634b-n adicionales. 74 La Figura 13 ilustra mensajes de petición y respuesta en pantalla o impresora terminal nativa 640 que se transfieren entre una aplicación distribuida 128 y la interfaz del programa distribuido en computadoras 132. Un mensaje de respuesta 640 consiste de datos para pantalla o impresora terminal 642 representados como caracteres ASCII, un indicador para secuencia de registro 644, dos caracteres para control de pantalla 646, 648, y un indicador de longitud de datos 649. El indicador de secuencia de registro 644 indica el mensaje de petición o respuesta 640 ¦"medio", "último" y/o "único". Los caracteres para control de pantalla 646, 648 son sólo válidos para los mensajes de respuesta en pantalla terminal 640 y se utilizan por una aplicación distribuida en pantalla terminal 124 para determinar la colocación y comportamiento en pantalla para los datos en pantalla terminal 642. La Figura 14 es un diagrama de flujo lógico que ilustra un proceso de ejemplo 700 para el intercambio de un mensaje electrónico en un formato de impresora nativa entre un sistema de computadora central 102 y una aplicación distribuida en impresoras 130. La Figura 15 ilustra un mensaje para 75 respuesta en impresora 750 que puede ser cualquier número de caracteres y puede consistir de bloques de datos en impresora central TPF nativa múltiple 702a-n. Será evidente para aquellos expertos en la técnica que, aunque estos mensajes son mensajes unidireccionales provenientes del sistema de computadora central 102 hacia una aplicación distribuida en impresoras 130, los mismos se pueden iniciar por una aplicación central 108 o alternativamente, se pueden iniciar por una aplicación distribuida por separado 128 como una secuencia de petición/respuesta en terminal nativa que instruya a la aplicación central 108 para que construya un mensaje en impresora 750 a partir del mensaje en pantalla terminal puesta en cola actualmente y enviar el mensaje en impresora 750 a una impresora terminal 131 unida a la estación de trabajo distribuida en computadoras 122. De esta forma, en el paso 701, una aplicación distribuida en impresoras 128 llama la interfaz del programa distribuido en computadoras 132, utilizando la función del programa "créate", para iniciar una cesión de envió de mensajes con el sistema de computadora central TPF 102. La aplicación distribuida en impresoras 130 especifica un nombre de 76 cesión con base en texto en la función del programa "créate", el cual la interfaz del programa distribuido en computadoras 132 utiliza para tener acceso a un archivo de configuración, ubicado dentro de la estación de trabajo distribuida en computadoras 122, con los detalles de configuración acerca de la cesión para envió de mensajes central. Los detalles de configuración de la cesión para envío de mensajes central incluyen la información que pertenece al recurso central específico tal como por ejemplo, una designación para una cesión para envío de mensajes en impresora del sistema de computadora centra TPF nativa 102, la forma en que la cesión para envío de mensajes mapea a un recurso de red de comunicación, y los detalles sobre la creación de las conexiones de comunicación entre la interfaz del programa distribuido en computadoras 132 y la aplicación para transmisión distribuida de mensajes 124, y también entre el dispositivo de conexión en red de comunicaciones y la aplicación para transmisión distribuida de mensajes 124. En el paso 702, la aplicación distribuida en impresoras 130 llama a la interfaz del programa distribuido en computadoras 132, utilizando la función del programa "subscribe", para que comience a recibir mensajes de respuesta en 77 impresora nativa unidireccionales desde el sistema de computadora central TPF 102. En el paso 703, una aplicación central 108 genera un mensaje de respuesta en impresora 750. En el paso 704, el mensaje de respuesta en impresora 750 se segmenta en múltiples bloques de datos de respuesta en impresora central TPF nativa 620 si el tamaño del mensaje de respuesta en impresora excede el tamaño de bloque de transmisión máximo sobre la red de comunicaciones 106. En el paso 706, los bloques de datos se almacenan en una puesta en cola de impresora central 120. En el paso 708, una copia de cada uno de los bloques de datos 620 se transmite secuencialmente hacia la aplicación para transmisión distribuida de mensajes 124 a través de la red de comunicaciones 106. Los bloques de datos 620 están en un formato de impresora central TPF nativa, es decir, caracteres de datos de mensaje EBCDIC 622, un final del carácter de mensaje 624 y dos caracteres para control de pantalla 626, 628. Este formato es el mismo que el de los bloques de datos de mensajes de respuesta en pantalla terminal nativa como se muestra en la Figura 1. En el paso 710, la aplicación para transmisión distribuida de mensajes 124 recibe cada 78 uno de los bloques de datos 620 del mensaje de respuesta en impresora 750. En el paso 712, la aplicación para transmisión distribuida de mensajes 124 traduce los datos del mensaje EBCDIC 622 a formato ASCII y convierte el final del carácter de mensaje 624 a un indicador de secuencia de registro 644. En el paso 713, la aplicación para transmisión distribuida de mensajes 124 convierte los datos del mensaje en un formato aceptable para la interfaz del programa distribuido en computadoras 132. El paso de conversión implica agregar un carácter de comando 310 a la parte frontal . del mensaje de respuesta, que informa a la interfaz del programa distribuido en computadoras 132 que este es un mensaje de respuesta para impresora nativa, y agrega un indicador de longitud total 309 a la parte frontal del mensaje de petición para que represente la longitud total de la transmisión para la interfaz del programa distribuido en computadoras 132. En el paso 714, la aplicación para transmisión distribuida de mensajes 124 envía los bloques de datos de la impresora 620 reformateados hacia la interfaz del programa distribuido en computadoras 132. En el paso 716, la interfaz del programa distribuido en computadoras 132 pasa el mensaje de respuesta en impresora 640 hacia 79 la aplicación distribuida en impresoras 131. En el paso 718, la aplicación distribuida en impresoras 131 genera y envía un mensaje de reconocimiento unidireccional hacia el sistema de computadora central 102, que contiene únicamente un indicador de secuencia de registro de mensaje 644 wmedio", vía la interfaz del programa distribuido en computadoras 132 y la aplicación para transmisión distribuida de mensajes 124. En el paso 720, la puesta en cola de la impresora central 120 pregunta por la recepción de reconocimiento proveniente de la aplicación distribuida en impresoras 130. En el paso 722, si se recibe un reconocimiento, el proceso de ejemplo 700 suprime el bloque de datos en la impresora 620 de la puesta en cola de la impresora 120 y luego regresa al paso 708 hasta que ya no haya bloques de datos de impresora 620 en la puesta en cola de la impresora 120. Sin no se recibe ningún reconocimiento en el paso 720-, el proceso de ejemplo regresa al paso 708 y la puesta en cola de la impresora central 120 vuelve a enviar el bloque de datos 620 a la impresora anterior repetidamente durante un periodo de tiempo pre-seleccionado o hasta que se reciba un reconocimiento. 80 La Figura 16 es una ilustración de un diagrama de bloques de un proceso para transferencia de bloques de datos en la impresora 755 entre el sistema de computadora central 102 y la aplicación para transmisión distribuida de mensajes 124. En este caso, la aplicación central 108 ya ha generado un mensaje de respuesta para la impresora 750, que se ha almacenado en la puesta en cola de la impresora central 760. La puesta en cola de la impresora central 760 desensambla el mensaje de respuesta de la impresora 750 en varios bloques de datos 762, que luego se transmiten sobre la red de comunicaciones 106 hacia la aplicación para transmisión distribuida de mensajes 124. Una vez que la aplicación para transmisión distribuida de mensajes 124 ha recibido un bloque de datos 762, esta lo pasa hacia la interfaz del programa distribuido en computadoras 132 y luego hacia la aplicación distribuida en impresoras 130. La aplicación distribuida en impresoras 130 luego genera y envia un mensaje de reconocimiento 764 hacia la puesta en cola de la impresora principal 760. El proceso 755 se repite para cada bloque de datos 762 del mensaje de respuesta en la impresora 750. Como se describe de acuerdo con la Figura 1, 81 la aplicación para transmisión distribuida de mensajes 124 se puede agregar a cada una de las otras aplicaciones distribuidas 128 a través de conexiones de comunicación individual para múltiples casos de la interfaz del programa distribuido en computadoras 132 constituida en cada aplicación distribuida 128. La Figura 17 es un diagrama de bloques funcional que representa la arquitectura y los componentes de la interfaz del programa distribuido en computadoras 132 de una modalidad de ejemplo de la presente invención.

La aplicación central 108 se comunica con la interfaz del programa distribuido en computadoras según se describió anteriormente en relación con las Figuras 1 y 16. Similármente, la aplicación distribuida 128 también puede comunicarse con la interfaz del programa distribuido en computadoras 132. Ya sea la aplicación central 108 o la aplicación distribuida-128 pueden crear una conexión de comunicación para transmitir y procesar mensajes al llamar la interfaz del programa distribuido en computadoras 132. Una aplicación 108, 128 puede dar acceso a la funcionalidad de la interfaz del programa distribuido en computadoras 132 al transmitir un mensaje de función de programa a la interfaz del programa distribuido en computadoras. Un mensaje de 82 función de programa se reconoce por la interfaz de programación de aplicación 133. El uso de una interfaz de programación de aplicación (API, por sus siglas en inglés) 133 es un medio bien conocido para reconocer y procesar mensajes o llamadas de función de programa. En una modalidad de ejemplo de la presente invención, la API 133 se puede configurar para que reconozca únicamente un número relativamente pequeño de mensajes de función de programa. Este conjunto de mensajes de función de programa se puede denominar como lista verbal. Minimizar la lista verbal puede optimizar la eficiencia de la interfaz del programa distribuido en computadoras, al minimizar el tiempo y los recursos requeridos para reconocer y procesar un mensaje de función de un programa determinado. Como se describió anteriormente en relación con la Figura 1, la aplicación para transmisión distribuida de mensajes 124 se puede agregar a la red de comunicaciones 106 a través de conexiones de comunicación para dispositivos de conexión en red de comunicación en la red. Estos dispositivos para conexión en red de comunicación se denominan comúnmente como transportes 170-176. Los transportes son responsables, entre otras cosas, de concentrar 83 mensajes provenientes de muchas estaciones de trabajo distribuidas en computadoras 122 sobre conexiones de comunicación de capacidad mayor con el sistema de computadora central 102. Cada transporte 170-176 puede tener su propio conjunto único de funciones que son particularmente útiles para ciertos tipos de mensajes y/o ciertos tipos de comunicaciones entre una estación de trabajo del sistema distribuido en computadoras 122 y un sistema de computadora central 102. ' ' üna aplicación central 108 o una aplicación distribuida 128 puede requerir el uso de un transporte 170-176 particular dado un cierto conjunto de condiciones y puede requerir el uso de un segundo transporte dado un segundo conjunto de condiciones.

Para adaptar esto, una modalidad de ejemplo de la presente invención también incluye un administrador de perfiles 178 que puede operar de acuerdo con una base de datos de perfiles 180 para coordinar las operaciones de la interfaz del programa distribuido en computadoras 132 y el transporte 170-176. Específicamente, el administrador de perfiles puede determinar ciertas características de un mensaje y puede dar acceso a la base de datos de perfiles 180 para determinar la forma en que el mensaje se debe 84 procesar para la transmisión y cuál transporte utilizar. La base de datos de perfiles 180 se podría implementar como una tabla multi-dimensional a partir de la cual el administrador de perfiles 178 puede buscar los datos relevantes con referencia a las características determinadas del mensaje en cuestión. Por consiguiente, el transporte adecuado y otra información del procesamiento de mensajes se pueden determinar para un mensaje particular. De manera ventajosa, los transportes 170-176 se pueden cambiar, eliminar, o agregar sin requerir de un cambio correspondiente en cualquiera de las aplicaciones 108, 128. Similarmente, si se realiza una decisión de plan de acción para el procesamiento de un mensaje particular, la decisión de plan de acción se puede implementar en la forma en la una modificación de la base de datos de perfiles 180 en lugar de requerir una modificación para una o más aplicaciones 108, 128. Por consiguiente, el administrador de perfiles 178 y la base de datos de perfiles 180 operan como soporte lógico personalizado para facilitar el procesamiento de los mensajes por la interfaz del programa distribuido en computadoras 132 en coordinación con los transportes 170-176. Las diversas formas del procesamiento de mensajes que se 85 realizan por la interfaz del programa distribuido en computadoras 132 (en relación con otros componentes en red), con frecuencia se denominan como servicios. Cuando una aplicación 108, 128 transmite un mensaje, un generador de componentes 135 dentro de la interfaz del programa distribuido en computadoras 132 se activa para crear un componente de servicio 137. El componente de servicio puede identificar el contenido del mensaje y un identificador de servicio. Un identificador de servicio es una cadena de texto u otros datos que pueden identificar directa o indirectamente la forma en la que un mensaje será enrutado hacia una aplicación receptora. Por ejemplo, un mensaje se puede enrutar a una aplicación receptora como un formato de petición-respuesta, un formato de publicación-suscripción, o un formato de enviar y olvidar. Estos formatos de mensajes se describen más adelante con mayor detalle, en relación con las Figuras 19-25. El identificador de servicio se puede asociar con un mensaje haciendo referencia a una política definida en la base de datos de perfiles 180. ? partir de la perspectiva de la aplicación de envío, el identificador de servicio representa una dirección de enrutamiento . En el caso de una aplicación que está transmitiendo un mensaje para 86 petición de suscripción, el identificador de servicio puede indicar el servicio de publicación al cual la aplicación de envío se está suscribiendo. Una vez que el componente de servicio 137 se ha creado, la aplicación puede transmitir el mensaje utilizando el transporte 170-176 adecuado, en la forma descrita anteriormente. Además de los componentes de servicio 137, el generador de componentes 135 también puede generar un componente UTIL para proporcionar una funcionalidad de análisis y procesamiento de datos. El generador de componentes también puede crear un componente para tolerancia de falla que funciona para permitir el monitoreo de aplicaciones activas e inactivas para los fines de determinar cuáles, si es que las hay, aplicaciones 108, 128 responden a un mensaje en particular. Aquellos expertos en la técnica podrían apreciar que otros diversos componentes se podrían crear por el generador de componentes 135 para facilitar el procesamiento y manejo de mensajes. La Figura 18 es un diagrama de flujo que representa un proceso de ejemplo para procesar un mensaje recibido desde una aplicación. El método inicia en el bloque de decisión 800 y continua en el paso 802. En el paso 802, se recibe un mensaje desde 87 una aplicación. El método de la Figura 18 luego prosigue al paso 804. En el paso 804, el servicio y la acción implicados por el mensaje se identifica. En la modalidad de ejemplo descrita en relación con la Figura 17, la interfaz distribuida en computadora puede realizar este paso al examinar un mensaje recibido y extraer la información que pertenece a la identificación del servicio y a la acción de procesamiento de mensajes deseada. El método de la Figura 18 prosigue del paso 804 para el bloque de decisión 806. En el bloque de decisión 806, se realiza una determinación para saber si la recepción del mensaje representa la primera vez que el servicio identificado en el mensaje se solicitó por la aplicación. Si se determina que el servicio se ha solicitado por primera vez por la aplicación, el método se ramifica del bloque de decisión 806 al paso 810. En el paso 810, se genera un componente de servicio que corresponde al servicio identificado en el mensaje. Si, por otro lado, se determina en el bloque de decisión 806 que el servicio identificado ya se ha solicitado anteriormente por la aplicación, el mensaje se ramifica al paso 808. En el paso 808, se llama a un componente de servicio existente (es decir, creado 88 anteriormente) para procesar el mensaje recibido. El método de la Figura 18 prosigue del paso 808 al paso 812. Notablemente, el paso 812 también se puede alcanzar a partir del paso 810. En el paso 812, el perfil que está implicado por el componente de servicio y/o la aplicación se identifica. En la modalidad descrita en relación con la Figura 17, este paso se puede realizar por el administrador de perfiles 178 junto con la base de datos de perfiles 180. En cualquier caso, un perfil asociado con las características del mensaje (por ejemplo, el componente de servicio relevante, la acción de procesamien o de mensajes relevantes) se puede utilizar para identificar y asociar un perfil con el mensaje recibido. El método prosigue del paso 812 al paso 814. En el paso 814, el transporte implicado por el perfil se identifica. Como se describió anteriormente en relación con las Figuras 1 y 16, el transporte es un componente de red para enrutar mensajes a través de un sistema distribuido en computadoras. Cuando se utilizan transportes múltiples, la identificación del transporte adecuado se utilizará para que un mensaje en particular pueda ser un paso significativo para un procesamiento de 89 mensajes adecuado. El método de la Figura 18 prosigue del paso 814 al paso 816. En el paso 816, el servicio implicado por el perfil asociado se identifica. Como se describió anteriormente en relación con la Figura 17, un perfil asociado con un mensaje recibido puede identificar una calidad de servicio con la cual el mensaje deberá ser procesado. La calidad de servicio es el nivel de protección al cual da derecho un mensaje particular. Entre otras cosas, la calidad de servicio puede identificar el transporte que será utilizado para transmitir el mensaje, si el mensaje es un mensaje para suministro garantizado, y si el mensaje está encriptado. Aquellos expertos en la técnica, apreciarán que entre mayor sea la calidad de servicio del mensaje, mayor será el costo de la transmisión de mensajes. Debido a que una modalidad de ejemplo de la presente invención permite la creación y modificación de políticas para procesamiento de -mensaje, los costos de las transmisiones de mensaje se pueden minimizar al adaptar la calidad de servicio en, por ejemplo, una base de datos de perfil. El método prosigue del paso 816 al paso 818, en donde el mensaje se transmite sobre el transporte adecuado. El método luego 90 prosigue al final en el bloque 820 y termina. El método de la Figura 18, de esta forma, procesa un mensaje recibido de acuerdo con un perfil que está asociado con ese mensaje. El perfil adecuado se puede determinar al hacer referencia a una ' o más características del mensaje, tales como por ejemplo, la aplicación que envía el mensaje, el contenido del mensaje, los servicios solicitados por el mensaje, etc. El perfil de aplicación puede contener información del módulo de transporte que se puede utilizar para transmitir el mensaje, de los servicios para aplicar al mensaje, y la calidad de servicio que se aplica a la transmisión del mensaje. De manera ventajosa, una modalidad de ejemplo de la presente invención se puede utilizar para procesar mensajes generados mediante una variedad de aplicaciones y utilizando cualquiera de varios transporte distintos. Una modalidad de ejemplo de la presente invención se puede adaptar ya que un mensaje se puede procesar adecuadamente, incluso cuando una aplicación y/o transporte se cambia o elimina del sistema distribuido en computadoras, haciendo referencia a una base de datos de perfiles actualizados. Esta versatilidad adaptable también hace que las modalidades de ejemplo 91 de la presente invención sean muy útiles para mensajes de procesamiento, sin importar la estructura del sistema distribuido en computadoras. Las Figuras 18-24 y el texto acompañante proporcionan una descripción de la forma en que las modalidades de ejemplo de la presente invención se pueden implementar junto con diversas estructuras de trabajo en red y las llamadas de función que se utilizan comúnmente en. aquellas estructuras. La Figura 19 es un diagrama de bloques que representa una estructura en red de computadoras distribuida semejante a semejante 900 de ejemplo. En una estructura en red semejante a semejante 900, todas las computadoras distribuidas 902-910 en la red se sitúan similarmente y no existe un sistema de computadora central. Todas las aplicaciones residen en las computadoras semejantes 902-910. La Figura 20 es un diagrama de bloques que representa una estructura en red de computadoras distribuida de clientes-servidor 912 de ejemplo. En una estructura en red de cliente-servidor 912, todas las computadoras distribuidas 914-922 en la red se sitúan similarmente, aunque los sistemas distribuidos en computadoras se conectan a un sistema de computadora central, denominado como un servidor 924. 92 El servidor 924 enruta y procesa los mensajes transmitidos entre el servidor y cada uno de los clientes 914-922. El servidor también enruta y procesa los mensajes transmitidos entre los clientes 914-922. Las aplicaciones distribuidas (no mostradas) residen en computadoras del cliente. Las aplicaciones centrales 928 pueden residir en el servidor 924 o pueden residir dentro de un módulo de servicio 926 que está conectado funcionalmente al servidor. En resumen, un módulo de servicios es un conjunto de códigos o instrucciones que se pueden llamar cuando se transmite un mensaje dirigido al módulo. Este mensaje se puede identificar (es decir, se puede asociar con el módulo de servicio) al hacer referencia a un identificador de servicio que se puede enviar como parte del mensaje. Típicamente un módulo de servicio recibe un mensaje como entrada y regresa un mensaje de respuesta como salida. La Figura 21 es un diagrama de bloques que representa una estructura en red de computadoras distribuida de cliente-servidor de área amplia 930. En una estructura en red de cliente-servidor de área amplia 930, todas las computadoras distribuidas (por ejemplo, 932-940) en la red se sitúan similarmente , aunque los sistemas distribuidos en computadora se 93 conectan a un sistema de computadora central, denominado como servidor 942. El servidor 942 enruta y procesa los mensajes transmitidos por el servidor a cada uno de los clientes. Sin embargo, a diferencia de la red cliente-servidor representado en la Figura 20 , existen típicamente demasiadas computadoras de cliente en la red de área amplia 930 para soportar eficientemente las transmisiones de mensajes de cliente a servidor o las transmisiones de mensajes de cliente a cliente. Por consiguiente, el servidor 942 típicamente se utiliza en un contexto para envío de mensajes para distribuir los mensajes sobre la red 930. Estos mensajes distribuidos ya sea se reciben típicamente por- todas las computadoras o por aquellas computadoras de cliente que están suscritas a un servicio particular. Una aplicación central 944 puede residir en el servidor 924 o puede residir dentro de un módulo de servicio 946 que está conectado funcionalmente al servidor. Aquellos expertos en la técnica apreciarán que se pueden utilizar diversas técnicas para envío de mensajes en diversas circunstancias, dependiendo en parte de la estructura de la red en la cual se realiza el envío de mensajes. Por ejemplo, podría ser ineficiente o imposible para el servidor 942 94 enviar un mensaje a un cliente especifico 932-940 y solicitar la confirmación de la recepción del mensaje y/o solicitar una respuesta del cliente. Por otro lado, es muy común enviar un mensaje con una petición para una respuesta en una red de cliente-servidor o una red semejante a semejante. Las Figuras 21-24 representan diversos servicios de procesamiento de mensajes que se pueden implementar por una modalidad de ejemplo de la presente invención en el contexto de diversas estructuras de red descritas en relación con las Figuras ,18-20. La Figura 22 es un diagrama de bloques que representa un servicio de procesamiento de mensajes 950 para solicitar respuesta síncrona de ejemplo. Los elementos de red 952, 954 podrían ser computadoras centrales/distribuidas que operan en una red que puede soportar la transmisión de un mensaje de respuesta en contestación a una petición. Estas redes pueden incluir redes semejante a semejante, redes cliente-servidor, y redes de área amplia. En una red semejante a semejante o una red cliente-servidor, el mensaje para petición de respuesta se puede enviar a una aplicación que corre sobre un elemento de red particular (por ejemplo, un sistema de computadora central/servidor) proveniente de una 95 aplicación que corre sobre otro elemento de red (por ejemplo, un sistema de computadora distribuida/cliente) . En un modo síncrono de procesamiento de mensajes, el sistema que envia la petición de respuesta típicamente forzará la aplicación solicitante a que espere por la respuesta antes de ejecutar otras tareas. En una red de área amplia, el mensaje para petición de respuesta se puede enviar como un mensaje de distribución por una computadora para publicación y ser recibido por todas las computadoras distribuidas que están suscritas al servicio de mensajes. Aquellas computadoras distribuidas que se configuran para responder a esta petición de respuesta (por ejemplo, abonados al servicio de publicación) enviarán mensajes de respuesta a la aplicación solicitante sobre la computadora de publicación. En el servicio para procesamiento de mensajes que solicitan respuesta síncrona 950 de ejemplo representado en la Figura 22, un primer elemento de red 952 está corriendo una aplicación solicitante 956 y un segundo elemento de red 954 está corriendo una aplicación de respuesta 958. Los elementos de red se conectan a través de una interfaz de programación distribuida en computadoras, también 96 denominada como una Interfaz de Programación para Aplicación de Servicios (SAPI, por sus siglas en inglés) 964. En resumen, los otros elementos de la red de comunicación no se representan en la Figura 22. Como se describió anteriormente, la SAPI 964 traducirá la petición 960 recibida desde la aplicación solicitante 956 a un formato que se puede entender por la aplicación de respuesta 958. Asimismo, la SAPI 964 traducirá la respuesta 962 recibida desde la aplicación de respuesta 958 a un formato que se pueda entender por la aplicación solicitante 956. El mensaje para petición de respuesta en modo síncrono 965 representado en la Figura 22 proporciona un ejemplo de una petición de respuesta típica. La aplicación solicitante 956 que transmite esta petición de respuesta típicamente esperará hasta que se reciba un mensaje de respuesta 962 desde la aplicación de respuesta 958 antes de proceder a ejecutar otras funciones. La Figura 23 es un diagrama de bloques que representa un servicio para procesamiento de mensajes que solicitan respuesta asincrona 966 de ejemplo. Como se describió en relación con la Figura 22, los elementos de red 952, 954 podrían ser computadoras centrales /distribuidas que operan en una red que 97 puede soportar la transmisión de un mensaje de respuesta en respuesta a una petición. Estas redes pueden incluir redes semejante a semejante, redes cliente-servidor, y redes de área amplia. En una red semejante a semejante o una red cliente-servidor, el mensaje para petición de respuesta se puede enviar a una aplicación que corre sobre un elemento de red particular (por ejemplo, un sistema de computadora central-servidor) desde una aplicación que corre sobre otro elemento de red (por ejemplo, un sistema de computadora distribuida/cliente) . En un modo asincrono de procesamiento de mensajes, la aplicación solicitante típicamente no esperará por el mensaje de respuesta antes de ejecutar otras tareas. Por el contrario, la aplicación solicitante típicamente llamará una aplicación de manipulación o "handle" (no mostrada) para menjar el mensaje de respuesta y enrutarlo hacia la aplicación solicitante cuando se transmita desde la aplicación de respuesta. En una red de área amplia, el mensaje para petición de respuesta se puede enviar como un mensaje de distribución por una computadora de publicación y ser recibido por todas las computadoras distribuidas que está suscritas al servicio de envió de mensajes. Aquellas computadoras distribuidas que están 98 configuradas para responder a esta petición de respuesta (por ejemplo, abonados al servicio de publicación) enviarán mensajes de respuesta a la aplicación solicitante sobre la computadora de publicación. En el servicio de procesamiento de mensajes para petición de respuesta asincrona 966 de ejemplo representado en la Figura 23, un primer elemento de red 952 que está corriendo una aplicación solicitante 956 y un segundo elemento de red 954 está corriendo una aplicación de respuesta 958. Los elementos de red se conectan a través de una interfaz de programación distribuida en computadoras, también denominada como Interfaz de Programación para Aplicación de Servicios (SAPI) 964. En resumen, los otros elementos de la red de comunicaciones no se representan en la Figura 23. Como se describió anteriormente, la SAPI 964 traducirá la petición 960 recibida desde la aplicación solicitante 956 a un formato que pueda ser entendido por la aplicación de respuesta 958. Asimismo, la SAPI 964 traducirá la respuesta 962 recibida desde la aplicación de respuesta 958 a un formato que pueda ser entendido por la aplicación solicitante 956. El mensaje para petición de respuesta en ' modo asincrono 963 99 representado en la Figura 23 proporciona un ejemplo de una petición de respuesta típica. La aplicación solicitante 956 que transmite esta petición de respuesta típicamente no esperará hasta que se reciba un mensaje de respuesta 962 desde la aplicación de respuesta 958 antes de proceder a ejecutar otras funciones. En su lugar, se puede utilizar- un manipulador para notificar a . la aplicación solicitante 956 que se ha generado un mensaje de respuesta por parte de la aplicación de respuesta.

En el mensaje para petición de respuesta 963 representado en la Figura 23, el manipulador llamado se identifica por el argumento "replyHandler". La Figura 24 es un diagrama de bloques que representa un servicio para procesamiento de mensajes de enviar y olvidar de ejemplo. El mensaje para enviar y olvidar se puede utilizar virtualmente en cualquier estructura en red. Como se describe en relación con la Figura 22, los elementos de red 970, 974 podrían ser computadoras centrales /distribuidas que operan en una red que ' puede soportar las transmisiones de mensajes. Estas redes pueden incluir redes semejante a semejante, redes cliente-servidor y redes de área amplia. En una red semejante a semejante o una red cliente-servidor, el 100 mensaje de .enviar y olvidar se puede enviar a una aplicación que corre sobre un elemento de red particular (por ejemplo, un sistema de computadora central/servidor) desde una aplicación que corre sobre otro elemento de red (por ejemplo, un sistema de computadora distribuida/cliente). Como se indica por el nombre, el mensaje de enviar y olvidar típicamente no implicará la petición o la generación de un mensaje de respuesta. El mensaje de enviar y olvidar es particularmente útil en una red de área amplia, en donde una respuesta proveniente de las aplicaciones receptoras es imposible o particularmente no eficaz. Aquellas computadoras distribuidas que están configuradas para recibir este mensaje de enviar y olvidar (por ejemplo, los abonados al servicio de publicación) procesarán el mensaje recibido, mientras que aquellos que no están configurados para recibir mensajes ignorarán el mens aj e . En el servicio para procesamiento de mensajes de enviar y olvidar 968 de ejemplo representado en la Figura 24, un primer elemento de red 970 está corriendo una aplicación de envío 972 y un segundo elemento de red 974 está corriendo una aplicación de recepción 976. Los elementos de red 101 970, 976 se conectan a través de una interfaz de programación distribuida en computadoras, también denominada como una Interfaz de Programación para Aplicación de servicios (SAPI) 964. En resumen, los otros elementos de la red de comunicación no se representan en la Figura 24. Como se describió anteriormente, la SAPI 964 traducirá la petición 978 recibida desde la aplicación de envío 972 a un formato que. pueda ser entendido por la aplicación de respuesta 976. El mensaje de enviar y olvidar 980 representado en la Figura 24 es un ejemplo de este tipo de mensajes. La Figura 25 es un diagrama de bloques que representa un servicio para procesamiento de mensajes de publicación-suscripción 982 de ejemplo. El conjunto de mensajes de publicación-suscripción se puede utilizar virtualmente en cualquier estructura de red. Como se describió en relación con la Figura 22, los elementos de red 984, 990 podrían ser computadoras centrales/distribuidas que operan en una red que puede soportar la transmisión de mensajes. Estas redes pueden incluir redes semejante a semejante, redes cliente-servidor y redes de área amplia. En una red semejante a semejante o una red cliente-servidor, el mensaje para petición de 102 suscripción 992 se puede enviar a una aplicación que corre en un elemento de red particular (por ejemplo, un sistema de computadora central/servidor) desde una aplicación que corre en otro elemento de red (por ejemplo, un sistema de computadora' distribuida/cliente). Asimismo, el mensaje para respuesta publicada 994 se puede enviar a una aplicación -que corre en un elemento de red particular (por ejemplo, un sistema de computadora central/servidor) desde una aplicación que corre sobre otro elemento de red (por ejemplo, un sistema de computadora distribuida/cliente) . El conjunto de mensaje de publicación/suscripción típicamente no implicará un mensaje de respuesta direccionada . Es decir, la aplicación de publicación típicamente no identifica una aplicación de suscripción particular que debería recibir la respuesta publicada 994. Por el contrario, la aplicación de suscripción 986 de un manipulador de mensajes usualmente operará para identificar el mensaje de respuesta publicado y reconocer que el mensaje de respuesta publicado corresponde a un mensaje de suscripción que la aplicación suscriptora transmitió anteriormente. El mensaje de publicación-suscripción es particularmente útil en una red de área amplia, en donde una 103 respuesta proveniente de las aplicaciones receptoras es imposible o particularmente no eficaz. Aquellas computadoras distribuidas que están configuradas para recibir este mensaje publicado (por ejemplo, los abonados al servicio de publicación) procesarán el mensaje recibido, mientras que aquellas que no están configuradas para recibir el mensaje ignorarán el mensaj e . En el servicio para procesamiento de mensajes de publicación-suscripción 982 de ejemplo representado en la Figura 25, un primer elemento de red 984 está corriendo una aplicación de suscripción 986 y un segundo elemento de red 988 está corriendo una aplicación de publicación 990. Los elementos de red 984, 988 se conectan a través de una interfaz de programación distribuida en computadoras, y también se denomina como una Interfaz para Programación de Aplicación de Servicios (SAPI) 964. En resumen, los otros elementos de la red de comunicación no se representan en la Figura 25. Como se describió anteriormente, la SAPI 964 producirá la petición de suscripción 992 recibida desde la aplicación de suscripción 986 a un formato que se pueda entender por la aplicación de publicación 990. Asimismo, la SAPI 964 traducirá el mensaje de respuesta publicado 104 994 recibido desde la aplicación de publicación 990 a un formato que se pueda entender por la aplicación de suscripción 986. El mensaje para petición de suscripción 996 representado en la Figura 25 es un ejemplo de este tipo de mensajes. La aplicación de suscripción 986 que transmite esta petición de suscripción típicamente no esperará hasta que se reciba un mensaje de respuesta publicada 994 proveniente de la aplicación de publicación 990 antes de proceder a ejecutar otras funciones. En efecto, se puede utilizar un manipulador para notificar a la aplicación de suscripción 986 que se ha generador un mensaje de respuesta publicada 994 por la aplicación de publicación 990. En el mensaje para petición de suscripción 996 representado en la Figura 25, el manipulador llamado está identificado por el argumento " essageHandler". Se apreciará que la presente invención cumple con las necesidades de la técnica convencional descrita en la presente y cumple con los objetivos establecidos anteriormente. Mientras que se han mostrado y descrito las modalidades preferidas de la invención, será evidente para aquellos expertos en la técnica que se pueden realizar diversas modificaciones y cambios a las mismas sin apartarse

Claims

NOVEDAD DE LA INVENCIÓN Habiendo descrito el presente invento, se considera como una novedad y, por lo tanto, se reclama como propiedad lo contenido en las siguientes REIVINDICACIONES : 1. Un sistema para procesamiento de mensajes para transmitir y recibir mensajes entre una aplicación de sistema de computadora central y una aplicación de sistema distribuido en computadoras, el sistema para procesamiento de mensajes comprende: una aplicación para transmisión distribuida de mensajes asociada con la aplicación del sistema distribuido en computadoras operativo para procesar un mensaje generado por la aplicación del sistema distribuido en computadoras, y para transmitir el mensaje a la aplicación del sistema de computadora central sobre la red de comunicaciones; una aplicación para transmisión de mensajes del sistema central asociada con una aplicación central y operativa para procesar un mensaje recibido desde la aplicación para transmisión distribuida de mensajes; y una interfaz del programa distribuido en computadoras conectada funcionalmente a la aplicación del sistema distribuido en computadoras y a la aplicación para transmisión distribuida de mensajes y operativa para configurar el mensaje para la transmisión sobre una red de comunicaciones.
2. El sistema para procesamiento de mensajes según la reivindicación 1, en donde la configuración del mensaje para transmisión sobre la red de comunicaciones comprende asociar un perfil de transmisión con el mensaje.
3. El sistema para procesamiento de mensajes según la reivindicación 2, que comprende además una interfaz del programa distribuido en computadoras que es operativa para asociar el mensaje con un perfil de transmisión almacenado en una base de datos de perfiles.
4. El sistema para procesamiento de mensajes según la reivindicación 3, en donde la interfaz del programa distribuido en computadoras comprende un administrador de perfiles operativo para examinar al menos una característica del mensaje para determinar el perfil de transmisión que estará asociado con el mensaje.
5. El sistema para procesamiento de mensajes según la reivindicación 4, en donde la característica del mensaje es un identificador de aplicación.
6. El sistema para procesamiento de mensajes según la reivindicación 4, en donde la característica del mensaje es un número de serie.
7. El sistema para procesamiento de mensajes según la reivindicación 4, en donde la característica del mensaje es un indicador de secuencia de registro.
8. El sistema para procesamiento de mensajes según la reivindicación 4, en donde la característica del mensaje es un dato de aplicación.
9. El sistema para procesamiento de mensajes según la reivindicación 4, en donde la característica del mensaje es un carácter de comando.
10. El sistema para procesamiento de mensajes según la reivindicación 4, en donde la red de comunicaciones es una red semejante a semejante.
11. El sistema para procesamiento de mensajes según la reivindicación 4, en donde la red de comunicaciones es una red cliente-servidor.
12. El sistema para procesamiento de mensajes según la reivindicación 4, en donde la red de comunicación es una red cliente-servidor de área amplia.
13. El sistema para procesamiento de mensajes según la reivindicación 4, en donde el mensaje es un mensaje de respuesta solicitada.
14. El sistema para procesamiento de mensajes según la reivindicación 4, en donde el mensaje es un mensaje de enviar y olvidar.
15. El sistema para procesamiento de mensajes según la reivindicación 4, en donde el mensaje es un mensaje de distribución.
16. El sistema para procesamiento de mensajes según la reivindicación 15, en donde el mensaje de distribución se genera por una aplicación de servicio de publicación y en donde el mensaje de distribución se recibe por un elemento de red de sus cripción .
17. Un método para procesar un mensaje entre una primera aplicación que corre en un primer elemento de red y una segunda aplicación que corre en un segundo elemento de red de una red de comunicaciones, el método comprende los pasos de: generar el mensaje en el primer elemento de red; configurar el mensaje para transmisión sobre la red de comunicaciones; transmitir el mensaje sobre la red comunicaciones; y suministrar el mensaje al segundo elemento de red; en donde el paso de configurar el mensaje para transmisión comprende producir el mensaje en un formato asociado con la segunda aplicación.
18. El método según la reivindicación 17, en donde el paso de configurar el mensaje para transmisión sobre la red de comunicaciones comprende asociar un perfil de transmisión con el mensaje.
19. El método según la reivindicación 18, en donde el paso de configurar el' mensaje para transmisión sobre la red de comunicaciones comprende tener acceso a una base de datos de perfiles para asociar el perfil de transmisión con el mensaje.
20. El método según la reivindicación 19, en donde el paso de configurar el mensaje para transmisión sobre la red de comunicaciones comprende asociar el perfil de transmisión con el mensaje, con base en al menos una característica del mensaje.
21. El método según la reivindicación 20, en donde la característica del mensaje es un identificador de aplicación.
22. El método según la reivindicación 20, en donde la característica del mensaje es un número de serie .
23. El método según la reivindicación 20, en donde la característica del mensaje es un indicador de secuencia de registro.
24. El método según la reivindicación 20, en donde la característica del mensaje es un dato de aplicación.
25. El método según la reivindicación 20, en donde la característica del mensaje es un carácter de comando .
26. El método según la reivindicación 18, en donde el perfil de transmisión comprende un identificador .de transporte operativo para asociar el mensaje con un transporte que será utilizado para transmitir el mensaje sobre la red de comunicaciones.
27. El método según la reivindicación 18, en donde el perfil de transmisión comprende un identificador de servicio operativo para asociar el mensaje con un formato de mensaje que será utilizado para transmitir el mensaje sobre la red de comunicaciones .