MXPA04002731A

MXPA04002731A - Distribucion de mensajes con resoluciones y caracteristicas configurables entre dos puntos extremos.

Info

Publication number: MXPA04002731A
Application number: MXPA04002731A
Authority: MX
Inventors: D Hill Richard
Original assignee: Microsoft Corp
Priority date: 2003-03-27
Filing date: 2004-03-23
Publication date: 2005-06-17
Also published as: EP1463249A2; CN1534923A; ZA200401582B; JP2004295895A; NZ531382A; IL160572A0; NO20041261L; CN1534923B; US7676580B2; SG116532A1; MY144262A; KR20040086583A; PL366440A1; EP1463249A3; TW200503487A; RU2004109131A; RU2363040C2; CA2460274A1; CO5560092A1; TWI337823B

Abstract

Se proporciona un modelo de programacion sencillo para tener acceso a una pluralidad de transportes de mensajes distintos mientras se desarrolla una o mas aplicaciones para la distribucion de mensajes entre dos puntos extremos. El modelo de programacion permite resoluciones y caracteristicas independientemente configurables para transportar los mensajes. Las resoluciones configurables pueden seleccionarse de distribucion de por lo menos una vez, distribucion de mensajes a lo mucho una vez, distribucion de mensajes en orden, y tiempo de mensaje para existir. Las caracteristicas independientemente seleccionadas pueden incluir un almacenamiento de estado de sesion, una extension de tiempo para existir, y memoria a intermedia de mensaje negociado.

Description

DISTRIBUCION DE MENSAJES CON RESOLUCIONES Y CARACTERISTICAS CO FIGURABLES ENTRE DOS PUNTOS EXTREMOS 1. Campo de la Invención La presente invención se refiere generalmente a sistemas de envío de mensajes confiables. Más particularmente, la presente invención proporciona un modelo de programación sencillo con resoluciones y características confiables que pueden configurarse y hacerse a la medida de los requerimientos específicos de una aplicación o de instalaciones particulares de la aplicación. 2. Antecedentes y Técnica Relevante Los sistemas de envío de mensajes se han vuelto una forma cada vez más popular de comunicarse. Estos sistemas de comunicación varían de sistemas de correo electrónico a transacciones aseguradas, de cuartos de charlas a varios servicios de red tales como compras por Internet. Cada uno de estos sistemas de comunicación requiere varios grados de seguridad, confiabilidad, escalabilidad y disponibilidad. Estos requerimientos varían de modelos holgadamente acoplados tales como mecanismos de datagrama con sistemas simples de confiabilidad de disparo y olvido y de puesta en cola que proporcionan envío de mensajes durable despachado, a modelos fuertemente acoplados que utilizan protocolos tales como Protocolo de Control de Transmisión (TCP) y Llamada de Procedimiento Remota (RPC) con comunicación orientada a sesión. Debido a los diversos requerimientos de varios mecanismos de comunicación, tales como aquellos específicamente identificados en lo anterior, modelos de programa difieren entre cada uno de estos mecanismos, y aún entre sistemas similares de diferentes vendedores. Además, el grado de flexibilidad de configuración en cada modelo de programa varía a través de los diferentes mecanismos e implementaciones. Los programadores y diseñadores de sistemas típicamente deben entender cada mecanismo; decidir cual se ajusta mejor a sus requerimientos, y escribir el código a la interfase específica definida por este mecanismo. Si los requerimientos del producto o desarrollo cambian, sin embargo, y se requiera un mecanismo de comunicación diferente, el código resultante normalmente debe ser rediseñado y reimplementado. Esto es debido al hecho de que la mayoría de los mecanismos de comunicación confiables no proporcionan suficiente flexibilidad con respecto a o control sobre la selección de resoluciones y características de confiabilidad que proporcionan a las aplicaciones que la utilizan. Por ejemplo, tales mecanismos comúnmente proporcionan solo distribución exactamente una vez en orden. Sin embargo, existen muchas situaciones donde esto es más que lo que una aplicación realmente necesita. También existe costo incurrido en proporcionar más resoluciones o más altas, tales como distribución exactamente de una vez en orden. Por ejemplo, los mensajes de aceptación deben enviarse desde el receptor nuevamente al emisor para la recepción de aceptación de los mensajes. Sin está aceptación, el emisor no puede saber si el mensaje fue o no recibido, y por lo tanto no puede proporcionar la resolución exactamente de una vez. Aplicaciones que pueden existir con pérdida ocasional de mensajes no pueden querer incurrir el costo de un protocolo de aceptación por lo menos una vez, y arriesgarse a una falla de sesión si un mensaje de baja prioridad sencillo no pudiera suministrarse. La aceptación de requerimiento en tales casos puede incrementar innecesariamente los costos de comunicación y disminuir la disponibilidad de aplicación. Por consiguiente, existe una necesidad de un modelo de programación sencillo, que proporcione una infraestructura de envío de mensajes confiable donde resoluciones y características de distribución de mensajes que se van a proporcionan a la aplicación sean configurables. Además, existe una necesidad de un modelo de programación de envío de mensajes confiable sencillo que soporta un amplio margen de instalaciones de estado de sesión y almacenaje de mensajes para varias implementaciones de transporte y para varias resoluciones y características.

COMPENDIO DE LA INVENCION De acuerdo con modalidades ejemplares de la presente invención, las deficiencias y desventajas antes identificadas de sistemas de envió de mensajes actuales se solucionan. Por ejemplo, modalidades ejemplares proporcionan un sistema de envío de mensajes que soporta uno o más transportes de mensajes. Además, la presente invención proporciona una abstracción de mensajes confiable que simplifica el desarrollo de aplicación al proporcionar un modelo de programa sencillo que permita especificar una o más resoluciones de distribución de extremo a extremo para la selección de un transporte de mensajes particular o transportes en tiempo de ejecución, como opuesto a especificar el transporte de mensajes particular al momento del desarrollo. La abstracción de mensajes confiable de la presente invención, proporciona la resolución de distribución de mensajes especificada para aplicación que es independiente de transporte o transportes subyacentes que se utilizan para transferir actualmente los mensajes. Por consiguiente, está abstracción aisla el desarrollador de aplicación de los detalles de nivel de transporte. Similarmente, la abstracción permite que los desabolladores se aislen de los detalles de la topología de red y la conectividad del sistema. El sistema primero define una interfase de canal de mensaje que extrae las operaciones de envío y recepción para intercambiar mensajes sobre la pluralidad de distintos transportes de mensajes. A diferencia de los modelos de programas tradicionales, una pluralidad de resoluciones de distribución de mensajes de extremo a extremo que son independientes de los transportes subyacentes se definen, y cada una de estas resoluciones de distribución de mensajes de extremo a extremo pueden seleccionarse para uso con el modelo de programación sencillo. Además, las resoluciones de distribución de mensajes pueden seleccionarse de lo siguiente: distribución de v mensajes por lo menos de una vez, distribución de mensajes a lo mucho una vez, distribución de mensajes enviados en orden y tiempo de sesión para existir. Finalmente, una pluralidad de características de envío de mensajes confiables locales se definen, cada una de las cuales puede seleccionarse para su uso dentro del modelo de programa sencillo. Además, las características de envío de mensajes confiables locales pueden ser cualquiera de un almacenaje de estado, tiempo de mensajes para existir, y almacenamiento temporal de mensajes despachados. De acuerdo con otra modalidad ejemplar de la presente invención, un método para simplificar el desarrollo de aplicación al proporcionar un modelo de programa sencillo para tener acceso a los distintos transportes de mensaje se proporcionan al extraer una interfase del canal de mensaje para intercambiar mensajes sobre los distintos transportes de mensajes, y permitir que un desarrollador de aplicación especifique una o más resoluciones de distribución de mensajes de extremo a extremo. Las resoluciones de distribución de mensajes pueden seleccionarse para su uso con el modelo de programa sencillo, y pueden seleccionarse de: distribución de mensajes por lo menos de una vez, distribución de mensajes a lo mucho una vez, distribución de mensajes enviados en orden, y tiempo de sesión para existir. Además, el método proporciona permitir un desarrollador de aplicación para especificar una o más características de envío de mensajes confiables locales. Cada una de las características de envío de mensajes confiables locales pueden seleccionarse para su uso dentro de un modelo de programa sencillo y comprende por lo menos uno de un almacenaje de estado de sesión, tiempo de mensajes de existencia, y almacenamiento temporal de mensajes despachados. Características y ventajas adicionales de la invención se establecerán en la descripción que sigue, y en parte será obvia a partir de la descripción, o puede aprenderse mediante la práctica de la invención. Las características y ventajas de la invención pueden realizarse y obtenerse por medio de los instrumentos y combinaciones particularmente señalados en las reivindicaciones anexas. Estas y otras características de la presente invención se volverán completamente más aparentes a partir de la siguiente descripción y las reivindicaciones anexas, o puede aprenderse mediante la práctica de la invención como se establece de aquí en adelante.

BREVE DESCRIPCION DE LOS DIBUJOS Para describir la forma en la cual las ventajas y características antes descritas y otras de la invención pueden obtenerse, una descripción más particular de la invención brevemente descrita en lo anterior se hará por referencia a las modalidades específicas de la misma que se ilustran en los dibujos anexos. En entendimiento de que estos dibujos solamente representan modalidades típicas de la invención y por lo tanto no se considerarán como limitantes de su alcance, la invención se describirá y explicará con especificidad adicional y detalle a través del uso de los dibujos anexos en los cuales: La Figura 1 ilustra pilas de mensajes confiables para enviar y recibir mensajes de acuerdo con modalidades ejemplares de la presente invención; La Figura 2 ilustra una estructura de mensaje de acuerdo con modalidades ejemplares de la presente invención; La Figura 3 ¡lustra un ciclo de vida de un enlace entre una aplicación y un transporte de acuerdo con modalidades ejemplares de la presente invención; y La Figura 4 ilustra un sistema ejemplar que proporciona un ambiente de operación adecuado para la presente invención.

