MXPA04002729A - Transmision y recepcion de mensajes a traves de un canal de comunicacion y modelo de programacion adaptable. - Google Patents

Abstract

Se describen metodos, sistemas y productos de programa de computadora para extraer capas de procesamiento dentro de una infraestructura de envio de mensajes, de manera que se pueden hacer cambios o mejoras a la infraestructura mientras se retiene la funcionalidad existente. Las implementaciones de transporte de mensajes son extraidas dentro de una capa de mensaje, permitiendo que otras capas dentro de la infraestructura interactuen con mensajes en mas de una forma generica, enormemente independiente del transporte de mensajes. Los ejemplos de transporte incluyen conductos denominados, Protocolo de Control de Transmision (TCP), Protocolo de Transferencia de Hipertexto (HTTP), Protocolo de Transferencia de Correo Simple (SMTP), etc. Una capa de canal por arriba de la capa de mensaje extrae implementaciones de intercambio de mensaje, permitiendo que otras capas dentro de la infraestructura envien y reciban mensajes en una forma mas generica, enormemente independiente de la semantica de intercambio de mensajes de una implementacion de intercambio de mensajes de implementacion especifica. Los ejemplos de intercambio de mensajes incluyen datagramas, dialogos, monologos, colas, y similares. Por arriba de la capa de canal y la capa de mensaje, una capa de servicio extrae las implementaciones de union que unen las implementaciones de intercambio de mensaje a implementaciones de codigos de usuario.

Description

TRANSMISION Y RECEPCION DE MENSAJES A TRAVES DE UN CANAL DE COMUNICACION Y MODELO DE PROGRAMACION ADAPTABLES 1. Campo de la Invención La presente invención se refiere a infraestructuras de envío de mensaje. Más particularmente, la presente invención se refiere a métodos, sistemas y productos de programa de computadora que abstraen o extraen capas de procesamiento dentro de una infraestructura de envío de mensajes, de manera que se pueden hacer cambios o mejoras sin tener que volver a implementar la funcionalidad existente. 2. Antecedentes y Técnica Relacionada Con el surgimiento de conectividad entre las computadoras que muchas redes poderosas actuales proporcionan, el procesamiento distribuido se ha vuelto enormemente atractivo para una amplia variedad de aplicaciones. Sin embargo, las infraestructuras más modernas para desarrollar aplicaciones distribuidas ofrecen poca flexibilidad en términos de seleccionar de entre la tecnología de comunicación disponible y la que surge. Por ejemplo, los modelos de programación, semántica de intercambio de mensajes, y transportes de mensajes tienden a quedar herméticamente acoplados. Como resultado, la selección de cualquiera, por lo regular dicta las otras. La Figura 1A ilustra un ejemplo de la técnica anterior de una infraestructura de envío de mensajes herméticamente acoplados 100A basada en el Modelo de Objeto de Componente Distribuido (DCOM). El modelo DCOM es una extensión del Modelo de Objeto de Componente (COM) que permite que los componentes se comuniquen tanto dentro de una red como a través de límites de red, el COM se limitó al interprocesar la comunicación dentro de una sola máquina. Un desarrollador que desee utilizar el DCOM acepta el modelo de programación de DCOM 130A, semántica de intercambio de mensajes de llamada de procedimiento remoto (RPC) 120A, y las conexiones de red de RPC 110A correspondientes, como un grupo. La Figura 1B ilustra otro ejemplo de la técnica anterior de una infraestructura de envío de mensajes hermética acoplada 100B. Similar a la infraestructura de DCOM mostrada en la Figura 1A, esta otra infraestructura de envío de mensaje 100B incluye otro modelo de programación 130B, otra semántica de intercambio de mensaje 120B y otras conexiones de red 110B. Observar que las porciones de cierre 121B de otro modelo de programación 130B, otra semántica de intercambio de mensajes 120B, y otras conexiones de red 110B difieren de las porciones de cierre 121A del modelo de programación de DCOM 130A, semántica de intercambio de mensaje de RPC 120A, y conexiones de red de RPC 110A. Las diferencias entre las porciones de cierre 121A y 121 B ilustran la falta de flexibilidad de la técnica anterior al seleccionar a partir de la variedad de opciones existentes y que surgen para desarrollar aplicaciones distribuidas. Al haber seleccionado DCOM o alguna otra tecnología y su infraestructura correspondiente, se hace relativamente difícil la tarea de utilizar aspectos de otras tecnologías, sin sacrificar el esfuerzo gastado en el desarrollo de aplicaciones existentes. Por lo regular, dichos cambios o mejoras en la tecnología requieren de empezar, esencialmente a partir de líneas de partida. Por consiguiente, los modelos de programación desacoplados, semántica de intercambio de mensajes, y transportes de mensaje representan un avance en la técnica. Los desarrolladores son capaces de tomar aspectos a un nivel dentro de la infraestructura sin tener que lamentarse de las emisiones no relacionadas en otro nivel. Además, los desarrolladores pueden moverse de un modelo de programación hacia otro sin tener que aprender una nueva infraestructura. El desacoplamiento de capas conduce a una capacidad de utilización adicional mayor y fomenta la innovación, ya que los cambios y mejoras en una infraestructura desacoplada permiten retener los esfuerzos de desarrollo existentes.

COMPENDIO DE LA INVENCION La presente invención se refiere a métodos, sistemas y productos de programa de computadora para extraer capas de procesamiento dentro de una infraestructura de envío de mensajes, de manera que se pueden hacer cambios o mejoras subsecuentes a la infraestructura mientras se retiene la funcionalidad existente. De acuerdo con modalidades ilustrativas de la presente invención, que se describen más adelante con mayor detalle, la infraestructura incluye tres capas primarias: una capa de mensajes, una capa de canal y una capa de servicio. Cada una de estas capas resume la funcionalidad de manera que los detalles de una implementación particular generalmente quedan ocultos de otras capas. En una modalidad ilustrativa, las implementaciones de transporte de mensaje son resumidas dentro de una capa de mensaje, permitiendo que otras capas dentro de la infraestructura interactúen con mensajes en una forma más genérica, enormemente independiente de! transporte de mensajes. Ejemplos de transporte de mensajes incluyen conductos, Protocolo de Control de Transmisión (TCP), Protocolo de Transferencia de Hipertexto (HTTP), Protocolo de Transferencia de Correo Simple (SMTP), etc. Una capa de canal por arriba de la capa de mensajes resume implementaciones de intercambio de mensaje, permitiendo que otras capas dentro de la infraestructura envían y reciban mensajes en una forma más genérica, enormemente independiente de la semántica de intercambio de mensajes de una implementación de intercambio de mensajes específicos. Ejemplos de implementaciones de intercambio de mensajes incluyen datagramas, diálogos, monólogos, colas, y similares. Por arriba de la capa de canal y la capa de mensaje, una capa de servicio resume las implementaciones de unión que unen implementaciones de intercambio de mensaje a implementaciones de códigos de usuario (por ejemplo, aplicaciones) que utilizan la infraestructura. La capa de servicio, describe por lo menos en parte, un modelo de programación para utilizarse en la infraestructura de envío de mensajes. Cada capa de extracción puede corresponder a una pluralidad de módulos de programa para la implementación resumida o extraída. La extracción de capa de mensaje puede resumir o extraer puertos que proporcionan una extracción de envío/recepción atomístico para mensajes. Para cada implementación extraída, la infraestructura puede incluir un caso específico de la extracción que representa la implementación para utilizarse dentro de la infraestructura. Por ejemplo, en el caso de una extracción de canal puede ser unida a un caso de una implementación de código de servicio o usuario para procesar mensajes. La unión puede ser realizada a través de una representación de servicio para las implementaciones de código de canal y de usuario. A medida que los mensajes fluyen a través de los casos y representación de servicio, éstos pueden ser interceptados y procesados adicionalmente. La extracción de capa de servicio puede resumir una implementación de almacenamiento de servicio que maneja la vida física de los casos de código de servicio o de usuario. Aspectos y ventajas adicionales de la invención se establecerán en la descripción que sigue, y en parte serán obvios a partir de la descripción, o pueden ser aprendidos a través de la práctica de la invención. Los aspectos y ventajas de la invención pueden ser realizados y obtenidos a través de los instrumentos y combinaciones particularmente señalados en las reivindicaciones anexas. Estos y otros aspectos de la presente invención serán más ampliamente evidentes a partir de la siguiente descripción y reivindicaciones anexas, o pueden ser aprendidos a través de la práctica de la invención como se establece más adelante.

