MXPA98003869A - Soporte logico personalizado de comunicaciones deregistro - Google Patents

Abstract

Un sistema de computadora tiene una pluralidad de clientes no compatibles (102) y servidores (110) interconectados selectivamente sobre una red (108), cada cliente es capaz de iniciar una aplicación (124) en la cual estácomprendido un servidor compatible relacionado. La comunicación entre los clientes y los servidores comprende un primer proceso de registro (104, 126) que incluye la aceptación de los mensajes específicos de la aplicación de un cliente, destinados a un servidor preseleccionado, y encapsularlos en mensajes específicos, normales de registro (128). El encaminamiento de los mensajes se determina por una base de datos que responde a una orden verbal, de un cliente particular, para proporcionar el encaminamiento de los datos. Luego, hay una traducción de los mensajes específicos de registro en un protocolo preseleccionado (106, 130). Un segundo proceso de registro (104, 126) ocurre en un extremo distante para restaurar el mensaje después de pasar a través de la red. El segundo registro acepta los mensajes traducidos y los convierte desde el formato del protocolo al formato específico de la aplicación original para el uso por el servidor compatible preseleccionado.

Description

SOPORTE LÓGICO PERSONALIZADO DE COMUNICACIONES DE REGISTRO SOLICITUDES RELACIONADAS Esta solicitud se relaciona a la Solicitud de Patente Norteamericana, co-pendiente Número de Serie 08/580,950 titulada "EXITS: Servicio de Transferencias de Información Extendido", presentada el 29 de diciembre de 1995.

CAMPO DE A INVENCIÓN Esta invención se refiere a redes de cómputo distribuido y, en forma más especifica, a un sistema que proporciona una capa de comunicaciones estandarizada entre las aplicaciones del cliente/servidor y productos de generación de mensajes de la red.

ANTECEDENTES DE LA INVENCIÓN El cómputo distribuido es el método para asignar el procesamiento de datos de la aplicación entre varios recursos de cómputo. En la industria de la tecnología de la información este es un campo con rápido crecimiento debido a las eficiencias ganadas al utilizar varios procesadores diferentes para aplicaciones comunes. También se conocen plataformas de cómputo distribuido como plataformas de cliente/servidor, debido a que cada recurso de cómputo representa ya sea un cliente o un servidor. Un recurso de cliente es un consumidor de servicios de aplicación. Ejecuta un proceso fundamental de enviar mensajes de petición a un servidor. Los clientes representan en general a los usuarios de un sistema, tal como una persona que está corriendo una estación de trabajo de la aplicación. Un recurso de servidor es un proveedor de servicios de la aplicación. Ejecuta procesos fundamentales de recibir mensajes de petición desde un cliente, y mandar mensajes de contestación hacia el mismo. Los servidores representan en general los componentes que mantienen los recursos de datos de las empresas e implementan políticas de negocios. Un requerimiento fundamental para implementar una plataforma de cómputo distribuido es la integración de varios tipos de recurso de cómputo y de la red en una red individual con varias empresas. Existen muchos productos, normas y protocolos de comunicación disponibles para hacer esto, y muchas empresas hacen uso de varios de estos. Esto crea un problema significante con respecto a la inter operabilidad. Varias aplicaciones diferentes que corren en varios sistemas de operación y el equipo fisico de la computadora deben trabajar directamente con los numerosos protocolos de comunicación de la red y generación de mensajes. Los programadores de la aplicación deben tratar con las complejidades y enredos de todos estos protocolos a fin de que sus aplicaciones trabajen en la plataforma de cómputo distribuido. Además, los programadores deben proporcionar un medio para sus aplicaciones, para determinar los mecanismos de transporte óptimos para los mensajes. Esto es necesario tanto en los recursos del cliente como del servidor. Claramente, existe una necesidad por una gestión que utilice recursos de cómputo distribuido y redes para implementar una interfaz normal para aplicaciones que usen estos recursos. No existe corrientemente un producto en el mercado para hacer esto.

BREVE DESCRIPCIÓN DE LA PRESENTE INVENCIÓN La presente invención, identificada como Registro, es un sistema que reside en cada recurso de la aplicación (tanto cliente como servidores) de la plataforma de cómputo distribuido. Es un agente de comunicaciones que soporta un grupo de productos de generación de mensajes de comunicaciones y protocolos de red. Sirve como una capa lógica de comunicaciones entre aplicaciones y los mecanismos de transporte de la red. Al hacer esto asi, el registro protege a los programadores de la aplicación de todas las complejidades relacionadas de los protocolos de transporte y generación de mensajes de propiedad privada. El registro acepta mensajes específicos de la aplicación de los clientes, encapsulándolos en mensajes normales específicos del registro, y luego traduciéndolos en el protocolo necesario para cualquiera de los mecanismo de transporte de generación de mensajes que se van a usar..

En el oro aspecto, el registro toma el mensaje enviado por el cliente y los traduce desde el protocolo de transporte que se usó hacia un mensaje especifico de la aplicación que se usa por el servidor. Por consiguiente, es una ventaja del registro que proporcione conductividad de aplicación para varias empresas a través de un arreglo ancho de sistemas de operación, plataformas de equipos físicos de computadoras, productos de generación de mensajes, y protocolos de red. Es otra ventaja del registro que proporciona una interfaz, normal, individual a las aplicaciones, mientras que proporciona una interfaz específica del producto a cada uno de los varios productos diferentes de comunicación de red y de generación de mensajes. Es otra ventaja del registro que permite que los programadores de la aplicación eviten el requerimiento de programar semántica de transporte de generación de mensajes de bajo nivel en sus aplicaciones; los programadores pueden enfocarse en la semántica orientada a negocios. Esta ventaja incrementa la flexibilidad y disminuye las complejidades de las aplicaciones. Es otra ventaja del registro que elimina la necesidad para que cada aplicación tenga interfaces específicas a los varios protocolos de transporte de generación de mensajes que están en uso. Es otra ventaja del registro que proporciona aplicaciones con un medio para determinar los mecanismos óptimos de transporte para cada transacción. Es otra ventaja del registro que permite que las aplicaciones lleguen a ser independientes de la plataforma del protocolo. Esto es, los programadores de la aplicación no necesitan conocer que sistemas de operación, plataformas del equipo físico de la computadora, y protocolos de comunicación se pueden usar por los clientes y servidores de la aplicación; solo necesitan programar en una interfaz normal al registro. También, los clientes y servidores se pueden poner desde una plataforma/protocolo a otro sin que tenga que programar los cambios correspondientes en cada aplicación. Es otra ventaja del registro que a través del uso de un directorio de enrutamiento de la red lógica, los cambios en las direcciones de los recursos físico solo requieran actualizaciones en el directorio del registro, y no en cada aplicación.