DESCRIPCION DETALLADA DE LAS MODALIDADES PREFERIDAS La presente invención se extiende a métodos, sistemas y productos de programa computarizados para simplificar el desarrollo de aplicación de mensajes confiable al proporcionar un modelo de programación sencillo para tener acceso y utilizar a una pluralidad de distintos transportes de mensajes mientras desarrolla una o más aplicaciones. Las modalidades de la presente invención pueden comprender una computadora de propósito especial o de propósito general que incluye varios hardware (aparatos, equipo, máquinas, etc.) de computadora, como se discute en mayor detalle en lo siguiente. La Figura 1 ¡lustra una representación de alto nivel de pilas 100a y 100b de mensajes confiables. En una pila de mensajes, sin un Protocolo 125 de Mensajes Confiable la Aplicación 105, cuando desea enviar un mensaje a, por ejemplo, otro nivel 185 de Aplicación, puede transferir un mensaje o serie de mensajes 115, directamente al nivel 140 de Mensajes de datagrama (Nótese que la aplicación 105 puede ser cualquier tipo de aplicación, tal como, por ejemplo, un servicio, y generalmente debe entenderse que abarca una infraestructura de aplicación como sea apropiado). Debido a que los datagramas no son confiables, los mensajes o mensaje 115 pueden duplicarse, retardarse y/o caerse. Por ejemplo, en un protocolo de Datagrama menos confiable que tiene conf labilidad de disparo y olvido, el mensaje o mensajes 115 pueden caerse por cualquier número de razones, incluyendo un intermediario 135 entre los transportes 160 y 165. Por consiguiente, la Aplicación 185 de punto extremo original no puede recibir jamás el mensaje o mensajes 115 y la Aplicación 105 de envío no tener conocimiento de que el mensaje o mensajes 115 no se recibieron. De acuerdo con modalidades ejemplares de la presente invención, sin embargo, las pilas 100a y 100b de mensajes confiable se proporcionan con un protocolo 125 de mensajes confiables. Por consiguiente, por ejemplo, la infraestructura 120 de mensajes confiable (o alternativamente 180) puede asegurar que el mensaje o mensajes 115 enviados desde la Aplicación 105 lleguen adecuadamente a su punto extremo de destino. Por ejemplo, si la aplicación 105 desea transferir mensaje o mensajes 115 a su Aplicación 185 de contraparte de sesión, la Aplicación 105 puede Enviar() mensaje o mensajes 115 a la Infraestructura 120 de Mensajes Confiable donde se asignaron a la sesión y se les dio los números de secuencia de mensajes. Un identif icador de sesión corresponde a la comunicación de sesión entre la Aplicación 105 y la Aplicación 185. En otras palabras, una sesión se refiere a la conversación dúplex entre dos Aplicaciones 105 y 185. La numeración de secuencia corresponde al mensaje particular dentro de la comunicación de sesión. Por ejemplo, pueden existir varios mensajes dentro de una sola sesión comunicada entre las dos aplicaciones 105 y 185, y cada mensaje es numerado secuencialmente en el orden enviado por la aplicación. Además, pueden existir múltiples sesiones establecidas entre las Aplicaciones 105, 185 y posiblemente otras aplicaciones (cada sesión establecida puede tener las mismas o diferentes resoluciones de distribución). Por consiguiente, cada mensaje puede asignársele una sesión y número de secuencia únicamente identificando la sesión particular y el orden de secuencia de los mensajes dentro de la sesión. Después de escribir una sesión y encabezado de secuencias en el mensaje 191 y realizar otro procesamiento de canal requerido, el mensaje 191 se almacena en el estado 190 de sesión en una memoria intermedia de envío. Subsecuentemente, una copia del mensaje 191 se transporta hacia abajo a través de la Envío de mensajes 140 de datagrama, que facilita la transmisión de extremo a extremo del mensaje 191 por ejemplo al proporcionar encabezado de enrutamiento. El mensaje 191 se transfiere entonces, potencialmente a través de uno o más intermediarios, por ejemplo, Intermediarios 135, cada uno facilitando la transmisión de extremo a extremo del mensaje 191 como una serie de transmisiones de punto a punto. El mecanismo de intercepción extensible puede utilizarse para implementar conductas tales como enrutamiento, filtración, administración de política y seguridad. Se observa que los transportes 145, 170, 155 y conductas disponibles en los puntos extremos en los puntos extremos de mensajes y el intermediario 140, 175, 150 pueden establecerse ya sea programáticamente o a través de la configuración. Si la resolución para la distribución por lo menos una vez (descrita en mayor detalle más adelante) se especifica para la Aplicación 105, la Infraestructura 120 de Mensajes Confiable espera recibir aceptaciones de la Infraestructura 180 de Mensajes Confiables que indica que los mensajes se reciben adecuadamente. El mensaje 192 lleva una aceptación que el mensaje 191 (por ejemplo el mensaje 5 en una secuencia) se recibió. Periódicamente, si el mensaje 192 de aceptación no se recibe por la Infraestructura 120 de Mensajes Confiable, ya sea debido a que una copia no se ha recibido adecuadamente por la Infraestructura 180 de Mensajes Confiable, o debido a que ninguna de las aceptaciones de 180 se recibió por 120, el mensaje 191 se transmite nuevamente. Por consiguiente, si el mensaje 191 se cayó, retardo, o perdió su ruta, por ejemplo, por intermediario 135, la Infraestructura 120 de Mensajes Confiable continua transmitiendo periódicamente el mensaje 191 (dentro de un periodo de tiempo establecido, posteriormente descrito) en un intento por asegurar que por lo menos una copia del mensaje 191 se reciba adecuadamente por la Infraestructura 180 de Mensajes Confiable. Se debe observar, sin embargo, que por razones similares a aquellas descritas en lo anterior con respecto al mensaje 191, la aceptación 192 puede caerse, retardarse o perder su ruta, Como tal, la presente invención proporciona la distribución de mensajes confiable del mensaje 192 de aceptación como se describe de aquí en adelante. Una vez que la Infraestructura 180 de Mensajes Confiable recibe exitosamente una copia del mensaje 191 , envía el mensaje 192 de aceptación a la Infraestructura 120 de Mensajes Confiable. Con la recepción del mensaje 192 de aceptación, la Infraestructura 120 de Mensajes Confiable borra de su memoria intermedia 190 de estado de sesión (envío) la copia de mensaje 191 y deja de hacer transmisiones adicionales de éste. Similarmente, la Infraestructura 180 de Mensajes Confiables registra en su estado 195 de sesión que ha recibido una copia de mensaje 191, de manera que cualquier mensaje duplicado recibido por la Infraestructura 180 de Mensajes Confiable pueda descartarse, independiente de si los mensajes se han ya entregado o no a la aplicación 185. Después de esto, la aplicación 185 puede recuperar de la memoria intermedia 195 de estado de sesión (recepción) el mensaje recibido a través de su comando RecepciónQ. Si la Infraestructura 120 de Mensajes Confiable no recibe la aceptación 192 debido a que se cayó, se retardó o se perdió su ruta, entonces la retransmisión del mensaje 191 continuará, por consiguiente disparando la Infraestructura 180 de Mensajes Confiable para enviar otra copia de aceptación 192.