BREVE DESCRIPCION DE LOS DIBUJOS Con el fin de describir la forma en la cual las ventajas y aspectos antes mencionados y otros de la invención pueden ser obtenidos, se proporcionará una descripción más particular de la invención descrita brevemente haciendo referencia a sus modalidades específicas, las cuales se ilustran en los dibujos anexos. El entendimiento de estos dibujos representa solamente modalidades típicas de la invención y, por lo tanto, no se deben considerar como limitantes de su alcance, la invención será descrita y explicada con carácter específico adicional y detalla a través del uso de los dibujos anexos, en los cuales: Las Figuras 1A-1B ilustran ejemplos de la técnica anterior de infraestructuras de envío de mensaje herméticamente acopladas; La Figura 2 ilustra una representación de alto nivel de una infraestructura de envío de mensajes de acuerdo con la presente invención; La Figura 3 es un diagrama de bloque que muestra una modalidad ilustrativa de una infraestructura de envío de mensajes de acuerdo con la presente invención; Las Figuras 4A-4B muestran acciones y pasos ilustrativos para métodos para extraer o resumir datos de procesamiento dentro de una infraestructura de envío de mensajes de acuerdo con la presente invención; y La Figura 5 ¡lustra un sistema ilustrativo que proporciona un ambiente operativo adecuado para la presente invención.

DESCRIPCION DETALLA DE LAS MODALIDADES PREFERIDAS La presente invención se extiende a métodos, sistemas y productos de programa de computadora para resumir o extraer capas de procesamiento dentro de una infraestructura de envío de mensajes, de manera que se pueden hacer cambios y mejoras subsecuentes a la infraestructura sin tener que volver a implementar necesariamente la funcionalidad existente. Las modalidades de la presente invención pueden comprender uno o más propósitos especiales y/o una o más computadoras de propósito general, incluyendo varios de hardware (aparatos, equipo, maquinaria, etc.) de computadora, como se discute con mayor detalle más adelante. La Figura 2 ilustra una representación de alto nivel de una infraestructura de envío de mensajes 200 ilustrativa de acuerdo con la presente invención. Un mayor detalle con respecto a una implementación ilustrativa de una infraestructura de envío de mensaje se proporciona a continuación, con relación a la Figura 5. La infraestructura 200 soporta programación distribuida a través de una arquitectura en capas (por ejemplo, la infraestructura puede ser vista como un grupo ordenado de sub-sistemas, en donde cada subsistemas depende de sub-sistemas previos). Por ejemplo, en la infraestructura de envío de mensajes 200, las capas principales incluyen una capa de envío de mensajes 210, una capa de canal 240, y una capa de servicio 270. Como se describe con mayor detalle más adelante, cada una de estas capas extrae ciertos de detalles de implementación , de manera que cosas similares pueden ser tratadas en una forma común. Las extracciones desacoplan modelos de programación, semántica de intercambio de mensaje, y transportes de mensaje, de manera que los desabolladores son capaces de recoger de aspectos a un nivel dentro de la infraestructura sin tener que lamentarse de emisiones no relacionadas a otro nivel. Como resultado, los desabolladores pueden, por ejemplo, moverse de un modelo de programación hacia otro sin tener que aprender una nueva infraestructura. Esta extracción conduce a una mayor capacidad de volver a utilizar y fomenta la innovación, ya que los cambios y mejoras en una infraestructura desacoplada permiten retener esfuerzos de desarrollo existentes. La capa inferior, la capa de envío de mensajes 210, proporciona una transmisión de punto extremo a punto extremo o transporte de mensajes. La capa de envío de mensajes 210 soporta la capacidad de extensión de transporte, de manera que se implementan como nuevos transportes, pueden ser utilizados por otras capas dentro de la estructura. Por ejemplo, la capa de envío de mensajes 210 extrae implementaciones para protocolos de transporte, tales como conductos nombrados, Protocolo de Control de Transmisión (TCP), Protocolo de Transferencia de Hipertexto (HTTP), Protocolo de Transferencia de Correo Simple (SMTP), etc. Por consiguiente, en términos simples, la capa de envió de mensajes 210 proporciona una extracción de envío/recepción de mensaje atomística hacia las otras capas dentro de la infraestructura, de manera que las otras capas pueden procesar mensajes, un poco independiente del protocolo de transporte particular usado para enviar o recibir los mensajes. La capa de envío de mensajes 210 permite la intercepción extensa de mensajes a medida que salen de y llegan a los puntos extremos. El mecanismo de intercepción extensible se puede utilizar para implementar comportamientos tales como enrutamiento, filtración, manejo de política y seguridad. Tanto los transportes como los comportamientos disponibles en puntos extremos en la capa de envío de mensajes 210 pueden ser establecidos ya sea programáticamente o a través de configuración. La capa de canal 240 proporciona extracciones de envío de mensajes en la parte superior de las extracciones de transporte provista por la capa de envío de mensajes 210. Los canales representan el comportamiento ¡mplementado entre los puntos extremos y un modelo de objeto que extrae el comportamiento ¡mplementado. Ejemplos de canales comunes incluyen canales de 1 o datagrama para envío de mensajes no correlacionados unidireccionales, canales de diálogo para envío de mensajes correlacionados bidireccionales, canales de monólogo para el envío de mensajes de difusión de publicación/suscripción o unidireccionales, y canales en cola para el envío de mensajes en cola unidireccional. La aplicación o código de usuario utiliza canales creando casos de canal (por ejemplo, un objeto de canal de memoria) en un punto extremo y envía mensajes en esos casos. Cuando un mensaje llega a otro punto extremo, la aplicación o código de usuario reconoce el canal creado en el lado de envío del canal y crea un caso de canal para participar en la conversación. La capa de servicio 270 proporciona modelos de programación en la parte superior de la capa de canal 240 y la capa de envío de mensajes 210. Los programadores de aplicación típicamente utilizarán la infraestructura de envío de mensajes 200 en la capa de servicio. Los modelos de programación de la capa de servicio se distinguen uno del otro por mecanismos de despacho de mensajes, como los mensajes son enviados (por ejemplo, estructuras contra llamadas de método tipificado), y sistemas de tipo. La capa de servicio 270 proporciona un mecanismo general para unir casos del modelo de programación a los casos de canal descritos anteriormente. La capa de servicio 270 también proporciona aquellos aspectos que los modelos de programación seleccionan para proporcionar a los desabolladores, tales como el control de estado y vida, manejo de servicio, intercepción de llamada, y despacho de mensajes sincronizado. Los modelos de programación tanto simples como complejos pueden ser desarrollados para la capa de servicio. Con el fin de facilitar la unión e interoperabilidad apropiadas, los modelos de programación en general definirán una relación fija entre los tipos de transporte de capa de envío de mensajes y los tipos definidos y controlados dentro de la misma infraestructura, en particular los tipos que corresponden a la aplicación u objetos de código de usuario dentro de la capa de servicio 270. La Figura 3 es un diagrama de bloque que muestra una modalidad ilustrativa de una infraestructura de envío de mensajes 300 de acuerdo con la presente invención. En general, la infraestructura de envío de mensajes 300 está hecha de módulos para unir casos de canal (es decir, objetos de extracción de canal de memoria) con casos de código implementados a través de los modelos de programación soportados. Similar a la descripción anterior con respecto a la Figura 2, la Figura 3 incluye una capa de envío de mensajes 310, una capa de canal 340 y una capa de servicio 370. La descripción de la Figura 3 puede ser dividida en dos categorías generales: la misma infraestructura de envío de mensajes, y modelos de programación que pueden ser soportados por la infraestructura de envío de mensajes. La discusión que sigue comienza describiendo la infraestructura de envío de mensajes, y después regresa a una descripción de un modelo de programación ilustrativo. Aunque las referencias a los componentes ilustrados en la Figura 3 pueden ser en singular, se debe entender que los múltiplos de cada componente pueden y en general estará presentes dentro de una infraestructura individual. Tres administradores, uno dentro de cada capa, implementan muchos de la funcionalidad básica ofrecida por la infraestructura 300: el puerto 312 en la capa de envío de mensajes 310, el administrador de canal 342 en la capa de canal 340, y el administrador de servicio 382 en la capa de servicio 370. Por consiguiente, la descripción de la Figura 3 inicialmente se enfoca en estos tres administradores en general, y después regresa a discusión más detalla de los tres manejadores y los otros componentes que se ilustran. El primero de los tres administradores, el puerto 312, actúan como un corredor de multiplexión entre implementaciones de transporte y el resto de la infraestructura. En términos simples, el puerto 312 y la capa de envío de mensajes 310 proporcionan una extracción de envío/recepción de mensajes atomística a la infraestructura de envío de mensajes 300. Como se indicó previamente, esta extracción libera a otras capas del molesto entendimiento de los detalles asociados con las implementaciones de transporte individuales. Más bien, otras capas interactúan con una extracción de mensajes, y dejan los detalles como los mensajes son transportados a la capa de envío de mensajes 310 y al puerto 312. El segundo de los tres administradores, el administrador de canal 342 en la capa de canal 340, reúne y correlaciona los mensajes, o posiblemente los almacena y/u ordena, y presenta una extracción de canal de nivel más alto a la capa de servicio 370 en general, y al administrador de servicio 382 y el unidor de servicio 372 en particular. Similar a la extracción de mensajes ofrecida por la capa de envío de mensajes 310, aquí también, la extracción de canal provista por la capa de canal 340 y el administrador de canal 342 liberan otras capas de la necesidad de entender detalles asociados con la semántica de intercambio de mensaje individual. Otras capas simplemente interactúan con una extracción de canal, y dejan los detalles de cómo los mensajes son intercambiados (por ejemplo, datagrama, diálogo, etc.) a la capa de canal 340. El tercero de los tres administradores, el administrador de servicio 382, es responsable de conectar casos de servicio 376 (casos de una clase implementada de acuerdo con uno de los modelos de programación) a los casos de canal 344 producidos por el administrador de canal 342, que proporcionan un caso de una extracción de canal a los casos de servicio correspondientes. El administrador de servicio 382 conecta los casos de servicio 376 a los casos de canal 344 a través de un unidor de servicio 376 que entiende los detalles tanto de modelo de canal como de programación particulares. Como se describe con detalle más adelante, el unidor de servicio 372 coopera con el almacenamiento de servicio 378 para crear y registrar casos. El administrador de servicio 382 y el unidor de servicio 372 unen los casos de servicio 376 a los casos de canales 344 utilizando una representación de servicio 374, la cual también se describe más adelante con mayor detalle. Una vez que todos los casos son creados, el almacenamiento de servicio 378 extrae su durabilidad (por ejemplo, tiempo de vida, etc.) y la ubicación del resto de la infraestructura. Los mensajes y llamadas que fluyen hacia casos de servicio pueden ser interceptados por el código suministrado por las extensiones de servicio 392 registradas con el administrador de servicio 382. Los casos de servicio se comunican con la infraestructura a través de una interfase en los casos de servicio, denominado como un sitio de servicio, que implementa funciones comúnmente usadas por un caso. El sitio de servicio de un caso es inicializado (o situado) cuando el almacenamiento de servicio crea el caso . El administrador de servicio 382 es un grupo de interfases que se utilizan para crear canales y tener acceso a otros componentes dentro de la infraestructura y es la entidad a través de la cual se configura la infraestructura. Cuando se crea un administrador de servicio, crea las unidades de servicio, almacenamientos de servicio y tipos de servicio que están disponibles en un puerto, y los conecta a la infraestructura. Si un puerto es capaz de manejar solicitudes para múltiples servicio, solamente un administrador de servicio individual está asociado para el puerto. Aunque las infraestructuras tradicionales pueden tener cierta forma del administrador de servicio para crear casos y manejar coordinación de infraestructura, el manejador de servicio 382 realiza sus tareas indirectamente, delegando este trabajo a otros módulos apropiados para una tarea particular. Como resultado, el administrador de servicio 382, como otros componentes de infraestructura 300, soporta un alto grado de capacidad de extensión, mientras que los administradores de servicio en infraestructuras tradicionales tienden a crear casos y manejar la coordinación de infraestructura directamente, haciendo difícil la innovación ya que la funcionalidad existente puede necesitar volver a ser implementada para soportar un nuevo comportamiento o funcionalidad. El unidor de servicio 372 es responsable de manejar la relación entre los casos de canal 344, casos de servicio 376 y almacenamientos de servicio 378. Por consiguiente, el unidor de servicio 372 típicamente tiene un reconocimiento específico de cada canal disponible y modelo de programación disponible. Los canales implementan eventos idiosincráticos e interfases que el unidor de servicio 372 utiliza para mover mensajes hacia adentro y hacia fuera de la capa de canal 340. Los modelos de programación especifican un mapa entre tipos, que el unidor de servicio utiliza para aplicar mensajes a métodos y regresar llamadas de método a los mensajes. Ya que cada canal y modelo de programación es diferente. Una unidad de servicio usualmente soporta uno de cada uno. Por consiguiente, típicamente un puerto de operación está asociado con uno o más unidores de servicio para cada par de canal/modelo de programa soportado. Un modelo de programación ilustrativo puede trazar un mapa entre un tipo de puerto de Lenguaje de Definición de Servicios Web (WSDL) y un tipo manejado dentro de la rutina de la infraestructura.