BREVE DESCRIPCIÓN DE LAS FIGURAS Los objetos y ventajas mencionados anteriormente de la presente invención se entenderán más claramente cuando se consideren en unión con los dibujos acompañantes, en los cuales: La Figura 1 es un diagrama de bloques que muestra una arquitectura de sistemas de alto nivel en la plataforma de cómputo distribuido de muestra que utiliza el registro. La Figura la es un diagrama que muestra las capas lógicas de las comunicaciones del cliente/servidor y donde se ajusta el registro. La Figura 2 es un diagrama de bloques que ilustra la arquitectura interna del registro, y una conexión individual de una plataforma de cómputo distribuido que la utiliza. La Figura 2a es un diagrama de flujo de gatos que ilustra en detalles la interfaz IPC generalizada identificada en la Figura 2. La Figura 2b es un diagrama de bloques que muestra el monitor de proceso de registro en mayor detalle. La Figura 3a es un diagrama de flujo de proceso que ilustra la operación del registro.

La Figura 3b es una continuación del diagrama de flujo del proceso en la Figura 3a.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Con referencia a la Figura 1, se representa el registro como una interfaz normal, para las aplicaciones tanto del cliente como del servidor. El registro es realmente un sistema que reside en cada recurso individual del cliente y el servido. Proporciona una interfaz normal, individual a cada aplicación del cliente y el servidor para proteger estas aplicaciones de las complejidades de los varios productos de generación de mensajes y protocolos de red de propiedad privada. Los sistemas de operación, productos de generación de mensajes, y protocolos de red mostrados son solo una muestra de aquéllos soportados por el registro. El registro 104 acepta los mensajes de petición a partir de las aplicaciones 102 del cliente como parte de un diálogo. Las aplicaciones 102 pueden correr bajo varios sistemas de operación, como se indica. Estos mensajes de petición representan una solicitud para una respuesta y/o una instrucción para realizar un proceso. Se generan por las aplicaciones del cliente con la intención de ser distribuidas a una aplicación 110 del servidor. La aplicación 110 también se puede correr bajo varios sistemas de operación, como se muestra. Puesto que los elementos de programación del registro residen en los mismos componentes del equipo físico de la computadora como las aplicaciones, el enlace entre el registro 104 y las aplicaciones 102 del cliente representa un proceso de los elementos de programación. Aunque se ilustran cuatro ejemplos de los sistemas de operación y emuladores de terminales, el registro soporta mucho más. EL registro 104 luego ejecuta un proceso de encapsular el mensaje de petición del cliente en un mensaje definido por el registro. Este proceso se representa en mayor detalle en referencia a las Figuras 2 y 4. El registro determina el producto 106 apropiado de generación de mensajes y convierte un mensaje en el protocolo de propiedad privada de este producto de generación mensajes. En algunas situaciones, el registro puede servir realmente como el producto de generación de mensajes; en estos caso, convertirá el mensaje a el protocolo de propiedad privada del transporte 108 de la red (es decir, SNA LU6.2, TCP/IP, etc.) . El producto 106 de generación de mensajes usará un protocolo apropiado de red para transportar el mensaje sobre una red disponible 108. En el extremo distante, el producto 106 de generación de mensajes recibe el mensaje y lo pasa fuera hacia el registro 104. El registro convierte el mensaje desde el protocolo de propiedad privada del producto 106 de generación de mensajes a un mensaje que es reconocible para la aplicación 110 del servidor. Si se pide una respuesta de la aplicación 110 del servidor, el proceso precedente se repite para enviar el mensaje de respuesta de regreso a la aplicación 102 del cliente. Con referencia a la Figura la, se ilustra el papel que asume el registro 104 en las capas lógicas de las comunicaciones del cliente/servidor. En este diagrama, el recurso se identifica en el frente de cada capa, la interfaz que los proporciona se identifica en la parte superior de cada capa, y la semánticas usadas en la interfaz se identifican a la derecha de cada capa. La capa 122 de la parte superior representa al usuario de una aplicación. Trabaja directamente con una aplicación vía las interfaces de usuario/recurso definidas por la aplicación, intercambiando información orientada a negocios con la aplicación. La siguiente capa 124 hacia abajo representa la aplicación. Trabaja directamente con el registro vía el uso de un conjunto verbal normal (SVS por sus siglas en ingles) . Las semánticas usadas son transacciones de cliente/servidor orientadas a negocios, conocidas como "verbo", y representan el único protocolo que los programadores de al aplicación necesitan tratar.