Este proceso puede continuar hasta que por lo menos una aceptación 192 se reciba por la Infraestructura 120 de Mensajes Confiable o hasta que la infraestructura 120 de mensajes confiable deje de intentarlo, y envíe una indicación de omisión a la aplicación 105. Las Infraestructuras 120 y/o 180 de Mensajes Confiable, pueden configurarse cada una como Diálogo 200 (Figura 2) de acuerdo con la presente invención, y como se describe en mayor detalle con respecto a la Figura 2. El Diálogo 200 es una abstracción de infraestructura de mensajes, en donde los servicios (o casos de aplicación) utilizan el Diálogo 200 para la comunicación orientada a sesión confiable con otros servicios. Los programadores pueden utilizar un canal 220 de diálogo para tener acceso a los diálogos. Además, el Diálogo 200 proporciona una infraestructura de mensajes confiable y un modelo de programación sencillo donde las resoluciones de instrucción de mensajes a las aplicaciones son configurables. Estas resoluciones de confiabilidad necesitan encontrarse o se presenta una falla de sesión. El diseño del Diálogo 200 da una implementación de tiempo de ejecución correspondiente la flexibilidad de ofrecer características adicionales sometidas para mantener las resoluciones (restricciones de corrección) mantenidas para la implementación de aplicación. En particular, una aplicación puede proporcionarse con varios grados de disponibilidad y escalabil ¡dad transparentes a la implementación de aplicación. Además, estas comunicaciones de sesión entre las Aplicaciones 105 y 185 pueden realizarse sobre una variedad de equipos de transporte (por ejemplo TCP/IP 160 y HTTP 165), casos de conexión de transporte, y topologías de red. Las resoluciones de confiabilidad proporcionadas por el dialogo 200 incluyen la distribución de Por Lo Menos Una Vez (ALO), A Lo Mucho Una Vez (AMO) y En Orden (10). También se proporciona una resolución de Tiempo de Sesión Para Existir (TTL). La resolución de AMO garantiza que para cualquier mensaje dado enviado por la aplicación de envío, el mensaje se entregará a la aplicación de recepción a lo mucho una vez. Debido que el Diálogo 200 es una abstracción, la aplicación es liberada de tener que detectar y descartar los mensajes duplicados si los mensajes duplicados puedan romper la semántica de aplicación. Similarmente, la resolución de ALO estipula que todos los mensajes enviados por la aplicación de envío sean recibidos por el punto extremo de recepción, que libera las aplicaciones de tener que detectar la pérdida de mensajes o mal dirigidos y combinar su retransmisión. La resolución de 10 estipula que los mensajes se suministren a la aplicación de recepción en el orden que se enviaron por la aplicación de envío. Esto libera la aplicación de tener que tratar con la recepción fuera de orden de mensajes. El Diálogo 200 también proporciona una resolución de TTL de sesión, que requiere que la sesión de diálogo entren los socios de punto extremo asociado sea completada antes de que expire TTL de sesión. Si TTL de sesión expira antes de que se haya completado en la sesión de diálogo, los canales de diálogo se colocan en un estado de omisión y de notificación de la omisión se proporciona a las aplicaciones. Las aplicaciones pueden extender TTL de sesión al renegociar el TTL. Los diálogos permiten que estas resoluciones de distribución de mensajes se utilicen ya sea individualmente o en cualquier combinación para satisfacer los requerimientos particulares de una aplicación dada y desarrollos. Por ejemplo, la combinación de las tres resoluciones de AMO, ALO e 10 proporcionan la distribución exactamente una vez en orden típica de la mayoría de los mecanismos de comunicación confiables, tales como TCP/IP. A diferencia de los mecanismos de comunicación típicos y sus modelos de programación correspondientes, sin embargo, estas resoluciones pueden hacerse a la medida sin cambiar el modelo de programación que utiliza la aplicación. El Diálogo 200 no solo permite las resoluciones configurables sino también permite que las características de mensajes confiables locales se seleccionen y configuren independientemente entre sí, e independientemente de las resoluciones seleccionadas en lo anterior. Estas características de mensajes confiables locales caen en dos categorías distintas: aquellas que son parte integral del modelo de programación y aquellas que tienen que ver con la adaptación independiente del programa de aplicación. Por ejemplo, características locales integrales pueden incluir: memoria intermedia negociada, la cual tiene consistencia, aislamiento y semántica de atomicidad para la aplicación; o una referencia de perfil, que asocia un perfil con una sesión para permitir la adaptación independiente. Las características locales adaptables pueden incluir: configuración de almacenaje de estado de sesión, cupo de la memoria intermedia, tiempo establecido de envío, TTL de mensajes configurable, mensajes de prioridad de sesión, o umbral de detección de mensaje de veneno, como se describe más adelante. De acuerdo con modalidades ejemplares de la presente invención, el Diálogo 200 proporciona estado de sesión y almacenaje de mensajes como un componente reemplazable llamado el Almacenamiento 260 de Diálogo. Debido a que el Almacenamiento 260 de Diálogo es reemplazable, terceras partes pueden autorizar y distribuir independientemente implementaciones de Almacenamiento 260 de Diálogo. Administradores pueden recoger y elegir los almacenes de diálogo actualmente utilizados en una instalación dada. Por consiguiente, este mecanismo permite que tremenda flexibilidad cumpla las metas de durabilidad, rendimiento, autonomía y administrativa. El Almacenamiento 260 de Diálogo puede ser un almacenamiento que se puede conectar que tenga por lo menos uno de un almacenamiento en memoria, un almacenamiento durable en disco, en un almacenamiento de proceso demonio almacenamiento de memoria no volátil, un almacenamiento óptico, cinta magnética, almacenaje unido a red, o removible. Además, el almacenamiento de diálogo puede ser remoto o fuera de nodo. De acuerdo con una modalidad ejemplar de la presente invención, se proporciona una implementacion de almacenamiento de diálogo en memoria (por ejemplo, el Almacenamiento 260 de Diálogo) que mantiene todo el estado en la memoria de aplicación. Este almacenamiento proporciona muy rápido acceso al estado; sin embargo, a costa de que todo el estado se pierda si el estado de proceso de aplicación se pierde (por ejemplo, la aplicación determinada por el usuario, es terminada por el sistema de operación, por ejemplo, debido a una falla de aplicación, o el sistema donde se ejecuta la aplicación falla). De acuerdo con otra modalidad ejemplar, una implementacion de almacenamiento de diálogo expreso (por ejemplo el Almacenamiento 260 de Diálogo) mantiene el estado en la memoria de un proceso familiar dedicado separado. Este almacenamiento de diálogo asegura que el estado sobreviva a la falla de proceso de aplicación, sin embargo, a costa de hacer que el proceso conmute para mantener el estado. Si el proceso familiar falla o el sistema operante o nodo de la computadora falla, entonces todo el estado para las sesiones de que es responsable se pierden. De acuerdo con aún otra modalidad de la implementacíón de almacenamiento de diálogo (por ejemplo, el Almacenamiento 260 de Diálogo), la información de estado de sesión se mantiene en una forma durable en una base de datos, tal como el servidor de Lenguaje de Pregunta Estructurada (SQL). Este estado durable puede sobrevivir a la falla del nodo de la computadora o el sistema de operación, sin embargo, a costa de ser el disco que escribe para mantener el estado. Un beneficio de utilizar un sistema de base de datos tal como el servidor de SQL para el mantenimiento de estado es que las instalaciones pueden ya tener herramientas, técnicas y procesos en lugar de ser el soporte regular y la recuperación del estado de aplicación importante. La presente invención también estipula que algunos almacenes de diálogo puedan configurarse para ejecutarse en el nodo de computadora local, u otro nodo. Por ejemplo, un almacenamiento de diálogo durable, tal como un servidor de SQL, puede configurarse para utilizar una base de datos del servidor local o una en otro nodo. El otro nodo puede ser parte de un sistema de cúmulos, y de este modo tener muy alta disponibilidad. La presente invención también estipula que múltiples almacenes (o configuraciones de almacenamiento) puedan existir simultáneamente para cumplir las características de desarrollo específicas utilizadas por una aplicación o aplicaciones. Además, una configuración de aplicación puede modificarse para utilizar un almacenamiento diferente (o configuración de almacenamiento) para poder acomodar cambios tales como carga incrementada o requerimientos de capacidad, para tomar ventaja de las nuevas opciones de almacenaje o para dirigir otras consideraciones de ambiente y desarrollo. Además, diferentes sesiones de comunicación dentro de la misma aplicación pueden tener diferentes requerimientos de configuración. El diálogo permite que cada sesión se configure individualmente. Por ejemplo, algunas sesiones dentro de una aplicación pueden funcionar mejor con almacenamiento de estado durable, mientras que otras sesiones pueden funcionar mejor con almacenaje de estado volátil. El almacenamiento de diálogo puede configurarse mediante un perfil (descrito en lo siguiente) o especificarse en un código de aplicación. Otra característica configurable ofrecida por el Diálogo 200 es un cupo de memoria intermedia. El Diálogo 200 guarda los mensajes en la memoria intermedia en las aplicaciones del emisor y receptor. Esta memoria intermedia incrementa la autonomía de las dos aplicaciones, permitiendo que cualquier lado envíe o reciba mensajes hasta o desde sus memorias intermedias locales, aún si la otra parte no esta ejecutando o se puede alcanzar, por ejemplo, debido a una partición de red. Por ejemplo, la Aplicación 205 puede continuar enviando mensajes aunque la otra parte no este disponible temporalmente, es decir, no este ejecutando o se pueda alcanzar. Esto se logra al acumular mensajes en la Memoria Intermedia 250 de Envío local hasta que puedan transferirse exitosamente. Similarmente, la aplicación 205 puede recibir mensajes que se guardaron previamente en la memoria intermedia en la memoria intermedia 245 de recepción aunque la aplicación que las envió actualmente no pueda estar ejecutándose. El Diálogo 200 proporciona un cupo de memoria intermedia configurable, el cual define el número máximo de mensajes (dependiendo del tamaño de mensaje) que se guardará en la memoria intermedia por el sistema. Por consiguiente, esto limita la cantidad de espacio consumido por el Estado 235 de Diálogo, y limita los recursos locales que puedan consumirse por el otro punto extremo. Esto también permite que el sistema de mensajes reserve un espacio suficiente para la aplicación para guardar temporalmente en forma local el número específico de mensajes. El Diálogo 200 también proporciona un cupo de memoria intermedia mínimo que define un número reservado mínimo de mensajes que se guardarán en la memoria por la infraestructura de mensajes, que en combinación con un tamaño de mensaje máximo define un número mínimo de bits que se guardarán en la memoria intermedia por la infraestructura de mensajes. El cupo de memoria intermedia puede configurarse mediante un perfil (descrito en lo siguiente) o especificarse en el código de aplicación. El Diálogo 200 también proporciona una característica de tiempo establecido de envió configurable. Cuando un mensaje es enviado, se coloca en el Almacenamiento 260 de Diálogo/Memoria Intermedia 250 de Envío. Si la memoria intermedia está llena, es decir, si el cupo de la memoria intermedia se ha alcanzado, entonces la llamada ha enviar (210) se bloquea hasta que expira el tiempo establecido de envío, o el espacio se vuelva disponible en la memoria intermedia para contener el mensaje. El espacio se hace disponible en la memoria intermedia cuando los mensajes se transfieren exitosamente a, y son aceptados por, el punto de extremo de recepción y ya no son necesarios en el punto extremo local para procesar de nuevo. Si el espacio se vuelve disponible antes de que espire el tiempo establecido de envió, las llamadas de EnviarQ 210 se completa normalmente. Si expira el tiempo establecido de envío antes de que este disponible el espacio, surge una excepción que proporciona una notificación a la aplicación de que el mensaje no puede guardarse en la memoria exitosamente (capturar). Por consiguiente, la aplicación puede intentar nuevamente más adelante. El tiempo establecido configurable permite que las aplicaciones elijan el grado de responsabilidad sobre la simplicidad del bloqueo. El tiempo establecido de envío puede configurarse mediante un perfil (descrito en lo siguiente) o especificarse en el código de aplicación.