El lenguaje WSDL está en un formato XML que describe servicios de red como un grupo de grupos finales que son capaces de intercambiar mensajes. Se proporciona un mecanismo relativamente simple para especificar el formato básico de solicitudes independientes del protocolo subyacente (Protocolo de Acceso de Objeto Simple-SOAP, HTTP GEP/POST, etc.) o codificando (Extensiones de Correo de Internet de Propósito Múltiple-MIME, etc.). Las operaciones de extracción y los mensajes se unen a protocolos de red específicos y formatos de mensaje para definir un punto extremo. Por consiguiente, los servicios de lenguaje WSDL son colecciones de puntos extremos, también conocidas como puertos. En el lenguaje WSDL, los tipos de puerto describen colecciones de operaciones, Se debe apreciar que la Figura 3 ilustra una modalidad ilustrativa de la presente invención, en donde la infraestructura incluye un código manejado de tipos de datos que son trazados en el lenguaje WSDL. Sin embargo, la presente invención puede ser practicada en una variedad de ambientes, en donde se restringe aquellos con tipos manejados de código/datos o tipos de puerto de WSDL. Como se indicó anteriormente, los unidores de servicio 372 están registrados con un administrador de servicio 382 durante la creación de un puerto. Los unidores de servicio están asociados con un grupo de tipos de puerto/servicio. La individualidad de los tipos a través de los unidores de servicio resulta de los tipos manejados dentro de la rutina de tiempo de la infraestructura que implementa un servicio heredado de los tipos de interfase que son únicos a un unidor de servicio. Para la infraestructura 300 ilustrativa, el mismo procedimiento que abre un puerto también abre al administrador de servicio 382 y a todos los unidores de servicio 372 disponibles en el puerto. Cuando se abren, los unidores de servicio se conectan a sus administradores de canal 342 correspondientes. Cuando un código de usuario emite una llamada al administrador de servicio 382 para crear un canal, el administrador de servicio itera sobre el grupo de unidores de servicio registrados y ofrece a cada canal con el que debe tratar el tipo especificado. Entonces, el administrador de servicio utiliza el unidor de servicio que reconoce el tipo especificado para crear un caso de servicio 376, registrarlo con el almacenamiento de servicio 378, y unir el caso de servicio a un caso de canal 344 con una representación de servicio 374. Similarmente, cuando un mensaje llega a un canal que no está asociado con un caso de servicio existente, el grupo de unidores de servicio unido al canal se les pide si reconocen el tipo de puerto de entrada/servicio. El unidor de servicio 372 que reconoce el tipo se utiliza para crear un caso de servicio, unirlo al caso de canal con una representación de servicio, y después hacer que los mensajes de entrada fluyan a través de los casos y la representación hacia el código de usuario. Para llenar una solicitud para un nuevo caso, un unidor de servicio crea un caso de servicio 376, lo registra con un almacenamiento de servicio 378, crea una representación de servicio 374, conecta un caso de canal 344 a la representación de servicio 374 y la representación de servicio 374 al código de usuario en el caso de servicio 376, y activa el flujo del primer mensaje en el canal. Después, los mensajes fluyen del caso de canal hacia la representación de servicio 374, que los traduce a pilas de llamadas y los despacha al caso de servicio correspondiente. En forma similar, las llamadas fluyen fuera del caso de servicio 376 hacia la representación de servicio 374, que los traduce a mensajes y los envía a través del caso de canal a su destino. Aunque las infraestructuras tradicionales pueden tener cierta forma de un unidor de servicio, una infraestructura de acuerdo con la presente invención es capaz de soportar múltiples unidores de servicio. Además, en contraste a las infraestructuras a tradicionales, la conexión de unidor de servicio como un todo es independiente de capa de canal por debajo de ésta, así como el almacenamiento de servicio y modelos de programación dentro de la capa de servicio 370. Las infraestructuras tradicionales tienden a implementar el transporte, canal, unidor, almacenamiento y funcionalidad de casos en un paquete herméticamente unido, el cual por lo regular requiere de cambios importantes cada vez que se hagan mejoras o cambios para dirigir las necesidad de tecnología y aplicación. Como se indicó anteriormente, el almacenamiento de servicio 378 administra o maneja casos. Cuando un unidor de servicio llena una solicitud para crear un nuevo caso de servicio, el unidor de servicio crea un caso y registra el caso con el almacenamiento de servicio. Después de que el caso es creado, el unidor de servicio utiliza el almacenamiento para situar el caso (inicializar con interfases de comunicación comúnmente utilizada), y después del unidor de servicio une el canal al sitio. El almacenamiento de servicio 378 mantiene el carril del número de canales asociados con un caso, y libera un caso cuando no están unidos los canales. Esto proporciona a los unidores de servicio (quienes ven mensajes/eventos del cierre de canal y la liberación de casos de representación) la habilidad de participar en el control de la vida de casos lógicos (un caso como se puede ver desde afuera de la infraestructura). Aunque los unidores controlan la duración de los casos lógicos, el almacenamiento de servicio 378 maneja la duración de casos físicos (casos de objeto reales que viven en memoria). Cuando un almacenamiento de servicio desea eliminar un caso físico de la memoria, notifica a los canales asociados, de manera que pueden desconectar el caso físico de su representación de servicio asociada en 374. Después, la siguiente vez que se aplica una llamada/mensaje al caso, el almacenamiento de servicio es responsable de crear un nuevo caso y volver a conectarlo a la representación apropiada. Los almacenamientos de servicio 378 soportan grados variables de respeto para el estado de un caso. Un almacenamiento de servicio puede mantener todos los casos en memoria y nunca utilizar el mecanismo de desconectar/volver a conectar. Alternativamente, un almacenamiento de servicio puede mantener todos los casos en memoria y desconectar la desconexión/reconexión agresiva en un esfuerzo para fomentar el estado de los casos. Los almacenamiento de servicio puede soportar la desconexión/reconexión basándose en la carga de máquina, emisiones de licencia (por ejemplo, conexiones a una base de datos), y/o patrones de uso, y combinar la desconexión/reconexión con la deserialización/serialización de casos y el almacenamiento de casos en bases de datos de transacción para soportar casos confiables, duraderos. La base de datos usada por el almacenamiento de servicio puede cooperar con un almacenamiento usado por un canal duradero y un enrutador enfrente del puerto para implementar la migración de casos de una máquina hacia otra. Los almacenamientos de servicio 378 pueden ser útiles en la recolección de basura, estancamientos, manejos de conexiones de larga vida, etc. Los almacenamientos de servicio en infraestructuras tradicionales tienden a enlazar directamente duraciones de casos físicos y lógicos. La relación entre los dos típicamente es codificada en forma dura dentro de la infraestructura. Como resultado, son difíciles de implementar alternativas sin impactar otras áreas del sistema. Además, la modificación por usuarios expertos como un punto de capacidad de extensión o como una infraestructura es impráctica, proporcionando el acoplamiento significativo entre almacenamientos de servicio y otras porciones de la infraestructura. Como se indicó anteriormente, una representación de servicio 374 es un caso de un tipo específico de unidor de servicio que enlaza un tipo particular de caso de canal 344 a un tipo particular de caso de servicio 376. Para una llamada que entra, la representación de servicio solicita eventos del canal anunciando que un mensaje está disponible, crea la pila de llamadas apropiadas del mensaje, y la aplica al caso. Para una llamada que sale, la representación de servicio 473 solicita la llamada, la traduce a un mensaje, si es necesario, y la envía a través del caso de canal 344. Dependiendo de la dirección, una representación de servicio 374 se ve similar tanto a un canal tipificado (por ejemplo, de un caso de servicio) como a una representación de tipo manejada (por ejemplo, del caso de canal). Además de su función de unir como puente, también se implementa cierto comportamiento dentro y a través del uso de representaciones de servicio. Por ejemplo, una o más representaciones de servicio pueden implementar la administración, limitando el número de llamadas que pasan a un caso de servicio individual en un punto dado en el tiempo. Como se indicó anteriormente, con respecto al almacenamiento de servicio 378, la representación de servicio implementa la desconexión/reconexión, de manera que un almacenamiento de servicio puede desacoplar la duración del caso físico de la duración del caso lógico. Se apreciará que la representación de servicio 374 permite que tanto el unidor de servicio 372 como el almacenamiento de servicio 378 implementen un comportamiento en formas extensibles. Además de los puertos 312, administradores de canal 342 y administrador de servicio 382, pueden existir otros administradores dentro de la infraestructura 300. Estos administradores implementan comportamientos a ciertos niveles o a todos los niveles de la infraestructura, incluyendo la filtración y enrutamiento de mensajes, intercambio y aplicación de política, seguridad, entrada, y servicios de transacción. Cada administrador que proporciona capacidad de extensión, define una interfase de extensión para permitir que otros administradores ¡mplementen esa capacidad de extensión. Por ejemplo, el puerto 312 en la capa de envío de mensajes 310 suministra una extensión de puerto, permitiendo que los administradores contribuyan con manejadores para que los mensajes de conductos fluyan a través de esa capa. Similarmente, los administradores de canal individuales implementan extensiones que permiten módulos como el administrador de servicio para enganchar mensajes para crear casos de canal del canal. La extensión de servicio 392 en una interfase definida por el administrador de servicio 382 que permite que otros administradores se enganchen en los puntos de capacidad de extensión de trayectoria de llamada soportados por la infraestructura. Cuando se establecen primero las extensiones, el administrador de servicio pasa la información de tipo reflejada de los tipos de servicio que conoce con respecto a los administradores interesados a través de la extensión de servicio. Los administradores que implementan una extensión de servicio combinan estos datos de reflexión con su propia configuración para establecer lo que desean hacer en cuanto a los mensajes/llamadas particulares para que fluyan dentro y fuera de casos de servicio. La notificación antes y después del mensaje se comunica a los administradores a través de eventos que fluyen mediante la extensión de servicio. Este grado de capacidad de extensión del mecanismo de extensión de servicio no se encuentra en infraestructuras tradicionales. Siempre que la infraestructura sea configurada para soportar un comportamiento en general, no almacenar u otro componente, excepto el administrador asociado con el comportamiento, necesita ser modificado con el fin de introducir ese comportamiento en la infraestructura. Un caso de servicio 376 es un caso de un tipo de servicio de código manejado o administrado que implementa la interfase asociada con el tipo de puerto/servicio, tal vez a través de un envolvente especificado como parte de un modelo de programación. En general, y como se describe con mayor detalle más adelante, una diferencia de modelos de programación está en la forma en la que está asociada una conversación con las interfases y métodos en un tipo de servicio. Para la modalidad ilustrada en la Figura 3, los tipos de servicio escritos contra modelos de programación válidos tienen mapas trazados directos entre conversaciones de WSDL, operaciones y mensajes, e interfases de código administrado de tiempo de operación de infraestructura, métodos y tipos de argumento. La infraestructura también puede soportar tipos de servicio creados utilizando diferentes modelos de programación que pueden parecer algo diferentes. Además de las interfases usadas por la representación de servicio asociada, los tipos de servicio pueden implementar otras interfases para engancharse así mismos en otros aspectos del comportamiento de la infraestructura. Por ejemplo, un tipo de servicio puede implementar interfases especiales con el fin de engancharse en algún almacenamiento de servicio o participar en algún comportamiento implementado por una extensión de servicio. Como se describió anteriormente, un caso de servicio 376 típicamente está situado (contiene una referencia a un sitio único de servicio para sí mismo). Los casos de servicio están situados implementando una interfase apropiada o dando de una clase de base que implementa la interfase apropiada. Cuando un unidor de servicio 372 crea un caso de servicio, éste utiliza el almacenamiento de servicio 378 para situar el caso. El almacenamiento de servicio, a su vez, sitúa el caso fijando la propiedad de sitio de servicio en la interfase correspondiente. La propiedad de sitio de servicio proporciona acceso al estado de infraestructura de caso, incluyendo cosas como la colección de canales activos conectados al caso. El caso puede utilizar esta información de estado para adquirir, examinar y modificar su canal. El almacenamiento de servicio, también puede utilizar esta información de estado cuando agrega y remueve canales de los canales activos del caso de servicio a medida que une y separa el canal a y del caso de servicio. Para la modalidad ilustrada en la Figura 3, la infraestructura está diseñada para soportar cualquier modelo de programación que implemente un trazado de mapa directo de los tipos de puerto del WSDL a tipos de clase de código administrado para el tiempo de operación de la estructura. Un modelo de programación ilustrativo utiliza atributos de código administrado para establecer la asociación entre tipos de WSDL y tipos de código administrado. Los modelos de programación de este tipo son clases de código administrado decoradas con atributos que describen la relación entre las clases de código administrado y el contrato de WSDL del tipo de puerto que implementa. Las herramientas que implementan el modelo de programación son capaces tanto de generar WSDL de las clases de código administrado e interfases decoradas con los atributos apropiados, o de generar clases de código administrado e interfases decoradas con los atributos apropiados del WSDL. Otros modelos de programación pueden incluir o modelos de objeto remotos, modelos para describir la secuencia lógica de procedimientos de negocios, etc. El término servicio, por lo tanto, debe ser interpretado ampliamente para cubrir estos y otros modelos de programación. Un modelo de objeto remoto más tradicional, tal como DCOM, puede pensarse que consiste de dos interfaces, una implementada en la representación usada por el cliente del objeto, y la otra implementada en el mismo objeto. Los métodos de una aplicación en estas dos interfases usualmente son idénticos en este tipo de modelo de programación, aunque cada uno puede contener métodos de infraestructura apropiados para uno o el otro lado de la conversación. En contraste, una conversación de WSDL es bidireccional. Sus operaciones son ya sea mensajes individuales o pares de mensajes de solicitud/respuesta que pueden fluir en cualquier dirección como parte de la conversación. Para soportar estas operaciones, el modelo de programación ilustrativo incluye cuatro interfases, dos interfases de implementación de servicio y dos interfases de control de canal. Cada lado de la conversación tiene una interfase de implementación de servicio con un código de correrá en reacción a un mensaje o a una solicitud, y una interfase de control de canal con métodos de representación que enviará mensajes de salida o solicitudes y eventos que pueden ser enganchados para agregarse al procesamiento a mensajes o solicitudes de entrada. Los atributos pueden configurar los detalles del trazado de mapa de los tipos de código administrado a los tipos de WSDL y las calidades de los casos creados para correr el código. Ejemplos de atributos incluyen atributos que determinan el tiempo de vida del caso, tales como si se crea un nuevo caso lógico para cada mensaje/solicitud o si un caso lógico dura mientras se mantiene una conexión. Los atributos pueden especificar si una operación es un mensaje o un par de mensajes de solicitud/respuesta, junto con atributos o códigos, según sea apropiado, para especificar si el método es sincrónico o asincrónico. Otros atributos pueden controlar la relación entre los nombres de métodos y parámetros en los tipos de código administrado y los nombres de operaciones de WSDL, mensajes y partes. Los atributos pueden ser utilizados para controlar el trazado de mapas de llamadas de método a mensajes que consisten de una sola parte que envuelve los argumentos de la llamada del método, o a un mensaje de partes múltiples que consiste de una parte por argumento. Finalmente, los atributos pueden controlar el trazado de mapas del modelo de programación para mensajes de documento/literales o de RPC/cod ificados. También es posible implementar un código que solicite al modelo de programación pasar a lo largo del caso de canal subyacente al caso de servicio, pero esto no tiene efecto en el lenguaje WSDL. La presente invención también puede ser descrita en términos de métodos que comprenden pasos funcionales y/o acciones no funcionales. Lo siguiente es una descripción de acciones y pasos que se pueden realizar para practicar la presente invención. Usualmente, los pasos funcionales describen la invención en términos de resultados que son logrados, mientras que las acciones no funcionales describen acciones más específicas para lograr un resultado particular. Aunque los pasos funcionales y las acciones no funcionales pueden ser descritas o reclamadas en un orden particular, la presente invención no se limita necesariamente a ningún orden particular o combinaciones de acciones y/o pasos. Las Figuras 4A-4B muestran acciones y pasos ilustrativos para métodos de extracción de capas de procesamiento dentro de una infraestructura de envió de mensajes de acuerdo con la presente invención. Un paso de extraer o resumir (420) una o más implementaciones de transporte de mensaje dentro de una capa de mensaje puede incluir una acción de (410) definir una interfase de capa de mensaje que extraiga las implementaciones de transporte de mensaje. Ejemplos de transportaciones de mensaje incluyen TCP 411, HTTP 413, SMTP 415, y otras trasportaciones 417. El puerto 412 es un ejemplo de una extracción de trasporte que proporciona una extracción de en ío/recepción de mensajes atomística para la capa de canal. Un paso para extraer (440) una o más implementaciones de intercambio de mensaje dentro de una capa de canal puede incluir una acción de definir (430) una interfase de capa de canal que extrae una o más implementaciones de intercambio de mensaje. Ejemplos de implementaciones de intercambio de mensaje incluyen datagramas 431, diálogo 433, monólogo 435, cola 437, y otras implementaciones de intercambio 439. Un caso de intercambio de mensaje 430 o un caso de canal es un ejemplo de una extracción de intercambio de mensaje. Un paso para extraer (490) una o más implementaciones de unión dentro de una capa de servicio puede incluir una acción de definir (450) una interfase de capa de servicio que extrae una o más implementaciones de unión que unen una o más implementaciones de intercambio de mensaje a implementaciones de código de usuario o de procesamiento de mensaje. El código de usuario 454 escrito de acuerdo con los modelos de programación 451 opera como casos de procesamiento de mensaje 452. El modelo de programación A, el modelo de programación B, el modelo de programación C, etc., son ejemplos de modelos de programación 451, con un código de usuario A1, código de usuario A2, correspondiente, etc., código de usuario B1, código de usuario B2, etc., código de usuario C1, código de usuario C2, etc., para correr como casos de procesamiento de mensaje 452. Un paso para extraer (490) una o más implementaciones de unión además puede incluir: trazar mapas de (460) tipos de capas de mensaje a tipos de capa de servicio (por ejemplo, WSDL para administrar tipos de código); la unión (470) de casos de un procesamiento de mensaje a casos de intercambio de mensaje (por ejemplo, casos de servicio a casos de canal); y el manejo o administración (480) de el tiempo de vida física de los casos de procesamiento de mensaje (por ejemplo, a través de un almacenamiento de servicio). Las modalidades dentro del alcance de la presente invención también incluyen medios legibles por computadora para llevar o tener instrucciones ejecutables por computadora o estructuras de datos almacenadas en los mismos. Dichos medios legibles por computadora pueden ser cualesquiera medios disponibles que puedan ser accesados por una computadora de propósito general o de propósito especial. A manera de ejemplo, y no de limitación, dichos medios legibles por computadora pueden comprender RAM, ROM, EEPROM, CD-ROM, u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que pueda ser usado para llevar o almacenar medios de código de programa deseados en la forma de instrucciones ejecutables por computadora o estructuras de datos y que puedan se accesados por una computadora de propósito general o de propósito especial. Cuando la información es transferida o provista a través de una red u otra conexión de comunicaciones (ya sea mediante cables, inalámbrica, o una combinación de cables o inalámbrica) a una computadora, la computadora con propiedad de la conexión como un medio legible por computadora. De esta manera, cualquier conexión es apropiadamente denominada como un medio legible por computadora. Las combinaciones de lo anterior también deben ser incluidas dentro del alcance de los medios legibles por computadora. Las instrucciones ejecutables por computadora comprenden, por ejemplo, instrucciones y datos que hacen que una computadora de propósito general computadora de propósito especial, o dispositivos de procesamiento de propósito especial realice cierta función o grupo de funciones. La Figura 5, y la siguiente discusión, están destinadas a proporcionar una breve descripción general de un ambiente de cómputo adecuado en donde la invención puede ser implementada. Aunque no se requiere, la invención será descrita en el contexto general de instrucciones ejecutables por computadora, tales como módulos de programa, que se ejecutan por computadoras en ambientes de red. En general, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc., que realizan tareas particulares o implementan tipos de datos abstractos particulares. Las instrucciones ejecutables por computadora, estructuras de datos asociadas y módulos de programa representan ejemplos de los medios de código de programa para ejecutar los pasos de los métodos aquí descritos. La secuencia particular de dichas instrucciones ejecutables o estructuras de datos asociadas representa ejemplos de acciones correspondientes para implementar las funciones descritas en tales pasos. Aquellos expertos en la técnica apreciarán que la invención puede ser practicada en ambientes de cómputo de red con muchos tipos de configuraciones de sistema de computadora, incluyendo computadoras personales, dispositivos portátiles, sistemas de procesadores múltiples, electrónica de consumidor programable o a base de microprocesador, PCs de red, minicomputadoras, macrocomputadoras, y similares. La invención también puede ser practicada en ambientes de cómputo distribuidos en donde se realizan tareas a través de dispositivos de procesamiento locales y remotos que están enlazados (ya sea a través de enlaces con cables, enlaces inalámbricos, o una combinación de enlaces con cables o inalámbricos) a través de una red de comunicaciones. En un ambiente de cómputo distribuido, los módulos de programa pueden ser localizados en dispositivos de almacenamiento de memoria, tanto locales como remotos. Con referencia a la Figura 5, un sistema ilustrativo para implementar la invención incluye un dispositivo de cómputo de propósito general en la forma de una computadora 520 convencional, que incluye una unidad de procesamiento 521, una memoria de sistema 522, y una barra colectora 523 del sistema que acopla varios componentes del sistema, incluyendo la memoria de sistema 522 a la unidad de procesamiento 521. La barra colectora 523 del sistema puede ser cualquiera de los varios tipos de estructura de barra colectora, incluyendo una barra colectora de memoria o controlador de memoria, una barra colectora periférica, y una barra colectora local utilizando cualquiera de una variedad de arquitecturas de barra colectora. La memoria de sistema incluye memoria de solo lectura (ROM) 524 y memoria de acceso aleatorio (RAM) 525. Un sistema básico de entrada/salida (BIOS) 526, conteniendo las rutinas básicas que ayudan a la transferencia de información entre elementos dentro de la computadora 520, tal como durante el encendido, pueden ser almacenadas en la ROM 524. La computadora 520 también puede incluir una unidad de disco duro magnético 527 para leer de y escribir a un disco duro magnético 539, una unidad de disco magnético 528 para leer de o escribir a un disco magnético removible 529, y una unidad de disco óptico 530 para leer de o escribir a un disco óptico removible 531 tal como un CD-ROM u otros medios ópticos. La unidad de disco duro magnético 527, unidad de disco magnético 528 y unidad de disco óptico 530 están conectas a la barra colectora 523 del sistema a través de una inferíase de unidad de disco duro 532, una inferíase de unidad de disco magnético 533 y una interfase de unidad óptica 534, respectivamente. Las unidades y sus medios legibles por computadora asociados proporcionan el almacenamiento no volátil de instrucciones ejecutables por computadora, estructuras de datos, módulos de programa, y otros datos para la computadora 520. Aunque el ambiente ilustrativo descrito aquí emplea un disco duro magnético 539, un disco magnético removible 529 y un disco óptico removible 531, se pueden utilizar otros tipos de medios legibles por computadora para almacenar datos, incluyendo casetes magnéticos, tarjetas de memoria flash, discos versátiles digitales, cartuchos de Bernoulli, RAMs, ROMs, y similares. Los medios de código de programa que comprenden uno o más módulos de programa pueden ser almacenados en el disco duro 539, disco magnético 529, disco óptico 531, ROM 524 o RAM 525, incluyendo un sistema operativo 535, uno o más programas de aplicación 536, otros módulos de programa 537 y datos de programa 538. Un usuario puede introducir comandos e información a la computadora 520 a través del teclado 540, dispositivo de señalamiento 542 u otros dispositivos de entrada (no mostrado), tales como un micrófono, palanca de juegos, almohadilla de juegos, antena de satélite, explorador, o similares. Estos y otros dispositivos de entrada por lo regular están conectados a la unidad de procesamiento 521 a través de una interfase de puerto en serie 546 acoplada a la barra colectora 523 del sistema. Alternativamente, los dispositivos de entrada pueden ser conectados a través de otras interfases, tales como un puerto paralelo, un puerto de juegos, o una barra colectora en serie universal (USB). Un monitor 47 u otro dispositivo de presentación también está conectado a la barra colectora 523 del sistema a través de una interfase, tal como un adaptador de vídeo 548. Además del monitor, las computadoras personales típicamente incluyen otros dispositivos de salida periféricos (no mostrados), tales como bocinas e impresoras. La computadora 520 puede operar en un ambiente en red utilizando conexiones lógicas a una o más computadoras remotas, tales como las computadoras remotas 549a y 549b. Las computadoras remotas 549a y 549b cada una puede ser otra computadora personal, un servidor, un enrutador, una PC de red, un dispositivo de par en par u otro nodo de red común, y típicamente incluyen muchos o todos los elementos descritos anteriormente con relación a la computadora 520, aunque solamente los dispositivos de almacenamiento de memoria 550a y 550b y sus programas de aplicación asociados 536a y 536b han sido ilustrados en la Figura 5. Las conexiones lógicas ilustradas en la Figura 5 incluyen una red de área local (LAN) 551 y una red de área amplia (WAN) 552 que están presentadas aquí a manera de ejemplo y no de limitación. Dichos ambientes en red son lugares comunes en oficinas o redes de computadora en empresas, intranets e Internet. Cuando se utiliza en un ambiente en red de LAN, la computadora 520 está conectada a la red local 551 a través de una interfase o adaptador de red 553. Cuando se utiliza en un ambiente en red de WAN, la computadora 520 puede incluir un módem 554, un enlace inalámbrico, u otros medios para establecer comunicaciones a través de la red de área amplia 552, tal como el Internet. El módem 554, el cual puede ser interno o externo, está conectado a la barra colectora 523 del sistema a través de la interfase de puerto en serie 546. En un ambiente en red, los módulos de programa ¡lustrados con relación a la computadora 520, o sus porciones, pueden ser almacenados en el dispositivo de almacenamiento de memoria remota. Se apreciará que las conexiones de red mostradas son ilustrativas y se pueden utilizar otros medios para establecer comunicaciones a través de la red de área amplia 552. La presente invención puede ser modalizada en otras formas específicas sin apartarse de su espíritu o características esenciales. Las modalidades descritas deben ser consideradas en todos los aspectos solo como ilustrativas y no restrictivas. El alcance de la invención, por lo tanto, está indicado por las reivindicaciones anexas en lugar de por la descripción anterior. Todos los cambios que queden dentro del significado y escala de equivalencia de las reivindicaciones están abarcados dentro de su alcance.

