TRANSMISIÓN A GRANEL DE MENSAJES MEDIANTE EL USO DE U NA SOLA SOLICITUD HTTP
ANTEC EDENTES DE LA INVENCIÓN 1 . El Campo de la I nvención La presente invención se refiere en general a transferencia de mensajes entre sistemas de cómputo mediante el uso de una comunicación de tipo solicitud-respuesta HTTP. Más específicamente, la presente invención proporciona la transferencia de una respuesta HTTP entre puntos extremos como una pluralidad de porciones diferentes con objeto de conservar recursos valiosos de sistema asociados con la validación y autorización de una solicitud HTTP correspondiente y para proporcionar comunicación de dos vías a un solicitante en ambientes donde eso no puede ser posible de otro modo.
2. Antecedentes y Materia Relacionada Las redes de computadora han mejorado nuestra habilidad de comunicación y acceso a la información al permitir que una computadora o dispositivo (en la presente referida en lo posterior como "sistema de cómputo") se comunique sobre una res con otro sistema de cómputo mediante el uso de mensajes electrónicos. Cuando se transfiere un mensaje electrónico entre sistemas de cómputo, el mensaje electrónico con frecuencia pasará a través de una pila de protocolo que lleva a cabo operaciones sobre los datos dentro del mensaje electrónico (por ejemplo, empaque, enrutamiento, control de flujo, etc.). El modelo de Interconexión de Sistema Abierto (OSI) es un ejemplo de una estructura de red para implementar tal pila de protocolo. El modelo OSI fractura las operaciones de transferencia de un mensaje electrónico en diversos "estratos" distintos, designado cada uno para llevar a cabo ciertas operaciones en el proceso de transferencia de datos. Aunque las pilas de protocolo pueden implementar potencialmente cada uno de los estratos, muchas pilas de protocolo implementan solo estratos selectivos para utilizarse en la transferencia de datos a través de una red. Por ejemplo, cuando los datos se transmiten desde un sistema de cómputo, se origina en el estrato de aplicación y se pasa hacia abajo a los estratos inferiores intermedios y después sobre una red. Cuando los datos se reciben en un dispositivo de cómputo de una red, entran al estrato físico y se pasan hacía arriba a estratos intermedios mayores y después se reciben eventualmente en el estrato de aplicación. El estrato de aplicación, el estrato más superior, es responsable de soportar aplicaciones y procesos de usuario final. Otro estrato incorporado por la mayoría de las pilas de protocolo es el estrato de transporte. Un ejemplo de un estrato de transporte es el Protocolo de Control de Transmisión (TCP). En un sistema distribuido (por ejemplo, un ambiente de Servicios en Red), los servicios y solicitudes de servicios se transportan frecuentemente mediante el uso de (HTTP). El Protocolo de Transferencia de HiperTexto opera entre el estrato de aplicación y otros estratos inferiores del modelo OSI a fin de facilitar la transferencia de contenido en un ambiente de sistema distribuido. Como la mayoría de los protocolos en red, HTTP utiliza el modelo de cliente-servidor. Más particularmente, un sistema de computadora cliente (en la presente referido en lo posterior como un punto extremo "cliente" o "demandante") abre una conexión y envía un mensaje de solicitud sobre un flujo de demandas a un servidor (en la presente referido en lo posterior como un punto extremo de "servidor" o "de servicio"). El servidor regresa entonces un mensaje de respuesta que normalmente contiene el recurso que fue solicitado (por ejemplo, un archivo, un resultado de consulta generado de manera dinámica, u otro conjunto de datos similar) sobre un flujo de respuestas de la comunicación HTTP. Después de proporcionar la respuesta, el servidor cierra la conexión; haciendo del HTTP un protocolo sin declaración, es decir, que no mantiene ninguna información de conexión entre las transacciones. Debido a que HTTP es un protocolo sin declaración, la autenticación de HTTP no soporta el concepto de una sesión - donde un usuario se conectaría y/o desconectaría. De acuerdo con lo anterior, cada solicitud de acceso al contenido que se transporta a través de HTTP (es decir, una solicitud HTTP) debe incluir información de autenticación de HTTP adecuada. Por lo tanto, existe una tremenda cantidad de saturación asociada con el procesamiento de la información de autenticación y validación del cliente para cada solicitud recibida en un punto extremo de servicio. Por ejemplo, típicamente el protocolo de HTTP proporciona información de autenticación por suministrarse con cada solicitud de HTTP a través de un encabezado especial, el cual se encuentra típicamente en el formato de un tipo de autenticación y credenciales. La manera como el cliente obtiene y transmite estas credenciales es la siguiente. La primera vez que un cliente intenta tener acceso a un sitio en red u otro de tales servicios que requieren de autenticación, el servicio típicamente se negará a proporcionar el contenido o la información solicitados y regresará al cliente un mensaje de error de HTTP (por ejemplo, un mensaje no autorizado) así como también cierta forma de obstáculo. Cuando el cliente recibe este mensaje, necesitará responder de manera adecuada al reto mediante el uso de las credenciales adecuadas con objeto de tener acceso a los recursos de servicio. Por ejemplo, el cliente, después de recibir el reto puede presentar a un usuario una caja de diálogo de despliegue que solicita un nombre de usuario y/o contraseña. De manera alternativa, o en conjunto, el reto puede requerir cierto tipo de credencial , como un distintivo, por ejemplo, un X.509, Kerberos u otro(s) distintivo(s) similar(es). Además, también pueden ser aplicables otros tipos de retos. Sin tomar en consideración el tipo de reto, después de que el usuario (o el cliente, como puede ser el caso) proporciona las credenciales adecuadas (por ejemplo, mediante mecanografía en una contraseña correcta), el cliente puede transmitir la solicitud original de HTTP al servidor; pero puede agregar el encabezado de autorización que incluye ahora las credenciales como un argumento de la etiqueta del encabezado. Si el servicio acepta las credenciales incluidas y regresa contenido válido, el cliente típicamente g uarda estas credenciales y las retransmite con cada nueva solicitud al mismo servicio o servicio derivado, asociado con el mismo contenido. Durante grandes transferencias de archivos o solicitudes que toman relativamente mucho tiempo de procesar (por ejemplo, un proceso de préstamo) , se hacen varias solicitudes con objeto de transferir el archivo o entero o de procesar toda la solicitud. Esto se debe en gran parte a la naturaleza de HTTP, en donde los clientes se consideran no dirigibles ya que no se les puede enviar datos sin enviarlos a través de un flujo de respuesta correspondiente a la solicitud. De acuerdo con lo anterior, para archivos grandes y solicitudes totales que toman tiempo para procesar, el cliente debe enviar continuamente solicitudes que incluyen la información de autenticación; y el servicio debe procesar continuamente tales credenciales de autenticación y reg resar las porciones adecuadas de la solicitud total a medida que se vuelven disponibles. Esta continua autenticación y proceso de validación para cada solicitud consume los valiosos recursos del sistema que podrían utilizarse de otro modo (por ejemplo, en el procesamiento de la respuesta total) . De manera similar, el procesamiento de solicitudes continuas, asociadas con la rig idez de muros contrafuego también consume valiosos recursos del sistema. Por lo tanto, existe una necesidad de ser capaz de mantener el flujo de respuesta de una comunicación HTTP abierta con objeto de enviar porciones de una respuesta total a un cliente a medida que se vuelve disponible. En otras palabras, existe una necesidad de ser capaz de recibir/enviar múltiples porciones de una respuesta total sin tener que recibir/enviar varias solicitudes para tales porciones.
BREVE DESCRIPCIÓN DE LA INVENCIÓN Las deficiencias y desventajas arriba identificadas de las actuales comunicaciones de tipo solicitud-respuesta HTTP se superan por las modalidades ejemplares de la presente invención. Por ejemplo, la presente invención proporciona la transferencia de una respuesta HTTP como una pluralidad de diferentes porciones con objeto de conservar valiosos recursos de sistema asociados con la validación y una solicitud HTTP correspondiente. Las modalidades ejemplares proporcionan el envío de un mensaje de solicitud sobre un flujo de solicitud HTTP para establecer una comunicación entre puntos extremos en un sistema distribuido. Una primer porción de una respuesta se recibe sobre un flujo de respuesta HTTP correspondiente en un primer periodo de tiempo. El flujo de respuesta HTTP se mantiene entonces abierto con objeto de recibir porciones adicionales de la respuesta. Sin enviar otro mensaje de solicitud, una segunda porción de la respuesta se recibe sobre el flujo de respuesta HTTP en un segundo periodo de tiempo, diferente del primer periodo de tiempo.
Otras modalidades ejemplares proporcionan la recepción de un mensaje de solicitud sobre un flujo de solicitud HTTP para establecer una comunicación entre puntos extremos en un sistema distribuido. Una primer porción de una respuesta se recibe sobre un flujo de respuesta HTTP correspondiente en un primer periodo de tiempo. Sin recibir otro mensaje de solicitud, una segunda porción de la respuesta se envía sobre el flujo de respuesta HTTP en un segundo periodo de tiempo, diferente del primer periodo de tiempo. Las características y ventajas adicionales de la invención se establecerán en la descripción que sigue y, en parte, serán obvias a partir de la descripción, o pueden aprenderse por la práctica de la invención. Las características y ventajas de la invención pueden llevarse a la práctica 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 más completamente aparentes a partir de la siguiente descripción y reivindicaciones anexas, o pueden aprenderse mediante la práctica de la invención, según se establece en la presente a continuación.
BREVE DESCRIPCIÓN DE LOS DIBUJOS Con objeto de describir la manera en la cual las ventajas y características de la invención arriba citadas y otras pueden obtenerse, una descripción más particular de la invención brevemente descrita con anterioridad se dará mediante referencia a modalidades específicas de la misma, las cuales se ilustran en los dibujos anexos. Entendiendo que estos dibujos ilustran solamente modalidades típicas de la invención y, por consiguiente, no deben considerarse limitantes de su alcance, la invención será descrita y explicada sin especificidad y detalle adicionales a través del uso de los dibujos acompañantes, en los cuales: La Figura 1A ilustra un patrón de intercambio de mensajes que utilizan un flujo de respuesta HTTP extendido de acuerdo con modalidades ejemplares de la presente invención; La Figura 1 B ilustra una sesión de comunicación de dos vías entre puntos extremos en un sistema distribuido mediante el uso de dos flujos de respuesta HTTP extendidos, de acuerdo con las modalidades ejemplares de la presente invención; La Figura 2 y la Figura 3 ilustran diagramas de flujo ejemplares para la transferencia de una respuesta HTTP como una pluralidad de diferentes porciones de acuerdo con modalidades ejemplares de la presente invención; y La Figura 4 ilustra un sistema ejemplar que proporciona un ambiente operativo adecuado para la presente invención.
DESCRIPCIÓN DETALLADA DE LAS MODALIDADES PREFERIDAS La presente invención se extiende a métodos, sistemas y productos de programas de computadora para la transferencia de una respuesta HTTP entre puntos extremos como una pluralidad de diferentes porciones con objeto de conservar valiosos recursos del sistema. Las modalidades de la presente invención pueden comprender una computadora de propósito especial o de propósito general, que incluya diverso hardware de computadora, según se disquete en mayor detalle a continuación. La presente invención proporciona el mantenimiento de un flujo de respuesta HTTP para una comunicación abierta, de tal manera que mensajes o porciones de una respuesta total puedan enviarse a través del flujo de respuesta HTTP. A medida que las diversas porciones de la respuesta total se vuelven disponibles en un punto extremo de servicio correspondiente, el servicio encapsula de manera adecuada los mensajes y los envía al punto extremo de solicitud. La encapsulación será típicamente privada para cada servicio y sus detalles específicos no son núcleo de esta invención. No obstante, lo que es aquí importante es una manera acordada en la cual leer una fracción o porción de una respuesta y determinar los límites de los mensajes encapsulados. De acuerdo con lo anterior, como resultado de una solicitud, la respuesta es, de hecho, una corriente de porciones de una respuesta total, cada una de las cuales viene como una fracción de la solicitud total. El recipiente o punto extremo demandante de la respuesta es entonces capaz de leer las porciones disponibles de la respuesta y decodifica adecuadamente las porciones incrustadas y es libre de procesarlas según lo adecuado. De acuerdo con lo anterior, aún cuando no se haya recibido la respuesta HTTP completa, el punto extremo demandante puede comenzara a trabajar en base a cada una de las porciones incrustadas o los mensajes que ha recibido. Además, debido a que solo se hace una solicitud para varias porciones de un valioso recurso de sistema de respuesta, los recursos se reservan solo para requerir una autenticación y/o validación de un punto extremo de demanda. La Figura 1A ilustra algunas de las modalidades ventajosas arriba descritas. Como puede verse, un sistema distribuido 100 incluye un punto extremo demandante 165 y un punto extremo de servicio 145 que puede incluir varios módulos de servicio 147, 150, 155, 160. En una modalidad, el punto extremo demandante 165 envía un mensaje de solicitud 1 15 sobre un flujo de solicitudes HTTP 120 con objeto de establecer una comunicación con el punto extremo de servicio 145. El mensaje de solicitud 1 15 típicamente incluirá las credenciales adecuadas con objeto de autentificar el punto extremo demandante 1 65. Además, también se encuentran disponibles otras maneras de autentificación para la presente invención. Por ejemplo, el punto extremo demandante puede establecer un secreto compartido u otra manera de autentificar el mensaje de solicitud 1 15. Además, cualquier tipo conocido de credencial (por ejemplo, distintivo, secreto compartido, encripción, etc.) también se encuentra disponible para la presente invención. De acuerdo con lo anterior, cualquier manera particular de autentificación y/o tipo de credencial, según se describe en la presente, se utiliza para propósitos ilustrativos solamente y no significa que limite o angoste de otro modo el alcance de la presente invención.
Tomando en cuenta que al menos el punto extremo demandante 165 se ha autentificado adecuadamente (y tomando en cuenta que los puntos extremos soportan y concuerdan en un formar de encapsulación, según se describe a continuación), las porciones 135, 140 de una respuesta total 150 pueden enviarse desde el punto extremo de servicio 145 hacia el punto extremo demandante 165 a medida que se vuelven disponibles. Por ejemplo, una primer porción de la respuesta 1 50 puede enviarse a través del flujo de respuesta HTTP 125 en un primer periodo de tiempo y cuando se vuelve disponible una segunda porción 140 de la respuesta 150, en un segundo periodo de tiempo, también puede enviarse a través del mismo flujo de respuesta HTTP 125 siempre y cuando el punto extremo demandante 165 mantenga el flujo de respuesta HTTP 125 abierto. Observe que antes de cualquier tipo de intercambio real para una comunicación, las modalidades ejemplares proporcionan el aseguramiento de que las dos porciones de extremo 165, 145 soporten el mantenimiento del flujo de respuesta abierto para un flujo de respuesta HTTP 125. Tal validación permite que los dos puntos extremos 165, 145 concuerden sobre cierto tipo de codificación para mantener el flujo de respuesta 125 abierto durante la comunicación. De acuerdo con lo anterior, el empaque de las porciones 135, 140 será típicamente privado para los puntos extremos, demandante 165 y de servicio 145. Además, el acuerdo puede ser de naturaleza dinámica y los puntos extremos 165, 145 pueden acordar un tipo diferente de codificación durante una comunicación separada. Además, la codificación puede predeterminarse, en cuyo caso tal validación y acuerdo dinámico sobre codificación no son necesarios. Un ejemplo de un estándar sobre acuerdo para encapsulación utiliza las porciones de encabezado de los mensajes, por ejemplo, documentos de Lenguaje de marcado Extensibles (XML). En este ejemplo, el punto extremo de servicio 145 puede enviar continuamente porciones 135, 140 a través del flujo de respuesta HTTP 125 sin incluir un encabezado de "mensaje final" hasta, según se describe con mayor detalle a continuación, que ocurren uno o más eventos. No obstante, el cuerpo del mensaje necesita codificarse de tal manera que el punto extremo demandante 165 entienda que todas las diferentes porciones 1 35, 140 son parte de la respuesta total 150. Observe también que las porciones 135, 140 de la respuesta total 1 50 son datos arbitrarios ya que pueden ser de diverso tamaño y tipos de datos, incluso dentro de la misma respuesta. Por ejemplo, una porción 135 puede ser datos de corriente mientras que otra porción 140 puede ser un solo mensaje. Además, otros tipos de datos y formatos también se encuentran disponibles para la presente invención. De acuerdo con lo anterior, cualquier tipo particular o formato de mensajes se utilizan para propósitos ilustrativos solamente y no se entiende que limiten o angosten de otro modo el alcance de la presente invención a menos que se reivindique de manera explícita. Existen varias ventajas y razones que uno podría desear para mantener un flujo de respuesta 125 de una comunicación de solicitud-respuesta HTTP abierta, como se describe arriba. Por ejemplo, un punto extremo de servicio 145 puede desear enviar más de una respuesta a un punto extremo demandante 165 cuando la respuesta completa toma tiempo para producirse, pero las fracciones de la respuesta se encuentran disponibles en un momento anterior. Tal puede ser el caso cuando un punto extremo demandante 165 desea adquirir un artículo del punto extremo de servicio 145. Después de recibir el mensaje de solicitud 1 15, el punto extremo de servicio 155 puede enviar inicialmente una primer porción 135, indicando al punto extremo demandante 1 65 que el mensaje de solicitud 1 1 5 se recibió. Después de esto, el punto extremo de servicio 145 puede validar una tarjeta de crédito u otra información personal en cierto momento posterior y enviar una segunda porción 140 de la respuesta total 150 al punto extremo demandante 165, confirmando la información personal. Cuando el producto se envía finalmente al usuario, el punto extremo de servicio 145 puede enviar una porción posterior 135, 140 de la respuesta total 150 al punto extremo demandante 165, indicando que el artículo se ha enviado. Cualquier otra porción posterior 135, 140 de la respuesta 150, tal como rastreo u otra información, puede enviarse como porciones 135, 140 a medida que la información se vuelve disponible al punto extremo de servicio 145. Otra razón para mantener el flujo de respuesta HTTP 125 abierto es que la respuesta completa 150 puede ser una combinación de mensajes proveniente de diferentes fuentes, tales como módulos de servicio A-C 160, 1 55, 1 50. De manera similar, la solicitud 1 15 puede ser una colección de solicitudes de los diferentes módulos de servicio A-C 160, 155, 150. En cualquier caso, el punto extremo de servicio 145 puede obtener u otorgar información de varios módulos de servicio 160, 155, 150. Por ejemplo, el único servidor 147 puede utilizar los servicios proporcionados a partir de otros módulos de servicio 160, 155, 150 e incluir estos como porciones 135, 140 de la respuesta total 150. Por ejemplo, en el ejemplo dado arriba, el punto extremo de servicio 145 puede validar la información de tarjeta de crédito u otra información personal a través del módulo de servicio A 160; recibir el estado de suministro del módulo de servicio B 155; y recuperar información de rastreo del módulo de servicio C 150. A medida que estas porciones de información se vuelven disponibles, el servidor 147 puede actuar como un mandato o enrutador para las diversas porciones 135, 140 y transferirlas a través del flujo de respuesta HTTP 125, como se describió previamente. Como se aludió arriba, la manera como el servidor 147 sabe recuperar la información de los diversos módulos 160, 155, 150 dentro del punto extremo de servicio 145 puede variar. Por ejemplo, con un acuerdo adecuado después de la codificación, el punto extremo demandante 165 puede enviar una colección de referencias de punto extremo, por ejemplo, dentro del mensaje de solicitud 115 que identifica las diferentes porciones 1 35, 140 o servicios a recuperar de los diversos módulos de servicio 160, 155, 150. El servidor 147 puede realizar entonces las preguntas adecuadas a los diversos módulos de servicio 160, 155, 1 50 y a medida que los módulos de servicio 160, 155, 150 procesan y envían de regreso las respuestas adecuadas, el servidor 147 puede enviar estas como porciones 130, 145 de la respuesta total 150 a través del flujo de respuesta HTTP 125. De manera alternativa (o posiblemente incluso en conjunto), un solo mensaje de solicitud 1 15 dirigido al servidor 147 puede reconocer que diversas porciones 130, 145 se necesitan de diversos módulos de servicio 160, 155, 150 dentro del punto extremo de servicio 145 y pueden recuperarse automáticamente, según lo adecuado. Otros procesos para la identificación y recuperación de porciones de una respuesta total 150 también se encuentran disponibles para la presente invención. Observe también que solo tres módulos de servicio 1 60, 155, 150 se muestran dentro del punto extremo de servicio 145; sin embargo, cualquier número deservicios o módulos de servicio 160, 155, 150 se encuentra disponible para la presente invención. De acuerdo con lo anterior, cualquier descripción específica de referencia a un módulo de servicio 160, 1 55, 1 50 o punto extremo de servicio 145 o cualquier número particular de módulos de servicio 160, 155, 150, según se describe en la presente, se utiliza solo para propósitos ilustrativos y no se entiende que limite o angoste de otro modo el alcance de la presente invención a menos que se reivindique de manera explícita. Todavía otra razón para mantener el flujo de respuesta 125 de la comunicación HTTP abierta puede ser con objeto de acomodar dispositivos o puntos extremos 1 65, 145 con espacio regulador limitado o para soportar comunicaciones no reguladas. En esta modalidad, cuando una respuesta es un conjunto grande de datos y los puntos extremos desean evitar la regulación del conjunto entero de datos en la memoria, porciones menores 135, 140 de la respuesta total pueden enviarse periódicamente o asimétricamente a través del flujo de respuesta HTTP y procesarse inmediatamente para evitar la regulación. Tal cosa puede ser deseable en el caso de corriente de audio o video o para sistema con recursos de sistema limitados. Observe que en cualquier momento el punto extremo demandante 165 puede romper la conexión o comunicación con el punto extremo de servicio 145, de acuerdo con el protocolo estándar de HTTP. Este corte de conexión puede ser, por ejemplo, una expresión ya sea que se ha suministrado demasiada información y/o de que ha ocurrido una falla. De manera similar, el punto extremo de servicio 145 tiene la habilidad de detener la producción o de encapsular porciones 135, 140 de la respuesta total 150 y terminar la solicitud original 1 15. De acuerdo con lo anterior, cualquiera de los puntos extremos 165, 145 en la comunicación tiene la habilidad de servir a la interacción dentro del conjunto típico de mecanismos en su desecho. Es decir, no se requieren mecanismos HTTP nuevos para asegurar conexiones o cerrar el flujo de respuesta HTTP 125. Además de la modalidad total de mensajes encapsulados dentro de una sola respuesta 150(es decir, las porciones 135, 140 de la respuesta total 150), otras modalidades ejemplares proporcionan la administración de la comunicación entre los puntos extremos 165, 145, a través de los mensajes de control 105. El mensaje de control 1 05 puede ser uno o más de una colección de mensajes que ayuda a ambos puntos extremos 165, 145 a manejar tal interacción de corriente encapsulada. Cada mensaje de control 105 puede modelarse como un par de solicitud-respuesta de mensajes, que encajan de manera agradable en el modelo de transporte HTTP. Observe que, típicamente, los mensajes de control deben transmitirse 1 10 mediante el uso de una solicitud HTTP diferente a la que produce la respuesta 150 sobre el flujo de respuesta HTTP 125. Aunque un mensaje de solicitud inicial 1 15 puede incluir información de control en la etapa inicial de la comunicación, se. necesitará enviar información de control adicional 105 sobre otro transporte de solicitud-respuesta 1 1 0. Los mensajes de control 105 también pueden enviarse fuera de límite a través de otros tipos de transportes de comunicación 1 10 siempre y cuando identifiquen la comunicación particular entre el punto extremo demandante 165 y el punto extremo de servicio 145. Además, otros procesos y transportes para enviar el mensaje de control 105 a través de diversos transportes 1 10 hacia el punto extremo de servicio 145 también se encuentran disponibles en la presente invención. De acuerdo con lo anterior, cualquier uso específico de un proceso o transporte particular para enviar mensajes de control 105 al punto extremo de servicio 145 se utiliza para propósitos ilustrativos solo y no significa que limite o angoste de otro modo el alcance de la presente invención. Existen varios tipos de mensajes de control 105 que se encuentran disponibles en la presente invención. Por ejemplo, un mensaje de control 105 puede ser un mensaje de "está ok a granel". Este mensaje de control 105 se utiliza para determinar si un punto extremo puede aceptar una respuesta a granel en corriente 150. Es decir, tal mensaje de control 1 05 puede utilizarse en las etapas iniciales de establecer una comunicación con objeto de determinar si tal comunicación se soporta por un punto extremo en particular 165, 145 y qué tipo de encapsulación utilizar. Otro mensaje de control 105 puede ser un mensaje de "suspender", en donde el punto extremo demandante 165 desea detener temporalmente la recepción de la porción encapsulada 1 35, 140 de la respuesta 1 50. Otro mensaje de control 105 puede ser un mensaje de "resumir", en donde el punto extremo demandante 165 desea reiniciar la recepción de mensajes de respuesta encapsulados 150. Todavía otro mensaje de control 105 puede ser un "detonar", en donde un punto extremo 1 65, 145 desea determinar que el otro punto extremo 1 65, 145 es aún operacional. Otros mensajes de control 1 05 pueden incluir un mensaje de "inicio en múltiplex". Este mensaje de control en particular 105 permite que un punto extremo de servicio 145 (y más específicamente un servidor 147) comunique una colección de referencias de punto extremo que es capaz de servir como un enrutador o mandato intermedio. De acuerdo con lo anterior, los mensajes para cualquier referencia de punto extremo se envían como porciones encapsuladas, como se describió previamente a través del servidor 147. Otro mensaje de control 1 05 puede ser un mensaje de "desconexión" aunque se describe como un mensaje, puede ser más bien un simple encabezado de mensaje que contiene una referencia de punto extremo que identifica la respuesta HTTP 150 que permite que el punto extremo demandante 165 se refiera a la respuesta 150 o a la comunicación total entre los puntos extremos 145, 165 en otros canales, por ejemplo 1 10. Como uno puede observar, estos datos tienen múltiples usos para el envío de mensajes de control 1 05 y otra información entre diversos puntos extremos. Otros mensajes de control muy conocidos 105 y/o encabezados para controlar una comunicación también se encuentran disponibles en la presente invención. De acuerdo con lo anterior, la lista arriba descrita de mensajes de control 1 05 no significa que sea inclusiva, y cualquier otra referencia en particular a un mensaje de control en particular 105 se utiliza solo para propósitos ilustrativbs y no significa que limite o angoste de otro modo el alcance de la presente invención a menos que se reivindique explícitamente. Otras modalidades ejemplares proporcionan un patrón de intercambio de dos vías entre dos servicios de punto extremo. En tal modalidad, el proceso arriba perfilado para el establecimiento de una comunicación puede realizarse dos veces, actuando cada punto extremo tanto como punto extremo demandante 165 como de servicio 145. Por ejemplo, como se muestra en la Figura 1 B el sistema distribuido 1 00 incluye el punto extremo A y el punto extremo B 1 80. Una primer sesión de comunicaciones A 175 puede establecerse mediante el envío desde el punto extremo A 170 de una solicitud sobre un flujo de solicitud A 1 85, en donde las porciones posteriores de una respuesta total se reciben sobre un flujo de respuesta A 190, como se describió previamente. De manera similar, el punto extremo B puede establecer una sesión de comunicación B 195 mediante el envío de un mensaje de solicitud sobre un flujo de solicitud B 182 y recibir las porciones posteriores de una respuesta total a través de un flujo de respuesta B 184 de acuerdo con modalidades ejemplares. En tales casos, los dos puntos extremos 170, 180 deben coordinar típicamente cuáles solicitudes y porciones de las respuestas totales corresponden a la comunicación de una vía y de dos vías. La presente invención también puede describirse en términos de métodos que comprenden etapas funcionales y/o acciones no funcionales. Lo siguiente es una descripción de etapas y/o acciones que pueden llevarse a cabo en la práctica de la presente invención. Normalmente, las etapas funcionales describen la invención en términos de resultados que se llevan a cabo mientras que las acciones no funcionales describen acciones más específicas para lograr un resultado en particular. Aunque las etapas funcionales y/o acciones no funcionales pueden describirse o reivindicarse en un orden particular, la presente invención no se limita necesariamente a ningún orden o combinación de etapas y/o acciones en particular.
Además, el uso de etapas y/o acciones en la recitación de las reivindicaciones y la siguiente descripción para los diagramas de flujo de las Figuras 2 y 3 se utilizan para indicar el uso específico deseado de tales términos. Las Figuras 2 y 3 ilustran diagramas de flujo ejemplares de diversas modalidades ejemplares de la presente invención. La siguiente descripción de las Figuras 2 y 3 ocasionalmente se referirá a los elementos correspondientes de las Figuras 1 A y 1 B. Aunque puede hacerse referencia a un elemento específico de esas Figuras, tales elementos se utilizan solo para propósitos ilustrativos y no significa que limiten o angosten de otro modo el alcance de la presente invención a menos que se reivindique de manera explícita. La Figura 2 ilustra un diagrama de flujo ejemplar de un método 200 para la transferencia de una respuesta HTTP como una pluralidad de diferentes porciones con objeto de conservar valiosos recursos de sistema asociados con la validación y autorización de una solicitud correspondiente. Observe que el método 200 es desde la perspectiva de un punto extremo demandante 1 65 e incluye una acción de enviar 205 un mensaje de solicitud sobre un flujo de solicitud HTTP. Por ejemplo, el punto extremo demandante 165 puede enviar mensaje de solicitud 1 1 5 sobre un flujo de respuestas HTTP 125 para el establecimiento de una comunicación con el punto extremo de servicio 145 en el sistema distribuido 100. El mensaje de solicitud 15 puede contener información de control, por ejemplo, mensaje de control 105 para el control de la comunicación. Sin embargo, típicamente, los mensajes de control se enviarán en una comunicación separada con objeto de administrar la comunicación establecida entre el punto extremo demandante 165 y el punto extremo de servicio 145. Como se describió previamente, los mensajes de control pueden ser uno o más de "está ok a granel", "suspender", "resumir", "detonar", "reconectar", "inicio en múltiplex" o "esta conexión", etc. Después de enviar un mensaje de solicitud, el método 200 incluye una acción de recibir 210 una primer porción de una respuesta sobre un flujo de respuesta HTTP 125. Por ejemplo, el punto extremo demandante 165 puede recibir una primer porción 135 de una respuesta sobre un flujo de respuesta HTTP correspondiente 125, el cual se recibe en un primer periodo de tiempo. El método 200 también incluye una acción de mantener abierto 215 el flujo de respuesta HTTP 125. Por ejemplo, el punto extremo demandante 165 puede mantener el flujo de respuesta HTTP 125 abierto con objeto de recibir porciones de adición de la respuesta 150. Sin enviar otro mensaje de solicitud, el método 200 también incluye una acción de recibir 220 una segunda porción de la respuesta sobre el flujo de respuesta HTTP 125. Por ejemplo, el punto extremo demandante 165 puede recibir una segunda porción 140 de la respuesta 150 sobre el flujo de respuesta HTTP 125, en donde la segunda porción se recibe en un segundo periodo de tiempo diferente del primer periodo de tiempo. Las porciones, primera 135 y segunda 140, pueden recibirse de manera asincrona, es decir, a intervalos arbitrarios. Además, estas porciones 135, 140 pueden encontrarse ya sea en corriente, ser mensajes individuales o ambos, que conforman la respuesta total 150, Además, la primer porción 135 y la segunda porción 140 pueden ser mensajes discretos que se procesaron a partir de módulos de servicio separados, 160, 155, 150 dentro del sistema distribuido 1 00. Las porciones, primera y segunda, 135, 140 pueden recibirse a partir de un solo servicio 147 o servidor que solicitó los mensajes discretos 135, 140 de los módulos de servicio separados 160, 1 55, 150 mediante el uso de referencias de punto extremo enviadas desde el punto extremo demandante 165. Estas referencias de punto extremo pueden incluirse en el mensaje de solicitud 1 15. De manera alternativa, o en conjunto, el punto extremo de servicio 145 puede enviar las referencias de punto extremo que soporta en un mensaje de control 105 al punto extremo demandante 165. Además, las referencias de punto extremo pueden enviarse en un mensaje de control 105 sobre un transporte de comunicación separado a partir del flujo de respuesta HTTP 125. Como se mencionó arriba, una comunicación de dos vías puede establecerse entre los dos puntos extremos en el sistema distribuido 100. En tal modalidad, si el punto extremo A 170 dentro de la Figura 1 B es el punto extremo demandante 165 de la Figura 1 A; y el punto extremo B 180 dentro de la Figura 1 B es el punto extremo de servicio 1 80 de la Figura 1A entonces, siguiendo un establecimiento de una primer sesión de comunicaciones A 175, las modalidades adicionales proporcionan lo siguiente. El punto extremo A 170 puede recibir un segundo mensaje de solicitud sobre un segundo flujo de respuesta HTTP (por ejemplo, el flujo de solicitud B 182) para el establecimiento de una sesión de comunicación de dos vías entre el punto extremo 170, 1 80 dentro de un sistema distribuido 1 00. Por consiguiente, el punto extremo A 170 puede enviar una primer porción de una segunda respuesta sobre un segundo flujo de respuesta HTTP correspondiente (por ejemplo, flujo de respuesta B 184) en un tercer periodo de tiempo. Sin recibir otro mensaje de solicitud, el punto extremo A 170 puede enviar una segunda porción de la segunda respuesta sobre el segundo flujo de respuesta HTTP (por ejemplo, flujo de respuesta B 184) en un cuarto periodo de tiempo diferente del tercer periodo. Desde el punto extremo de servicio 145, la Figura 3 ilustra un método 300 para transferir una respuesta HTTP como una pluralidad de diferentes partes de acuerdo con las modalidades ejemplares de la presente invención. El método 300 incluye un acto para recibir 305 un mensaje de solicitud sobre un flujo de respuesta HTTP. Por ejemplo, el punto extremo de servicio 145 puede recibir el mensaje de solicitud 1 1 5 desde el punto extremo demandante 165 sobre un flujo de respuesta HTTP 125. El método 300 también incluye un acto de enviar 310 una primera parte de una respuesta sobre un flujo de respuesta HTTP. Por ejemplo, el punto extremo de servicio 145 puede enviar una primera parte 135 de respuesta 150 sobre un flujo de respuesta HTTP 125 en un primer período de tiempo. El método 300 también incluye un acto de enviar 315 una segunda parte de una repuesta sobre el flujo de respuesta HTTP. Por ejemplo, el punto extremo de servicio 145 puede enviar una segunda parte 140 de la respuesta 1 50 sobre el flujo de respuesta HTTP 1 25 en un segundo período de tiempo diferente del primer período de tiempo. Nótese que las otra modalidades ejemplares según se descrien previamente también pueden aplicar al método 300. Las modalidades dentro del alcance de la presente invención también incluyen medios leíbles por computadora para llevar o tener instrucciones ejecutables por computadora o estructuras de datos almacenadas en la misma. Tales medios leíbles por computadora pueden ser cualquiera de los medios disponibles que pueden accesarse por un propósito general o computadora de propósito especial. A manera de ejemplo, y no limitación, tales medios leíbles por computadora pueden comprender RAM, ROM, EEPROM, CD-ROM y otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que puede utilizarse para llevar o almacenar los medios del código de programa deseados en la forma de instrucciones ejecutables por computadora o estructuras de datos y que pueden accesarse por un propósito general o computadora de propósito especial. Cuando la información se transfiere o se proporciona sobre una red u otra conexión de comunicaciones (ya sea, con conexión inalámbrica, inalámbrica, o una combinación de conexión inalámbrica, o inalámbrica) a una computadora, la computadora adecuadamente observa la conexión como un medio leíble por computadora. De esta manera, cualquier conexión tal se denomina adecuadamente un medio leíble por computadora. Las combinaciones de lo anterior deberán también incluirse dentro del alcance de los medios leíbles por computadora. Las instrucciones ejecutables por computadora comprenden, por ejemplo, instrucciones y datos que originan una computadora de propósito general, computadora de propósito especial, o dispositivo de procesamiento de propósito especial para realizar una cierta función o grupo de funciones. La Figura 4 y la siguiente discusión se pretende que proporcionen una breve, descripción general de un ambiente de computación adecuada en la cual la invención puede implementarse. A pesar de no requerirse, la invención se describirá en el contexto general de las instrucciones ejecutables por computadora, tales como módulos de programa, que se ejecutan por computadoras en ambientes de red. Generalmente, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc. que realizan pruebas 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 etapas de los métodos descritos en la presente. La secuencia particular de tales instrucciones ejecutables o estructuras de datos asociadas representa ejemplos de actos correspondientes para implementar las funciones descritas en tales etapas. Aquellos expertos en la materia apreciarán que la invención puede practicarse en ambientes de computación de red con varios tipos de configuraciones de sistema de computadora, incluyendo computadoras personales, dispositivos portátiles, sistemas multiprocesadores, electrónica de consumidor programable o basado en microprocesador, PCs de red, minicomputadoras, computadoras de estructura principal , y lo similar. La invención también puede practicarse en ambientes de computación distribuidos en donde se realizan por las pruebas y los dispositivos de procesamiento remotos que se enlazan (ya sea por conexiones inalámbricas, uniones inalámbricas, o por una combinación de uniones inalámbricas o conexiones inalámbricas) a través de una red de comunicaciones. En un ambiente de computación deseada, los módulos de programa pueden ubicarse tanto en y como en dispositivos de almacenamiento de memoria remotos. Con referencia a la Figura 4, un sistema ejemplar para implementar la invención incluye un dispositivo de computación de propósito en la forma de una computadora convencional 420, incluyendo una unidad de procesamiento 421 , una memoria de sistema 422, y un bus de sistema 423 que acopla varios componentes de sistema incluyendo la memoria de sistema 422 a la unidad de procesamiento 421 . El bus de sistema 423 puede ser de cualquiera de los varios tipos de estructuras de bus incluyendo un bus de memoria , o controlador de memoria, un bus periférico, y un bus utilizando cualquiera de una variedad de arquitecturas de bus. La memoria de sistema incluye leer solamente la memoria (ROM) 424 y la memoria de acceso al azar (RAM) 425 Un sistema de entrada/salida básica (BIOS) 426, 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 la instalación, pueden almacenarse en ROM 424. La computadora 420 también puede incluir una unidad de disco duro magnético 427 para leerse de y escribirse en un disco duro magnético 439, una unidad de disco magnético 428 para leerse de o escribirse en un disco magnético removible 429, y una unidad de disco óptico 438 para leerse de o escribir en un disco magnético removible 431 tal como una CD-ROM u otro medio óptico. La unidad de disco duro magnético 427, unidad de disco magnético 428, y unidad de disco óptico 430 se conectan al bus de sistema 423 por una ¡nterfase de unidad de disco duro 432, una interfase de unidad de disco magnético 433, y una interfase de disco óptico 434, respectivamente. Las unidades y sus medios leíbles por computadora asociados proporcionan almacenamiento no volátil de instrucciones ejecutables por computadora, estructuras de datos, módulos de programa y otros datos para la computadora 420. A pesar de que el ambiente ejemplar descrito en la presente emplea un disco duro magnético 439, un disco magnético removible 429 y un disco óptico removible 431 , otros tipos de medios leíbles por computadora para almacenar datos pueden utilizarse, incluyendo casetes magnéticos, tarjetas de memoria flash, discos versátiles digitales, cartuchos Bernoulli, RA s, RO s, y lo similar. Los medios de código de programa que comprenden uno o más módulos de programa pueden almacenarse en el disco duro 439, disco magnético 429, disco óptico 431 , ROM 424 o RAM 425, incluyendo un sistema operativo 435, uno o más programas de aplicación 436, otros módulos de programa 437, y datos de programa 438. Un usuario puede ingresar comandos e información en la computadora 420 a través del teclado 440, dispositivo de señalamiento 442, u otros dispositivos de entrada (no mostradas), tales como un micrófono, palanca de mando, almohadilla de juegos, disco satelital, explorador, o lo similar. Estos y otros dispositivos de entrada frecuentemente se conectan a la unidad de procesamiento 421 a través de una interfase de puerto serial 446 acoplada al bus de sistema 423. Alternativamente, los dispositivos de entrada pueden conectarse por otras interfases, tales como un puerto paralelo, un puerto de juegos o un bus serial universal (USB). Un monitor 447 u otro dispositivo de despliegue también se conecta al bus de sistema 423 por medio de una interfase, tal como un adaptador de video 448. Además del monitor, las computadoras personales típicamente incluyen otros dispositivos de salida periférica (no mostrados), tales como parlantes e impresoras. La computadora 420 puede operar en un ambiente con red utilizando conexiones lógicas a una o más computadoras ' remotas, tales como computadoras remotas 449a y 449b. Las computadoras remotas 449a y 449b pueden cada una ser una computadora personal, un servidor, un router, una PC de red, un dispositivo par u otro nodo de red común, y típicamente incluyen varios o todos los elementos anteriormente descritos en relación a la computadora 420, a pesar de que solamente los dispositivos de almacenamiento de memoria 450a y 450b y sus programas de aplicación asociados 436a y 436b se han ilustrado en la Figura 4. Las conexiones lógicas representadas en la Figura 4 incluyen una red de área (LAN) 451 y una red de área ancha (WAN) 452 que se presentan aquí a manera de ejemplo y no limitación. Tales ambientes de red son lugares comunes en redes de computadora a nivel empresarial o nivel oficina, intranets y la Internet. Cuando se utiliza un ambiente de red LAN, la computadora 420 se conecta a la red 451 a través de una interfase de red o adaptador 453. Cuando se utiliza en un ambiente de red WAN, la computadora 420 puede incluir un módem 454, una conexión inalámbrica, u otros medios para establecer comunicaciones sobre el ambiente de área ancha 452, tal como la Internet. El módem 454, que puede ser interno o externo, se conecta al bus de sistema 423 por medio de la interfase de puerto serial 446. En un ambiente con red, los módulos de programa representados en relación a la computadora 420, o partes de los mismos, pueden almacenarse en el dispositivo de almacenamiento de memoria remoto. Se apreciará que las conexiones de red mostradas son ejemplares y otros medios para establecer comunicaciones sobre la red de área ancha 452 pueden utilizarse. La presente invención puede incorporarse en otras formas específicas sin apartarse de su espíritu o características esenciales. Las modalidades descritas deben considerarse en todos los aspectos como solo ilustrativas y no restrictivas. Por consiguiente, el alcance de la invención se indica por las reivindicaciones anexas en vez de por la descripción anterior. Todos los cambios que vienen dentro del significado y rango de equivalencia de las reivindicaciones deben abarcarse dentro de su alcance.