Como se menciona previamente, el Diálogo 200 soporta una resolución de TTL de sesión de extremo a extremo. El Diálogo 200 también proporciona un mensaje opcional entre Tiempo Para Existir que es configurable como una característica local. El mensaje TTL requiere que los mensajes transmitidos deban recibirse exitosamente por el punto extremo de recepción dentro de un tiempo específico en el TTL, de otra manera da lugar un error en la Aplicación 205, El Diálogo 200 también proporciona una extensión configurable para el mensaje TTL. Por consiguiente, cuando el TTL expira, la notificación se proporciona a la Aplicación 205 de envío. La Aplicación 205 entonces tiene la elección de terminar el diálogo o extender la TTL del mensaje. Similar a los tiempos establecidos de envío, los de TTL pueden establecerse por el código de aplicación, o configurarse indirectamente utilizando un perfil. Otra característica proporcionada por el Diálogo 200 es la prioridad opcional asignada. Todos los mensajes dentro de un Diálogo 200 tienen la misma prioridad. Sin embargo, cuando los mensajes de los múltiples diálogos están disponibles para la transmisión, los diálogos con prioridad más alta se les da precedencia sobre los diálogos con menor prioridad en transmitir los mensajes. Similarmente, cuando los mensajes están disponibles para la "distribución" a la aplicación de recepción, los mensajes con prioridad más alta son recibidos antes de los mensajes con prioridad más baja. Las prioridades pueden establecerse por el código de aplicación o indirectamente utilizando los perfiles descritos más adelante. El Diálogo 200 también proporciona memoria intermedia negociada opcional de mensajes. Cuando un Diálogo se utiliza con transacciones, las memorias intermedias de envío y recepción locales actúan como administradores de recursos de transacción. En este caso, los mensajes recibidos bajo una transacción se consideran suministrados tentativamente (borrados de la memoria intermedia de recepción) sometidos al resultado de transacción. Similarmente, los mensajes enviados bajo una transacción son capturados tentativamente (agregados a la memoria intermedia de envío) sometidos al resultado de transacción. Si se entrega la transacción, estas capturas y suministros de mensajes tentativos se hacen permanentemente. Si se aborda la transacción, estas operaciones tentativas son abandonadas como si nunca hubieran ocurrido. Similar a otros administradores de recursos de transacción, los almacenes del diálogo son responsables de proporcionar aislamiento de transacción para operaciones de memoria intermedia tentativas (por ejemplo mensajes capturados que no son visibles fuera de la transacción), y atomicidad de transacción con término transacción bajo el control de un administrador de transacción. La memoria temporal de transacción simplifica el desarrollo de las aplicaciones de mensajes correctas (por ejemplo, que hacen transiciones de estado correctas aún frente a las fallas o actividad concurrente). Las aplicaciones pueden utilizar esta característica para coordinar el intercambio de mensajes y el procesamiento de mensajes local. Por ejemplo, una aplicación puede recibir y procesar un mensaje dentro del alcance de una transacción. Este procesamiento de mensajes puede incluir leer y actualizar una o más bases de datos de transacción así como enviar uno o más mensajes sobre diálogos incluidos en la transacción. Si la transacción aborta, todo el trabajo está desecho. En particular, los mensajes que se enviaron tentativamente se abandonan - es decir, los socios de sesión no verán estos resultados parciales - y el mensaje recibido permanece disponible para su distribución. Esto último permite que el mensaje se procese dentro del alcance de una nueva transacción. Cuando se entrega una transacción, toda esta actividad se vuelve permanente, incluyendo el borrado del mensaje recibido y el guardado temporal de los mensajes enviados. La afectación neta es el procesamiento de mensajes exactamente una vez. El guardado en memoria de transacción es una característica de Diálogo local en que la aplicación utilice o no está característica es completamente transparente a sus aplicaciones de socio de sesión. De acuerdo con modalidades ejemplares, y como se describe en lo siguiente con referencia a la Figura 2, en el punto extremo del emisor cuando se llama el EnvíoQ 210, el mensaje se coloca tentativamente en el Almacenamiento 260 de Diálogo. Si se entrega la transacción, el mensaje se entrega al Almacenamiento 260 y se hace disponible para transmisión al punto extremo asociado. Si la transacción aborta, el mensaje se descarta. En el receptor, cuando se llama la Recepcíón() 215 (o Borra) el mensaje se borra tentativamente del Almacenamiento 260 de Diálogo. Si se entrega la transacción, el mensaje se borra permanentemente del Almacenamiento 260. Si la transacción aborta, el mensaje permanece en el Almacenamiento 260 y está disponible para la redistribución. La recepción negociada permite el procesamiento exactamente de una vez de mensajes. Se debe observar que aunque la memoria intermedia negociada es una característica común de los sistemas de formación en cola, estos sistemas generalmente requieren un almacenamiento durable. El Diálogo 200 proporciona esta misma semántica de transacción independientemente de la durabilidad del Almacenamiento 260 de Diálogo, proporcionando el mismo modelo de programa en todos los casos. Por ejemplo, el almacenamiento en memoria proporciona semánticas de transacción al participar como un administrado de recursos de transacción. El Diálogo 200, sin embargo, permite que la implementación de aplicación se aisle de los detalles de desarrollo, incluyendo los detalles asociados con el transporte y las características de conectividad , el enrutamiento de mensajes y el manejo de estado de punto extremo. Otra característica proporcionada por el Diálogo 200 es una función de mensaje de veneno opcional. Como se menciona previamente, cuando un mensaje recibido y procesado bajo una transacción, y esa transacción aborta, el mensaje permanece en el Almacenamiento 260 de Diálogo y está disponible para su redistribución a la aplicación. Algunas veces, el problema que provoca la transacción para abortar es transitorio, por ejemplo, el tiempo establecido debido a una interrupción, y el procesamiento de distribución y mensajes tiene éxito en el siguiente intento. Sin los intentos de distribución para un mensaje dado provocan repetidamente un aborto, el mensaje se considera un "veneno". El Diálogo 200 proporciona una forma de configurar cuantas veces la distribución de mensaje se aborta antes de que el mensaje se considere un veneno. Cuando se detecta un mensaje de veneno, se obtiene un error en la aplicación y además intentos en procesar el mensaje se detienen hasta que la aplicación toma acción correctiva. Esto asegura que los recursos de procesamiento no se desperdicien intentando trabajar aquello que nunca pueda tener éxito o pueda tener éxito solamente después de cierta intervención. La detección de mensaje de veneno puede configurarse mediante un perfil (descrito en lo siguiente) o especificarse en el código de aplicación.

La característica de perfiles opcional proporciona un conjunto nombrado de opciones de configuración de diálogo. Como se describe en lo anterior, existen muchas características configurables de diálogos, tales como cupos de memoria intermedia, tiempos establecidos, almacenes, etc. Además, el Diálogo 200 proporcionados para las resoluciones de distribución de mensajes configurables, por ejemplo, ALO, AMO e 10, cuyos códigos de aplicación puede especificar independientemente un nivel mínimo de resolución de distribución deseable que pueda incrementarse a través de la configuración si se desea. El perfil proporciona una forma de agrupar los establecimientos de Diálogo comunes, y de referir aquellos establecimientos por nombre. Además, la implementación del Diálogo 200 permite la selección de perfiles a través de archivos de configuración de aplicación de manera que los administradores tienen control de tiempo de desarrollo sobre los establecimientos. Cuando se crea o acepta diálogos, las aplicaciones se refieren al perfil por nombre, y agregan todos los ajustes como especificados en el perfil que se utilizan para crear el Diálogo 200. El ajuste puede establecerse directamente como parte de un programa de aplicación, como código, o como otras construcciones de programación. Los perfiles pueden asociarse con un programa directamente por las referencias en el código u otras construcciones de programación, tales que los valores de perfil puedan establecerse independientemente de los programas de aplicación. Los valores de perfil establecidos directamente toman procedencia sobre el valor de perfil establecido directamente por las referencias de perfil. Debido a que el Diálogo 200 proporciona cualquier combinación de estas características y resoluciones, independientes entre sí, el Diálogo 200 puede configurarse para cumplir cualquier configuración de acoplamiento de los modelos de programación fuertemente acoplados similares a los del protocolo de control de transmisión (TCP) y la Llamada de Procedimiento Remota (RPC), a los modelos de programación holgadamente acoplados similares a los datagramas y colas. Además, el Diálogo 200 soporta eficientemente los diversos modelos de intercambio de mensajes de segunda parte (MEP) tales como de una vía, semidúplex, de una solicitud/respuesta sencilla a más modelos complejos), y las interacciones más complejas totalmente dúplex. Por consiguiente, el Diálogo 200 permite la unificación de modelos de programación de comunicación de segunda parte. La Figura 2 ilustra las características operacionales de un diálogo 200 de acuerdo con modalidades ejemplares de la presente invención. Una interfase 220 de programación de aplicación de canal de diálogo (API) se proporciona con una abstracción para la aplicación 205. Como se describe previamente, el diálogo 200 utiliza un protocolo de mensajes, tal como el envío de mensajes confiable de servicios de red (WS-RM), que define una secuencia de mensajes. Una secuencia define un conjunto unidireccional de mensajes en una sesión. Las dos secuencias se combinan para formar un diálogo, una secuencia en cada dirección entre las dos partes que se comunican. Cuando se llama el Envío() 210 del método de canal 220, el mensaje, el cual se pasa como un parámetro al método 210 de envío, se almacena en el estado 250 de envío y se estampa únicamente con un número de secuencia de mensajes en forma monótona incrementado de acuerdo con el orden en el cual se envío el mensaje. Los mensajes 255 se guardan temporalmente en el estado 250 de envío para mantener el estado sobre los mensajes 255 individuales en una secuencia. En este punto, se dice que los mensajes son "capturados" en el estado 250 y el EnvíoQ 210 regresa a la aplicación. Más particularmente, el método 210 de envío acepta un mensaje como un parámetro. Es este mensaje el que se pasa a la Memoria Intermedia 250 de Envío para estamparse con un número de secuencia y subsecuente o simultáneamente almacenarse en el Almacenamiento 260. Es a este punto que el mensaje se juzga "capturado", y el método 210 de envío regresa. Repitiendo esta llamada con otros mensajes resulta en una frecuencia o secuencia parcial del mensaje 255.