Claims (37)

REIVINDICACIONES

1.- Un producto de programa de computadora que implementa una infraestructura de envío de mensajes, la cual extrae varias capas de procesamiento dentro de la infraestructura, en donde la infraestructura proporciona un nivel base de funcionalidad de envío de mensajes, y en donde las capas de procesamiento de extracción son extensibles de manera que se pueden hacer cambios o mejoras sin necesariamente tener que volver a implementar el nivel base de la funcionalidad de envíos de mensaje provista en otras capas de procesamiento de extracción, el producto de programa de computadora comprende uno o más medios legibles por computadora que llevan instrucciones ejecutables por computadora en la forma de módulos de programa, los módulos de programa comprendiendo: uno o más módulos de capa de envío de mensajes proporcionando la transmisión de punto extremo a punto extremo de uno o más mensajes e implementando soporte para uno o más protocolos de transporte de mensaje; uno o más módulos de capa de canal proporcionando la semántica de intercambio de mensaje en la parte superior de uno o más módulos de capa de mensaje; y uno o más módulos de capa de servicio proporcionando uno o más modelos de programación sobre la parte superior de uno o más módulos de capa de canal para interactuar con la infraestructura de envío de mensajes exponiendo uno o más aspectos de la infraestructura de envío de mensajes que serán analizados por el software (programas, instrucciones, etc.) diseñado para utilizar la infraestructura de envío de mensajes.