La siguiente capa 126 hacia abajo representa el registro. Trabaja directamente con los productos de generación de mensajes (también conocido como, soporte lógico personalizado de comunicaciones) vía las interfaces específicas del producto. Las semánticas usadas son específicas al producto de generación de mensajes. La siguiente capa hacia abajo 128 representa los productos de generación de mensajes del soporte lógico personalizado de comunicación. Trabajan directamente con la red vía las interfaces del protocolo de red, usando las semánticas de transmisión de datos. La capa del fondo 130, que representa el protocolo de la red, puede consistir de tipos tal como SNA LU6.2 o TCP/IP. En algunos casos, el registro 126 puede extenderse realmente a través de la capa 128 de soporte lógico personalizado de comunicaciones. Por ejemplo, el registro puede traducir los mensajes de petición del cliente en mensajes de TCP/IP reales, y enviar directamente sobre la red de TCP/IP. Con referencia a la Figura 2, la estructura lógica interna del registro se muestra para ilustrar una conversación típica de cliente/servidor utilizando el registro . Una aplicación del cliente 202 genera un mensaje de petición que necesita ser enviado a una aplicación 222 distante del servidor. Un ejemplo típico de un mensaje de petición puede ser una petición para los ingresos mensuales de facturación del cliente desde una base de datos de facturación del cliente de la compañía localizada en un servidor distante. El cliente y el servidor se conectan por una red 218 de datos de la compañía y tienen varios productos 216 de generación de mensajes disponibles para transportar sus mensajes sobre la red 218. Usarán el registro 204 como una interfaz para todos estos productos 216 de generación de mensajes y protocolos de la red 218. La aplicación 202 del cliente se comunica con el registro 204 vía la interfaz de programación de la aplicación (API) 206 del registro. La API contiene un conjunto de órdenes conocidas como un conjunto verbal normal (SVS), que se define como sigue: CONJUNTO VERBAL NORMAL El conjunto verbal normal (SVS) del registro es un conjunto de órdenes que el registro usa para comunicarse con las aplicaciones tanto del cliente como del servidor. Este conjunto limitado de órdenes representa todo el protocolo de comunicaciones que los programadores de la aplicación del cliente/servidor necesitan usar para sus aplicaciones para comunicarse con el registro, y de esta manera, la red de la empresa.

