SISTEMA Y MÉTODO DE PASO A UNIDAD SUSTITUTORIA DESCRIPCIÓN DE LA INVENCIÓN La presente invención se refiere a arquitectura de computadoras y redes y más particularmente se refiere a un sistema y método de paso a unidad sustitutoria o de recuperación ante fallos. La sociedad cada vez más está confiando en las computadoras y redes para interactuar y llevar a cabo negocios. Para lograr un alto nivel de disponibilidad demandada en sistemas críticos, el tiempo improductivo no planeado provocada por defectos en software y hardware debe reducirse . La industria de servicios financieros es sólo un ejemplo de una industria que demanda sistemas altamente disponibles. De hecho, un gran número de actividades de procesamiento de datos en la industria financiera de hoy en día son soportadas por sistemas de cómputo. Particularmente interesantes son las aplicaciones denominadas Procesamiento de Transacción en Línea (OLTP) "en tiempo real" y "casi en tiempo real" , las cuales típicamente procesan grandes cantidades de transacciones financieras durante un periodo prolongado, con alta velocidad y baja latencia. Estas aplicaciones generalmente muestran las siguientes características: (1) procesamiento de datos complejo y de alta velocidad, (2) almacenamiento de datos no volátil
fiable, y (3) alto nivel de disponibilidad, es decir, la capacidad de soportar los servicios en una base sustancialmente ininterrumpida. Cuando se implementan, sin embargo, aplicaciones existentes tienden a realizar cambios entre estos requerimientos de rendimiento, puesto que, debido a sus efectos contradictorios en el comportamiento del sistema, ningún diseño puede satisfacer completamente todas estas características simultáneamente, como se especifica en mayor detalle en lo siguiente. Primero, el procesamiento de datos complejo se refiere a la capacidad de realizar, en una forma puntal, una gran cantidad de cálculos, recuperaciones/actualizaciones de bases de datos, etc. Esto puede implementarse a través de procesamiento paralelo, donde múltiples unidades de trabajo se ejecutan simultáneamente en la misma máquina física o en una red distribuida. En algunos sistemas, el resultado de cada transacción depende de los resultados de las transacciones previamente completadas. Los aspectos paralelos de tales sistemas son, inherentemente no deterministas: debido a condiciones de competencia, tareas de programación del sistema operativo, o retardos variables de la red, la secuencia del mensaje y la ejecución de la cadena no pueden ser predichas, ni pueden ser procesadas en paralelo simplemente al pasar copias de mensaje de entrada a un sistema duplicado. Los sistemas no deterministas tienen un
resultado no idéntico, de modo que no se ejecutan en paralelo en dos diferentes máquinas de cómputo, con la intención de tener un sustituto para la otra en caso de falla. En segundo lugar, el almacenamiento de datos no volátil confiable se refiere a la capacidad de almacenar persistentemente los datos procesados, incluso si una cantidad de componentes de software o hardware del sistema experimentan falla no esperada. Esto puede implementarse normalmente al utilizar transacciones Atómicas, Consistentes, Aisladas y Durables ("ACID") cuando se acceden o modifican los datos compartidos. Las transacciones ACID pueden asegurar la integridad y persistencia de los datos tan pronto como se complete una unidad de trabajo. Cada transacción ACID dedicada se escribe en la memoria no volátil de la computadora (disco duro) , la cual ayuda a asegurar la durabilidad de los datos, pero es muy costosa en términos de rendimiento y típicamente ralentiza todo el sistema. En tercer lugar, los sistemas altamente disponibles intentan asegurar el porcentaje de disponibilidad de un sistema de cómputo dado tan cerca como sea posible al 100% del tiempo. Tal disponibilidad puede ser implementada a través de software y/o hardware redundantes, los cuales se encargan de la funcionalidad en caso de que se detecte una falla de componente. Para obtener el éxito, la recuperación ante fallos duplica no sólo los datos, sino también el estado
de proceso. Como se apreciará por aquellos de experiencia en la técnica, la duplicación de estado puede ser particularmente desafiante en sistemas no deterministas (es decir, sistemas donde el procesamiento computacional del mismo conjunto de eventos puede tener más de un resultando dependiendo del orden en el cual se procesan esos eventos) . Las aplicaciones de software altamente disponibles normalmente se despliegan en ambientes redundantes, para reducir y/o eliminar el punto simple de falla que comúnmente se asocia con el hardware subyacente. Dos procedimientos comunes se conocen como recuperación ante fallos en caliente y recuperación ante fallos templada. La recuperación ante fallos en caliente se refiere a procesar simultáneamente la misma entrada en múltiples sistemas, esencialmente proporcionando una redundancia completa en el caso de una falla en uno de esos sistemas. La recuperación ante fallos templada se refiere a duplicar el estado de la aplicación (es decir, los datos) en sistemas de respaldo, sin procesar esos datos en los sistemas de respaldo, pero teniendo aplicaciones capaces de procesar esos datos cargados y en espera en caso de falla de un sistema primario. La recuperación ante fallos en frío, la cual por muchos no es considerada que sea una forma de alta disponibilidad, se refiere simplemente a arrancar un sistema de respaldo y preparar ese sistema de respaldo para asumir responsabilidades de procesamiento a
partir del sistema primario. En configuraciones de recuperación ante fallos en caliente, dos casos de la aplicación se están ejecutando simultáneamente en dos diferentes instalaciones de hardware, procesando copias de la misma entrada. Si una de ellas experimenta una falla crítica, un sistema de sincronización suplementario puede asegurar que el otro continuará soportando la carga de trabajo. En las configuraciones de recuperación ante fallos templada, uno de los sistemas, designado como primario, está ejecutando la aplicación; en caso de falla, el segundo sistema, designado como de respaldo, el cual está aguardando en un estado en espera, "despertará", se encargará y retomará la funcionalidad. Procedimientos de recuperación ante fallos en caliente de la técnica anterior tienen por lo menos dos desventajas. La primera, el software suplementario tiene que ejecutarse para mantener sus dos sistemas sincronizados. En el caso de sistemas no deterministas, este esfuerzo de sincronización puede conducir a una disminución inaceptable (o de otra forma indeseable) en el rendimiento y complejidad donde el orden de llegada de los eventos debe ser garantizado para ser idéntico. También, los sistemas con corrientes de la técnica anterior utilizados en tales aplicaciones típicamente permiten que múltiples cadenas se ejecuten simultáneamente, de modo que son inherentemente no deterministas. Incluso los
no deterministas son los sistemas con servidores y clientes geográficamente distribuidos, donde el retardo de red variable distribuye los mensajes al servidor en una secuencia impredecible . La recuperación ante fallos templada puede utilizarse para solucionar ciertos problemas con la recuperación ante fallos en caliente. La recuperación ante fallos templada puede ser otra forma de implementar la recuperación ante fallos de sistemas no deterministas, al duplicar los datos del sistema en un sistema de respaldo redundante, y después restablecer la funcionalidad de la aplicación al sistema secundario. Este procedimiento tiene sus desventajas en el tiempo requerido para recuperar los datos a un estado consistente, después poner la aplicación en un estado funcional, y al final, regresar la aplicación al punto en el procesamiento donde se quedó fuera. Este proceso normalmente toma horas, requiere intervención manual y no puede recuperar generalmente las transacciones al vuelo. Un número de patentes intenta dirigir por lo menos parte de los problemas anteriores. La Patente Norteamericana No. 5,305,200 propone lo que esencialmente es un mecanismo sin renunciación para comunicaciones en un escenario de comercialización negociada entre un comprador/vendedor y un comerciante (creador de mercado) . La redundancia se proporciona para asegurar que el mecanismo sin renunciación
funcione en el caso de una falla. No dirige la recuperación ante fallos de una aplicación de transacción en línea en un ambiente no determinista. En términos simples, la Patente Norteamericana No. 5,305, 200 se dirige a proporcionar una respuesta inequívoca a la pregunta: "¿Fue enviada la orden o no?" después de experimentar una falla de red. La Patente Norteamericana No. 5,381,545 propone una técnica para respaldar datos almacenados (en una base de datos) mientras las actualizaciones aún se están realizando en los datos. La Patente Norteamericana No. 5,987,432 dirige un sistema de planta de cotización de datos de mercado tolerante a fallos para ensamblar datos de mercado financiero mundial para distribución regional. Éste es un ambiente determinista, y la solución se enfoca en proporcionar un flujo de datos ininterrumpido de una sola vía a los consumidores. La Patente Norteamericana No. 6,154,847 proporciona un método mejorado para revertir transacciones al combinar un registro de transacción en un almacén no volátil tradicional con una lista de transacciones en el almacén volátil. La Patente Norteamericana No. 6,199,055 propone un método para llevar cabo transacciones distribuidas entre un sistema y un procesador portátil a través de un enlace de comunicación no seguro. La Patente Norteamericana No. 6,199,055 trata con autentificación, asegurando transacciones completas con dispositivos remotos, y con restablecer los
dispositivos remotos en caso de falla. En general lo anterior no dirige la recuperación ante fallos de una aplicación de transacción en línea en un ambiente no determinista. La Patente Norteamericana No. 6,202,149 propone un método y aparato para redistribuir automáticamente tareas para reducir el efecto de suspensión temporal de una computadora. El aparato incluye por lo menos un grupo de redundancia comprendido de uno o más sistemas de cómputo, los cuales a su vez son comprendidos de una o más particiones de cómputo. La partición incluye copias de un esquema de base de datos que se duplican en cada partición del sistema de cómputo. El grupo de redundancia monitorea el estado de los sistemas de cómputo y las particiones del sistema de cómputo, y asigna una tarea a los sistemas de cómputo basándose en el estado monitoreado de los sistemas de cómputo. Un problema con la Patente Norteamericana No. 6,202,149 es que no enseña cómo recuperar el flujo de trabajo cuando un sistema de respaldo asume la responsabilidad de procesar transacciones, pero de hecho se dirige a sí misma a la duplicación de toda una base de datos, lo cual puede ser ineficiente y/o lento. Además, tal duplicación puede provocar que información de transacción importante se pierda al vuelo, particularmente durante una falla del sistema primario o la red que interconecta el sistema primario y el de respaldo, llevando por consiguiente a un estado inconsistente entre el primario
y el de respaldo. En general, la Patente Norteamericana No. 6,202,149 carece de ciertas características que se desean en el procesamiento de transacciones en línea y similares, y en particular carece de características necesarias para recuperar ante fallos de sistemas no deterministas. La Patente Norteamericana No. 6,308,287 propone un método para detectar una falla de una transacción de componente, retrocediéndolo, almacenando un indicador de falla confiable de modo que se pueda recuperar después de una falla de sistema, y luego volver este indicador de fallas disponible para una transacción adicional. No dirige la recuperación ante fallos de una aplicación de transacción de un ambiente no determinista. La Patente Norteamericana No. 6,574,750 propone un sistema de objetos distribuidos, duplicados, donde los objetos no son deterministas. Propone un método para garantizar la consistencia y limitar la reversión en el evento de falla de un objeto duplicado. Se describe un método donde un objeto recibe una solicitud de cliente entrante y compara la ID de la solicitud con un registro de todas las solicitudes previamente procesadas por réplicas del objeto. Si se encuentra una correlación, entonces la respuesta asociada se devuelve al cliente. Sin embargo, este método en aislamiento no es suficientes para resolver los diversos problemas en la técnica anterior. Otro problema es que el método de la Patente
Norteamericana No. 6,574,750 asume una cadena de invocación sincrónica, la cual es inapropiada para aplicaciones de Procesamiento de Transacción en Línea ("OLTP") de alto rendimiento. Con una invocación sincrónica, el cliente espera una respuesta o una pausa antes de continuar. El objeto invocado a su vez puede convertirse en un cliente de otro objeto, propagando la cadena de llamadas sincrónica. El resultado puede ser una operación sincrónica extensiva, bloqueando el procesamiento de cliente y requiriendo que pausas largas se configuren en el cliente de origen. Un aspecto de la presente invención proporciona un sistema para recuperación ante fallos que comprende por lo menos un cliente que se puede conectar selectivamente a uno de por lo menos dos servidores interconectados mediante una conexión de red. En un estado normal, uno de los servidores se designa como servidor primario cuando se conecta al cliente y el resto de los servidores se designa como servidores de reserva cuando no se conectan al cliente. Por lo menos un cliente se configura para enviar mensaje al servidor primario. Los servidores se configuran para procesar los mensajes utilizando por lo menos un servicio que es idéntico en cada uno de los servidores. Los servicios desconocen si un servidor correspondiente al servicio está operando como el servidor primario o el servidor de reserva. Los servidores además se configuran para mantener una
biblioteca u otros conjuntos distintos de código útil, que realiza una variedad de tareas, incluyendo indicar si un servidor es el servidor primario o un servidor es el servidor de reserva. Los servicios dentro de cada servidor son para realizar llamadas externas a su biblioteca respectiva. La biblioteca en el servidor primario se configura para completar las llamadas externas y devolver los resultados de las llamadas externas al servicio en el servidor primario y para reenviar resultados de las llamadas externas al servicio en el servidor de reserva. La biblioteca en el servidor secundario no realiza llamadas externas sino simplemente reenvía los resultados de las llamadas externas, como recibidos del servidor primario, al servicio en el servidor secundario cuando se solicite hacerlo de esta forma por el servicio en el servidor secundario. La biblioteca puede implementarse como uno o más conjuntos distintos de código útil. Los servidores cada uno puede configurarse para mantener un recurso compartido donde los servicios puedan almacenar resultados para procesar los mensajes. El recurso compartido puede ser, y por razones de rendimiento, de preferencia se mantienen en una memoria de acceso aleatorio de un servidor respectivo. Sin embargo, no es necesario mantener el recurso compartido en la memoria de acceso aleatorio.
La llamada externa puede ser (como una lista no limitante de ejemplos) una solicitud de una marca de tiempo, o llamada a otro servicio proporcionado en el mismo servidor, o una llamada a otro servicio proporcionado físicamente en una máquina separada. El sistema puede ser parte de un sistema de comercialización electrónica y el mensaje de este modo puede ser una orden para comprar o vender un título. En este caso, la llamada externa puede ser una solicitud de una cotización de fuente de mercado para un valor del título. Donde el sistema es un sistema de comercialización electrónica, por lo menos un servicio puede incluir uno de un servicio de colocación de orden; un servicio de cancelación de orden; un servicio de cambio de orden; un servicio de correlación de orden; un servicio para entrar a una negociación previamente ejecutada; o un servicio para entrar a una negociación cruzada . El servicio en el servidor primario puede configurarse para confirmar al cliente que el mensaje ha sido procesado sólo si el servidor de reserva confirma que los resultados de las llamadas externas se reenviaron exitosamente al servidor de reserva. El servicio en el servidor primario puede ser configurado para confirmar al cliente que el mensaje ha sido procesado independientemente de si el servidor de reserva
confirma que los resultados de las llamadas externas se reenviaron exitosamente al servidor de reserva. El servidor primario puede estimar que el servidor de reserva ha fallado si el servidor de reserva no confirma que los resultados de las llamadas externas se reenviaron exitosamente al servidor de reserva dentro de un periodo de tiempo predefinido. Otro aspecto de la invención proporciona un método para recuperación ante fallos en un sistema que comprende: por lo menos un cliente que se puede conectar selectivamente a uno de por lo menos dos servidores interconectados mediante una conexión de red; uno de los servidores se designa como servidor primario cuando se conecta al cliente y el resto de los servidores se designa como servidor de reserva cuando no se conecta al cliente; por lo menos un cliente configurado para enviar mensajes al servidor primario; el método comprende: configurar los servidores para procesar los mensajes utilizando por lo menos un servicio que es idéntico en cada uno de los servidores y desconoce si un servidor correspondiente al servicio está operando como el servidor primario o el servidor de reserva; configurar los servidores para mantener una biblioteca que indica si el servidor es el servidor primario o el servidor es el servidor de reserva; configurar los servicios para hacer llamadas
externas a su biblioteca respectiva; y configurar la biblioteca en el servidor primario para completar las llamadas externas y devolver los resultados de las llamadas externas al servicio en el servidor primario y para reenviar los resultados de las llamadas externas al servicio en el servidor de reserva. Otro aspecto de la invención proporciona un medio que se puede leer por computadora que almacena un conjunto de instrucciones de programación que se pueden ejecutar en uno de por lo menos dos servidores interconectados mediante una conexión de red que se puede conectar selectivamente por lo menos a un cliente. Uno de los servidores puede ser designado como servidor primario cuando se conecta al cliente en cuyo caso el resto de los servidores se designa como servidor de reserva cuando no se conectan al cliente. Por lo menos un cliente se configura para enviar mensajes al servidor primario. Las instrucciones de programación comprenden: instrucciones para configurar los servidores para procesar los mensajes utilizando por lo menos un servicio que es idéntico en cada uno de los servidores y desconoce si un servidor correspondiente al servicio está operando como el servidor primario o el servidor de reserva; instrucciones para configurar los servidores para mantener una biblioteca que indica si el servidor es el servidor primario o el servidor es el servidor de reserva;
instrucciones para configurar los servicios para hacer llamadas externas a su biblioteca respectiva; y instrucciones para configurar la biblioteca en el servidor primario para completar las llamadas externas y devolver los resultados de las llamadas externas al servicio en el servidor primario y para reenviar los resultados de las llamadas externas al servicio en el servidor de reserva. BREVE DESCRIPCIÓN DE LOS DIBUJOS La invención ahora se describirá por medio de ejemplo solamente, y con referencia los dibujos anexos, en los cuales: La Figura 1 es una representación esquemática de un sistema para recuperación ante fallos de acuerdo con una modalidad de la invención; la Figura 2 es una representación esquemática del sistema en la Figura 1 como operando en un estado normal y que incluye detalles ejemplares de varios elementos de software que se ejecutan en los servidores en el sistema; la Figura 3 es un diagrama de flujo que representa un método para operar un sistema para recuperación ante fallos en el estado normal de acuerdo con otra modalidad de la invención; la Figura 4 muestra el sistema de la Figura 2 durante el rendimiento del método en la Figura 3 ; la Figura 5 muestra el sistema de la Figura 2
durante el rendimiento del método en la Figura 3 ; la Figura 6 muestra el sistema de la Figura 2 durante el rendimiento del método en la Figura 3; la Figura 7 muestra el sistema de la Figura 2 durante el rendimiento del método en la Figura 3; la Figura 8 muestra el sistema de la Figura 2 durante el rendimiento del método en la Figura 3; la Figura 9 muestra el sistema de la Figura 2 durante el rendimiento del método en la Figura 3 ; la Figura 10 muestra el sistema de la Figura 2 durante el rendimiento del método en la Figura 3 ; la Figura 11 muestra el sistema de la Figura 2 durante el rendimiento del método en la Figura 3; la Figura 12 muestra el sistema de la Figura 2 durante el rendimiento del método en la Figura 3; la Figura 13 muestra el sistema de la Figura 2 durante el rendimiento del método en la Figura 3 ; la Figura 14 muestra el sistema de la Figura 2 durante el rendimiento del método en la Figura 3 ; la Figura 15 es un diagrama de flujo que representa un método para recuperación ante fallos de acuerdo con otra modalidad de la invención; la Figura 16 muestra el sistema de la Figura 2 con uno de los servidores operando en el estado sólo primario de acuerdo con otra modalidad de la invención;
la Figura 17 muestra el sistema de la Figura 16 con otro servidor operando en el estado sólo primario de acuerdo con otra modalidad de la invención; la Figura 18 es un diagrama de flujo que representa un método para operar uno de los servidores en el estado sólo primario de acuerdo con otra modalidad de la invención; y la Figura 19 es un diagrama de flujo que representa un método para recuperación ante fallos desde el estado normal hasta el servidor de reserva que opera en el estado sólo primario de acuerdo con otra modalidad de la invención. Con referencia ahora a la Figura 1, un sistema para recuperación ante fallos se indica generalmente en 50. El sistema 50 comprende una pluralidad de clientes 51-1 y 54-2 remotos (generalmente referidos en la presente como "cliente 54" y colectivamente "clientes 54" . Esta nomenclatura se utiliza para otros elementos en las Figuras) . Los clientes 54 se conectan a una red 58. La red 58 puede ser cualquier tipo de red de cómputo, tal como la Internet, una red de área local, una red de área extensa, o combinaciones de las mismas. A su vez, la red 58 se conecta a un primer servidor 62-1 y un segundo servidor 62-2. Por consiguiente, clientes 54 pueden comunicarse cada uno con el servidor 62-1 y el servidor 62-2 mediante la red 58, como se discutirá en mayor detalle en lo siguiente. Los clientes 54 cada uno pertenece a individuos y/o
entidades que utilizarán su cliente 54 respectivo para presentar solicitudes al servidor 62-2. Para conveniencia, tales individuos o entidades se refieren en la presente como comerciantes T, con el comerciante T-l utilizando el cliente 54-1, y el comerciante T-2 utilizando el cliente 54-2. Cada cliente 54 típicamente es un dispositivo de cómputo tal como una computadora personal que tiene un teclado y un ratón (y otros dispositivos de entrada) un monitor (u otro dispositivo de salida) y un módulo de escritorio que conecta el teclado, ratón y monitor y aloja una o más unidades de procesamiento central, memoria volátil (es decir, memoria de acceso aleatorio) , memoria no volátil (es decir, dispositivos de disco duro) e interfaces de red para permitir al cliente 54 comunicarse sobre la red 58. Sin embargo, se entenderá que el cliente 54 puede ser cualquier tipo de dispositivo de cómputo, tal como un asistente digital personal, teléfono celular, computadora tipo laptop, dispositivo de búsqueda de correo electrónico, etc. Servidores 62 pueden ser cualquier tipo de dispositivo de cómputo que puede operar para recibir y procesar mensajes de los clientes 54, tal como Sun Fire V480 que ejecuta en un sistema operativo UNIX, de Sun Microsystems, Inc. de Palo Alto California, y que tiene cuatro unidades de procesamiento central cada una operando en aproximadamente 900 megahertz y que tiene aproximadamente
cuatro gigabytes de memoria de acceso aleatorio y un dispositivo de almacenamiento no volátil tal como una unidad de disco duro. Otro tipo de dispositivo de cómputo adecuado para servidores 62 es un servidor HP ProLiant BL25p de Hewlett-Packard Company, 800 South Taft, Loveland, CO 80537. Sin embargo, se enfatizará que estos servidores particulares son sólo ejemplares, una vasta disposición de otros tipos de ambientes de cómputo para servidores 62-1 y 62-2 se encuentran dentro del alcance de la invención. El tipo de mensaje que es recibido y procesado por el servidor 62-1 no se limita particularmente, pero en una presente modalidad, el servidor 62-1 opera en un sistema de comercialización en línea, y de este modo es capaz de procesar mensajes que incluyen solicitudes para comprar, vender, cancelar, etc., títulos que pueden ser comercializados en línea. Más particularmente, el servidor 62-1 se puede operar para mantener un motor de correlación central (no mostrado) , donde las solicitudes se ejecutan entre sí, y contra un depósito central de órdenes para procesar por consiguiente la comercialización de títulos. El servidor 62-2 típicamente tiene un ambiente de cómputo idéntico (o por lo menos sustancialmente idéntico) como el servidor 62-1. Como se explicará además en lo siguiente, el ambiente de cómputo que incluye su hardware, sistema operativo, aplicaciones, etc., de este modo se
selecciona para volver al servidor 62-2 operativo para sustituir la funcionalidad del servidor 62-1 en el caso de falla de servidor 62-1. El sistema 50 también incluye un enlace 78 de duplicación que interconecta el servidor 62-1 y el servidor 62-2. En una presente modalidad, el enlace 78 de duplicación incluye por sí mismo un enlace 82 principal y un enlace 86 a prueba de fallos para proporcionar mayor fuerza en comunicaciones entre el servidor 62-1 y el servidor 62-2. Detalles adicionales sobre las funciones del servidor 62-1 principal, el servidor 62-2 de reserva y el enlace 78 de duplicación, y por extensión los diversos tipos de hardware que puede utilizarse para implementar los servidores 62-1 y 62-2, se volverán aparentes en la siguiente discusión. En la Figura 2, los servidores 62-1 y 62-2 se muestran en mayor detalle. También debe observarse, las diversas conexiones en la Figura 2 se muestran en líneas punteadas, para denotar conexiones virtuales entre varios elementos en el sistema 50, en contraste a las conexiones de línea gruesa en la Figura 1, las cuales denotan las conexiones físicas entre varios elementos del sistema 50. De este modo, tales conexiones como se muestra en la Figura 2 se pretenden para denotar el sistema 50 que opera en un estado normal por el cual el servidor 62-1 se designa como el
servidor primario y el servidor 62-2 se designa como el servidor de reserva, con el servidor 62-1 primario dando servicio a solicitud entre los clientes 54. Detalles adicionales sobre el estado normal, y otros estados en los cuales puede operar el sistema 50, se proporcionarán en lo siguiente . Con referencia aún a la Figura 2, el servidor 62-1 y el servidor 62-2 cada uno incluye una pluralidad de elementos de software que ejecutan en sus ambientes de hardware respectivos para dar servicio a solicitudes de clientes y proporcionar funcionalidad de recuperación ante fallos . El servidor 62-1 y el servidor 62-2 cada uno incluye un agente 90-1 y 90-2 de recuperación ante fallos respectivamente. Los agentes 90 de recuperación ante fallos se comunican entre sí y se pueden operar para probar periódicamente la integridad del enlace 78 y entre sí. En una presente modalidad, en el estado normal, el agente 90-1 de recuperación ante fallos distribuirá periódicamente una señal de mantener vigente (por ejemplo, "¿Estás vigente?") al agente 90-2 de recuperación ante fallos, al cual el agente 90-2 de recuperación ante fallos se espera responda periódicamente (por ejemplo, "Sí") . Siempre que son contestadas tales solicitudes por el agente 90-2 de recuperación ante fallos, y siempre que el servidor 62-1
primario continúa operando normalmente, entonces el sistema 50 permanecerá en el estado normal mostrado en la Figura 2. De este modo, el agente 90-1 de recuperación ante fallos siempre se puede operar para comunicarse con otros elementos de software en el servidor 62-1 para indicar que el estado normal está en efecto. Ahora debe ser aparente que los agentes 90 de recuperación ante fallos se pueden operar para hacer uso del enlace 82 principal y el enlace 86 de protección contra fallos que conjuntamente comprenden el enlace 78, como es apropiado o como se desee de otra forma. De esta forma, el sistema 50 puede permanecer en el estado normal siempre y cuando por lo menos uno del enlace 82 principal y el enlace 86 de protección contra fallos sean operacionales . Los servidores 62 cada uno incluye uno o más servicios que pueden recibir y procesar varias solicitudes de uno o más clientes 54. Los tipos de servicios no se limitan particularmente y pueden incluir cualquier tipo de servicio, aplicación, o proceso o similar para el cual se desea la protección de recuperación ante fallos. En una presente modalidad y puramente ejemplar, donde el sistema 50 es un sistema de comercialización en línea, los servidores 62 cada uno incluye un servicio 94 de colocación de orden y un servicio 98 de cancelación de orden. El servicio 94 de colocación de orden, como el nombre lo implica, se configura
para recibir solicitudes de los clientes 54 para colocar una orden de venta o una orden de compra para un título particular. El servicio 98 de cancelación de orden, como el nombre lo implica, se configura para recibir solicitudes de los clientes 54 para cancelar las órdenes de compra o venta para un título particular, que se colocó previamente utilizando el servicio 94, pero antes de que se llene completamente la orden particular. Otros tipos de servicios que podrían implementarse , como se presentará ahora para aquellos con experiencia en la técnica de comercialización electrónica, incluyen, sin limitación, correlación de orden, orden de cambio, entrar a una comercialización, o entrar a una comercialización cruzada. En una presente modalidad, los servicios 94 y 98 son de varios comercios, aunque éste no es un requisito. (Como se utiliza en la presente, el multiensarte variado no se utiliza en un sentido limitante, y se refiere a varias formas de procesamiento concurrente donde múltiples mensajes se están procesando simultáneamente, que además contribuye a la naturaleza no determinista de los sistemas. El multiensarte puede implementarse, por ejemplo, utilizando múltiples procesos, o utilizando múltiples cadenas de ejecución con un solo proceso) . Los servidores 62 cada uno también incluye una biblioteca 102 que se puede acceder a los servicios 94 y 98 correspondientes respectivos a la misma. Cada biblioteca 102
incluye un secuenciador 106 y una memoria caché 110. como se explicará en mayor detalle en lo siguiente, el secuenciador 106 genera un número de secuencia en respuesta a una solicitud de un servicio 94 ó 98 correspondiente a la biblioteca 102. El secuenciador 106-2 está inactivo en el estado normal y tal inactividad se representa en la Figura 2 por la codificación hash a través de óvalo que representa el secuenciador 106-2. (La codificación hash se utiliza en otros elementos para denotar si ese elemento está activo o inactivo en cualquier estado particular dado) . La memoria caché 110 es un área de almacenamiento para resultados de celdas de función externa formadas por la biblioteca 102. Cada biblioteca 102 también incluye un registro 114 de estado que mantiene el estado en el cual el sistema 50 está operando actualmente, y que se comunica continuamente con su agente 90 de recuperaciones ante fallos respectivo para poder verificar el estado en el cual está operando actualmente el sistema 50. En la Figura 2, el sistema 50 está operando en el estado normal y por consiguiente el registro 114-1 de estado indica que el servidor 62-1 está designado actualmente como el servidor primario mientras el registro 114-2 de estado indica que el servidor 62-2 está designado actualmente como el servidor de reserva. Sin embargo, como se explicará en mayor detalle en lo siguiente, el estado del sistema 50 puede cambiar dependiendo del estado operacional
de varios componentes en el sistema 50. Los servidores 62 cada uno también incluye un agente 118 de recursos externos el cual es responsable de hacer las llamadas externas a los recursos externos a nombre de los servicios 94 y 98, pero que se hacen mediante la biblioteca 102. Los recursos externos pueden incluir recursos que son externos a los servicios 94 y 98 pero que residen en cada servidor 62, tal como una marca de tiempo del reloj del sistema operativo (no mostrado) y/o recursos que son externos a cada servidor 62 conjuntamente, tal como en el caso de un sistema de comercialización electrónica, una alimentación marcada (no mostrada) que mantiene la información actualizada de los precios de mercado de varios títulos que pueden ser el objeto de una orden de compra o una orden de venta que se coloca mediante el servicio 94 de colocación de orden. Aquellos con experiencia en la técnica ahora apreciarán que las llamadas por los servicios 94 y 98 a tales recursos externos contribuyen a la naturaleza no determinista del sistema 50. En el estado normal, solamente el agente 118-1 de recursos externo está activo, mientras el agente 118-2 de recursos externo está inactivo. La inactividad del agente 118-2 de recursos externo se representa en la Figura 2 por la codificación hash a través del óvalo que representa el agente 118-2 de recursos externo. Los servidores 62 cada uno también mantiene un
recurso 122 compartido que mantiene los resultados de las etapas de procesamiento realizadas por los servicios 94 y 98 y/o mantiene los datos que pueden ser necesarios para ser accesibles mediante los servicios 94 y 98. Por ejemplo, en el sistema de comercialización electrónica de la presente modalidad, el recurso 122 compartido mantiene una libreta de órdenes, la cual simplemente es un conjunto de registros de órdenes colocadas por el servicio 94. De este modo, el servicio 94 de colocación de orden por ejemplo, puede crear un registro en el recurso 122 compartido de una orden de compra. Tal orden de compra puede necesitar ser accedida en un momento posterior por el servicio 98 de cancelación de orden para cancelar esa orden de compra e indica como tal en el recurso 122 compartido. De igual forma, la orden de compra puede necesitar ser accedida por un servicio de correlación (no mostrado) el cual también se ejecuta en los servidores 62 para correlacionar esa orden de compra, de acuerdo con las reglas de mercado, con una orden de venta correspondiente apropiada, y actualizar esa orden de compra y esa orden de venta para indicar que se ha efectuado una correlación y se llevará a cabo una comercialización. Los servidores 62 cada uno también mantiene un agente 126 de duplicación. En el estado normal, solamente el agente 126-2 de duplicación está activo, mientras el agente 126-1 de duplicación está inactivo. La inactividad del agente 126-1 de
duplicación se representa en la Figura 2 por la codificación hash a través del óvalo que representa el agente 126-1 de duplicación. Como se explicará en mayor detalle en lo siguiente, un agente 126 de duplicación activo se comunica con la biblioteca 102 en el servidor 62 de contraparte para facilitar la réplica de información del servidor primario al servidor de reserva . Con referencia ahora a la Figura 3, un método para procesar solicitudes durante el estado normal de acuerdo con otra modalidad de la invención se indica generalmente en 300. Para ayudar en la explicación del método se asumirá que el método presente se opera utilizando sistema 50 en el estado normal mostrado en la Figura 2. Además, la siguiente discusión del método 300 conducirá a un entendimiento adicional del sistema 50 y sus diversos componentes. Para conveniencia solamente, sin embargo, varias etapas de proceso del método 300 se indican en la Figura 3 como presentándose dentro de ciertos componentes del sistema 50. Tales indicaciones no se interpretarán en un sentido limitante. Sin embargo, se entenderá que el sistema 50 y/o el método 300 puede ser variado, y no necesitan funcionar como discute en la presente con untamente entre sí, y las etapas del método 300 no necesitan realizarse en el orden como se muestra. Tales variaciones se encuentran dentro del alcance de la presente invención. Tales variaciones también aplican a otros
métodos y diagramas de sistemas discutidos en la presente. Comenzando primero en la etapa 310, se recibe un mensaje de un cliente. El tipo de mensaje no se limita particularmente y es generalmente complementario a un tipo esperado de entrada para uno de los servicios que se ejecutan en los servidores. Cuando se realiza en el sistema 50, el mensaje puede ser de este modo una orden de compra o una orden de venta que se pretende como entrada para el servicio 94 de colocación de orden, o puede ser una orden de cancelación que se pretende como entrada para el servicio 98 de cancelación de orden. Por ejemplo, asumir que una orden para comprar se coloca en un mensaje de cliente 54-1 por el comerciante T-l y el mensaje se envía sobre la red 58 al servicio 94-1 de colocación de orden, donde, de acuerdo con la etapa 310, el mensaje es recibido por el servicio 94-1 de colocación de orden. Este rendimiento ejemplar de la etapa 310 se muestra en la Figura 4, como un mensaje M(Oi) se muestra como operando del cliente 54-1 y recibido en el servidor 62-1 en el servicio 94-1 de colocación de orden. La Tabla 1 muestra un formato ejemplar del mensaje de colocación de orden M(Oi) . Tabla I Mensaje MtO],) Número de Nombre de Campo Contenidos Campo Ejemplares 1 Comerciante Comerciante T-l 2 Nombre de Título ABC Co. 3 Tipo de Transacción Compra 4 Cantidad 1,000 unidades
Más particularmente, el Campo 1 de la Tabla I, nombrado "Comerciante" identifica que el comerciante originador del mensaje M(Oi) es el Comerciante T-l. El Campo 2 de la Tabla I, nombrado "Nombre de Titulo" identifica el nombre del titulo específico que es el objeto de la comercialización - en este ejemplo, "ABC Co . " . El Campo 3 de la Tabla I, nombrado "Tipo de Transacción" identifica si la orden es para comprar, vender, etc., el título identificado en el Campo 2. En este ejemplo, el tipo de transacción es "Comprar", indicando que ésta es una orden para comprar. El Campo 4 de la Tabla 1, nombrado "Cantidad" identifica la cantidad deseada del título - en el presente ejemplo, la Cantidad es "1,000 unidades", indicando que la intención es Comprar 1,000 unidades de ABC Co . Aquellos con experiencia en la técnica reconocerán que la orden en la Tabla 1 es una orden de mercado, ya que el precio de la orden se basará en si el precio de mercado actual es para el Título en el Campo 2. Habiendo recibido el mensaje en la etapa 310, el método 300 avanza a la etapa 315 en la cual señalar el servicio relevante hará algunas llamadas para datos externos utilizados para procesar adicionalmente el mensaje. Continuando con el ejemplo, en la etapa 315, el servicio 94-1 de colocación de orden hará tales llamadas externas a la
biblioteca 102-1 primaria. En este ejemplo, se asumirá que tales llamadas son para: i) una marca de tiempo para asignar a la orden en el mensaje ?(??) que identifica el tiempo en el cual se recibió la orden y, ii) un precio de mercado actual para el título identificado en la orden en el mensaje M(Oi) . El rendimiento de la etapa 315 se representa en la Figura 2 como una línea punteada que representa una llamada del servicio 94-1 de colocación de orden a la biblioteca 102-1 primaria se indica en 130. Después, en la etapa 320, la biblioteca 102-1 primaria hará las llamadas. La biblioteca 102-1 primaria consultará con el agente 114-1 de recuperación ante fallos y confirmará que el servidor 62-1 se designa como el servidor primario y que el sistema 50 está en el estado normal. Después de confirmarlo de esta forma, la biblioteca 102-1 primaria responderá a las llamadas hechas por el servicio 94-1 al: i) hacer una llamada externa al agente 118-1 de recursos externo para obtener una marca de tiempo; ii) hacer una llamada externa adicional al agente 118-1 de recursos externo para obtener el precio de mercado actual . De este modo, en la etapa 325, el agente 118-1 de
recursos externo hará llamadas externas al reloj del sistema operativo (no mostrado) y la alimentación de mercado (no mostrada) para obtener una marca de tiempo y el precio de mercado actual, respectivamente. El rendimiento de las etapas 320 y 325 se representa en la Figura 6 como líneas punteadas que representan llamadas para una marca de tiempo mediante el agente 118-1 de recursos externo y un precio de mercado mediante el agente 118-1 de recursos externo se indican en 132 y 134, respectivamente. Aquellos con experiencia en la técnica ahora reconocerán que las llamadas 132 y 134 externas, en particular, convertirán al sistema 50 no determinista en naturaleza y por lo tanto presentarán retos únicos para proporcionar un sistema de recuperación ante fallos que, en el caso de una recuperación ante fallos dirija la naturaleza no determinista del sistema durante la recuperación de modo que la recuperación sea transparente para los comerciantes T. (Por medio de una explicación adicional, asumir que el sistema 50 fue alterado de modo que ambos servidores 62 hicieron llamadas externas para cada mensaje. Incluso, para cualquier mensaje dado M, la cantidad exacta cuando se hace una llamada para una marca de tiempo es crítica para asegurar la igualdad de mercado, y es muy improbable que ambos servidores 62 hagan una llamada para una marca de tiempo para
el mismo mensaje en el mismo tiempo, y por lo tanto cada servidor 62 podría asignar una prioridad diferente de tiempo para el mismo mensaje M, resultando en resultados diferentes del mismo proceso de máquina. De igual forma, para cualquier mensaje dado M, el momento exacto cuando se hace una llamada para un precio de mercado también es crítico para asegurar igualdad de mercado, y es muy improbable que ambos servidores 62 hagan una llamada para un precio de mercado para el mismo mensaje en el mismo tiempo, y por lo tanto cada servidor 62 podría tener un diferente precio de mercado para el mismo mensaje M. Durante una recuperación ante fallos, cada servidor 62 puede no tener datos consistentes comerciales y la recuperación ante fallos puede ser irrelevante) . A partir de leer más, aquellos con experiencia en la técnica reconocerán cómo tales retos son dirigidos, así como reconocerán otros aspectos de la invención. En la etapa 330, los resultados de las llamadas 132 y 134 externas son devueltos a la biblioteca 102-1 primaria. En la etapa 335, los resultados de todas las llamadas 132 y 134 se almacenan en la memoria caché 110-1 y se devuelven al servicio 94-1. Continuando con el ejemplo, se asumirá que el resultado de la llamada 132 es la marca de tiempo 12:00PM, enero 5, 2000; y se asumirá que el resultado de la llamada 134 es el precio de mercado de $2.00. El almacenaje de estos
resultados en la memoria caché 110-1 es representada en la Tabla II y la Figura 7. Tabla II Contenidos Ejemplares de la Memoria Caché 110-1 después de la Etapa 335
En la etapa 340, los resultados de la llamada se reciben por el servicio. Continuando con el presente ejemplo, los resultados de llamada almacenados en la Tabla II serán devueltos al servicio 94-1, el cual también se representa en la Figura 7. Después, en la etapa 345, el servicio hará una solicitud de recursos compartidos. En el presente ejemplo, la solicitud se hace por el servicio 94-1 a la biblioteca 102.1. A su vez, en la etapa 350, la biblioteca 102-1 emitirá una instrucción al recurso 122-1 compartido para "bloquearlo" y por consiguiente evitar que cualquier otro servicio (por ejemplo, el servicio 98-1, u otra cadena dentro del servicio 94-1), acceda al recurso 122-1 compartido. (Como se describirá en mayor detalle en lo siguiente, si los recursos 122-1 compartidos ya están bloqueados, entonces el método 300
hará una pausa en la etapa 345 hasta que los recursos 122-1 compartidos se desbloqueen) . El rendimiento de las etapas 345 y 350 se representan en la Figura 8 como una línea punteada que representa una solicitud de recursos compartidos indicada en 140. El bloqueo de los recursos 122-1 compartidos se representa por un candado 138. Después, en la etapa 355, un número de secuencia de recurso compartido se devuelve. Esa etapa puede ser realizada por la biblioteca 102-1 utilizando un secuenciador 106-1 para generar un número de secuencia asociado con el mensaje M(Oi) . Continuando con el ejemplo, se asumirá que un número de secuencia de "uno" se genera. El almacenaje de estos resultados en la memoria caché 110-1 se representa en la Tabla III y la Figura 8. Nótese que la Tabla III es una actualización de la Tabla II. Tabla III Contenidos Ejemplares de la Memoria Caché 110-1 después de la Etapa 355
Después, en la etapa 360, se solicita duplicación. tapa 360 en el presente ejemplo se realiza por
servicio 94-1, la cual envía una instrucción a la biblioteca 102-1 para realizar la duplicación. En la etapa 365, la duplicación del mensaje, los resultados de la llamada y el número de secuencia se inician. En el presente ejemplo, los contenidos de la Tabla III se duplican por la biblioteca 102- 1. La etapa 365 se discutirá más adelante en lo siguiente. En la etapa 370, el mensaje se procesa utilizando los resultados de llamada y los recursos compartidos bloqueados. En el presente ejemplo, la etapa 370 se realiza por el servicio 94-1, el cual utiliza los contenidos de la Tabla III y realiza las etapas de procesamiento asociados con el servicio 94-1 para poder generar resultados de la Tabla III. Puesto que el servicio 94-1 es un servicio de colocación de orden, y el mensaje M(Oi) representa una orden de compra, entonces en la etapa 370 el servicio 94-1 generará una orden de compra que será registrada en el recurso 122-1 compartido para una correlación subsiguiente con una orden de venta contra una orden de venta de, por ejemplo, el comerciante T- 2, u otro procesamiento de comercialización tal como la cancelación de la orden utilizando servicio 98-1. Para propósitos del presente ejemplo, se asumirá que no existen órdenes en los recursos 122-1 compartidos contra las cuales el mensaje M(Oi) pueda correlacionarse, y de este los resultados de la etapa 370 serán para generar simplemente un registro completo de los detalles de la orden
de compra asociada con el mensaje M(Oi) . La Tabla IV muestra resultados ejemplares del rendimiento de la etapa 370. Tabla IV Resultados Ejemplares del rendimiento de la etapa 370
Después, en la etapa 375, los resultados del rendimiento de la etapa 370 se escriben en los recursos compartidos, y después se desbloquean los recursos compartidos. La generación del Tabla IV por el servicio 94-1 en la etapa 370, y el almacenaje de estos resultados en los recursos 121-1 compartidos en la etapa 375 se representan en la Figura 9. Después, en la etapa 380, el servicio confirma que los resultados se han escrito en la etapa 375, y una confirmación que en la etapa 400 se ha realizado una duplicación. En el ejemplo actual, en la etapa 380, el servicio 94-1 esperará una confirmación de los recursos 122-1 compartidos que en la Tabla IV se escribió los recursos 122-1
compartidos. De igual forma, en la etapa 380, el servicio 94-1 esperará la confirmación, de la etapa 400, que la duplicación iniciada en la etapa 365 se ha completado. Las etapas 365 y 400 se explicarán en mayor detalle en lo siguiente. (En una modalidad alternativa, la etapa 380 no necesita realmente esperar la confirmación de la etapa 400 antes de proceder a la etapa 390. Sin embargo, la etapa 380 aún esperaría recibir eventualmente tal confirmación de la etapa 400, y si tal confirmación no estaba disponible, entonces la etapa 380 asumiría que el servidor 62-2 habría fallado, en cuyo caso el servidor 62-1 comenzaría a realizar el método 600 como se explica posteriormente. Aquellos con experiencia en la técnica ahora reconocerán que esto es un modo asincrónico de operación y puede preferirse en ciertas circunstancias donde se prefiere velocidad sobre la confirmación del estado del servidor 62-2) . Después, en la etapa 390, la confirmación se devuelve al cliente. En el ejemplo actual, en la etapa 390, el servicio 94-1 enviará un mensaje de confirmación al cliente 54-1 de que el mensaje M(Oi) se ha procesado como se solicitó por el comerciante T-l. Se reiterará que la etapa 390 del método 300 (es decir, la operación durante el estado normal) no se completa hasta que la etapa 380, la cual a su vez no se completa hasta
que la duplicación iniciada en la etapa 365 se haya completado. Regresando ahora a la etapa 365, los números del mensaje, resultados de llamada y la secuencia de recursos compartidos se duplican. En el presente ejemplo, la etapa 365 se realiza por la biblioteca 102-1 en respuesta a la solicitud del servicio 94-1 en la etapa 360. De este modo, la biblioteca 102-1 manejará los contenidos de la Tabla III y los distribuirá al agente 126-2 de duplicación. El rendimiento de las Etapas 365, 370, 375, 395, 400 y 390 se representan en la Figura 10. (La Figura 10 se fundamenta en la representación del rendimiento de las etapas 370 y 375 en la Figura 9) . La etapa 365, la distribución de la Tabla III de la memoria caché 110-1 de la biblioteca 102-1 al agente 126-2 de duplicación se representa por la línea indicada en 142. Las etapas 370 y 375 se representan en la Figura 10 como se discute previamente con relación a la Figura 9. La etapa 395, el número de mensaje, los resultados de llamada y el número de secuencia de recursos compartidos se representan por el óvalo marcado en la Tabla III que aparece dentro de un agente 126-2 de duplicación. En la etapa 400, la devolución de confirmación de la duplicación del agente 126-2 de duplicación al servicio 94-1 (llevado a cabo mediante la biblioteca 102-1) , se representa por la línea indicada en 144. La etapa 390, la devolución de confirmación del servicio 94-1 al cliente 54-1, se representa por la línea
punteada indicada en 146. Lo anterior sustancialmente completa la descripción del procesamiento de un mensaje por el servidor 62-1 primario durante la operación en el estado normal. Ahora se debe entender que el servidor 62-1 primario puede procesar múltiples mensajes, ya sea en serie y/o sustancialmente en paralelo de acuerdo con la descripción anterior de las etapas 310 a 400. Por ejemplo, mientras el servicio 94-1 está manejando un mensaje M, de igual forma el servicio 98-1 también puede estar procesando otro mensaje M sustancialmente como se describe en lo anterior, con la biblioteca 102-1 interactuando con ambos servicios 94-1, 98-1. Adicionalmente , mientras una cadena del servicio 94-1 está manejando un mensaje M. Otra cadena del servicio 94-1 también puede estar procesando otro mensaje M sustancialmente como se describe en lo anterior, con la biblioteca 102-1 interactuando con ambas cadenas del servicio. La etapa 350 asegura que los recursos 122-1 compartidos se bloqueen para evitar contención entre servicios 94-1 y 98-1 (o cadenas de los mismos) para asegurar que sólo uno de esos servicios puede interactuar con el recurso 122-1 compartido en un tiempo. (Nótese que "interactuar" puede incluir cualquier tipo de función, que incluya sin limitación lectura, escritura y borrado) . Como un ejemplo de contención que necesita ser evitado, el servicio 98-1 de cancelación de orden puede leerse y escribirse en el
recurso 122-1 compartido mientras se bloquea para poder cancelar una orden dada, lo cual puede evitar que un servicio de correlación (no mostrado) concuerde con una orden que está siendo cancelada. De la misma manera, la etapa 355 utiliza el secuenciador 106-1 para generar un número de secuencia única para cada mensaje M, e independientemente de que el servicio 94-1 ó 98-1 (o cadena del mismo) está manejando el mensaje M. De este modo, pueden existir momentos cuando un servicio 94-1 ó 98-1 particular (o cadena del mismo) hace una solicitud de los recursos 122-1 compartidos en la etapa 345 mientras los recursos 122-1 compartidos son bloqueados, y por lo tanto ese servicio particular (o cadena del mismo) hará una pausa en la etapa 345 hasta que los recursos 122-1 compartidos se desbloqueen antes de continuar hacia delante de la etapa 345. Habiendo descrito el procesamiento de los mensajes por el servidor 62-1 primaria durante la operación en el estado normal, la discusión del método 300 ahora regresará al rendimiento de las etapas 405 y hacia delante y el procesamiento de los mensajes por el servicio 62-2 secundario . Con referencia nuevamente a la Figura 3, en la etapa 405, los mensajes, los resultados de llamada y los números de secuencia se despachan de acuerdo con el número de secuencia de recurso compartido. Continuando con el ejemplo
anterior, en este punto, el mensaje M(Oi) (es decir, los contenidos del Campo 1 del Registro 1 de la Tabla III) se despacharán al servicio 94-2, mientras los resultados de llamada (es decir, los contenidos del campo 2 y 3 del Registro 1 de la Tabla III) y el número de secuencia (es decir, los contenidos del Campo 4 del Registro 1 de la Tabla III) se despacharán a la biblioteca 102-2 secundaria. De este modo, en la etapa 310S, el servicio 94-2 recibirá el mensaje M(Oi) del agente 126-2 de duplicación en la misma forma que, en la etapa 310, el servicio 94-1 recibió el mensaje M(Oi) del cliente 54-1. A partir de la perspectiva del servicio 94-2, el mensaje M(Oi) se ha recibido de un cliente. En este punto, ahora se volverá aparente que el servicio 94-2 es sustancialmente idéntico en todas las formas al servicio 94-1. (Igual que el servicio 98-2 es sustancialmente idéntico al servicio 98-1) . El servicio 94-2 operará en el servidor 62-2 sustancialmente en la misma forma que el servicio 94-1 opera en el servidor 62-1. En otras palabras, las etapas 310S, 315S, 340S, 345S, 360S, 370S, 380S y 390S se realizan por el servicio 94-2 de la misma forma que las etapas 310, 315, 340, 345, 360, 370, 380 y 390 se realizan por el servicio 94-1 en el servidor 62-1. Ni el servicio 94-1, ni el servicio 94-2 están concientes de si el servidor particular está operando dentro, se designan como el servidor primario o servidor de reserva. Esto presenta una de
las muchas ventajas de la presente invención, ya que los servicios pueden desarrollarse una vez para dos (o más) servidores, sin tener que desarrollar un conjunto de servicios para un servidor designado como servidor primario y un conjunto de servicios para un servidor designado como servidor de reserva. Sin embargo, cada biblioteca 102, en consulta con su agente 90 de recuperación ante fallos respectivo y el registro 114 de estado, está conciente de si su servidor 62 respectivo se designa como servidor primario o como servidor de reserva. De este modo, cuando el servicio 94-2 realiza la etapa 315S y hace llamadas, la biblioteca 102-2 no utilizará el agente 118-2 de recursos externo pero, en la etapa 415, simplemente devolverá los resultados de llamada (es decir, los contenidos de los Campos 2 y 3 del Registro 1 de la Tabla III) que se recibieron por la biblioteca 102-2 en la etapa 410. El rendimiento de las etapas 405, 310S, 410 se representan en la Figura 11. El rendimiento de las etapas 315S, 415 y 340S se representan en la Figura 12. De la misma manera, cuando el servicio 94-2 realiza la etapa 345S y solicita recursos compartidos, la biblioteca 102-2 responderá en la etapa 420 al bloquear los recursos 122-2 compartidos, y en la etapa 425 al devolver el número de secuencia de recursos compartidos (es decir, los contenidos
del Campo 4 del Registro 1 de la Tabla III) que se recibieron por la biblioteca 102-2 en la etapa 410 y sin utilizar el secuenciador 106-2. El rendimiento de las etapas 345S, 420, 425 se representan en la Figura 13. De la misma manera, cuando el servicio 94-2 se realiza en la etapa 360S y solicita duplicación, la biblioteca 102-2 responderá en la etapa 430 no sólo al realizar realmente la duplicación, sino al devolver una confirmación de duplicación al servicio 94-2 en la etapa 380S, especialmente imitando la etapa 400. Las etapas 370S y 435 de este modo se realizan sustancial e idénticamente a las etapas 370 y 375, respectivamente, de modo que todos los contenidos de la Tabla IV se generan independientemente por el servicio 94-2 y se almacenan dentro del recurso 122-2 compartido . El rendimiento de las etapas 370S y 435 se representan en la Figura 14. Similarmente , las etapas 380S y 390S se realizan de la misma forma que en la etapa 380 y las etapas 390, excepto que la confirmación de vuelta en la etapa 390S se devolvió al agente 126-2 de duplicación en lugar del cliente 54-1. En este punto, en la conclusión de este rendimiento del método 300, ahora se reconocerá que los resultados del mensaje de procesamiento M(Oi) ahora se almacenan en el
recurso 122-1 compartido y el recurso 122-2 compartido como la Tabla IV. También se puede observar que la latencia actual entre el rendimiento de las etapas 310S, 315S, 340S, 345S, 360S, 370S, 380S, 390S y las etapas 310, 315, 340, 345, 360, 370, 380, 390 realmente es muy poca. Cualquier latencia puede determinarse por la latencia de red en la etapa 365 y el procesamiento de las etapas 395 y 405, la cual puede ser muy rápida. En cualquier caso, el sistema 50 puede configurarse de modo que la latencia al final es mucho más rápida que la información de respaldo de escritura en un disco duro, la cual aún es otra ventaja de la presente invención. De este modo, el método 300 puede utilizarse para procesar mensajes para colocar órdenes para comprar y vender títulos utilizando el servicio 94-1 (y como se imita por el servicio 94-2) . De igual forma, el método 300 puede utilizarse para cancelar esas órdenes utilizando el servicio 98-1 (como se imita por 98-2) . Servicios adicionales pueden crearse e incluirse en el servidor 62-1 y pueden colocarse fácilmente en el servidor 62-2 para proporcionar una recuperación ante fallos fuerte para esos servicios, pero sin requerir un conjunto de códigos para el servicio en el servidor 62-1 mientras se requiere otro conjunto de códigos para el servicio en el servidor 62-2 - un conjunto de códigos para un servicio particular es todo lo que se necesita para ambos servidores. Tal vez en forma más importante, a partir
de ciertas perspectivas, es que el sistema 50 puede garantizar sustancialmente los resultados en el caso de una recuperación ante fallos, sin la pérdida de velocidad que normalmente acompaña la escritura en un disco duro. Puesto que en el estado normal, el servidor 62-2 mantiene un espejo actualizado del procesamiento realizado en el servidor 62-1, una falla del servidor 62-1 puede recuperarse rápidamente al hacer que el servidor 62-2 asuma las tareas de procesamiento del servidor 62-1 donde el servidor 62-1 se quedó fuera. La Figura 15 muestra un diagrama de flujo que representa un método 500 para manejar un par de servidores donde uno de los servidores se designa como servidor primario mientras el otro servidor se designa como servidor de reserva. Cuando se implementa utilizar el sistema 50, en la etapa 505, se determina si ambos servidores se encuentran disponibles. La etapa 505 se implementa con el uso de los agentes 90 de recuperación ante fallos y los registros 114 de estado. Si es sí, entonces la etapa 505 avanza a la etapa 510 donde el sistema 50 opera en el estado normal como se describe previamente con relación al método 300. La etapa 505 y la etapa 510 continúan ciclando a menos que se determine que ambos servidores no están disponibles en cuyo caso el método avanza a la etapa 520. En la etapa 520, se determina si sólo el primer servidor se encuentra disponible. Por ejemplo, si el agente 90-1 de recuperación
ante fallos no puede establecer una conexión, por cualquier razón, con el agente 90-2 de recuperación ante fallos, entonces se determina en la etapa 520 que sólo el primer servidor está disponible y el método 500 avanzará en la etapa 530 en cuyo punto el sistema 500 operará en el estado sólo primario. Posibles razones para que el agente 90-1 de recuperación ante fallos sea incapaz de establecer una conexión con el agente 90-2 de recuperación ante fallos incluyen, pero no se limitan a, el servidor 62-2 experimenta una caída fatal o el corte del enlace 78. Si el primer servidor no está disponible, entonces el método 500 avanza de la etapa 520 a la etapa 540 donde se determina si sólo el segundo servidor está disponible. Si no es así, entonces el método 500 finaliza con una excepción. Sin embargo, si se determina que el segundo servidor está disponible, entonces el método 500 avanza de la etapa 540 a la etapa 550. En la etapa 550, el sistema 50 se recupera ante fallos de modo que el procesamiento adicional se realiza por el segundo servidor. Después, en la etapa 560, la operación continúa como se hace el procesamiento adicional en el estado de sólo secundario. El método 500 entonces cicla entre la etapa 560 y 570 hasta que ambos servidores se vuelven disponibles nuevamente, en cuyo punto el método 500 avanza a la etapa 510 y el sistema 50 se regresa al estado normal. La Figura 16 muestra un ejemplo del sistema 50 en
el estado sólo primario, por el cual el servidor 62-1 se designa como el servidor primario pero el servidor 62-2 está fuera de linea (o de otra forma no está disponible debido a falla del enlace 78) . En la Figura 16, puesto que el servidor 62-1 está operando en el estado sólo primario, el registro 114-1 de estado indicará que el servidor 62-1 actualmente se designa como el servidor primario y opera en el estado sólo primario . La Figura 17 muestra un ejemplo del sistema 50 en el estado de sólo secundario, por el cual el servidor 62-2 se designa como el servidor primario pero el servidor 62-1 está fuera de línea. En la Figura 17, puesto que el servidor 62-2 está operando en el estado sólo primario, el registro 114-2 de estado indicará que el servidor 62-2 actualmente se designa como el servidor primario y opera en el estado sólo primario . Aunque no se muestra, observe que el sistema 50 podría ser configurado también para ser del estado normal por el cual el servidor 62-2 se designa como el servidor primario mientras el servidor 62-1 se designa como el servidor de reserva . La Figura 18 muestra un diagrama de flujo que representa un método 600 para procesar mensajes cuando sólo uno de los servidores 62 se encuentra disponible. El método 600 puede realizarse por el servidor 62-1 en la etapa 530 del
método 500, o puede realizarse por el servidor 62-2 en la etapa 560 del método 500. Aquellos con experiencia en la técnica ahora apreciarán que el método 600 sustancialmente refleja la operación del servidor primario en el método 300. Más particularmente, puede observarse que las etapas 310-360 y las etapas 370-390 del método 300 corresponden a las contrapartes en el método 600 que llevan los mismos números pero son seguidos por el sufijo "F" . Sin embargo, la etapa 365F del método 600 es diferente de la etapa 365 del método 300. La etapa 365F corresponde a la etapa 430 del método 300, como en la etapa 365F la biblioteca 102 responderá a la solicitud de duplicación de servicio 94 (ó 98) al imitar simplemente la confirmación de que se ha logrado la duplicación, de modo que el servicio 94 (ó 98) recibirá la confirmación en la etapa 380F y permite al método 600 avanzar a la etapa 390F. La Figura 19 muestra un diagrama de flujo que representa un método 700 para recuperación ante fallos de un servidor primario a un servidor de reserva que puede utilizarse para implementar la etapa 550 del método 500. El método 700 podría realizarse, por ejemplo, por el servidor 62-2 si el agente 114-2 de recuperación ante fallos descubrió que el servidor 62-1 había fallado (por ejemplo, cayó o por cualquier razón ya no estaba disponible) . Puesto que los clientes 54 ya se están comunicando con el servidor 62-1, los
clientes 54 continuarán interactuando con el servidor 62-1, a pesar del hecho que el servidor 62-2 asumirá que el servidor 62-1 ha fallado y que el servidor 62-2 asumirá que es el servidor primario. En ese evento, el método 700 puede comenzar en la etapa 710 en cuyo punto la cola del agente de duplicación puede encontrarse despejada. En los ejemplos descritos en lo anterior, el servidor 62-2 puede continuar procesando todos los datos almacenados en el agente 126-2 de duplicación de acuerdo con la etapa 405 (y las etapas 310S, 315S, 340S, 345S, 360S, 370S, 380S, 390S, 410, 415, 420, 425, 430 y 435 subsecuentes) para poder limpiar y duplicar el procesamiento de todos los mensajes (y las llamadas externas asociadas) que se estaban procesando en el servidor 62-1 antes de que el servidor 62-1 fallara. En el caso en que el servidor 62-1 falle en la etapa 370, el servidor 62-2 puede recibir un mensaje duplicado del cliente que ejecuta un protocolo de recuperación, tal como una recuperación de espacios, o como otro ejemplo, el tipo de recuperación descrito en la solicitud co-pendiente del solicitante como se describe en la Solicitud Publicada Norteamericana US20050138461. Puesto que el cliente jamás recibirá la confirmación del servidor 62-1 de que el mensaje se procesó. En este caso, el servidor 62-2 se configura para reconocer mensajes duplicados y simplemente devolver la misma respuesta, sin intentar reprocesar el mismo mensaje.
Después, en la etapa 720, el agente de duplicación puede ser desactivado. En el presente ejemplo, el agente 126-2 de duplicación puede desactivarse, de modo que ya no pueda mantener una cola de datos recibida en el servidor 62-1, o pueda configurarse para enviar mensajes a los servicios 94-2 y 98-2. En la etapa 730, el agente de recursos externo y el secuenciador pueden activarse. En el presente ejemplo, el agente 118-2 de recursos externo puede volverse activo de modo que pueda configurarse para realizar las llamadas de función externa mostradas en las etapas 325F y las etapas 330F del método 600. De igual forma, la secuencia 106-2 para que pueda ser configurada para asignar números de secuencia mostrados en la etapa 355F del método 600. Después, en la etapa 740, el agente de recuperación ante fallos se establece para indicar el estado sólo primario. En el ejemplo, el agente 114-2 de recuperación ante fallos se establece para indicar el estado sólo primario de modo que la biblioteca 102-2 sabe operar de acuerdo con las etapas 320F, 335F, 350F, 355F y 365F de método 600. Después, en la etapa 720, la presencia del servidor se anuncia a los clientes. En el presente ejemplo, el servidor 62-2 anunciará a los clientes 54 sobre la red 58 que el servidor 62-2 está listo para aceptar y procesar los mensajes de los clientes 54. La forma en la cual esto se hace no se limita particularmente, y sustancialmente , puede ser la misma forma en la cual el
servidor 62-1 se puede haber anunciado a los clientes 54 antes del comienzo del método 300. El protocolo de sesión puede realizar una recuperación de espacios de modo que los lados respectivos puedan reenviar comunicaciones que la contraparte no pudo haber recibido. En este punto, el sistema 50 está en el listado mostrado en la Figura 17, donde el servidor 62-2 ahora se designa como el servidor primario, y el sistema 50 está listo para operar en el estado sólo primario con el servidor 62-2 como el servidor primario. En este punto, el método puede regresar a la etapa 560 del método 500, por la cual, los mensajes de los clientes se reciben y procesan de acuerdo con el método 600. Mientras sólo combinaciones específicas de las diversas características y componentes de la presente invención se han discutido en la presente, será aparente para aquellos de experiencia en la técnica que los subconjuntos deseados de las características y componentes descritos y/o combinaciones alternativas de esas características y componentes pueden utilizarse, como se desee. Por ejemplo, mientras el sistema 50 incluye dos servidores 62-1 y 62-2, se contempla que cualquier número de servidores puede utilizarse. Un servidor puede designarse como servidor primario, mientras cualquier número de servidores adicionales puede designarse como servidores de reserva y unirse juntos, ya sea en serie o en paralelo, utilizando enseñanzas
adecuadamente modificadas en la presente. Tales servidores adicionales pueden tener sustancialmente el mismo ambiente de cómputo y estructura que los servidores 62 discutidos en la presente, y en cualquier caso, pueden tener servicios idénticos que interactúen con bibliotecas y otros elementos de software para realizar llamadas externas (en el caso de un servidor primario) a nombre de esos servicios, o para proporcionar duplicaciones de esas llamadas externas (en el caso de servidores de reserva) a nombre de las copias imitadas de esos servicios. También se debe entender que el método 300 puede ser variado. Por ejemplo, el método 300 podría configurarse para operar completa y sincrónicamente, mediante lo cual el servidor primario sólo confirmará al cliente que un mensaje se ha procesado con la condición de que los recursos compartidos primario y secundario se hayan escrito con los resultados del procesamiento hecho por un servicio particular. Esto puede implementarse al cambiar el método 300 de modo que la etapa 400 sólo se realice una vez que se realice la etapa 380S.