2.- Un producto de programa de computadora de acuerdo con la reivindicación 1, en donde uno o más protocolos de transporte de mensaje comprende por lo menos uno de conductos nombrados, protocolo de control de transmisión (TCP), protocolo de transferencia de hipertexto (HTTP), y protocolo de transferencia de correo simple (SMTP).

3.- Un producto de programa de computadora de acuerdo con la reivindicación 1, en donde uno o más módulos de capa de envío de mensaje permite la intercepción de mensajes a medida que un mensaje sale o llega a un punto extremo.

4. - Un producto de programa de computadora de acuerdo con la reivindicación 3, en donde uno o más módulos de capa de envío de mensaje implementa el comportamiento que comprende por lo menos uno de enrutamiento, filtración, administración de política, introducción, transacciones y seguridad.

5. - Un producto de programa de computadora de acuerdo con la reivindicación 1, en donde uno o más módulos de capa de canal implementan por lo menos uno de (i) un canal de datagramas para el envío de mensajes no correlacionados unidireccionales, (ii) un canal de diálogo para el envío de mensajes correlacionados bidireccionales, (iii) un canal de monólogo para el envío de mensajes de difusión unidireccionales, incluyendo el envío de mensajes de publicación/suscripción, y (iv) un canal de cola para el envío de mensajes en cola unidireccionales.