Existen dos conjuntos de verbos: uno para el uso por las aplicaciones del cliente y uno para el uso por las aplicaciones del servidor. Puesto que una aplicación puede funcionar potencialmente con cualquier cliente o servidor, ambos conjuntos de verbos se incluyen en el SVS para cada aplicación. Como se señala previamente, el SVS se mantiene dentro de la API 206 del registro, así como cada aplicación del cliente y el servidor. Los verbos del cliente y sus parámetros se definen como sigue: REGISTRO - Establece una sesión entre la aplicación que llama y el registro. Esta sesión es solo entre la aplicación que llama y el registro, y no entre aplicaciones. La sesión consiste de un área de control de registro (RCA) , que es memoria asignada por el verbo REGISTRO en el registro y pasa de regreso a la aplicación que llama. El RCA representa un caso único del proceso de registro, y se requiere una nueva RCA para cada emisión del REGISTRO por el cliente. Los parámetros del REGISTRO son: RETROALIMENTACION - Campo usado para regresar a la aplicación que llama una indicación en cuanto hacia el registro fue capaz de terminar la función pedida. REG-OPCIONES - Este contiene varios campos, la mayoría son opcionales, proporcionando la información usada para identificar la aplicación del cliente. Un campo requerido de este parámetro es una designación de un carácter que indica si la aplicación que llama es un cliente o un servidor . RCA-PTR - Campo usado para identificar únicamente el RCA al servir como un indicador al RCA. Designa una sesión específica establecida por el verbo REGISTRO, identifica las llamadas subsecuentes al registro como parte de la sesión específica. Cada emisión del REGISTRO debe designar una sesión diferente y, por lo tanto, tiene un valor diferente para este campo (por ejemplo, RCA-PTR1, RCA-PTR2, etc. ) . DEREGISTRO - Termina las actividades de las aplicaciones del cliente/servidor, y libera cualquiera de los recursos manejados por el registro, asociados. Los parámetros son los mismos que aquéllos para REGISTRO. ENVIARPETICION - Usado para enviar una petición del cliente a un servidor. Contiene los mismos parámetros como REGISTRO, más los siguiente: WS-PRUEBA-MSG - Este campo es la dirección del mensaje real que se envió por el cliente al servidor. WS- SG-LEN - Este campo indica la duración del mensaje del cliente. RECIBIRCONTESTACION - Usado para recibir una contestación a una petición previa. El RCA debe ser el mismo como el usado para el verbo ENVIARPETICION contiene los mismos parámetros como REGISTRO, más los siguientes: WS-OUT-MSG-PTR - Este campo es indicador al mensaje de contestación. S-OUT-MSG-LEN - Este campo indica la duración del mensaje de contestación. CONVERSACIÓN - Usado para conducir una transacción sincrónica de petición/contestación. Contiene los mismos parámetros como ENVIARPETICION y RECIBIRCONTESTACION combinados. Los verbos del servidor y sus parámetros se definen como sigue: REGISTRO - Misma definición como la versión del verbo del cliente. El servidor emite un verbo REGISTRO en respuesta a la petición del registro para hacerlo. DEREGISTRO - Misma definición como la versión del verbo del cliente . RECIBIRPETICION - Usado para recibir un mensaje de petición enviado por un cliente. El mensaje mismo se recibirá no modificado por el registro, y luego se procesará por el servidor . Contiene los mismos parámetros que REGISTRO, más lo siguiente: S-PETICION-MSG - Este campo es la dirección del mensaje que se envía al servidor por el cliente. S-PETICION-LEN - Este campo indica la duración del mensaje. ENVIARCONTESTACION - Usado para enviar la contestación del servidor al mensaje del cliente. Contiene los mismos parámetros que REGISTRO, más lo siguiente: WS-ENVIARCONTESTACION-MSG - Este campo es la dirección de la contestación que se envía al cliente por el servidor. WS-ENVIARCONTESTACION-LEN - Este campo indica la duración de la contestación. Con referencia adicional a la Figura 2, una aplicación 202 del cliente inicia una sesión al registrarse por si misma como un cliente con el registro 204. Esto se logra el emitir un verbo REGISTRO, que se lee por la API 206. Un componente del registro identificado como la ejecución de verbos 208 es responsable de validar los parámetros y procesar cada verbo. Cuando se recibe un miembro un verbo REGISTRO por la API 206, la ejecución de verbo 208 creará un área de control de registro (RCA) y enviará la dirección de RCA de regreso al cliente 202 vía la API 206. Esta RCA se usa para almacenar y procesar todos las comunicaciones entre el cliente y el registro. La aplicación del cliente 202 luego emitirá un verbo ENVIARPETICION al registro. Este verbo ordenará al registro enviar el mensaje de petición del cliente, generado previamente por el cliente, al servidor 222. El mensaje de petición real también se enviará al registro como un parámetro del verbo ENVIARPETICION. Este mensaje está en un formato definido por la aplicación específica 202 del cliente que la generó, y permanecerá sin modificar por el registro 204. El registro simplemente la distribuirá al servidor 222. De manera alternativa, el cliente 202 puede emitir un verbo CONVERSACIÓN, que establece un diálogo de conversación, bidireccional, con el servidor 222. Esto es equivalente a emitir un verbo ENVIARPETICION y RECIBIRCONTESTACION. Al emitir solamente un verbo ENVIARPETICION el cliente 202 puede establecer ya sea un diálogo de conversación o unidireccional con el servidor 222, dependiendo de los parámetros del verbo. Con referencia adicional a la Figura 2, el verbo ENVIARPETICION de recibe y se reconoce por la API 206. El registro luego inicia el proceso de la ejecución de verbos 208. La ejecución de verbos 208 validará los parámetros del verbo. También decidirá la dirección de destino. Lee, a partir del mensaje de la aplicación del cliente, el nombre de la aplicación 222 del servidor para la cual se propone la petición del cliente. Luego pregunta a una base de datos 210 de servicios de directorio para determinar el destino de la red física para esa aplicación 222 del servidor. Los servicios de directorio 210 contienen los códigos de enrutamiento de la red física para cada aplicación del cliente/servidor en la red. Cuando se da un mensaje de petición o contestación al registro para distribuir hacia una aplicación específica en la red, el registro determina cuando esa aplicación reside al traducir su nombre a un nodo de red física vía los servicios de directorio. De esta manera, cuando se hace migrar una aplicación a otro nodo en la red, solo se necesitan actualizar los servicios de directorio, como lo opuesto a actualizar cada aplicación del cliente/servidor. En la modalidad preferida el destino de red de una aplicación se representa por un nombre de tres partes, que consiste de un dominio, un NombredeServicio, y un CalificadordeServicio. El dominio se refiere a una sub-red distinta de la red de varias empresas. El NombredeServicio, se refiere a la función, en lugar de la ubicación física, el nodo de destino, es el identificador fundamental del destino. El CalificadordeServicio se refiere a un caso específico de la función del NombredeServicio, en casos donde hay más de un caso. Un ejemplo sería especificar una función del NombredeServicio de los datos geográficos del cliente en los CalificadoresdeServicio de "Este" y "Oeste". Con referencia adicional a la Figura 2, la ejecución de verbos 208 lanza la ejecución del verbo ENVIARPETICION al emitir una petición IPC generalizada a una interfaz 212 IPC generalizada. Las IPC (comunicaciones interproceso) se refieren a todos los componentes y procesos entre el registro en el extremo del cliente y registro en el extremo del servidor. Incluye los productos 216 de generación de mensajes, las redes de datos 218, y cualquiera que soporte las comunicaciones entre los procesos del cliente y los procesos del servidor. La interfaz 212 de IPC generalizada es el componente de registro responsable para seleccionar los productos de IPC apropiados para transportar el mensaje del cliente hacia el servidor. La interfaz 212 de IPC generalizada contiene una vista generalizada de todos los productos de generación de mensajes 216 y de la red 218, disponibles, y selecciona uno para el uso en la sesión corriente. También es responsable de traducir la envoltura del mensaje (el mensaje mismo permanece no modificado) al formato apropiado del producto de IPC seleccionado. La petición de IPC generalizada es una orden emitida por la ejecución de verbos 208 a la interfaz 212 de IPC generalizada. Contiene el mensaje del cliente, la dirección de red del servidor y una petición para enviar el mensaje La interfaz 212 de IPC generalizada se muestra en mayor detalle en la Figura 2a, que es un diagrama de flujo de datos que ilustra la operación de la interfaz 212. Con referencia a Figura 2a, la interfaz de IPC generalizada se identifica dentro de la línea discontinua. Consiste de tres componentes lógicos primarios: un procesador de petición 230 de la interfaz de IPC generalizada, una calificación 232 del producto de IPC, y una interfaz 234 de generación de mensajes de IPC. También contiene una base de datos de la información de servicios disponibles 236, que puede ser una base de datos dividida de los servicios de directorio 210, o una base de datos separada. El procesador de petición 230 de la interfaz de IPC generalizada proporciona la interfaz formal e inicial a la ejecución de verbos 208. Recibe la petición 240 de IPC generalizada y determina qué servicios se requieren para procesar la petición. Luego compila estos servicios en una lista de servicios requeridos 242, que la envía a la calificación 232 del producto de IPC. La lista de servicios requeridos 242 es un conjunto de puntos de datos, cada punto que identifica un servicio definido por el registro que se necesita para procesar la petición. Los ejemplos de estos servicios son la puesta persistente de mensajes en cola de espera, recuperación de mensajes, y exceso del tiempo impartido. El componente 232 de la calificación del producto de IPC determina que producto 216 de generación de mensajes se va a usar para transportar el mensaje del cliente sobre la red de datos 218. Esta determinación se basa en dos entradas. La lista de servicios requeridos 242 del procesador de petición 230, y una lista de productos 244 de IPC disponibles a partir de la base de datos 236 de información de servicios disponibles. La base de datos 236 de información de servicios disponibles, que recibe a los servicios de directorio 210 en la modalidad preferida del registro, contiene las listas preprogramadas de todos los productos de IPC disponibles (que incluye los productos 216 de generación de mensajes y los protocolos de la red de datos 218) y sus requerimientos. En base a los servicios requeridos 242 para la petición particular, y los productos de IPC disponibles 244, el componente 232 de calificación del producto de IPC selecciona el producto de IPC apropiado 216 para el uso. Luego envía la identificación de este producto 246 de IPC seleccionado a la interfaz 234 degeneración de mensajes de IPC. La interfaz 234 de generación de mensajes de IPC proporciona la interfaz del registro a los productos de IPC seleccionados, incluyendo el producto 216 de generación de mensajes. Como se señala previamente, IPC se refiere a todos los componentes necesarios para transportar el mensajes desde el registro del cliente al registro del servidor; esto incluye los productos 216 de generación de mensajes, normal principalmente la industria y los productos 218 de la red de datos. Traduce la petición 240 de IPC generalizada a un formato definido y requerido por el producto 216 de generación de mensajes, seleccionado. También inicia el diálogo con el producto 216 de generación de mensajes. Cuando la petición 240 de IPC generalizada (que contiene el mensaje de petición nativo del cliente) se traduce al apropiado formato del producto 216 de generación de mensajes, se pasa al producto 216 de generación de mensajes para transportarse sobre la red de datos 218 a un servidor distante 222. Con referencia nuevamente a la Figura 2, en el extremo del servidor, el producto 216 de generación de mensajes recibe el mensaje desde la red 218, y distribuye el mensaje 224 al registro 204 via la interfaz 212 de IPC generalizada. Esta distribución del mensaje 224 al registro 204 junto con el proceso completo llevado a cabo por el registro en el extremo del servidor, se controla por un componente del registro identificado como un monitor 220 del proceso del registro. El monitor 220 del proceso de registro controla el recibo y procesamiento de los mensajes del servidor 222. Sus objetivos son maximizar el rendimiento de mensajes del servidor, manejar el número deseado de tareas del servidor para procesar las cargas de trabajo, controlar la capacidad y utilización del servidor al terminar/reactivar las tareas del servidor conforme cambien las demandas de la carga de trabajo, y para proporcionar mecanismos definidos por la aplicación para controlar la asignación de recursos del servidor. Con referencia a la Figura 2b, el monitor del proceso de registro (RPM) 220 se muestra en mayor detalle para ilustra su operación. El RPM consiste de tres componentes primarios: un monitor de línea de espera (QM) 260, un monitor de proceso (PM) 262, y un monitor de control (CM) 264. Conforme se recuperan los mensajes unidos al servidor de la red 218 por los productos 216 de generación de mensajes, se retienen en colas de espera pendientes de la recuperación por el registro 204. Cada cola de espera se asigna a una clase de servicio para indicar su prioridad. Cada QM 260 se asigna a una cola o lista de espera o a un intervalo de colas o listas de espera y, por lo tanto, a una clase de servicio o intervalo de clases. El QM 260 inspecciona estas listas o colas de espera al recibir los datos 226 del estado de la cola de espera a partir de los productos 216 de generación de mensajes. Al investigar que los mensajes se liberan del procesamiento del servidor, el QM 260 conoce el nivel corriente de utilización del servidor y su capacidad para manejar mensajes adicionales. Cuando el QM 260 determina que el servidor tiene suficiente capacidad de recursos para manejar mensajes adicionales, el QM 260 selecciona un mensaje de una cola en espera específica para el procesamiento subsecuente. Luego envía al PM 262 los requerimientos 270 para una conexión del servidor necesaria para recuperar el mensaje. Esta conexión 276 del servidor representa un enlace de procesamiento entre el sistema de operación del servidor 222 y el registro 204. Se usará por la aplicación 222 para pedir y recibir el mensaje de cliente. El PM 262 enviará una petición 272 al servidor 222 para ajustar una conexión por el registro mismo con el registro. El servidor 222 luego emitirá un verbo REGISTRO al registro. Estos establece una sesión entre el servidor 222 y el registro 204, idéntico a la manera en la cual lo hace el servidor 202. El servidor 222 luego emite un verbo RECIBIRPETICION, que permite recibir el mensaje de petición del cliente via la conexión 276 del servidor. El verbo RECIBIRPETICION se recibe por la API 206 y se pasa a la ejecución de verbo 208 para el procesamiento. La ejecución de verbo 208 valida los parámetros. A partir del parámetro S-PETICION-MSG el registro conoce donde el mensaje está y puede recuperarlo vía la interfaz 212 de IPC generalizada. La interfaz 212 de IPC recupera el mensaje 224 y extrae el mensaje de petición nativo del cliente de éste. Este mensaje de petición del cliente luego se pasa al servidor 222 para el procesamiento específico de la aplicación. El CM 264 sirve como una función de utilidad, proporciona el manejo de sistemas y configuración para el registro. Proporciona una interfaz gráfica al usuario (GUI) 266 a un operador de sistemas para permitir que un operador realice las funciones de administración del sistema. También permite que el operador modifique el dominio de las colas en espera manejadas por cada QM 260. Con referencia nuevamente a la Figura 2, después del procesamiento de mensaje del petición del cliente, y si se pide una petición, el servidor 222 emite un verbo ENVIARCONTESTACION. Este verbo contiene el mensaje de contestación del servidor como un parámetro que se identifica como WS-ENVIARCONTESTACION-MSG. Este verbo se procesa similar a como se proceso previamente el verbo ENVIARPETICION. Con referencia a la Figura 3a, un diagrama del flujo del proceso ilustra la operación del registro cuando una aplicación del cliente emite un verbo ENVIARPETICION para enviar un mensaje a una aplicación del servidor. Se llevaría a cabo una operación similar si se emitió un verbo CONVERSACIÓN. En el paso 302, la aplicación 202 del cliente inicia una petición para que se procese una aplicación 222 del servidor. Esta petición se debe distribuir a la aplicación 222 del servidor, que reside en una máquina distante. En el paso 302, la petición está de esta manera contenida dentro de la aplicación 202 del cliente. En el paso 304, el cliente 202 emite un verbo REGISTRO al registro 204. El verbo REGISTRO es la orden que establece una sesión de comunicación entre el cliente 202 y el registro 204. En el paso 306, el componente 208 de ejecución de verbos del registro 204 valida los parámetros del verbo REGISTRO. Luego, en el paso 308, la ejecución de verbo 208 construye un área de control de registro (RCA) , que es una asignación de memoria usada para pasar los parámetros verbales (incluyendo el mensaje del cliente) entre el cliente 202 y el registro 204. En el paso 310, el cliente 202 emite un verbo ENVIARPETICION al registro 204. El cliente 202 envía su mensaje de petición como un parámetro del verbo ENVIARPETICION. En el paso 312, el componente 208 de ejecución de verbos del registro 204 valida los parámetros del verbo ENVIARPETICION. Luego, en el paso 314, la ejecución de verbos 208 determina la dirección de enrutamiento de la red física de la aplicación 222 del servidor, propuesta. Esto se hace el nombre de la aplicación del servidor a partir del mensaje del cliente y traduciendo ese nombre a un destino d la red vía una pregunta a los servicios de directorio 210. Los servicios del directorio 210 regresarán un destino de red en forma de un dominio, un NombredeServicio y un CalificadordeServicio, como se especifica previamente con referencia a la Figura 2. En el paso 316, el componente 208 de ejecución de verbos realiza su función final en el verbo ENVIARPETICION al emitir una petición de IPC generalizada a la interfaz 212 de IPC generalizada. La petición de IPC generalizada es una orden que da instrucciones a la interfaz 212 de IPC para realizar ciertas funciones necesarias para distribuir el mensaje del cliente. Sus funciones se especifican en los pasos de 318 hasta 324. La petición de IPC también contiene el mensaje del cliente y la dirección de red del servidor. La emisión de la petición de IPC generalizada se representa en la Figura 2a como el punto 240. Con referencia adicional a la Figura 3a, en el paso 318, el procesador de petición 230 de IPC generalizada compila una lista de servicios que se requieren para procesar la petición de IPC generalizada. Estos servicios requeridos se realizarán por el producto 216 de generación de mensajes. La lista de servicios requeridos 242 que se genera se usa por el componente 232 de la calificación del producto de IPC en el paso 320 para seleccionar un producto de IPC. La calificación 232 del producto de IPC también recibe una lista de productos de IPC disponibles 244 a partir de la base de datos 236 de la información de servicios disponible. En el paso 320, la calificación 232 del producto de IPC compara los servicios requeridos de la lista de servicios requeridos 242 a aquellos ofrecidos a partir de ciertos productos de IPC identificados en la lista de productos de IPC disponibles 244, selecciona el producto de IPC apropiado. El producto de IPC seleccionado será un producto 216 de generación de mensajes y/o un protocolo de transporte de la red 218 de datos. La identificación del producto de IPC seleccionado luego se envía al componente de interfaz 234 de generación de mensajes de IPC. En el paso 322, el componente 234 de interfaz de generación de mensajes de IPC da formato a la petición de IPC generalizada (que se ha recibido de la ejecución de verbos 208 como se representa en la Figura 2a) en un mensaje que es propiedad privada al producto de IPC seleccionado. Los procedimientos a esta traducción de formatos se han programado en el componente 234 de interfaz de generación de mensajes de IPC. Luego en el paso 324, la interfaz 234 establece una sesión de comunicaciones con el producto 216 seleccionado de generación de mensajes de una manera que es la norma para ese producto de generación de mensajes. Una vez que se establece la sesión, el mensaje se pasa al producto de generación de mensajes, que prosigue para distribuir el mensaje sobre la red de datos 218. Se señala que el "mensaje" referido en la presente consiste del mensaje de petición nativo del cliente empacado en una envoltura que el registro ha formateado específicamente para los productos de IPC seleccionados. El paso 326 representa el transporte del mensaje sobre la red de datos 218 de una manera que está normal para el protocolo particular de la red que está en uso. En el paso 328, el registro en el sitio del servidor se prepara para recibir el mensaje. El componente 260 del monitor de lista de espera (QM) del monitor 220 del proceso del registro inspecciona el mensaje en una cierta lista de espera. Esto se hace al recibir los datos 226 de listado de la lista o cola de espera de cada uno de los productos 216 de generación de mensajes, conectados. El QM 260 también investiga la capacidad de recursos del servidor al ser programado con la capacidad inicial del servidor e investiga cada mensaje que se envía al servidor. De esta manera, el QM 260 conoce la utilización corriente del servidor y su capacidad para procesar mensajes adicionales. Como parte del paso 328, el QM 260 valora la capacidad corriente del servidor y determina cuándo se puede recuperar el próximo mensaje.