El Estado 235 de Diálogo comprende memorias intermedias 250 y 240 de Envío y Recepción 250 y 240 respectivamente. El Estado 235 de Diálogo controla y almacena la información invariante como el identificador de Diálogo, las resoluciones especificadas por la aplicación y la dirección de punto extremo asociado. El Estado 235 de Diálogo también controla la información de sesión tal como el siguiente número de secuencia de transmisión próximo y el estado de aceptación. Además, los datos de configuración tal como TTL de Diálogo, tiempos establecidos, la ubicación del almacenamiento, etc., se mantiene en el Estado 235 de Sesión de Diálogo. Una vez que se captura el mensaje, el Protocolo 270 entonces puede procesar y transmitir el mensaje capturado, por ejemplo, mensaje 275, por consiguiente a través del Puerto 285. El modelo de programación y la infraestructura de tiempo de ejecución para el Diálogo 200 proporcionan un modelo de resolución de punto extremo flexible y eficiente. El modelo, cuando mucho, asegura que los dos puntos extremos sean resueltos suficientemente para proporcionar el intercambio de mensajes confiable. En particular, el protocolo 270 puede asegurar antes de suministrar el mensaje inicial en un diálogo para el procesamiento, que ambos puntos extremos contengan una referencia suficiente para garantizar la capacidad única de punto extremo y la correlación correcta de los mensajes a través del Diálogo 200 y su sesión correspondiente. Esto se requiere, por ejemplo, para asegurar que un mensaje se suministre confiablemente a un socio de sesión sencillo, para asegurar la distribución a lo mucho de una vez. Esta resolución de punto extremo puede basarse en múltiples factores, incluyendo un identificador que identifica la aplicación asociada (por ejemplo, un identificador de recurso universal (URI)) utilizado por el creador del Diálogo 200, configuración local, datos de enrutamiento encabezados de mensajes, configuraciones intermediarias y la configuración de aplicación de objetivo. Es importante observar que la implementación 205 de aplicación no necesita tener que ver que los detalles de la resolución de punto extremo de diálogo. La infraestructura para el Diálogo 200 realiza un proceso de resolución para coordinar el punto extremo inicial para asegurar que es el punto extremo homólogo únicamente seleccionado para la sesión. Esto se hace como se necesita y es transparente para la implementación 205 de aplicación. La resolución de punto extremo de tiempo de ejecución para el diálogo también puede proporcionarse para asegurar lograr las metas de distribución de mensajes, mientras proporcione la flexibilidad para lograr la ejecución correcta en un amplio margen de configuraciones de red. Esta característica soporta el desarrollo flexible de aplicaciones en varias configuraciones para dirigir la escalabilidad, disponibilidad, seguridad (tales como cortafuegos) y los requerimientos de rendimiento. Las configuraciones de desarrollo de servicio incluyen, por ejemplo, contribuciones de aplicación (por ejemplo, réplicas de escala) y particiones de aplicación (por ejemplo, para dividir el procesamiento por el número de cliente o región geográfica). Las contribuciones de aplicación y particiones pueden utilizarse separadamente o juntas. Por ejemplo, una aplicación puede desarrollarse para utilizar enrutamiento dependiente de datos a una partición de aplicación, la cual a su vez se comprende de una contribución de servicios de aplicación. El Protocolo 270 también determina que tipo de resolución de extremo a extremo y características locales se han especificado por la aplicación 205, independiente del método para realizar la resolución de punto extremo descrita en lo anterior. Si la aplicación 205 especifica la resolución de ALO, el protocolo 270 mantiene un acopio del mensaje 275 en la Memoria Intermedia 250 de Envío de Diálogo hasta que el Protocolo 270 recibe una aceptación positiva del receptor (no mostrado) que el mensaje 275 se recibió adecuadamente. Cuando el Protocolo 270 recibe una aceptación positiva del receptor, registra este hecho en el Estado 235 de Sesión, y borra el mensaje de la Memoria Intermedia 250 de Envío. Si el Protocolo 270 no recibe una aceptación positiva dentro de un tiempo establecido de reintento específico, el Protocolo retransmite una copia del mensaje 275 con el mismo número de secuencia de mensaje. El Diálogo 200 puede repetir este proceso un número de veces, y puede emplear estrategias de retroceso de cronómetros de reintento para poder evitar congestión adicional en la red. Si una aceptación no se recibe dentro del periodo de tiempo especificado por el TTL de mensaje, entonces inicia un error para informar la Aplicación 205 de envío que la resolución no pudo cumplirse. Cuando un mensaje 280 de diálogo se recibe, el Protocolo 270 copia el mensaje en el estado 240 de Memoria Intermedia de Recepción. El Protocolo 270 también registra el siguiente número de secuencia de mensaje esperado. Cuando se recibe el mensaje 280, si las resoluciones del Diálogo 200 incluyen AMO, el número de secuencia de mensaje del mensaje 280 de llegada se compara con el conjunto de números de secuencia de mensaje que han llegado previamente, que como se menciona previamente, se almacenan en el estado 240 de Memoria Intermedia de Recepción. Si el conjunto ya contiene un número de secuencia de correlación, el mensaje 280 se considera un duplicado y se descarta; de otra manera, el mensaje 280 se coloca en la Memoria Intermedia 240 de Recepción local para referencia futura. Si las resoluciones incluyen ALO, entonces el Protocolo 270 envía una aceptación positiva selectiva completa sin secuencia, con la recepción del mensaje 280 al punto extremo asociado para el diálogo. Esta aceptación debe incluir los números de secuencia de todos los mensajes que se han recibido de este modo hasta ahora en la sesión. Una notación taquigráfica que incluye un conjunto de márgenes de secuencia puede utilizarse para conservar el espacio de mensajes. Si las resoluciones específicas no incluyen 10 entonces el mensaje 280 sea inmediatamente disponible para "distribución" a la aplicación 205 de recepción a través del canal 220 de recepción. En particular, se envía una notificación a la aplicación 205 que el mensaje está disponible para la recepción. La aplicación 205 puede entonces llamar a la Recepción() 215 con la cual el siguiente mensaje disponible para distribución se pasa a la aplicación 205 y la "distribución" se dice que ocurre. Si se especifica la resolución IO, el número de secuencia del mensaje 280 de llegada se compara con el siguiente número de secuencia esperado. Si el número de secuencia es menor que el siguiente número de secuencia esperado, se descarta el mensaje 280 de llegada. Si concuerdan, el mensaje 280 de llegada se hace inmediatamente disponible para la distribución a la aplicación 205 de recepción, y el siguiente número de secuencia esperado se establece al número de siguiente mensaje perdido. Si el número de secuencia es mayor que el siguiente número de secuencia esperado, entonces la conducta depende de si la resolución de ALO también está o no especificada. Si la resolución de ALO no se especifica, entonces el mensaje 280 se hace inmediatamente disponible para la distribución a la aplicación 205 de recepción, y el siguiente número de secuencia esperado se establece a uno o más del número de secuencia del mensaje 280 de llegada. Si la resolución de ALO se especifica, el mensaje 280 no se hace disponible para la distribución a la aplicación 205 de recepción, pero permanece en la memoria intermedia 240 de recepción. Por consiguiente, sino concuerdan, una suposición de que por lo menos otro mensaje de un número de secuencia más bajo aún no se ha recibido. Cuando todos los mensajes numerados menores perdidos han llegado, entonces el margen continuo de mensajes se hace disponible para distribución a la aplicación de recepción en la secuencia apropiada, y el siguiente número de secuencia esperado se establece al número del siguiente mensaje perdido. Como se menciona en lo anterior, cuando los mensajes se hacen disponibles para la distribución a la aplicación 205 de recepción, se expide una notificación a la aplicación 205 de recepción. La aplicación de recepción entonces puede llamar al método 215 de Recepción() en el canal 220 de diálogo para aceptar la distribución del siguiente mensaje disponible. La Recepción() puede llamarse múltiples veces para recibir cada mensaje disponible en turno. Para asegurar el orden, las multiplicaciones de eventos se entregan en forma de serie. Por consiguiente, cuando se hace disponible un mensaje para la distribución a la aplicación 205, una notificación de eventos sencilla se suministra a la aplicación 205 al llamar al código de aplicación que previamente se registró con un evento de Diálogo 200. Hasta que la llamada al código de aplicación regresa, ninguna otra llamada a este código de aplicación se hará aún si otros mensajes están disponibles para su distribución. Dentro del código de aplicación, la aplicación 205 puede llamar típicamente a la Recepción() 215 de diálogo para recibir el siguiente mensaje disponible. También como se describe en lo anterior, cuando se llama el Envío() 210, el número de mensajes actualmente en la memoria intermedia 250 de envío se compara con el cupo de la memoria intermedia específico. Si excede el cupo, el Envío() 210 de que llama se bloquea en un evento hasta que el espacio se vuelve disponible, o hasta que se excede el tiempo establecido de envío. Cuando el espacio se vuelve disponible en la memoria intermedia 250 de envío, la memoria intermedia verifica si existe algún visitante que espera enviar mensajes. Si es así, el Envío() 210 de que llama desbloquea y nuevamente puede enviar los mensajes. Todos los estados para el Diálogo 200 - incluyendo aquellos en las memorias intermedias 250 y 240 de mensajes, aquellos en el canal 220, y aquellos en el Protocolo 270 - pueden mantenerse simultáneamente en el almacenamiento 260 de diálogo. El Almacenamiento 260 de Diálogo debe contener la información más actualizada. Esto garantiza que el Estado 235 de Diálogo tenga las propiedades de durabilidad del Almacenamiento 260 de Diálogo, y permita que todas las características funcionen independientes del Almacenamiento 260 que está en uso. Por ejemplo, poner un mensaje 280 en la memoria intermedia 240 de recepción puede implicar que el disco escriba en el Almacenamiento 260. Para proporcionar las resoluciones, las aceptaciones son enviadas solamente después de que se ha registrado el mensaje en el Almacenamiento 260. Esto asegura, por ejemplo que el emisor o el receptor siempre tenga una copia del mensaje. Similarmente, en el lado de envío, el Envío() 210 puede completar solo después de que se ha registrado al mensaje del Almacenamiento 260.