6.- Un producto de programa de computadora de acuerdo con la reivindicación 1, en donde uno o más módulos de capa de servicio que proporcionan uno o más modelos de programación en la parte superior de uno o más módulos de capa de canal implementa un trazado de mapa directo entre uno o más tipos de puerto de lenguaje de descripción de servicios de web (WSDL) y uno o más tipos manejados dentro de la infraestructura de envío de mensajes.

7.- Un producto de programa de computadora de acuerdo con la reivindicación 1, en donde uno o más módulos de capa de envío de mensajes comprende un puerto que proporciona una extracción de envío/recepción de mensajes atomística para uno o más modelos de capa de canal.

8.- Un producto de programa de computadora de acuerdo con la reivindicación 1, en donde uno o más módulos de capa de canal comprende un administrador de canal que reúne y correlaciona mensajes y presenta una extracción de nivel más alto a uno o más módulos de capa de servicio.

9.- Un producto de programa de computadora de acuerdo con la reivindicación 1, en donde uno o más módulos de capa de servicio comprenden un administrador de servicio que coordina la infraestructura de envío de mensajes estableciendo una o más conexiones entre por lo menos uno o más módulos de capa de servicio y por lo menos uno del uno o más módulos de capa de canal.

10.- Un producto de programa de computadora de acuerdo con la reivindicación 9, en donde el administrador de servicio soporta la capacidad de extensión delegando una o más tareas a otros módulos dentro de la infraestructura para una o más tareas.