En el paso 330, la QM 260 determina que el próximo mensaje se va a recuperar y emite los requerimientos para una conexión 276 del servidor. Como se menciona previamente, esta conexión 276 del servidor representa un enlace de procesamiento entre el sistema de operación del servidor 222 y el registro 204. Se usará por la aplicación 222 del servidor para pedir y recibir el mensaje. Los requerimientos de conexión del servidor se emiten por el QM 260 al monitor del proceso (PM) 262. En el paso 332, el PM 262 emite una petición para una conexión del servidor al sistema de operación del servidor. Esto sirve como un accionador para la aplicación 222 del servidor para establecer una sesión con el registro 204. Esto se hace al emitir un verbo REGISTRO, como se hace previamente por el cliente 202. En el paso 334, el Servidor 222 emite el verbo REGISTRO, que se lee por la API 206 del registro y pasa a la ejecución del verbos 208. Esto establece la sesión del servidor con el registro. El proceso continua en el conector A fuera de página en la Figura 3b. Con referencia ahora a la Figura 3b, en el paso 336, la ejecución de verbos 208 procesa el verbo REGISTRO del servidor como lo hace con el del cliente. Construye el RCA que es específica a la sesión corriente. Luego, en el paso 338, el servidor 222 emite un verbo RECIBIRPETICION al registro. El verbo RECIBIRPETICION da instrucciones al registro para enviar el mensaje del cliente al servidor 222. En el paso 340, la ejecución de verbos 208 valida los parámetros del verbo RECIBIRPETICION. Uno de estos parámetros se poblará con la dirección en la memoria del mensaje de petición del cliente. En el paso 342, la ejecución de verbos 208 extrae el mensaje de petición nativo del cliente del mensaje empacado que se distribuyó sobre la red 218, y pasa este mensaje de petición al servidor 222. En el paso 344, el Servidor 222 procesa el mensaje de petición del cliente de una manera que es específica a la aplicación e independiente del registro. Una contestación del servidor a la petición del cliente se puede pedir o no como se determina en el paso 346. Si se requiere una petición, el servidor 222 emite un verbo ENVIARCONTESTACION en el paso 348 que se procesa de la misma manera como un verbo ENVIARPETICION del cliente, empezando en el paso 310. La contestación del servidor luego se distribuye al cliente, como se indica en el paso 350. El servidor 222 luego prosigue para emitir otro verbo RECIBIRPETICION en el paso 352. Si no se requiere una contestación, como se determina en el paso 346, el servidor 222 emite otro verbo RECIBIRPETICION en el paso 352. Si no están en lista de espera más mensajes de petición para el servidor, se regresa un mensaje que señala "ningún mensaje más" al servidor 222 del registro 204, como se indica en el paso 354. Luego el proceso termina con el paso 356, en el cual el servidor 222 emite un verbo DEREGISTRO. El verbo de DEREGISTRO da instrucciones al registro para terminar la sesión. Si, en el paso 354, no se regresa el mensaje "no más mensajes", se hace una suposición que están en lista de espera más mensajes de petición. El proceso regresa el paso 340, en el cual la ejecución de verbos 208 prosigue para procesar el verbo RECIBIRPETICION al validar los parámetros Las especificaciones en la descripción anterior se deben interpretar como limitaciones en el alcance de la invención, sino sólo como especificaciones de la modalidad preferida. Son posibles otra variaciones y modificaciones obvias que se le ocurrirán a las personas expertas en la técnica. Se debe entender que la invención no se limita a los detalles exactos de la construcción mostrada y descrita en la presente sino que abarca también las modificaciones obvias que se les ocurran a las personas expertas en la técnica.