Como se menciona previamente, el Almacenamiento 260 de Diálogo puede ser un almacenamiento que se puede conectar, que permite que la flexibilidad tremenda cumpla las metas de durabilidad, rendimiento, autonomía y administrativas. Por ejemplo, al Almacenamiento 260 puede seleccionarse de uno de una pluralidad de almacenes dentro de una infraestructura sencilla que incluye lo siguiente: una implementación de Almacenamiento de Dialogo de memoria que mantenga todo el estado en la memoria de aplicación; una implementación de Almacenamiento de Diálogo exprés que mantenga el estado de la memoria de un proceso demonio dedicado, separado; o una implementación de almacenamiento de base de datos durable, tal como un servidor de Lenguaje de Pregunta Estructurada (SQL). Diferentes diálogos dentro de la misma Aplicación 205 puede utilizar diferentes almacenes. Además, la presente invención también estipula que algunos Almacenes 260 de Diálogo puedan configurarse para ejecutarse en el nodo de computadora local, u otro nodo. Debido a que el Diálogo 200 actúa como un agente a nombre de la aplicación 205, la aplicación 205 se aisla a los cambios en la conectividad. Esto permite, por ejemplo, estilos de lotes de procesamiento donde una aplicación inicia envía y recibe mismos mensajes, y después sale sin tener que esperar el otro punto extremo para responder o aún estar disponible. Además, la distribución de mensajes puede programarse con mayor flexibilidad sometida solo a cumplir las diversas resoluciones de distribución y características locales, por ejemplo, mensaje o TTL de sesión. Por ejemplo, someterlo a resoluciones de distribución, el Diálogo 200 puede propagar las cargas de mensajes pico sobre el mismo periodo de tiempo (equilibrio de carga) o de otra manera cambiar la distribución de mensajes a un tiempo de costo más efectivo, esperar, que un recurso se vuelva disponible, explicar el mensaje o prioridad de diálogo, etc., independiente de la aplicación 205. Además, el Almacenamiento 260 proporciona capacidades de apagado y reinicio para la aplicación 205. El procesamiento en lotes, la programación, así como las capacidades de apagado y reinicio de aplicación incrementan la disponibilidad y la escalabilidad del sistema. Además, y como se establece en lo anterior, la Aplicación 205 puede especificar que las operaciones de EnvíoQ 210 o Recepción() 215 se negocian con respecto a las Memorias Intermedias 250 y 240 de Diálogo. Esto permite la aplicación, por ejemplo, para recibir un mensaje, enviar algunos mensajes en uno o más diálogos y actualizar una tabla de aplicación todos dentro de una sola transacción. En este uso de transacciones, simplemente es una noción local y no lleva al otro punto extremo. El diálogo también proporciona recuperación de omisión durante el tiempo de ejecución, lo cual puede recuperar automáticamente (enmascarar) muchas omisiones 265 sin implicar la ¡mplementación de aplicación. Una aplicación puede confiar recibir las características afirmadas (es decir, la resolución afirmada y las características) para el ciclo de vida de un Diálogo 200. Si la infraestructura para el Diálogo 200 o Protocolo 270 determina que las características afirmadas pueden ya no satisfacerse, el diálogo se coloca en un estado con omisión, y se forma un evento de omisión, permitiendo la acción correctiva fuera de banda independiente del código de aplicación de línea principal o aun de la Aplicación 205. Si la omisión 265 puede corregirse (repararse), el diálogo puede colocarse nuevamente en servicio. Las fallas no recuperables, es decir, omisiones que no pueden repararse, pueden resultar en la terminación del Diálogo 200 y la notificación de aplicación. Tal diseño se conforma al modelo de "falla rápida", el cual es fundamental para el desarrollo de las aplicaciones confiables. Las fallas que sobreviven pueden incluir lo siguiente: mensajes corruptos, perdidos, duplicados o retardados; fallas de transporte y de red; fallas de proceso; fallas intermediarias y fallas de sistema. Como se menciona en lo anterior, debido a que el Diálogo 200 proporciona una abstracción a la aplicación y mantiene sus propias memorias intermedias y almacenamiento, el Diálogo 200 también soporta las aplicaciones y ambientes con conectividad intermitente. Los diálogos también pueden adaptarse a los ambientes cambiantes, tales como cargas a la topología de red, contextos de seguridad negociados o reubicación de punto extremo. El Diálogo 200 puede intentar automáticamente reparar estas fallas por si mismo, tal como al reenviar un mensaje. Alternativamente o en conjunto, el Diálogo 200 puede enviar una solicitud a una tercera parte, por ejemplo un operador de sistema o código de diagnóstico, que requiere la asistencia en la reparación de la falla. Esta asistencia puede ser, por ejemplo, intervención humana simple para reparar una conexión rota en una red, o posiblemente un proceso de reparación automatizado. En cualquier caso, una vez que se repara la falla, el Diálogo 200 puede continuar enviando los mensajes. Estos, acoplados con otras características de disponibilidad, permiten los diálogos de larga duración. Sin embargo, si no puede resolverse una falla por el Diálogo 200 o a través de alguna otra intervención de tercera parte, un mensaje de error puede formarse en la Aplicación 205 que inició el diálogo. Las aplicaciones pueden configurarse para utilizar los almacenes 280 de diálogo que permiten que se mantengan los diálogos a través de la falla de proceso de aplicación y reinicio. Algunos Almacenes 260 pueden tolerar adicionalmente la falla de sistema y reinicio. Otras fallas de transmisión pueden manejarse automáticamente por una combinación de manejadores de falla de dominio específico y soportes de retransmisión de mensaje básico como se describe en lo anterior. Ejemplos incluyen fallas que resultan de la credencial de seguridad o el término de la política. Si un mensaje transmitido en una sesión asegurada falla debido a la expiración de la credencial, el Diálogo 200 puede negociar las credenciales de seguridad y desplegar la falla de diálogo. Cuando se resume el procesamiento de diálogo, los mensajes guardados temporalmente se retransmitirán con las credenciales actualizadas en virtud del proceso de reintento estándar. También como se menciona en lo anterior, el diseño y la infraestructura correspondiente para el Diálogo 200 permite que el tiempo de ejecución adapte dinámicamente un Diálogo 200 a un ambiente de ejecución de cambio. Esto puede proporcionarse transparente a la implementación de aplicación y soporta la existencia de los diálogos de larga duración y las aplicaciones altamente disponibles. Las combinaciones antes descritas de manejadores de fallas (que pueden ser conectados), la transmisión y el reintento de distribución y el modelo de falla y reparación permiten que los diálogos se adapten a muchos cambios ambientales. Estos cambios incluyen, pero no se limitan a, cambios de política (por ejemplo, privacía de mensajes), cambios de protocolo (por ejemplo, soporte para nuevos protocolos de seguridad), cambios de topología de red (por ejemplo, la adición o remoción de enrutadores o cortafuegos), cambio de una aplicación desarrollada para manejar la carga incrementada (por ejemplo introducir una contribución de aplicación y/o particiones), y reubicación de un punto extremo de diálogo y estado asociado (por ejemplo, recuperación de desastres). Esto permite también opciones de desarrollo escalable, que incluyen soporte de muy pequeño á muy grande. Por ejemplo, el Diálogo 200 soporta duplicación de escala ascendente, escala externa, aplicación o partición, nuevamente transparente a la implementación de aplicación . La Figura 3 ilustra el ciclo de vida y los estados del Diálogo 200. El Diálogo 200 puede estar en uno o dos estados principales, Activo 320 o inactivo 360. Si el Diálogo 200 está activo 320, el objeto 220 de Canal de Diálogo está en memoria, de otra manera, el Diálogo 200 está Inactivo 360 y el Diálogo 200 existe solamente en el Almacenamiento 260 de Diálogo. Los recursos del sistema de administración ocurren a través de los procesos de Desactivación 350 y Reactivación 340 que pueden ocurrir manual o automáticamente. Por ejemplo la Desactivación 350 puede ocurrir manualmente si la aplicación llama la disposición o automáticamente debido a un tiempo de inactividad, en donde cierto periodo de tiempo transcurre donde no se intercambia ningún mensaje sobre el canal de diálogo, El canal puede desactivarse (los objetos correspondientes liberados de la memoria), de este modo liberando los recursos de la memoria para otras cosas. La Reactivación 340 puede ocurrir manualmente si una aplicación que solicita el Canal del Administrador de Diálogo (no mostrado), o la Reactivación 340 pueden ocurrir automáticamente si un nuevo mensaje llega para la sesión. Cada diálogo se asigna una ID única por el Administrador de Diálogo durante la Creación 310 de Diálogo. Esta ID se pasa por la Aplicación 205 al Administrador de Diálogo en una solicitud de Reactivación 340, y el Administrador de Diálogo utiliza la ID para localizar el estado de diálogo y reiniciar el canal. Las interfases de Desactivación 350 y Reactivación 340 permiten que el sistema limite los recursos de procesamiento asociados con Diálogos que no han sido activamente utilizados para enviar mensajes salientes o procesar mensajes entrantes. Esto permite que la infraestructura reclame los recursos relacionados excepto aquellos asociados con el Almacenamiento 260 de Diálogo. Además, este diseño permite que la programación de recursos incluya: programar la transmisión de mensajes basándose en la prioridad o la disponibilidad de recursos; formar en lotes los mensajes para transmisión más eficiente; programar la distribución de mensajes basándose en la prioridad o disponibilidad de recursos; y formar en lotes la distribución de mensajes para procesamiento más eficiente. La creación 310 de un diálogo se controla por el administrador de diálogo y puede iniciarse por la aplicación que llama la función de Creación 310. Alternativamente, el sistema de envío de mensajes puede iniciar la Creación 310 de Diálogo después de recibir un mensaje de otro punto extremo que indica la necesidad de un diálogo nuevo. En este caso, el sistema notifica la Aplicación 205 que se requiere un diálogo. La Aplicación 205 puede entonces llamar un método de aceptación en el administrador de diálogo para aceptar la solicitud de diálogo y provocar la creación 310 de diálogo, o puede llamar un método de rechazo en el administrador de diálogo para rechazar la solicitud de diálogo. El administrador de diálogo también controla el rompimiento 330, el cual puede iniciarse por un par de razones. Una razón puede ser que la sesión se termina exitosamente, es decir, ambos lados se les hizo el envió y ninguno mensaje más permanece. Otra razón para el rompimiento 330 puede ser que el Diálogo 200 se termine, por ejemplo, la aplicación llame una función de Terminación() o una indicación se recibe del punto extremo asociado para la terminación. Cuando un lado termina el diálogo, se envía un mensaje al otro lado para indicar este. No existe confiabilidad para este mensaje, simplemente es un intento para decir al otro lado que el diálogo se terminó. La terminación implica que ningún mensaje más se intercambiará sobre la sesión de diálogo. Aunque la descripción de la invención define el diálogo como un mecanismo de comunicación dúplex en el cual los mensajes de aplicación pueden enviarse y recibirse por ambos socios de punto extremo de sesión, otra modalidad ejemplar incluye un modelo simple. De acuerdo con la modalidad, un punto extremo de sesión solamente envía los mensajes de aplicación y no recibe los mensajes de aplicación de su punto extremo asociado, y el socio de punto extremo de sesión solamente recibe los mensajes de aplicación pero no envía los mensajes de aplicación. Las mismas resoluciones configurables y características de punto extremo local configurables aplican como en el diálogo. La implementación cambia ya que, en el punto extremo de envío, una memoria intermedia 240 de recepción no se requiere, y en el punto extremo de recepción, una memoria intermedio 250 de envío no se requiere. Las modalidades dentro del alcance de la presente invención también incluyen medios que se pueden leer por computadora para llevar o tener instrucciones que se pueden ejecutar por computadora o estructuras de datos almacenadas en los mismos. Los medios que se pueden leer por computadora pueden ser cualquier medio disponible que pueda accesarse por una computadora de propósito general o de propósito especial. A modo de ejemplo, y no de limitación, los medios que se pueden leer por computadora pueden comprender RAM, ROM, EEPROM, CD-ROM, u otro almacenaje en disco óptico, almacenaje en disco magnético u otros dispositivos de almacenaje magnético, o cualquier otro medio que pueda utilizarse para llevar o almacenar medios de código de programa deseados en forma de instrucciones que se pueden ejecutar por computadora o estructuras de datos y que pueden accesarse por una computadora de propósito general o de propósito especial. Cuando se transfiere la información o se proporciona sobre una red u otra conexión de comunicación (ya sea de cable físico, inalámbrica, o una combinación de alámbrica o inalámbrica a una computadora, la computadora ve adecuadamente la conexión como un medio que se puede leer por computadora. De este modo, cualquier conexión se llama adecuadamente medio que se puede leer por computadora. Combinaciones de lo anterior también deben incluirse dentro del alcance de los medios que se pueden leer por computadora. Las instrucciones que se pueden ejecutar por computadora comprenden, por ejemplo, instrucciones y datos que provocan que una computadora de propósito general, computadora de propósito especial o dispositivo de procesamiento de propósito especial realice una cierta función o grupo de funciones. La Figura 4 y la siguiente discusión se pretenden para proporcionar una breve descripción general de un ambiente de cómputo adecuado en el cual la invención puede implementarse. Aunque no se requiere, la invención se describirá en el contexto general de instrucciones que se pueden ejecutar por computadora, tales como módulos de programas, que se ejecutan por computadoras en ambientes de red. Generalmente, los módulos de programas incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc., que realizan tareas particulares o implementan tipos de datos abstractos particulares. Las instrucciones que se pueden ejecutar por computadora, estructuras de datos asociadas, y módulos de programas representan ejemplos de medio de código de programa para ejecutar etapas de los métodos descritos en la presente. La secuencia particular de las instrucciones que se pueden ejecutar o estructuras de datos asociadas representa ejemplos de actos correspondientes para implementar las funciones descritas en tales etapas. Aquellos con experiencia en la técnica apreciarán que la invención puede practicarse en ambientes de cómputo de red con muchos tipos de configuraciones del sistema de computadora, que incluyen computadoras personales, dispositivos portátiles, sistemas multiprocesadores, electrónica basada en microprocesador o de consumidor programable, PC de red, minicomputadoras, computadoras, computadoras de procesador central, y similares. La invención también puede practicarse en ambientes de cómputo distribuidos donde las tareas se realizan por los dispositivos de procesamiento local y remoto que se enlazan (ya sea por enlaces de cableado físico, enlaces inalámbricos, o por una combinación de enlaces de cableado físico o inalámbrico) a través de una red de comunicación. En un ambiente de cómputo distribuido, los módulos de programas pueden localizarse en ambos dispositivos de almacenaje de memoria local y remoto. Con referencia a la Figura 4, un sistema ejemplar para implementar la invención incluye un dispositivo de cómputo de propósito general en forma de una computadora 420 convencional, que incluye una unidad 421 de procesamiento, una memoria 422 de sistema, y una barra colectora 423 de sistema que acopla tales componentes de sistema que incluyen la memoria 422 de sistema a la unidad 421 de procesamiento. La barra colectora 423 de sistema puede ser cualquiera de varios tipos de estructuras de barra colectora que incluyen una barra colectora de memoria o controlador de memoria, una barra colectora periférico y una barra colectora local que utiliza cualquiera de una variedad de estructuras de barra colectora. La memoria de sistema incluye memoria 424 de solo lectura (ROM), y memoria 425 de acceso aleatorio (RAM). Un sistema 426 de entrada/salida (BIOS), que contiene las rutinas básicas que ayudan a la información de transferencia entre los elementos dentro de la computadora 420, tales como durante el inicio, pueden almacenarse en ROM 424. La computadora 420 también puede incluir una unidad 427 de disco duro magnética para leer y escribir en un disco 439 duro magnético, una unidad 428 de disco magnético para leer o escribir en un disco 429 magnético removible, y una unidad 430 de disco óptico para leer o escribir en el disco 431 óptico removible tal como CD-ROM u otro medio óptico. La unidad 437 de disco duro magnética, la unidad 428 de disco magnético, y la unidad 430 de disco óptico se conectan a la barra colectora 423 de sistema mediante una interfase 432 de unidad de disco duro, una interfase 433 de unidad de disco magnético, y una interfase 434 de unidad óptica, respectivamente. Las unidades y sus medios que se pueden leer por computadora asociados proporcionan almacenaje no volátil de instrucciones que se pueden ejecutar por computadora, estructuras de datos, módulos de programas y otros datos para la computadora 420. Aunque el ambiente ejemplar descrito en la presente emplea un disco 439 duro magnético, un disco 429 magnético removible y un disco 431 óptico removible, otros tipos de medios que se pueden leer por computadora para almacenar datos pueden utilizarse, incluyendo casetes magnéticos, tarjetas de memoria flash, discos versátiles digitales, cartuchos de Bernoulli, RAM, ROM, y similares. Los medios de código de programa que comprenden uno o más módulos de programa pueden almacenarse en el disco 439 duro, disco 429 magnético, disco 431 óptico, ROM 424 o RAM 425, incluyendo un sistema 35 operante, uno o más programas 36 de aplicación, otros módulos 437 de programas y los datos 438 de programas. Un usuario puede ingresar comandos e información en la computadora 420 a través de un teclado 440, dispositivo 442 de señalamiento, u otros dispositivos de entrada (no mostrados), tales como un micrófono, una palanca de mando, cojín de juego, disco satelital, explorador, o similares. Estos y otros dispositivos de entrada con frecuencia se conectan a la unidad 421 de procesamiento a través de una interfase 446 de puerto de serie acoplada a la barra colectora 423 de sistema. Alternativamente, los dispositivos de entrada pueden conectarse por otras interfases, tal como un puerto paralelo, un puerto de juego o una barra colectora de serie universal (USB). Un monitor 447 u otro dispositivo de presentación también se conecta a la barra colectora 423 del sistema mediante una interfase, tal como un adaptador 448 de video. Además del monitor, computadoras personales típicamente incluyen otros dispositivos de salida periféricos (no mostrados), tales como altavoces e impresoras. La computadora 420 puede operar en un ambiente de red utilizando conexiones lógicas a una o más computadoras remotas, tales como computadoras 449a y 449b remotas. Las computadoras 449a y 449b remotas pueden ser cada una otra computadora personal, un servidor, un enrutador, una PC de red, un dispositivo homólogo u otro nodo de red común, y típicamente incluir muchos o todos los elementos descritos en lo anterior con relación a la computadora 420, aunque solamente los dispositivos 450a y 450b de almacenaje de memoria y sus programas 436a y 436b de aplicación asociados se han ilustrado en la Figura 4. Las conexiones lógicas representadas en la Figura 4 incluyen una red 451 de área local (LAN), y una red 452 de área amplia (WAN) que se presentan aquí a modo de ejemplo y no de limitación. Los ambientes de red son comunes en redes computarizadas de oficinas o de empresas, intranet y la Internet. Cuando se utiliza en un ambiente de red de LAN, la computadora 420 se conecta a la red 451 local a través de una interfase de red o adaptador 453. Cuando se utiliza en un ambiente de red de WAN, la computadora 420 puede incluir un modem 454, un enlace inalámbrico, u otros medios para establecer comunicaciones sobre la red 452 de área extensa, tal como la Internet. El modem 454, el cual puede ser interno o externo, se conecta a la barra colectora 423 de sistema mediante la interfase 446 de puerto en serie. En un ambiente de red, los módulos de programas representados con relación a la computadora 420 o porciones de los mismos, pueden almacenarse en el dispositivo de almacenaje de memoria. Se apreciará que las conexiones de red mostradas son ejemplares y otros medios para establecer comunicaciones sobre la red 452 de área amplia pueden utilizarse. La presente invención puede representarse en otras formas específicas sin apartarse de su espíritu o características esenciales. Las modalidades descritas se considerarán en todos los respectos solo como ilustrativas y no como restrictivas. El alcance de la invención por lo tanto, se indica por las reivindicaciones anexa en lugar de por la descripción anterior. Todos los cambios que entren dentro del significado y margen de equivalencia de las reivindicaciones serán abarcados dentro de su alcance.

Claims

REIVINDICACIONES

1. En un sistema de envío de mensajes que soporta uno o más transportes de mensajes, un método para simplificar el desarrollo de aplicación al proporcionar un modelo de programación sencillo que permita especificar una o más resoluciones de distribución de mensaje de extremo a extremo que se cumplirán en tiempo de ejecución, independiente de un transporte o transportes de mensajes particulares que se utilizan en tiempo de ejecución, como opuesto a especificar el transporte o transportes de mensajes particulares en tiempo de desarrollo, el método está caracterizado porque comprende los actos de: definir una interfase de canal de mensaje que extrae operaciones de envío y recepción para intercambiar mensajes sobre uno o más transportes de mensajes disponibles para enviar y recibir uno o más mensajes; y definir para su uso dentro de un modelo de programación sencillo, una pluralidad de resoluciones de distribución de mensajes de extremo a extremo, cada una de las cuales puede especificarse en tiempo de ejecución independiente de uno o más transportes de mensajes disponibles, sin especificar uno o más transportes de mensajes disponibles en el tiempo de desarrollo, en donde la pluralidad de resoluciones de distribución de mensajes comprende por lo menos una distribución de mensajes de por lo menos una vez, una distribución de mensajes de por lo mucho una vez, una distribución de mensajes enviados en orden, y tiempo de sesión para existir.

2. El método de la reivindicación 1 , que además comprende una acción de: definir una pluralidad de características de mensajes confiables, en donde cada una de la pluralidad de características de mensajes confiables locales puede seleccionarse para su uso dentro del modelo de programación sencillo, y en donde la pluralidad de características de mensajes confiables locales comprende por lo menos un almacenaje de estado de sesión, tiempo de mensaje para existir, y memoria temporal de mensaje negociado.

3. El método de acuerdo con la reivindicación 2, en donde la característica de mensaje confiable local de un almacenamiento de estado de sesión comprende un almacenamiento que se puede conectar.

4. El método de acuerdo con la reivindicación 3, en donde el almacenamiento comprende por lo menos uno de un almacenamiento en memoria, un almacenamiento durable en disco o un almacenamiento de proceso demonio.

5. El método de acuerdo con la reivindicación 4, en donde el almacenamiento es local a una aplicación que especifica una o más de la pluralidad definida de las resoluciones de distribución de mensajes de extremo a extremo.

6. El método de acuerdo con la reivindicación 4, en donde el almacenamiento es remoto de una aplicación que especifica una o más de la pluralidad definida de resoluciones de distribución de mensajes de extremo a extremo.

7. El método de acuerdo con la reivindicación 2, en donde las características de mensajes confiables locales además comprenden un cupo de memoria intermedia, que, en combinación con un tamaño de mensaje máximo define el número máximo de mensajes que se guardará temporalmente por el sistema y restricciones de los mensajes de espacio máximo que puede consumir.

8. El método de acuerdo con la reivindicación 7, en donde las características de mensajes configurados locales además comprende un tiempo establecido de envío, que desbloquea una función de envío de un mensaje después de que expira el tiempo establecido de envío si no ha estado disponible el espacio de memoria intermedia requerido, sometido al cupo de memoria intermedia.

9. El método de acuerdo con la reivindicación 2, en donde las características de mensajes confiables locales además comprenden un cupo de memoria intermedia, que, en combinación con un tamaño de mensaje máximo, reserva espacio de memoria intermedia suficiente para un número específico de mensajes.

10. El método de acuerdo con la reivindicación 2, en donde las características de mensajes confiables locales además comprenden una opción de prioridad, en donde la transmisión de menajes de prioridad más alta toman procedencia sobre los mensajes de prioridad más baja.

11. El método de acuerdo con la reivindicación 2, en donde las características de mensajes confiables locales además comprenden una opción de prioridad en donde la distribución de mensajes de más alta prioridad toma procedencia sobre los mensajes de más baja prioridad .

12. El método de acuerdo con la reivindicación 2, en donde la característica de mensaje confiable local de la memoria intermedia de mensaje negociado está disponible independiente de la durabilidad del almacenamiento de estado de sesión.

13. El método de acuerdo con la reivindicación 2, en donde las características de mensajes confiables locales además comprenden un número configurable de cuantas veces la distribución de mensajes debe abortar antes de que se considere un mensaje no entregable.

14. El método de acuerdo con la reivindicación 2, en donde las características de envío de mensajes pueden definirse por un conjunto de perfiles, que dan un conjunto específico de opciones de configuración de mensajes definidas por las resoluciones de distribución de mensajes de extremo a extremo y las características locales.

15. En un sistema de envío de mensajes que soporta uno o más transportes de mensajes, un método para simplificar el desarrollo de aplicación al proporcionar un modelo de programación sencillo que permita especificar una o más de las resoluciones de distribución de extremo a extremo para su uso en seleccionar un transporte de mensajes particular en tiempo de ejecución, como opuesto a especificar el transporte de mensajes particular en el tiempo de desarrollo, el método comprende las etapas para: extraer una ¡nterfase de canal del mensaje para intercambiar mensajes sobre uno o más transportes de mensajes; y permitir que un desarrollador de aplicación especifique una o más de la pluralidad de resoluciones de distribución de mensajes de extremo a extremo, para su uso dentro del modelo de programación sencillo, las resoluciones de distribución de extremo a extremo especificadas que se utilizan en la selección de un transporte de mensajes adecuado en tiempo de ejecución, sin especificar ningún transporte de mensaje en el tiempo de desarrollo, en donde la pluralidad de distribución de mensajes comprende por lo menos una distribución de mensajes de por lo menos una vez, distribución de mensajes a lo mucho a una vez, distribución de mensajes enviados en orden y tiempo de mensaje para existir.

16. El método de acuerdo con la reivindicación 15, que además comprende la etapa para: permitir que un desarrollador de aplicación especifique una o más de una pluralidad de características de mensajes confiables locales en donde cada una de la pluralidad de características de mensajes confiables locales puede seleccionarse para su uso dentro del modelo de programación sencillo, y en donde la pluralidad de características de mensajes confiables locales comprende por lo menos uno de un almacenaje de estado de sesión, un tiempo de mensaje para existir, y memoria intermedia de mensaje negociado.

17. El método de acuerdo con la reivindicación 16, en donde la característica de mensaje confiable local de un almacenaje de estado de sesión comprende un almacenamiento que se puede conectar.

18. El método de acuerdo con la reivindicación 17, en donde el almacenamiento comprende por lo menos uno de un almacenaje en memoria, un almacenaje durable en disco, o un almacenaje de proceso demonio.

19. El método de acuerdo con la reivindicación 16, en donde las características de mensajes confiables locales además comprenden un cupo de memoria intermedia, que, en combinación con un tamaño de mensaje máximo, define el número máximo de mensajes que se guardarán temporalmente por el sistema.

20. El método de acuerdo con la reivindicación 19, en donde las características de mensajes confiables locales además comprenden un tiempo establecido de envío, que desbloquea la función de envío después de que expira el tiempo establecido de envío si se ha cumplido el cupo de memoria intermedia.

21. El método de acuerdo con la reivindicación 16, en donde las características de mensajes confiables locales además comprenden una opción de prioridad, en donde los mensajes de más alta prioridad se transmiten antes de los mensajes de más baja prioridad .

22. El método de acuerdo con la reivindicación 16, en donde las características de mensajes confiables locales además comprenden una opción de prioridad, en donde los mensajes de más alta prioridad se reciben antes de los mensajes de más baja prioridad.

23. El método de acuerdo con la reivindicación 16, en donde la característica de mensaje confiable local de la memoria intermedia de mensaje negociado está disponible independiente de la durabilidad del almacenamiento de estado de sesión.

24. El método de acuerdo con la reivindicación 16, en donde las características de mensajes confiables locales además comprenden una forma de configurar cuantas veces la distribución de mensajes debe abortar antes de que se considere no entregable.

25. El método de acuerdo con la reivindicación 16, en donde las características de distribución de mensajes pueden definirse por un conjunto de perfiles, que dan un conjunto específico de opciones de configuración de mensajes definidas por las resoluciones de distribución de mensajes de extremo a extremo y las características locales.

26. En un sistema de envío de mensajes que soporta uno o más soportes de mensajes, un producto de programa de computadora que comprende uno o más medios que se pueden leer por computadora que llevan instrucciones que se pueden ejecutar por computadora que implementan un método para simplificar el desarrollo de aplicación al proporcionar un modelo de programación sencillo que permita especificar una o más resoluciones de distribución de extremo a extremo para su uso en seleccionar uno de un transporte de mensajes particular en tiempo de ejecución, como opuesta a especificar el transporte de mensajes particular en el tiempo de desarrollo, el método comprende las acciones de: definir una interfase de canal de mensaje que extrae las opciones de envío y recepción para intercambiar mensajes sobre uno o más transportes de mensajes; y definir para su uso dentro de un modelo de programación sencillo, una pluralidad de resoluciones de distribución de mensajes de extremo a extremo para utilizarse en seleccionar un transporte de mensaje adecuado en tiempo de ejecución, sin especificar el transporte de mensajes adecuado en el tiempo de desarrollo, en donde la pluralidad de resoluciones de distribución de mensajes comprende por lo menos uno de distribución de mensajes por lo menos una vez, distribución de mensajes a lo mucho una vez, distribución de mensajes enviados en orden, y tiempo de sesión para existir.

27. El producto de computadora de acuerdo con la reivindicación 26, además comprende una acción de: definir una pluralidad de características de mensajes confiables locales, en donde cada una de la pluralidad de características de mensajes confiables locales pueden seleccionarse para su uso dentro del modelo de programación sencillo, y en donde la pluralidad de características de mensajes confiables locales comprende por lo menos uno de almacenamiento de estado de sesión, tiempo de mensaje para existir, y memoria intermedia de mensaje negociado.

28. El producto de computadora de acuerdo con la reivindicación 27, en donde la característica de mensaje confiable local de un almacenamiento de estado de sesión comprende un almacenamiento que se puede conectar.

29. El producto de computadora de acuerdo con la reivindicación 28, en donde el almacenamiento comprende por lo menos uno de un almacenaje de memoria, almacenaje durable en disco, o un almacenaje de proceso demonio.

30. El producto de computadora de acuerdo con la reivindicación 27, en donde las características de mensajes confiables locales además comprenden un cupo de memoria intermedia que, en combinación con un tamaño de mensaje máximo, define el número máximo de mensajes que se guardarán temporalmente por el sistema.

31. El producto de computadora de acuerdo con la reivindicación 30, en donde las características de mensajes confiables locales además comprenden un tiempo establecido de envío, que desbloquea la función de envío después de que expira el tiempo establecido de envío si se ha cumplido el cupo de memoria intermedia.

32. El producto de computadora de acuerdo con la reivindicación 27, en donde las características de mensajes confiables locales además comprenden una opción de prioridad, en donde los mensajes de más alta prioridad se transmiten antes de los mensajes de más baja prioridad.

33. El producto de computadora de acuerdo con la reivindicación 27, en donde las características de mensajes confiables locales además comprenden una opción de prioridad, en donde los mensajes de más alta prioridad se reciben antes de los mensajes de más baja prioridad.

34. El producto de computadora de acuerdo con la reivindicación 27, en donde las características de mensajes confiables locales de la memoria intermedia de mensaje negociado está disponible independiente de la durabilidad de estado de sesión.

35. El producto de computadora de acuerdo con la reivindicación 27, en donde las características de mensajes confiables locales además comprenden una forma de configurar cuántas veces la distribución de mensajes debe abordar antes de que se considere un mensaje no entregable.

36. El producto de computadora de acuerdo con la reivindicación 27, en donde las características de distribución de mensajes pueden definirse por un conjunto de perfiles, que dan un conjunto específico de opciones de configuración de mensajes definidas por las resoluciones de distribución de mensajes de extremo a extremo y las características locales.

37. En un sistema de envío de mensajes que soporta uno o más transportes de mensajes, un producto de programa de computadora que comprende uno o más medios que se pueden leer por computadora que llevan instrucciones que se pueden ejecutar por computadora, que ¡mplementan un método para simplificar el desarrollo de aplicación al proporcionar un modelo de programación sencillo que permite especificar una o más resoluciones de distribución de extremo a extremo para su uso en la selección de un transporte de mensajes particular en el tiempo de ejecución, como opuesto a especificar el transporte de mensaje particular en el tiempo de desarrollo, el método comprende las etapas para: extraer una interfase de canal de mensaje para intercambiar mensajes sobre uno o más transportes de mensajes; y permitir que un desarrollador de aplicación especifique una o más de una pluralidad de resoluciones de distribución de mensajes de extremo a extremo, para su uso dentro del modelo de programación sencillo, las resoluciones de distribución de extremo a extremo especificadas se utilizan en la selección de un transporte de mensajes adecuado en tiempo de ejecución, sin especificar ningún transporte de mensaje en el tiempo de desarrollo, en donde la pluralidad de resoluciones de distribución de mensajes comprende por lo menos uno de distribución de mensajes por lo menos una vez, distribución de mensajes a lo mucho una vez, distribución de mensajes enviados en orden, y tiempo de mensaje para existir.

38. El producto de computadora de acuerdo con la reivindicación 37, en donde además comprende la etapa para: permitir que un desarrollador de aplicación especifique una o más de una pluralidad de características de mensajes confiables locales en donde cada una de la pluralidad de características de mensajes confiables locales puede seleccionarse para su uso dentro del modelo de programación sencillo, y en donde la pluralidad de características de mensajes confiables locales comprende por lo menos uno de un almacenamiento de estado de sesión, un tiempo de mensaje para existir, y memoria intermedia de mensaje negociado.

39. El producto de computadora de acuerdo con la reivindicación 38, en donde la característica de mensaje confiable local de un almacenamiento de estado de sesión comprende un almacenamiento que se puede conectar.

40. El producto de computadora de acuerdo con la reivindicación 39, en donde el almacenamiento comprende por lo menos uno de un almacenaje de memoria, almacenaje durable en disco, o un almacenaje de proceso demonio.

41. El producto de computadora de acuerdo con la reivindicación 38, en donde las características de mensajes confiables locales además comprenden un cupo de memoria intermedia, que en combinación con un tamaño de mensaje máximo, define el número máximo de mensajes que se guardará temporalmente por el sistema.

42. El producto de computadora de acuerdo con la reivindicación 41, en donde las características de mensajes confiables locales además comprende un tiempo establecido de envío que desbloquea la función de envío después de que expira el tiempo establecido de envío si se ha cumplido el cupo de memoria intermedia.

43. El producto de computadora de acuerdo con la reivindicación 38, en donde las características de mensajes confiables locales además comprenden una opción de prioridad, en donde los mensajes de más alta prioridad se transmiten antes de los mensajes de menos de más baja prioridad.

44. El producto de computadora de acuerdo con la reivindicación 38, en donde las características de mensajes confiables locales además comprenden una opción de prioridad, en donde los mensajes de más alta prioridad se reciben antes de los mensajes de más baja prioridad.

45. El producto de computadora de acuerdo con la reivindicación 38, en donde las características de mensajes confiables locales de la memoria intermedia de mensaje negociado están disponibles independiente de la durabilidad del almacenamiento de estado de sesión.

46. El producto de computadora de acuerdo con la reivindicación 38, en donde las características de mensajes confiables locales además comprenden una forma de configurar cuántas veces la distribución de mensajes debe abordar antes de que se considere un mensaje no entregable.

47. El producto de computadora de acuerdo con la reivindicación 38, en donde las características de distribución de mensajes pueden definirse por un conjunto de perfiles, que dan un conjunto específico de opciones de configuración de mensajes definidas por las resoluciones de distribución de mensajes de extremo a extremo y las características locales.