11.- Un producto de programa de computadora de acuerdo con la reivindicación 9, en donde el uno o más módulos de capa de programa comprende uno o más casos de canal, y en donde el uno o más módulos de capa de servicio comprende uno o más unidores de servicio, uno o más casos de servicio, y una o más representaciones de servicio que unen el uno o más casos de canal a uno o más casos de servicio.

12. - Un producto de programa de computadora de acuerdo con la reivindicación 11, en donde el uno o más casos de servicio representan uno o más casos de código de usuario para interactuar con la infraestructura de envío de mensajes, el uno o más casos de canal representa uno o más casos de uno o más canales para manejar uno o más mensajes de un tipo particular ya sea destinado para o que se origina de uno o más casos de servicio, y el uno o más unidores de servicio manejan como uno o más casos de servicio y uno o más casos de canal se relacionen y se comunican entre si a través de una o más representaciones de servicio.

13. - Un producto de programa de computadora de acuerdo con la reivindicación 12, en donde uno o más módulos de capa de servicio comprende (i) un almacenamiento de servicio que maneja el tiempo de vida física para uno o más casos de servicio, y (¡i) una o más extensiones de servicio que interceptan uno o más mensajes que fluyen hacia y fuera de uno o más casos de servicio, en donde una o más extensiones de servicio ¡mplementan el comportamiento comprendiendo por lo menos uno de enrutamiento, filtración, manejo de política y seguridad.

14.- En una infraestructura de envío de mensajes que comprende una pluralidad de capas de procesamiento proporcionando cierta funcionalidad inicial para el procesamiento de uno o más mensajes, un método para extraer la pluralidad de capas de procesamiento dentro de la infraestructura de envío de mensajes, de manera que se pueden hacer cambios o mejoras subsecuentes a la infraestructura de envío de mensajes, mientras se retiene cierta funcionalidad inicial, el método comprende las acciones de: definir una interfase de capa de mensaje que extrae una o más implementaciones del transporte de mensaje para una o más capas superiores dentro de la infraestructura de envío de mensajes; definir una interfase de capa de canal en la parte superior de la interfase de capa de mensaje, en donde la interfase de capa de canal extrae una o más implementaciones de intercambio de mensaje para una o más capas superiores dentro de la infraestructura de envío de mensaje; y definir una interfase de capa de servicio sobre la parte superior de la interfase de capa de canal, en donde la interfase de capa de servicio extrae una o más implementaciones de unión que unen una o más implementaciones de intercambio de mensaje, a través de la interfase de capa de canal, al código de usuario para una o más implementaciones de procesamiento de mensaje desarrolladas en la parte superior de la infraestructura de envío de mensajes.

15. - Un método de acuerdo con la reivindicación 14, en donde la interfase de capa de servicio, por lo menos en parte, describe un modelo de programación para utilizar la infraestructura de envío de mensajes.

16. - Un método de acuerdo con la reivindicación 14, en donde el modelo de programación especifica un trazado de mapa entre uno o más tipos de puerto de lenguaje de descripción de servicios web (WSDL) y uno o más tipos manejados dentro de la infraestructura de envío de mensajes.

17. - Un método de acuerdo con la reivindicación 14, en donde la interfase de capa de mensajes, la interfase de capa de canal y la interfase de capa de servicio cada una corresponde a una pluralidad de módulos de programa para una o más implementaciones de transporte de mensaje, la una o más implementaciones de intercambio de mensaje, y la una o más implementaciones de unión.

18. - Un método de acuerdo con la reivindicación 14, en donde uno o más protocolos de transporte de mensaje comprende por lo menos uno de conductos nombrados, protocolo de control de transmisión (TCP), protocolo de transferencia de hipertexto (HTTP), y protocolo de transferencia de correo simple (SMTP).

19. - Un método de acuerdo con la reivindicación 14, en donde una o más implementaciones de intercambio de mensaje comprende por lo merios uno de (i) un canal de datagrama para el envío de mensajes no correlacionados unidireccionales, (¡i) un canal de diálogo para el envío de mensajes correlacionados bidireccionales, (iii) un canal monólogo para el envío de mensajes de difusión unidireccional, incluyendo el envío de mensajes de publicación/suscripción, y (ív) un canal de cola para el envío de mensajes en cola unidireccionales.

20. - Un método de acuerdo con la reivindicación 14, en donde la interfase de capa de mensajes además extrae uno o más puertos, cada uno proporcionando una extracción de envío/recepción mensaje atomística.

21. - Un método de acuerdo con la reivindicación 14, en donde una o más implementaciones de unión comprende una o más implementaciones de unidor de servicio que realizan la unión de una o más implementaciones de intercambio de mensaje para una o más implementaciones de procesamiento de mensaje desarrolladas sobre la parte superior de la infraestructura de envío de mensajes.

22. - Un método de acuerdo con la reivindicación 21, en donde la una o más implementaciones de unidor de servicio utilizan una o más implementaciones de representación de servicio para realizar la unión de las una o más implementaciones de intercambio de mensaje a las una o más implementaciones de procesamiento de mensaje desarrolladas en la parte superior de la infraestructura de envío de mensajes .

23.- Un método de acuerdo con la reivindicación 22, en donde la infraestructura de envío de mensajes comprende uno o más casos de una o más implementaciones de intercambio de mensaje y uno o más casos de una o más implementaciones de procesamiento de mensaje, y en donde un caso de representación de servicios separado une cada uno de los casos de intercambio de mensaje a un caso de procesamiento de mensaje correspondiente.

24. - Un método de acuerdo con la reivindicación 23, en donde la inferíase de capa de servicio extrae una implementación de almacenamiento de servicio que maneja el tiempo de vida físico para uno o más casos de procesamiento de mensaje.

25. - Para instrucciones de envío de mensajes que comprende una pluralidad de capas de procesamiento proporcionando cierta funcionalidad inicial para el procesamiento de uno o más mensajes, un producto de programa de computadora que comprende uno o más medios legibles por computadora que llevan instrucciones ejecutables por computadora que ¡mplementan un método para extraer la pluralidad de capas de procesamiento dentro de la infraestructura de envío de mensajes, de manera que se pueden hacer cambios o mejoras subsecuentes a la infraestructura de envío de mensajes, mientras se retiene cierta funcionalidad inicial, el método comprende las acciones de: definir una interfase de capa de mensaje que extrae una o más implementaciones del transporte de mensaje para una o más capas superiores dentro de la infraestructura de envío de mensajes; definir una interfase de capa de canal en la parte superior de la interfase de capa de mensaje, en donde la interfase de capa de canal extrae una o más implementaciones de intercambio de mensaje para una o más capas superiores dentro de la infraestructura de envío de mensaje; y definir una interfase de capa de servicio sobre la parte superior de la interfase de capa de canal, en donde la interfase de capa de servicio extrae una o más implementaciones de unión que unen una o más implementaciones de intercambio de mensaje, a través de la interfase de capa de canal, al código de usuario para una o más implementaciones de procesamiento de mensaje desarrolladas en la parte superior de la infraestructura de envío de mensajes.

26. - Un producto de programa de computadora de acuerdo con la reivindicación 25, en donde la interfase de capa de servicio, por lo menos en parte, describe un modelo de programación para utilizar la infraestructura de envío de mensajes.

27. - Un producto de programa de computadora de acuerdo con la reivindicación 25, en donde la interfase de capa de mensajes, la interfase de capa de canal y la interfase de capa de servicio cada una corresponde a una pluralidad de módulos de programa para una o más implementaciones de transporte de mensaje, la una o más implementaciones de intercambio de mensaje, y la una o más implementaciones de unión.

28. - Un producto de programa de computadora de acuerdo con la reivindicación 25, uno o más protocolos de transporte de mensaje comprende por lo menos uno de conductos nombrados, protocolo de control de transmisión (TCP), protocolo de transferencia de hipertexto (HTTP), y protocolo de transferencia de correo simple (SMTP).