Claims (14)

1. 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 de computadora cliente-servidor que sirve como una capa lógica de comunicaciones entre aplicaciones y mecanismos de transporte de una red de datos que comprende: una pluralidad de medios del cliente, capaces de ejecutar aplicaciones controladas por un sistema de operación diferente; un primer medio de registro conectado a cada medio del cliente, para: (a) aceptar los mensajes específicos de la aplicación desde el medio del cliente, destinados para un medio preseleccionado del servidor, y encapsulados en un mensaje específico del registro normal; (b) traducir los mensajes específicos del registro a un protocolo preseleccionado; una red para comunicar los mensajes traducidos a un extremo distante; un segundo medio de registro localizado en el extremo distante para: (c) aceptar los mensajes traducidos; y (d) convertir los mensajes desde el formato de protocolo al mensaje específico de la aplicación original; un medio para conectar el medio de registro al medio preseleccionado del servidor para comunicar el mensaje específico de la aplicación al medio del servidor.
2. 2. El sistema según la reivindicación 1, que comprende además : un primer medio de generación de mensajes conectado entre el primer medio de registro y la red, para comunicar, hacia la red, los mensajes específicos del registro en el protocolo preseleccionado; y un segundo medio de generación de mensajes, conectado entre la red y la entrada del segundo medio de registro para recibir mensajes específicos del registro en el protocolo preseleccionado y transferirlos al segundo registro.
3. 3. El sistema según la reivindicación 1, en donde el primer medio de registro comprende además una interfaz de programación de la aplicación, conectada a una salida del medio del cliente, para recibir una orden verbal o de verbo del medio del cliente y traducir un mensaje específico de la aplicación relacionada desde el medio del cliente a un formato de registro correspondiente.
4. 4. El sistema según la reivindicación 3, en donde el primer medio de registro comprende además: un medio para validar los parámetros de la orden verbal y resolver subsecuentemente una dirección de destino para el mensaje desde el medio del cliente; y un medio de base de datos de servicios de directorio cuestionado por la orden verbal validada, para determinar un destino lógico desde la red al medio del servidor para el cual se propuso el mensaje del cliente, según la reivindicación
5. 5. El sistema según la reivindicación 2, en donde el primer medio de registro comprende además un medio de comunicación en interproceso para conmutar el mensaje en el formato de registro a uno de una pluralidad de adaptadores conectados en paralelo a la salida del medio de comunicación interproceso, en respuesta a la información de destino derivada del medio de base de datos de servicios de directorio, el adaptador correlaciona el mensaje de registro en un formato de protocolo específico requerido por un primer miembro de generación de mensajes, seleccionado y destinado a un medio del servidor.
6. 6. El sistema según la reivindicación 2, en donde el segundo medio de registro comprende: una pluralidad de adaptadores conectados en paralelo, conectados a las salidas del segundo medio de generación de mensajes para traducir los mensajes en el protocolo específico al formato de registro; un medio de comunicación interproceso para recibir selectivamente los mensajes traducidos desde los adaptadores para el proceso adicional; y una interfaz de programación de la aplicación, conectada a una salida del medio de comunicación interproceso para traducir el mensaje, en el formato del registro, a un formato requerido por una aplicación del servidor y conectarlo a un servidor designado.
7. 7. El sistema según la reivindicación 6, que comprende además un medio de inspección de registro, conectado a una entrada de la interfaz de programación de la aplicación, para programar el procesamiento por un servidor designado.
8. 8. El sistema según la reivindicación 7, en donde el segundo medio comprende además: (a) un medio para validar los parámetros de la orden verbal generada por el servidor, en respuesta a una pregunta del mensaje, y la solución subsecuente de una dirección de destino para el mismo, a partir del medio del cliente; (b) un medio de base de datos de servicios de directorio cuestionado por la orden de validación verbal, a partir del medio del cliente, para determinar un destino lógico de la red para una respuesta, desde el medio del servidor, a un medio del cliente que generó una pregunta inicial; (c) el medio de comunicación interproceso en el segundo medio de registro que selecciona un adaptador en el segundo medio de registro, para comunicar la respuesta a una entrada de un segundo medio de generación de mensajes seleccionado; y un medio adaptador, localizado fuera del segundo medio de registro, para conectar el medio de generación de mensajes a la red.
9. 9. Un sistema de computadora de cliente y un servidor que sirve como una capa lógica de comunicaciones entre aplicaciones y mecanismos de transporte de una red de datos, que comprende: una pluralidad de clientes, cada uno capaz de iniciar aplicaciones controladas de un sistema de operación correspondiente; un primer registro conectado a cada cliente para: (a) aceptar los mensajes específicos de la aplicación de un cliente, destinados para un servidor preseleccionado y encapsulados en un mensaje específico del registro normal; (b) traducir los mensajes específicos del registro en un protocolo preseleccionado; una red para comunicar los mensajes traducidos a un extremo distante; un primer dispositivo de generación de mensajes conectado entre el primer registro y la red, para comunicar, hacia la red, los mensajes específicos del registro en el protocolo seleccionado; un segundo registro localizado en el extremo distante para: (c) aceptar los mensajes traducidos; y (d) convertir los mensajes desde el formato de protocolo al mensaje específico de la aplicación original; y en donde el segundo registro se conecta al servidor preseleccionado para comunicar el mensaje específico de la aplicación al servidor; un segundo de generación de mensajes, conectado entre la red y la segunda entrada del registro para recibir los mensajes específicos del registro con el protocolo preseleccionado y transferirlos al segundo registro.
10. 10. El sistema según la reivindicación 9, en donde el primer registro comprende además: una interfaz de programación de la aplicación, conectada a una salida del cliente para recibir una orden verbal desde el cliente y traducir un mensaje específico de la aplicación relacionada desde el cliente a un formato correspondiente del registro; un dispositivo de validación para validar los parámetros de la orden verbal y resolver subsecuentemente una dirección de destino para el mensaje desde el cliente; una base de datos de servicios de directorio cuestionada por una orden verbal validada para determinar un destino lógico de la red al servidor, para el cual se propuso el mensaje del cliente; un comunicador interproceso para conmutar el mensaje del formato del registro a uno de una pluralidad de adaptadores conectados en paralelo a la salida del comunicador interproceso, en respuesta a la información de destino derivada de la base da datos de servicios de directorio, el adaptador correlaciona el mensaje del registro en un formato especifico de protocolo requerido por un primer dispositivo seleccionado de generación de mensajes y destinado a un servidor.
11. 11. El sistema según la reivindicación 9, en donde el segundo registro comprende: una pluralidad de adaptadores conectados en paralelo conectados a las salidas del segundo dispositivo de generación de mensajes para traducir los mensajes en el protocolo específico al formato del registro; comunicación interproceso para recibir selectivamente los mensajes traducidos desde los adaptadores para el procesamiento adicional; y una interfaz de programación de la aplicación, conectada a una salida de la comunicación interproceso para traducir un mensaje, en el formato de registro, a un formato requerido por una aplicación del servidor y conectarla a un servidor designado; y un monitor de registro conectado a una entrada de la interfaz de programación de la aplicación, para programar el funcionamiento por un servidor designado; un segundo validador para validar los parámetros de la orden verbal generada por el servidor, en respuesta a una pregunta desde el mensaje y resolver subsecuentemente una dirección de destino para el mismo, desde el cliente; una base de datos de servicios de directorio cuestionada por la orden de validación verbal a partir del cliente, para determinar un destino lógico de la red para una respuesta, desde el servidor hacia un cliente que generó una pregunta inicial; la comunicación interproceso en el segundo registro que selecciona un adaptador en el segundo registro para comunicar la respuesta a una entrada de un segundo dispositivo seleccionado de generación de mensajes; y un adaptador, colocado fuera del segundo registro, para conectar el dispositivo de generación de mensajes a la red.
12. 12. En un sistema de computadora que tiene una pluralidad de máquinas de cliente y servidor, interconectadas selectivamente sobre una red, cada una capaz de ejecutar aplicaciones controladas por un sistema de operación diferente, una capa lógica de comunicaciones entre las máquinas y que comprende los pasos de: realizar un primer proceso de registro, que incluye: (a) aceptar los mensajes específicos de la aplicación desde un cliente, destinados para un servidor preseleccionado, y encapsulados en un mensaje específico del registro, normal; (b) traducir los mensajes específicos del registro en un protocolo preseleccionado; someter el mensaje específico de registro a la generación de mensajes para comunicación hacia la red, de los mensajes específicos del registro en el protocolo preseleccionado; realizar un segundo proceso de registro en un extremo distante que incluye: (c) aceptar los mensajes traducidos; y (d) convertir los mensajes desde el formato de protocolo al formato específico de la aplicación original; conectar el mensaje específico de la aplicación, convertido al servidor preseleccionado;
13. 13. El método según la reivindicación 12, en donde el primer proceso de registro comprende además los pasos de: programar la aplicación trabajando directamente con el cliente, para recibir una orden verbal desde el cliente y traducir un mensaje específico de la aplicación relacionada desde el cliente a un formato del registro, correspondiente; validar los parámetro de la orden verbal y resolver subsecuentemente una dirección de destino para el mensaje desde el cliente; preguntar a una base de datos de servicios de directorio por la orden verbal validada para determinar un destino lógico de la red al servidor para el cual se propuso el mensaje del cliente; conmutar la comunicación interproceso del mensaje en el formato del registro a una de una pluralidad de adaptadores en respuesta a la información de destino derivada de la base de datos de servicios de directorio, el adaptador correlaciona el mensaje del registro en un formato específico de protocolo requerido por un primer dispositivo seleccionado de generación de mensajes, y destinado para un servidor.
14. 14. El método según la reivindicación 12, en donde el segundo proceso de registro, comprende los pasos de: someter los mensajes en el protocolo específico a la adaptación invertida, traduciendo de este modo los mensajes en el formato del registro; conmutar por conmutación interproceso para recibir selectivamente los mensajes adaptados, traducidos para el procesamiento adicional; programar por la aplicación trabajando directamente para traducir un mensaje, en el formato del registro, a un formato requerido por una aplicación del servidor y conectándolo a un servidor designado; y inspeccionar el trabajo directo de la programación para aplicación, para programar el procesamiento por un servidor designado; validar los parámetros de la orden verbal generado por el servidor, en respuesta a una pregunta del cliente y resolver subsecuentemente una dirección de destino para el mensaje desde el cliente; preguntar a una base de datos de servicios de directorio por la orden de validación verbal del cliente, para determinar un destino lógico de la red para una respuesta desde el servidor hacia el cliente que generó una pregunta inicial; comunicar la respuesta a la dirección del cliente para la distribución final al cliente que inició la aplicación.