29. - Un producto de programa de computadora de acuerdo con la reivindicación 25, en donde una o más implementaciones de intercambio de mensaje comprende por lo menos uno de (i) un canal de datagramas para el envío de mensajes no correlacionados unidireccionales, (ii) un canal de diálogo para el envío de mensajes correlacionados bidireccionales, (iii) un canal monólogo para el envío de mensajes de difusión unidireccional, incluyendo el envío de mensajes de publicación/suscripción, y (iv) un canal de cola para el envío de mensajes en cola unidireccionales.

30. - Un producto de programa de computadora de acuerdo con la reivindicación 25, en donde la interfase de capa de mensajes además extrae uno o más puertos, cada uno proporcionando una extracción de envío/recepción mensaje atomística.

31. - Un producto de programa de computadora de acuerdo con la reivindicación 25, en donde una o más implementaciones de unión comprende una o más implementaciones de unidor de servicio que realizan la unión de una o más implementaciones de intercambio de mensaje para una o más implementaciones de procesamiento de mensaje desarrolladas sobre la parte superior de la infraestructura de envío de mensajes.

32. - Un producto de programa de computadora de acuerdo con la reivindicación 25, en donde la una o más implementaciones de unidor de servicio utilizan una o más implementacíones de representación de servicio para realizar la unión de las una o más implementacíones de intercambio de mensaje a las una o más implementacíones de procesamiento de mensaje desarrolladas en la parte superior de la infraestructura de envío de mensajes.

33. - Un producto de programa de computadora de acuerdo con la reivindicación 32, en donde la infraestructura de envío de mensajes comprende uno o más casos de una o más implementacíones de intercambio de mensaje y uno o más casos de una o más implementacíones de procesamiento de mensaje, y en donde un caso de representación de servicio por separado une cada uno de los uno o más casos de intercambio de mensaje a un caso de procesamiento de mensaje correspondiente, en donde la ¡nterfase de capa de servicio extrae una implementación de almacenamiento de servicio que maneja el tiempo de vida física para uno o más casos de procesamiento de mensaje.

34. - En una infraestructura de mensaje que comprende una pluralidad de capas de procesamiento proporcionando cierta funcionalidad para procesar uno o más mensajes, un método para extraer la capas de procesamiento dentro de la infraestructura de envío de mensajes, de manera que se pueden hacer cambios o mejoras subsecuentes a la infraestructura de envío de mensajes mientras se tiene cierta funcionalidad inicial, el método comprende pasos para: dentro de una capa de mensaje, extraer una o más implementaciones de transporte de mensaje para usarse en una o más de otras capas dentro de la infraestructura de envío de mensajes; dentro de una capa de canal por arriba de la capa de mensaje, extraer una o más implementaciones de intercambio de mensaje para usarse en una o más de otras capas dentro de la infraestructura de envió de mensajes; y dentro de una capa de servicio por arriba de la capa de canal, extraer una o más implementaciones de unión para unir la una o más implementaciones de intercambio de mensaje al código de usuario que corresponde a una o más implementaciones de procesamiento de mensaje que utilizan la infraestructura de envío de mensaje.

35. - Un método de acuerdo con la rei indicación 34, en donde la interfase de capa de servicio, por lo menos en parte, describe un modelo de programación para utilizar la infraestructura de envío de mensajes.

36. - Un método de acuerdo con la reivindicación 34, en donde la extracción de capa de mensaje, la extracción de capa de canal y la extracción de capa de servicio corresponden a una pluralidad de módulos de programa para las una o más implementaciones de transporte de mensajes, la una o más implementación de intercambio de mensajes, y la una o más implementaciones de unión.

37. - Un método de acuerdo con la reivindicación 34, en donde la extracción de capa de mensajes además extrae uno o más puertos, cada uno proporcionando una extracción de envío/recepción de mensaje atomística. 38 - Un método de acuerdo con la reivindicación 37, en donde la infraestructura de envío de mensajes comprende uno o más casos de las una o más ¡mplementaciones intercambio de mensaje y uno o más casos de las una o más ¡mplementaciones de procesamiento de mensaje, y en donde una o más ¡mplementaciones de unión comprende una o más ¡mplementaciones de unidor de servicio que utilizan uno o más casos de representación de servicio para unir cada caso de intercambio de mensaje a un caso de procesamiento de mensaje correspondiente. 39.- Un método de acuerdo con la reivindicación 38, en donde la extracción de capa de servicios además extrae una implementacion de almacenamiento de servicio que maneja el tiempo de vida físico para uno o más casos de procesamiento de mensaje. 40.- Un método de acuerdo con la reivindicación 39, en donde uno o más protocolos de transporte de mensaje comprende por lo menos uno de conductos nombrados, protocolo de control de transmisión (TCP), protocolo de transferencia de hipertexto (HTTP), y protocolo de transferencia de correo simple (SMTP). 41.- Un método de acuerdo con la reivindicación 40, en donde una o más ¡mplementaciones de intercambio de mensaje comprende por lo menos uno de (i) un canal de datagramas para el envío de mensajes no correlacionados unidireccionales, (ii) un canal de diálogo para el envío de mensajes correlacionados bidireccionales, (iii) un canal monólogo para el envío de mensajes de difusión unidireccional, incluyendo el envío de mensajes de publicación/suscripción, y (iv) un canal de cola para el envío de mensajes en cola unidireccionales. 42.- Para una infraestructura de envío de mensajes que comprende una pluralidad de capas de procesamiento proporcionando cierta funcionalidad inicial para el procesamiento de uno o más mensajes, un producto de programa de computadora que comprende uno o más medios legibles por computadora que llevan instrucciones ejecutables por computadora que implementan un método para extraer la pluralidad de capas de procesamiento dentro de la infraestructura de envío de mensajes, de manera que se pueden hacer cambios o mejoras subsecuentes a la infraestructura de envío de mensajes mientras se retiene cierta funcionalidad inicial, el método comprende los pasos para: dentro de una capa de mensaje, extraer una o más implementaciones de transporte de mensaje para usarse en una o más de otras capas dentro de la infraestructura de envío de mensajes; dentro de una capa de canal por arriba de la capa de mensaje, extraer una o más implementaciones de intercambio de mensaje para usarse en una o más de otras capas dentro de la infraestructura de envió de mensajes; y dentro de una capa de servicio por arriba de la capa de canal, extraer una o más implementaciones de unión para unir la una o más implementaciones de intercambio de mensaje al código de usuario que corresponde a una o más implementaciones de procesamiento de mensaje que utilizan la infraestructura de envío de mensaje. 43. - Un producto de programa de computadora de acuerdo con la reivindicación 42, en donde la interfase de capa de servicio, por lo menos en parte, describe un modelo de programación para usar la infraestructura de envío de mensajes. 44. - Un producto de programa de computadora de acuerdo con la reivindicación 42, en donde la extracción de capa de mensaje, la extracción de capa de canal y la extracción de capa de servicio corresponden a una pluralidad de módulos de programa para una o más implementaciones de transporte de mensaje, una o más implementaciones de intercambio de mensaje, y una o más implementaciones de unión. 45. - Un producto de programa de computadora de acuerdo con la reivindicación 42, en donde la extracción de capa de mensajes además extrae uno o más puertos, cada uno proporcionando una extracción de envío/recepción de mensaje atomística. 46. - Un producto de programa de computadora de acuerdo con la reivindicación 45, en donde la infraestructura de envío de mensajes comprende uno o más casos de las una o más implementaciones de intercambio de mensaje y uno o más casos de la una o más implementaciones de procesamiento de mensaje, y en donde una o más implementaciones de unión comprenden una o más implementaciones de unidor de servicio que utilizan uno o más casos de representación de servicio para unir cada caso de intercambio de mensaje a un caso de procesamiento de mensaje correspondiente. 47. - Un producto de programa de computadora de acuerdo con la reivindicación 46, en donde la extracción de capa de servicios además extrae una implementación de almacenamiento de servicio que maneja el tiempo de vida físico para uno o más casos de procesamiento de mensaje. 48. - Un producto de programa de computadora método de acuerdo con la reivindicación 47, en donde uno o más protocolos de transporte de mensaje comprende por lo menos uno de conductos nombrados, protocolo de control de transmisión (TCP), protocolo de transferencia de hipertexto (HTTP), y protocolo de transferencia de correo simple (SMTP). 49. - Un producto de programa de computadora de acuerdo con la reivindicación 42, en donde una o más implementaciones de intercambio de mensaje comprende por lo menos uno de (i) un canal de datagrama para el envío de mensajes no correlacionados unidireccionales, (ii) un canal de diálogo para el envío de mensajes correlacionados bidireccionales, (iii) un canal monólogo para el envío de mensajes de difusión unidireccional, incluyendo envío de' publicación/suscripción, y (iv) un canal de cola para en envío de mensajes en cola unidireccional.