BRPI0619763B1

BRPI0619763B1 - sistema e método para otimização acionada de histórico de comunicação de serviços da web

Info

Publication number: BRPI0619763B1
Application number: BRPI0619763A
Authority: BR
Inventors: Narayanaswami Chandrasekhar; Thondanur Raghunath Mandayam; Rosu Marcel
Original assignee: Ibm
Priority date: 2005-12-05
Filing date: 2006-11-30
Publication date: 2019-09-03
Also published as: EP1969814B1; WO2007065850A3; US20080256171A1; US20070127440A1; CN101341724A; EP1969814A2; US7808975B2; BRPI0619763A2; TWI377819B; ATE426992T1; JP5052522B2; JP2009519508A; US8107463B2; KR101027299B1; TW200737855A; WO2007065850A2; CA2640838A1; CN101341724B; KR20080084974A; DE602006005963D1

Abstract

sistema e método para otimização acionada de histórico de comunicação de serviços da web. sistema, método e produto de programa de computador para comunicar mensagens de serviços da web (ws) . em primeiro lugar, é alocada uma quantidade idêntica de um armazenamento de histórico de cache em cada aparelho emissor e receptor para o armazenamento de um histórico de cadeias de mensagem ws comunicadas. no emissor, é gerada uma representação de dados intermediária de cada mensagem a ser construída, a cadeia de mensagem correspondente guardada no armazenamento de histórico de cache. a mensagem é comunicada como uma cadeia de dados serializada de acordo com a representação de dados construída. para cada mensagem posterior a ser comunicada, o método compreende identificação de porções idênticas em representações intermediárias de dados de uma mensagem atual sendo construída e substituindo cada porção identificada nas cadeias de mensagem com indicador de referência para um local no armazenamento de histórico cache que corresponde a uma porção de cadeia de caracteres idênticos associada a uma mensagem anterior que tenha sido comunicada. no aparelho receptor, as referências são identificadas nas cadeias de mensagens recebidas e uma ou mais representações de dados intermédios armazenadas localmente no dispositivo receptor são substituídos na mensagem para completar uma construção de uma mensagem recebida.

Description

SISTEMA E MÉTODO PARA OTIMIZAÇÃO ACIONADA DE HISTÓRICO DE COMUNICAÇÃO DE SERVIÇOS DA WEB

Antecedentes da Invenção

Campo da Invenção [0001] A presente invenção refere-se de modo geral a comunicações de rede, como através da Internet/ World Wide Web e, mais particularmente, a um sistema e método para reduzir a largura de banda de comunicação e overheads para entidades fornecendo e consumindo serviços baseados em Web (WS) .

Descrição do Estado da Técnica [0002] Os serviços Web (Web Services - WS) são um modelo de programação que inclui um conjunto de padrões desenvolvidos para fornecer acesso programático a lógica do aplicativo em uma máquina remota. Esta lógica de aplicativo é acessível aos clientes em todas as plataformas, e em toda linguagem de programação. Um dos blocos de construção de serviços Web do núcleo é SOAP (Simple Object Access Protocol), uma estrutura padrão que permite, mas não está limitada a mensagens RPC (Remote Procedure Call) a serem transmitidas, como documentos XML e que chama as capacidades de serviços Web. Sabe-se que WS são amplamente utilizados, não só através da Internet (ou Web), mas também em redes corporativas, mesmo entre a máquina localizada no mesmo local ou mesmo sala. Apesar de ter sido inicialmente projetado para o acesso em toda a web, WS são populares dentro de intranets, ou seja, redes de empresas.

[0003] A figura 1A apresenta uma arquitetura de WS típica 10, incluindo os seus componentes lógicos. Como mostra a Figura 1A, um provedor de serviços Web 18 é responsável pela implantação de serviços Web e publicá-los com um agente

Petição 870160076655, de 19/12/2016, pág. 17/58

2/31 de serviço Web 15 que é responsável pelo serviço de registro e descoberta de serviços Web. Particularmente, o agente lista vários tipos de serviço, descrições e locais de serviços que ajudam os solicitantes de serviços a encontrar e subscrever aos serviços necessários. Um solicitante de serviço Web 12 é responsável pela invocação de serviço, localizando o serviço Web usando o agente de serviço 15, invoca os serviços necessários, e o executa a partir do provedor de serviços. Mais especificamente, como descrito no livro Developing Java™ Web Services (Ramesh Nagappan, et al., Wiley Publishing, Inc. 2003), o provedor de serviço Web 18 inclui um contentor de serviços 28 que atua como o ambiente de execução de serviços Web e hospeda o provedor de serviços. O contentor de serviços 28 especialmente define o ambiente destinado para implementar a comunicação do cliente de uma maneira padronizada para descrever os serviços de rede usando uma especificação padrão baseada em esquema XML para descrever serviços web conhecida como Linguagem de Definição de Serviços Web (Web Services Definition Language - WSDL), e facilita a implantação e administração de serviços web. Além disso, ele 1ida com o registro da descrição do serviço com os registros de serviço 30a, b. Esses registros inc1uem aque1es implementando um padrão Universal Description, Discovery and Integration (UDDI) 30a (www.UDDI.org) ou um registo ebXML 30b que define os serviços de registro, protocolos de interação, e as definições de mensagens, e atua ainda como um armazenamento de informações compartilhadas (www.ebXML.org). O solicitante do serviço Web 12 inclui um componente de entrega de serviços 22, que atua como o ambiente de execução do c1iente, ao consultar os registros de serviços para encontrar os serviços necessários

Petição 870160076655, de 19/12/2016, pág. 18/58

3/31 e chamá-los a partir do provedor de serviços através de mensagens SOAP 25. Como se sabe, o protocolo SOAP inclui os seguintes elementos: um envelope SOAP, que serve como um contentor para outros elementos da mensagem SOAP; um transporte SOAP obrigatório para o protocolo de transporte subjacente, um conjunto de regras de codificação SOAP para representar dados em uma mensagem (mapeia os casos de tipos de dados de aplicação específica de mensagens XML) e um padrão de interação de aplicativo, na maioria das vezes uma convenção RPC, que é a definição da representação para solicitações de RPC e respostas e é definido como uma forma de serializar chamadas de procedimento remoto e respostas como mensagens SOAP. (Java e todas as marcas baseadas em Java e logotipos são marcas registradas da Sun Microsystems, Inc. nos Estados Unidos, outros países, ou ambos.) [0004] A figura 1B, retrata uma interação clienteservidor exemplar em uma implementação RPC SOAP convencional. Como mostra a figura 1B, um cliente 12 interage com um provedor de serviço (ou simplesmente Serviço) 18 sobre uma rede 99, como a Internet, usando um protocolo SOAP/ HTTP (ou seja, um protocolo de mensagem SOAP usando um binding de transporte HTTP). O protocolo de mensagens SOAP 25 permite que as mensagens sejam trocadas entre o terminal do provedor de serviço 18 e terminal do solicitante do serviço 12 em pares de solicitação-resposta. Este é o método SOAP usa com o transporte de mensagens HTTP (Internet) e/ ou convenção RPC. Enquanto SOAP define como as mensagens devem ser trocadas por HTTP, entende-se que qualquer protocolo de comunicações (por exemplo, SMTP, WebSphere® MQ, Raw Sockets, etc.) ou método pode ser substituído por HTTP (WebSphere é uma marca registrada da International Business Machines

Petição 870160076655, de 19/12/2016, pág. 19/58

4/31

Corporation nos Estados Unidos e outros países). Nesta implementação convencional, o cliente 12 faz chamadas de procedimento remoto (RPC) no provedor de serviços 18, enviando uma mensagem para cada chamada. De maneira semelhante, o provedor de serviços 18 responde a essas chamadas através do envio de uma mensagem de volta ao cliente 12 para cada resposta. A principal técnica em serviços Web é uso de processos respectivos de composição de uma mensagem SOAP, antes de enviá-la e decifrar uma mensagem SOAP após recebê-la. Estes processos de uma mensagem SOAP geralmente são realizados através da criação de DOM (Document Object Model), ou objetos do tipo ramificado similares, na memória. Desta forma, os processos podem ser realizados utilizando a representação de árvore da mensagem SOAP sem considerar a representação textual da mensagem.

[0005] Devido à natureza ASCII de XML, a implementação de serviços Web incorpora importantes requisitos de largura de banda e overheads de comunicação. Além disso, WS são auto descritivos, de forma que um cliente e servidor precisa apenas reconhecer o formato e o conteúdo de mensagens de solicitação e resposta. A definição do formato da mensagem do WS viaja com a mensagem; repositórios de metadados externos ou ferramentas de geração de código não são necessários. Assim, os overheads são evidentes quando se analisa o conteúdo de qualquer mensagem SOAP. O uso de SOAP e XML não somente se traduz em mensagens muito grandes, ou seja, overhead significativo na pilha TCP/ IP e o uso da largura de banda aumentado, mas também em overhead de análise significativo, devido a estrutura rica de SOAP. Além disso, HTTP, que é transporte WS mais comumente usado, acrescenta overhead de comunicação e de análise adicionais.

Petição 870160076655, de 19/12/2016, pág. 20/58

5/31 [0006] Nas plataformas de cliente/ servidor tradicionais, o impacto desses overheads tem sido amplamente compensado pela utilização de redes Gigabit Ethernet, processadores mais rápidos e mais memória, e eliminando os gargalos de desempenho presentes nas implementações SOAP iniciais, como o mecanismo Apache Axis. Infelizmente, as plataformas móveis de recursos limitados, como telefones celulares, PDAs ou laptops, não podem se beneficiar destas soluções. As abordagens orientadas a Hardware normalmente não se aplicam a estes dispositivos de energia e de tamanho limitados, à medida que redes ou CPUs mais rápidas, ou mais de memória, consomem mais energia e nem sempre se encaixam nos fatores de forma desejada. Da mesma forma, as implementações de mecanismo SOAP exigem otimizações adicionais para reduzir o seu impacto na memória.

[0007] Em um cenário de emprego de serviços web B2B típico, por exemplo, um cliente de serviços Web pode fazer várias chamadas para o ponto final de serviço, e estas chamadas podem ter vários parâmetros que não mudam de chamada para chamada. Considere, por exemplo, vários compradores interagindo com o ponto terminal de serviço da Web de um vendedor usando o serviço de web chama para enviar ordens de compra para o vendedor. Cada ordem de compra pode ter vários campos, e muitos destes campos podem descrever o comprador e, portanto, ser o mesmo para um comprador particular para cada chamada. Este tipo de repetição de parâmetro é principalmente devido à natureza independente de serviços web. Mantendo estado especifico para a combinação de (ponto de extremidade de serviço, o cliente) pode permitir uma melhor razão de compressão do trafego de rede que possível com a simples compressão estilo gzip sem estado.

Petição 870160076655, de 19/12/2016, pág. 21/58

6/31 [0008] Uma variedade de técnicas que facilitam os serviços Web e, particularmente, a compressão de mensagens, são conhecidos na técnica. Tais técnicas incluem, por exemplo:

1) “XMill: na Efficient Compressor for XML Data de Hartmut liefke e Suciu Dan (ACM SIGMOD 2000) descreve uma ferramenta para a compressão de dados XML, que atinge cerca de duas vezes a razão de compressão do gzip, em aproximadamente a mesma velocidade. XMill separa a estrutura dos dados, os itens de dados relacionados a grupos, e aplica um conjunto de compressores especializados. Só pode ser aplicada após a mensagem WS ser gerada, o que aumenta as latências de mensagem.

2) WAP Binary XML (WBXML) (http://www.w3.org/TR/wbxml/) junho de 1999, descreve dividir XML em tokens predefinidos, que são binários codificados e repouso, que está inline codificada. As tabelas de tokens são mantidas em ambos os lados de enviar/ receber. Inicialmente, apenas as tabelas de token para WAP estavam disponíveis; tabelas adicionais para SyncML e DRMREL (Digital Rights Management Rights Expression Language) foram definidas posteriormente. Grande benefício é que um analisador SAX de WBXML livre tem overhead muito baixo. Grande inconveniente é que só pode ser usado para um dialeto XML predefinido, à medida que tabelas de token para o dialeto XML devem existir em ambas as extremidades.

3) “Millau: an encoding format for eficiente representation and exchange of XML over the Web, de Marc Girardot e Neel Sundaresan (http://www9.org) maio de 2000, descreve a separação da estrutura do texto para a compressão e se utiliza do esquema associado. Extensão para WBXML que

Petição 870160076655, de 19/12/2016, pág. 22/58

7/31 comprime o texto embutido e compreende os tipos básicos de XML. Millau tem os mesmos inconvenientes que WBXML.

4) “Compressing SOAP messages by using differential encoding” de Christian Werner, Carsten Buschmann, Stefan Fischer (IEEE International Conference on Web Services, julho de 2004), descreve, em uma primeira parte do artigo a comparação dos requisitos de largura de banda do SOAP (.NET e Java) RMI-IIOP, Corba, RMI, e SOAP gziped. A segunda parte descreve compressão SOAP diferencial, que envia apenas a diferença entre uma mensagem e uma outra anterior. Na prática, a codificação diferencial funciona por calcular primeiro uma coleção de mensagens de esqueleto usando o arquivo WSDL; em seguida, ele calcula a diferença entre uma mensagem e um esqueleto previsto, que depois é transmitida. Na codificação diferencial, a codificação e decodificação de overhead pode ser significativa.

5) Performance Considerations for Mobile Web Services de M. Tian, T. Voigt, T. Naumowicz, H. Ritter, J. e Schiller (Elsevier Computer Communications Journal, Volume 27, Issue 11, 1 de julho de 2004, Páginas 1097-1105) descreve como a compressão não é sempre benéfica, especialmente quando se sobrecarrega o servidor.

6) Energy Aware Lossless Data Compression de Kenneth Barr e Krste Asanovic (Mobisys 2003, maio de 2003) descreve com ferramentas de compressão típicas, como é necessária mais energia para comprimir e enviar dados do que enviar os dados descompactados. As otimizações de conhecimento do Hardware de ferramentas de compressão são mostradas que reduzem a energia utilizada para a compressão. Este artigo mostra que o esquema de compressão deve ser escolhido com cuidado.

Petição 870160076655, de 19/12/2016, pág. 23/58

8/31

7) Wireless SOAP: Optimizations for Mobile Wireless Web Services de Naresh Apte, Keith Deutsch, e Ravi Jain (poster at www2005.org, maio de 2005) propõe duas técnicas de otimização: 1) Name Space Equivalency (NPE), e 2) WSDL Aware Encoding (WAE). NPE permite a recuperação de mensagens XML de uma forma diferente, mas equivalente. WAE requer um gateway dispositivo m6vel, o que cria tabelas de codificação para as operações descritas no arquivo WSDL. NPE não aparece para entregar compressão significativa enquanto WAE requer um gateway.

8) An Adaptive, Fast and Safe XML Parser Based on Byte Sequence Memorization de Toshiro Takase, Hisashi Miyashita, Toyotaro Suzumura, e Michiaki Tatsubon (www2005.org, maio de 2005) descreve um analisador XML (Deltarser) que usa o histórico para identificar construções sintáticas previamente vistas e reutiliza os resultados das construções correspondentes. O analisador Deltarser reduz overheads de análise sobre o nó receptor, mas não reduz os requisitos de largura de banda, nem os overheads de geração da mensagem sobre o nó de envio. Sumário da Invenção [0009] É fornecido, de preferência, um sistema e método que fornece uma ou várias otimizações para reduzir significativamente os overheads de processamento de mensagens SOAP em ambientes de serviço Web implantado.

[0010] É fornecido, de preferência, um sistema e método que fornece uma ou várias otimizações para reduzir significativamente os overheads de comunicação mensagens SOAP em ambientes de serviço Web implantado.

[0011] É fornecido, de preferência, um sistema e método que fornece um esquema de otimização de compressão de

Petição 870160076655, de 19/12/2016, pág. 24/58

9/31 mensagens WS/ SOAP que fornece compressão comparável com a energia e os custos de latência significativamente mais baixos do que dos esquemas de compressão mensagens WS/ SOAP existentes.

[0012] A presente invenção é dirigida, de acordo com uma concretização preferida, a um sistema, método e produto programa de computador que fornece uma ou várias otimizações para reduzir significativamente overheads de mensagens SOAP em ambientes de serviço Web implantado.

[0013] Mais particularmente, a presente invenção prevê, de acordo com uma concretização preferida, uma solução que aproveita a natureza repetitiva do tráfego WS entre dois pontos para identificar uma serie de otimizações em várias camadas nos mecanismos SOAP e HTTP dos dois dispositivos. Mais especificamente, os dois dispositivos de preferência, mantém um histórico do número mais recente N de bytes relacionados a WS recebidos e enviados em cada sentido. O tamanho do histórico não tem que ser o mesmo para ambos os sentidos, mas os terminais de envio e recepção de uma direção devem usar exatamente o mesmo tamanho de histórico. A entrega segura e em ordem de WS garante que os dois terminais tenham uma visão coerente do histórico comum.

[0014] Overheads de comunicação são reduzidos, de preferência, substituindo elementos bem definidos na mensagem SOAP com referências em mensagens anteriores. Tanto os terminais de envio e recebimento de preferência substituem nos seus buffers de histórico, as referências com as cadeias a que se referem: Isto permite a mesma compressão ou semelhante, em mensagens subsequentes enviadas na mesma direção.

Petição 870160076655, de 19/12/2016, pág. 25/58

10/31 [0015] Assim, de acordo com um aspecto da invenção, é fornecido um sistema, método e produto de programa de computador para comunicar mensagens. O método para comunicar mensagens inclui: atribuição de uma quantidade de uma primeira memória cache em cada um de um dispositivo emissor e um aparelho receptor, o cache para armazenar cadeias de caracteres correspondente ao comunicado e cadeias de mensagens recebidas no remetente e respectivos dispositivos do receptor e, a construção de uma estrutura de dados intermediária de uma mensagem a ser comunicada, a estrutura de dados intermediária adaptada para o armazenamento em uma segunda memória cache do dispositivo emissor, e, a construção de uma cadeia de mensagem deve ser comunicada com base na estrutura de dados intermediária construída e, para cada mensagem posterior devem ser comunicadas: porções de identificação em uma estrutura de dados intermediária construída de uma mensagem atual que está sendo construída com partes que são idênticas àquelas partes presentes em uma estrutura de dados intermediária construída correspondente a uma cadeia de mensagem comunicada antes; construção de uma cadeia de mensagem deve ser comunicada com base na atual estrutura de dados intermediária construída e substituindo cada parte identificada nas cadeias de mensagem com um indicador de referência para uma localização na primeira memória cache correspondente a uma parte de cadeia de caracteres idêntica associada com a mensagem anterior que foi comunicada e, no dispositivo receptor, identificando um indicador de referência em uma cadeia de mensagem recebida

e substituindo	uma ou mais partes de cadeia de caracteres
armazenadas em	cache idênticas armazenadas no cache de
primeiro nível	do dispositivo receptor para construir a

Petição 870160076655, de 19/12/2016, pág. 26/58

11/31 mensagem recebida, por meio de recursos de infraestrutura de comunicação de mensagens no envio e recepção de dispositivo são conservados.

[0016] Em uma concretização da invenção, a estrutura de dados intermediária compreende uma árvore representação estruturada de uma mensagem, com as partes identificadas sequência compreendendo um ou mais sub-árvore ou fragmentos de árvore.

[0017] Em uma modalidade da invenção, a alocação de armazenamento histórico do cache no dispositivo emissor e receptor compreende: implementação de um protocolo de handshake inicial entre os dispositivos de comunicação a quantidade de armazenamento primeira cache a ser alocado. Adicionalmente a desta modalidade, o montante atribuído a memória cache de primeiro nível do dispositivo receptor de preferência pelo menos tanto quanto um tamanho do primeiro cache alocado no dispositivo emissor.

[0018] Em uma modalidade da invenção, o indicador de referência se refere aos atributos de uma parcela serializado mensagem string correspondente a uma sub-árvore identificada fragmento ou porção de uma estrutura de dados construída intermediário que é idêntico a uma sub-árvore ou parte de fragmento presente em uma estrutura de dados intermediária construída correspondente a uma cadeia de mensagem prévia comunicada.

[0019] Um atributo pode compreender um ou mais dentre: uma indicação de uma mensagem anterior enviada, uma identificação de mensagem identificando a árvore de representação de uma mensagem previamente comunicada, o comprimento da cadeia correspondente à árvore identificada,

Petição 870160076655, de 19/12/2016, pág. 27/58

12/31 e, o comprimento do deslocamento na mensagem prévia comunicada.

[0020] Além disso, em uma implementação da invenção, no dispositivo receptor, a identificação das porções idênticas compreende: analisar a cadeia de mensagem recebida e construir uma representação em árvore estruturada para o armazenamento em uma segunda memória cache no dispositivo receptor. A representação em árvore estruturada é armazenada para posterior utilização na construção de mensagens recebidas no receptor.

[0021] Vantajosamente, os candidatos à substituição incluem, de preferência, elementos de um cabeçalho de protocolo de comunicação (por exemplo, o cabeçalho HTTP) e a mensagem WS (por exemplo, envelope SOAP). No entanto, otimizações mais avançadas estão disponíveis, que substituirão as operações, os nomes e até os parâmetros ou resultados.

[0022] De acordo com outro aspecto, é fornecido um aparelho para comunicar mensagens em um ambiente web compreendendo: um meio em um dispositivo emissor suportando implementação de pilha de serviços web (WS) para gerar cadeias de mensagem WS a serem comunicadas para um dispositivo receptor, as ditas cadeias de mensagens comunicadas sendo armazenadas em um primeiro dispositivo de armazenamento em cache no dito dispositivo emissor e armazenadas em um primeiro armazenamento em cache no dito dispositivo receptor; um meio em um dispositivo receptor suportando a implementação de pilha de WS para responder às cadeias de solicitações de mensagens WS recebidas comunicadas ao dispositivo receptor, cada uma da dita implementação de pilha WS nos ditos dispositivos emissor e

Petição 870160076655, de 19/12/2016, pág. 28/58

13/31 receptor construindo e armazenando estruturas de dados intermediárias que representam conteúdo de cadeia de mensagem WS enviados e recebidos e armazenando localmente estruturas de dados intermediárias construídas nos respectivos dispositivos emissor e receptor; a dita implementação de pilha de WS no dito dispositivo emissor implementando meios para construir uma cadeia de mensagem que deve ser comunicada com base em uma estrutura de dados intermediária construída atual e substituindo cada parte identificada nas cadeias de mensagem com um indicador de referência para um local no dito primeiro armazenamento em cache correspondente a uma parte de cadeia de caracteres idêntica associada com a mensagem anterior que foi comunicada e, a dita implementação de pilha de WS no dito dispositivo receptor identificando um indicador de referência na cadeia de mensagem recebida e substituindo uma ou mais partes de cadeia de caracteres idênticas armazenadas em cache no dito primeiro armazenamento em cache no dito dispositivo receptor para construir a mensagem recebida, por onde os recursos de infraestrutura de comunicação de mensagem WS nos ditos dispositivos de envio e recebimento são conservados.

[0023] De acordo com outro aspecto, é fornecido um dispositivo de armazenamento de programa legível por uma máquina, incorporando de forma tangível um programa de instruções executáveis pela máquina para realizar as etapas de método para comunicar mensagens, disse dispositivo de armazenamento de programa executando as instruções para a realização de etapas do método: alocar uma quantidade de uma primeira memória cache em cada um de um dispositivo emissor e um dispositivo receptor, o dito cache para armazenar cadeias de caracteres correspondente às cadeias de mensagem

Petição 870160076655, de 19/12/2016, pág. 29/58

14/31 comunicada e recebidas nos respectivos dispositivos emissor e receptor e, a construção de uma estrutura de dados intermediária representando uma mensagem a ser comunicada, a dita estrutura de dados intermediária adaptada para o armazenamento em uma segunda memória cache do dito dispositivo emissor, e, a construção de uma cadeia de mensagem deve ser comunicada com base na dita estrutura de dados intermediária construída e, para cada mensagem subsequente a ser comunicada: identificar porções em uma estrutura de dados intermediária construída de uma mensagem atual que está sendo construído com partes que são idênticas, como partes presentes em uma estrutura de dados intermediária construída correspondente a uma cadeia de mensagem comunicada anterior, a construção de uma cadeia de mensagem a ser comunicada com base na atual dita estrutura de dados intermediária construída e substituindo cada parte identificada em cadeias de mensagem com um indicador de referência para um local no dito primeiro armazenamento em cache correspondente a uma parte idêntica de cadeia de caracteres associada com a mensagem anterior que foi comunicada e, no dito dispositivo receptor, identificar um indicador de referência em uma cadeia de mensagem recebida e substituir uma ou mais partes de cadeia de caracteres idênticos armazenados em cache no dito primeiro armazenamento em cache no dispositivo receptor para construir a mensagem recebida, através do qual os recursos de infraestrutura de comunicação de mensagens nos ditos dispositivo de envio e recebimento são conservados.

Breve Descrição dos Desenhos

Petição 870160076655, de 19/12/2016, pág. 30/58

15/31 [0024] As concretizações preferidas da presente invenção serão agora descritas, a título de exemplo apenas, e com referência aos desenhos a seguir:

Figuras 1A e 1B fornecem uma arquitetura de serviço Web 10 (Figura 1A) e diagrama de mensagens 25 (Figura 1B) em que a invenção é implementada de acordo com uma concretização preferida;

Figuras 2A e 2B mostram o protocolo de handshake usado para determinar se ambas as extremidades de recepção e envio implementam a otimização de uma concretização preferida da presente invenção e, para definir o tamanho do histórico nas duas extremidades para o mesmo valor;

Figura 3 é um fluxograma descrevendo o processamento SOAP/HTTP do lado do emissor de acordo com a otimização de uma concretização preferida da presente invenção;

Figura 4 é um fluxograma descrevendo o processamento SOAP/ HTTP do lado do receptor de acordo com a otimização de uma concretização preferida da presente invenção;

Figuras 5A, 5B exemplifica o tráfego SOAP de WS é mostrado comunicado em ambos os sentidos (cliente para servidor na Figura 5A e servidor para o cliente na Figura 5B) para duas invocações de WS consecutivas;

Figura 6 retrata, de acordo com uma concretização preferida da presente invenção, as respectivas representações de arvore 255, 260 das duas mensagens de solicitação 205, 210 mostradas na Figura 5A; e

Figuras 7A, 7B ilustram, de acordo com uma concretização preferida da presente invenção, a sobreposição respectiva entre as cadeias respectivas 285, 290, correspondentes aos dois na mensagem SOAP/ cabeçalhos HTML nas invocações de mensagem de solicitação 205, 210 da Figura 5A.

Petição 870160076655, de 19/12/2016, pág. 31/58

16/31

Descrição Detalhada das Concretizações Preferidas [0025] A presente invenção fornece, de acordo com uma concretização preferida, um sistema, método e produto programa de computador para fornecer uma ou mais otimizações para reduzir significativamente overhead de mensagens SOAP gerais em ambientes de serviços Web implantados, como mostrado nas figuras 1A, B. Referência pode ser feita nesta descrição às forma impressa seguintes publicações, disponíveis tanto na ou on-line e aqui incorporadas por referência:

W3C®

Note, Web Services Description

Language (WSDL)

1.1, 15 de março de 2001;

W3C® Recomendation, Extensible Markup

Language

1.0 (Second Edition}, (6 de outubro (http://www.w3.org)

W3C®Recomendation, SOAP Version 1.2

Part : Primer junho de 2003);

W3C® Recomendation, SOAP Version

Part

Messaging

Framework (Recomendation);

W3C® Recomendation, SOAP Version

Part

Adjuncts (Recomendation);

6. W3C® Recomendation, SOAP Version 1.2

Specification

Assertions e Test Collection;

7. W3C® Recomendation, SOAP Message

Transmission

Optimization Mechanism (25

8. W3C® Recomendation,

XML-binary Optimized Packaging,

9. W3C®

Document

Object

Model (DOM) (http://www.w3.org/DOM/ )

De acordo com a primeira extensão opcional para o protocolo de mensagens SOAP, uma nova opção HTTP é fornecida em uma primeira mensagem de solicitação, que propõe

Petição 870160076655, de 19/12/2016, pág. 32/58

17/31 um tamanho de histórico para a direção em particular, por exemplo, o envio. Se o outro (por exemplo, recepção) terminal implementa a extensão, irá responder com um tamanho de histórico para o sentido de resposta e, possivelmente, com uma solicitação de um tamanho de histórico menor para a direção oposta. Este handshake inicial e remotamente semelhante à extensão SACK (Selective Acknowledgement) do protocolo TCP. A capacidade de negociar tamanhos de histórico foi adicionada a este protocolo de handshake. Subsequente ajuste do tamanho do histórico, em qualquer direção, é realizado ao propor um novo número de byte de tamanho de histórico. Aceitação ou rejeição é sinalizada na mensagem de resposta.

[0027] Figuras 2A e 2B mostram particularmente o Protocolo de Handshake 40 usado para determinar se os dois terminais de recepção de WS (cliente WS) 12 e o terminal de envio de WS (servidor WS) 18 implementam a otimização de uma concretização preferida da presente invenção e, para definir o tamanho de histórico em ambas as extremidades para o mesmo valor.

[0028] Como mostrado na Figura 2A, o cliente Web Service 12 em uma mensagem de handshake primeiro 45a propõe um valor para o tamanho de histórico, que além disso, indica para o servidor que o cliente implementa a otimização proposta. Se o servidor do serviço Web 18 implementa a otimização e tem a memória disponível, ele retorna o mesmo tamanho de histórico, ou um valor menor em uma mensagem de resposta de handshake 45b. Caso contrário, como mostrado na figura 2B, o servidor do serviço Web 18 ignora o tamanho da histórico proposto. Existem várias maneiras de implementar isso. Por exemplo, uma aplicação baseada em WS pode usar uma

Petição 870160076655, de 19/12/2016, pág. 33/58

18/31 operação adicional, com um nome e assinatura predefinidos, que é adicionado a todos os terminais implementando a otimização. Assim, por exemplo, a primeira chamada de um cliente 12 seria uma invocação de WS desta operação e o servidor 18 retorna um valor para o tamanho de histórico (Figura 2A) ou uma falha SOAP, se não compreender a solicitação, ou seja, não se aplica a otimização proposta (Figura 2B). Esta implementação tem a desvantagem de exigir uma chamada de WS adicional. Implementações alternativas usar um novo campo de cabeçalho HTTP ou um comentário XML no prolog para a negociação descrita acima. As implementações posteriores não exigem uma chamada de WS adicional, à medida que o protocolo de Handshake 40 combina sobre a primeira chamada de aplicativo. O protocolo de handshake 40 pode ainda ser usado para modificar o tamanho de histórico ou finalizar o uso da otimização proposta mais tarde, durante a interação. Nestas situações, a renegociação pode ser iniciada pelo servidor de WS, se uma das implementações posteriores é usada.

[0029] Deve ser entendido que o tamanho de histórico do cache que é negociado na mensagem de handshake 45a é memória “gerenciada, ou seja, um cache alocado para armazenar o histórico da cadeia de mensagem SOAP somente. Memória utilizada para armazenar em cache (sub)árvores (por exemplo, um cache de arvores), o conteúdo do que é determinado pelas cadeias mantidas no cache de cadeias, não é negociado de acordo com este protocolo de handshaking e essa memória não tem que ser a mesma em ambas as extremidade de cliente (emissor) e receptor. Apenas o cache alocado para armazenar o histórico de cadeia de mensagem SOAP tem que ter o mesmo tamanho em ambas as extremidades.

Petição 870160076655, de 19/12/2016, pág. 34/58

19/31 [0030] Figura 3 é um fluxograma descrevendo o processamento do lado de emissor SOAP/ HTTP de acordo com a otimização de uma concretização preferida da presente invenção.

[0031] Na Figura 3, na geração da pilha WS no terminal de envio, a compactação de acordo com uma concretização é executada, ou seja, as substituições dos elementos de mensagens SOAP são identificadas quando a mensagem SOAP está sendo construída. Isto está em contraste com a esquemas de compressão de cadeia típicos de que atuam, comparando a nova mensagem com o histórico disponível. Mais especificamente, os vários componentes do mecanismo SOAP no terminal de envio terão que manter históricos curtos dos componentes SOAP ainda disponíveis no histórico local. A compressão é totalmente integrada com o caminho de saída SOAP e, portanto, aproveita ao máximo a semântica do protocolo SOAP. Espera-se que este recurso ofereça compressão comparável com energia e os custos latência significativamente mais baixos do que os sistemas existentes, com a vantagem adicional de que quanto mais seja comunicado, mais que é aprendido, ou seja, o mais que pode ser comprimido se histórico bastante é mantido. Como resultado, é possível ainda ajustar o tamanho de histórico usando um algoritmo adaptativo, ou seja, os lados de cliente e emissor podem renegociar uma quantidade do tamanho de histórico de cache que cada lado deve manter. Entende-se, porém, que ambos os lados mantenham a mesma quantidade de cache de cadeia de mensagem. Para este algoritmo trabalhar, o receptor tem que manter pelo menos tanto cache quanto o remetente ou uma quantidade maior.

Petição 870160076655, de 19/12/2016, pág. 35/58

20/31 [0032] Em uma concretização, no lado de envio onde mensagens SOAP são geradas como mostrado na Figura 3, a metodologia 100 implementada em um dispositivo cliente inclui a etapa típica de invocar um stub de envio. O código de execução (rotinas) e infraestrutura de pilha de WS sobre a qual o stub é executado e que tenha sido modificado de acordo com uma concretização da presente invenção, é estabelecido na etapa 102, que permite o roteamento de transações (por exemplo, chamadas de método) para o objeto WS no servidor e/ou permitir a interação com um objeto de servidor para invocar serviços web. Em seguida, na etapa 105, assumindo uma histórico de cache foi previamente negociado (para armazenar o DOM (-like) conteúdo de estrutura de dados de árvore no emissor e receptor) de acordo com um protocolo de handshaking prévio, seja tomada uma decisão quanto a saber se o cache de árvore está vazio. Este cache pode estar vazio antes ou no momento que uma primeira mensagem é enviada quando não há histórico construído. Se o cache de árvore está vazio, conforme determinado na etapa 105, o próximo passo envolve a construção da estrutura de árvore hierárquica Document Object Model (DOM) na etapa 108 que permite o acesso dinâmico e atualização de um documento, e armazenar a árvore de construção no cache de árvore. Então, na próxima etapa 113, a arvore é serializada, por exemplo, através da implementação de rotinas para a conversão da estrutura de dados de árvore armazenada em um fluxo de caracteres que podem ser reagrupados de volta em uma cópia idêntica à estrutura de dados original na mensagem do emissor. Finalmente, na etapa 115, o fluxo de byte serializado é anexado (enrolado) com o cabeçalho HTTP e a solicitação é enviada para o servidor.

Petição 870160076655, de 19/12/2016, pág. 36/58

21/31 [0033] Voltando à Figura 3, na etapa 105, de acordo com as modificações de otimização de uma concretização preferida da invenção, se for determinado que o cache de arvore não está vazio, ou seja, inclui um histórico que compreende estrutura de dados DOM(tipo árvore) previamente construída (s) ou sub-árvores ou fragmentos de árvore (por exemplo, as sucursais) de uma primeira mensagem e/ ou anterior, então a próxima etapa envolve a construção de uma estrutura de árvore expandida a partir da estrutura de árvore existente no cache, como mostrado na etapa 120. Observe que, se a quantidade de tamanho de cache disponível para salvar a representação de cadeia da estrutura de árvore expandida não está disponível, árvores ou partes mais antigos, construídos de (sub-árvores ou fragmentos de árvores) do mesmo pode ser podada na etapa 120. De qualquer maneira, a estrutura de árvore expandida é salva como indicado na etapa 123. Nesta otimização, uma estrutura de árvore existente em cache é construída mediante o uso de elementos da árvore anterior (sub-árvore ou fragmentos), assim, evitando a necessidade de construir uma árvore desde a raiz e conservando recursos de processamento. Continuando na etapa 126, ao analisar a mensagem e construir a sua representação em cadeia, a estrutura de arvore expandida é serializada, convertida em bytes de dados adequados para transmissão. No entanto, para a otimização da concretização preferida, nem todas as árvores construídas devem ser serializadas. Ou seja, uma compressão é aplicada pela qual uma cadeia que foi enviada em uma mensagem anterior (por exemplo, corresponde a uma sub-árvore ou fragmento de árvore, por exemplo, é substituído por um ponteiro de referência anterior que indica onde no histórico de cache de cadeia essa parte de mensagem

Petição 870160076655, de 19/12/2016, pág. 37/58

22/31 foi enviada. Tal ponteiro de referência anterior ou indicador similar é fornecido no local da cadeia e tem atributos que apontam para o local no histórico de cache que a seção de árvore existe, por exemplo, quantos bytes procurar no histórico de cache de cadeia, a fim de recuperar a cadeia construída associada a uma sub-árvore anterior utilizada ou estrutura de dados de fragmento de árvore, e, uma indicação da quantidade de caracteres que foram gerados para que a sub-árvore ou fragmento de árvore. Desta forma, uma compressão é realizada em que o conteúdo de árvore não tem que ser enviado, apenas um ponteiro de referência anterior substituído que permite que o processamento de pilha de WS de receptor recupere o conteúdo exato de seu histórico armazenado em cache e crie a mensagem associada. Em seguida, na etapa 128, é realizada a etapa de compressão do cabeçalho do protocolo de rede responsável por comunicar as mensagens de SW, por exemplo, o cabeçalho HTTP. Assim, finalmente, o cabeçalho HTTP comprimido é acrescentado ao fluxo de byte serializado e a solicitação comprimida é enviada na etapa 129.

[0034] Em uma concretização, é vantajoso realizar uma compressão do cabeçalho HTTP, como o cabeçalho HTTP potencialmente pode representar uma fração significativa da mensagem SOAP. Isso é verdadeiro para todas as ligações HTTP atualmente definido ou previsto, tanto para solicitação HTTP e mensagens de resposta. Para pilhas SOAP projetadas para sistemas embarcados e relativamente simples, essa fração pode ser muito grande, por exemplo, como mostrado no conteúdo de mensagem de cabeçalho HTTP 202, 203 a 200 exemplar invocações exemplo foi mostrado na Figura 5A e 58. No lado do emissor, cabeçalhos HTTP são comprimidos usando um método

Petição 870160076655, de 19/12/2016, pág. 38/58

23/31 muito semelhante a sequência de compressão, mas com o overhead muito mais baixo. Por exemplo, a compressão HTTP pode ser realizada através da implementação de um algoritmo LZW (Lempel Ziv Welch) modificado, a «alteracao» que consiste na aplicação de LZW nos cabeçalhos HTTP enviados anteriormente apenas, e não no cache de cadeia inteiro. Isso ocorre porque a pilha de componentes realizando a compressão sabe que existe somente poucas sub-cadeias que o novo cabeçalho pode ser comparado com sucesso: os das mensagens enviadas anteriormente. No lado do receptor, o cabeçalho comprimido é substituído pela sub-cadeia a que se refere, ou seja, o cabeçalho de uma mensagem anteriormente recebida, e passado para o recipiente da Web, ou seja, a camada de processamento de HTTP, juntamente com todas as informações desta camada foram anexadas à sub-cadeia durante seu processamento. Esta informação adicional, que consiste na maioria de pares (atributo, valor), foi salva para ajudar o processamento subsequente da sub-cadeia; utilizando as informações anexas reduz o overhead de processamento de HTTP do lado do receptor. Assim, a etapa 129 na Figura 3 contempla a etapa de anexar um cabeçalho HTTP comprimido.

[0035] Como se sabe, um analisador DOM cria uma estrutura de árvore na memória a partir de um documento de entrada. DOM é uma interface de plataforma e linguagem neutra que permite que programas e scripts acessem e atualizem dinamicamente o conteúdo, estrutura e estilo de documentos. Além disso, também fornece uma especificação para representar documentos XML como uma hierarquia de objetos Node que também implementa outras interfaces mais especializados (ver http://www.w3.org/DOM/#specs). Alguns tipos de nós podem ter nós filhos de vários tipos, e outros

Petição 870160076655, de 19/12/2016, pág. 39/58

24/31 são nós folha que não podem ter qualquer coisa abaixo deles na estrutura do documento. As implementações de pilha WS usam interfaces/ analisadores DOM para manipular mensagens SOAP, entretanto, outros tipos de analisadores de linguagem estruturada, por exemplo, um analisador SAX, podem ser utilizados sem prejudicar o espirito e escopo da invenção. Assim, a abordagem DOM pode ser substituída pela utilização de analisadores SAX (Simple API para XML, versão atual é SAX 2.0.1) para construir a representação de árvore de uma mensagem SOAP de entrada.

[0036] Assim, ampliando a Figura 3 com maior detalhe, sabe-se que uma API baseada em árvore está centrada em torno de uma estrutura de árvore e, portanto, fornece interfaces de componentes de uma árvore, como interface Document, interface Node, a interface NodeList, interface Element, interface Attr e assim por diante, para o (que é um documento DOM). A execução da pilha de WS que suporta as otimizações da concretização preferida, utiliza uma abordagem semelhante. Entretanto, pelo menos três atributos de nó adicionais são utilizados: correspondente a árvore identificação da mensagem identificar a mensagem, e,

1) o comprimento da cadeia XML enraizada naquele nó, 2) a que a árvore representa para 3) o deslocamento na mensagem.

Esses atributos são usados para gerar o backpointer adicionado no lugar da seção de sub-árvore serializada ou representações de dados de fragmentos de arvore.

[0037]

Elaborando sobre a estrutura de cache de árvore avaliada na etapa 105, o cache de árvore é uma coleção de árvores/ sub-árvores correspondente às últimas poucas mensagens enviadas ou recebidas ou fragmentos destas mensagens; à medida que novas mensagens são enviadas ou

Petição 870160076655, de 19/12/2016, pág. 40/58

25/31 recebidas, as mais antigas são descartadas. Há um número máximo de arvores/ mensagens que o emissor pode usar; da mesma forma, existe um número mínimo de mensagens/ árvores que o receptor deve manter. Os dois números são determinados como o histórico de mensagem mais curto com um comprimento acumulado maior do que o tamanho do histórico negociado. Assim, a elaboração da etapa 126, na Figura 3, a implementação de cache de árvores evita o armazenamento de várias cópias idênticas de sub-árvores e facilita a construção de novas árvores (reutilização) de outras já existentes.

[0038] Assim, elaboração mediante a funcionalidade do lado de envio para a construção de árvore (etapas 123126) quando compor uma mensagem nova, a pilha de WS modificada tenta reutilizar o maior número possível de subárvores a partir do conteúdo de cache de árvore. Na mensagem SOAP, as sub-árvores reutilizadas traduzem em referências para XML textos em mensagens enviadas anteriormente. Apenas sub-árvores correspondentes às mensagens garantidas no cache do receptor são usadas para criar referências de volta na mensagem SOAP/ XML.

[0039] Figura 4 e um fluxograma descrevendo o processamento SOAP / HTTP no lado do receptor de acordo com a otimização de acordo com uma concretização preferida da presente invenção. No lado da recepção, onde as mensagens SOAP são recebidas como mostrado na Figura 4, a metodologia 130 implementada no servidor inclui: receber na mensagem SOAP do cliente (solicitação) e remover o cabeçalho HTTP (etapa 132). Em seguida, na etapa 135, é feita uma determinação sobre se o cabeçalho HTTP foi comprimido. Se na etapa 135, é determinado que o cabeçalho HTTP foi compactado,

Petição 870160076655, de 19/12/2016, pág. 41/58

26/31 em seguida, na etapa 138, o cabeçalho HTTP é descomprimido e o processo continua na etapa 140, indicando o processamento formal realizado no cabeçalho HTTP quando uma mensagem foi recebida. Caso contrário, se for determinado na etapa 135 que o cabeçalho de HTTP não esta compactado, em seguida, o processo prossegue para a etapa 140, que indica o tratamento formal realizado no cabeçalho HTTP quando uma mensagem foi recebida. Após o processamento da etapa 140, uma determinação é feita na etapa 142 para saber se o cache (para armazenar o conteúdo de estrutura de dados de árvore DOM(-like)) está vazio. Esse cache de servidor (lado de recepção) pode estar vazio no momento em que uma primeira mensagem deste emissor especifico é recebida à medida que nenhum histórico ainda foi construído no receptor. Se o cache de arvore está vazio, conforme determinado na etapa 142, em seguida, o processamento no lado de recepção é realizado incluindo etapas tais como: análise da cadeia de solicitação e a construção de uma árvore DOM (-like) (etapa 145); salvar a nova árvore no cache de árvore (etapa 146); e, identificar as operações/ parâmetros na solicitação e chamar o stub no lado de receptor de WS (etapa 148). Entende-se que o cliente processa as mensagens recebidas, que constituem as respostas do servidor.

[0040]

No lado de recepção onde as mensagens SOAP/

HTTP são recebidas, se for determinado na etapa 142 que o cache de árvores (para armazenar o conteúdo de estrutura de dados de árvore DOM (-like)) não é vazia, então o próximo passo envolve a análise da cadeia de solicitação e construir a árvore expandida DOM (-like) na etapa 150. No entanto, nesta concretização, a árvore construída utiliza uma subárvore armazenada em cache prévia (previsto) ou

Petição 870160076655, de 19/12/2016, pág. 42/58

27/31 representação de dados de fragmento de árvore de que foi previamente armazenado no histórico de cache de cadeia local a partir de uma mensagem anterior (invocação). De acordo com a concretização preferida, ao construir a árvore correspondente a uma mensagem recebida, o receptor utiliza sub-árvores armazenadas em cache com as instruções pelos ponteiros de referência anterior nas mensagens SOAP/ XML de entrada, se houver. Isto é, quando o conteúdo de XML explícito é recebido, uma nova sub-árvore é construída e inserida na árvore que representa a mensagem. A nova árvore pode reutilizar grandes frações de árvores existentes no cache do receptor, como indicado pelas referências anteriores na mensagem recebida. Em seguida, a nova estrutura de árvore expandido DOM (-like) é salva no cache, como indicado na etapa 153. Finalmente, na etapa 156, a operação/ parâmetros são identificados e um stub de recepção de WS chamado para responder à mensagem recebida ao chamar a funcionalidade de WS, como indicado na etapa 156.

[0041] Assim, no terminal de recepção, onde a descompressão é realizada, as otimizações que se seguem são fornecidas de acordo com uma concretização preferida da presente invenção. Particularmente, qualquer ponteiro de referência anterior é substituído por cadeias no histórico de cache de cadeia local e integrado no fluxo de mensagens recebidas. De preferência, uma referência é sempre substituída por uma cadeia de caracteres que foi previamente analisada pelo caminho de entrada do mecanismo SOAP local. Uma vez analisadas, as cadeias são anotadas com seus r6tulos de nível HTTP/ SOAP, como URL, EncodingStyleToken, etc. A presente invenção, de preferência, propõe, portanto, modificações no caminho de entrada para permitir a integração

Petição 870160076655, de 19/12/2016, pág. 43/58

28/31 direta da cadeia pré-analisada para a análise da mensagem de

WS	recebida. Isso resultará em	analisar	cada	um	dos	segmentos
de	cadeia comprimidos somente	uma vez.
	[0042] Em um exemplo	muito simples	de	uma	operação
de	compressão realizada de	acordo	com	a	concretização

preferida, a referência é feita agora às Figuras 5A, 5B, que retratam particularmente traços de mensagem exemplares que ilustram os tipos de repetição em chamadas e respostas de WS 200. Os traços são capturados com uma ferramenta chamada TCPMonitor, parte do Axis, que é uma implementação de código aberto da especificação SOAP e está disponível no site da Apache (www.apache.org). Nas Figuras 5A, 5B, tráfego SOAP de WS exemplar é mostrado comunicado em ambos os sentidos (cliente para servidor na Figura 5A e servidor para o cliente na Figura 5B) para dois duas chamadas de WS consecutivas. Conforme mostrado na Figura 5A, a primeira solicitação (do cliente para o servidor), inclui um cabeçalho HTTP 202 seguido pela mensagem SOAP para a chamada 'add' 205. No exemplo da operação 'Add', os dois parâmetros de exemplo são '7 'e '5'. Na segunda solicitação (do cliente para o servidor) um cabeçalho HTTP 203 é seguido pela mensagem SOAP para a segunda chamada 210 uma operação 'mul' com os parâmetros de exemplo '3 'e '11'. A Figura 5B ilustra as respectivas mensagens de resposta (a mensagem transmitida a partir do servidor para o cliente) 215, 220 à resposta para a primeira 'Add' e segunda 'mul' chamadas 205, 210, respectivamente.

[0043] Figura 6 ilustra respectivas representações de árvore 255, 260 das duas mensagens de solicitação 205, 210 mostradas na Figura 5A. O fragmento de mensagem comum 275 em cada uma das duas chamadas (sobreposição) é mostrado.

Petição 870160076655, de 19/12/2016, pág. 44/58

29/31

Nota-se que apenas a parte SOAP da mensagem é representada como uma árvore, ou seja, o cabeçalho HTTP não é. Os atributos são representados como nós quadrados 265, 280, anexados aos nós de elemento (círculos).

[0044] Figura 7A ilustra a sobreposição 277 entre respectivas cadeias 285, 290, correspondentes às duas mensagens de solicitação SOAP 205, 210 da Figura 5A. A pilha de WS modificada substitui as áreas em destaque com os ponteiros de referência anterior, usando uma codificação compacta. Figura 7B ilustra a sobreposição 297 entre as mesmas duas mensagens de solicitação, mas em seus cabeçalhos HTTP. Esta otimização exige mudanças no mecanismo HTTP suportando o mecanismo SOAP que ambos fazem parte da pilha de WS.

[0045] Vantajosamente, o mecanismo da presente invenção, de acordo com uma concretização preferida, requer modificações para o caminho de entrada, e espera-se render economia substancial no tempo de CPU e consumo de memória, que se traduzirá numa economia de energia significativa durante o processamento de mensagens de WS.

[0046] Nota-se que as otimizações propostas não tem que ser simétricas. A otimização pode ser ativada apenas em uma direção quando dois dispositivos têm características de recursos muito diferentes, como para um par de desktop/ telefone celular, ou quando as mensagens em uma direção são dominadas por um componente pseudoaleatório, como um resultado criptografado muito grande. Para desativar a otimização em uma determinada direção definir o tamanho de histórico para zero.

[0047] A presente invenção tem sido descrita com referência aos diagramas de métodos, equipamentos (sistemas)

Petição 870160076655, de 19/12/2016, pág. 45/58

30/31 e produtos de programa de computador, de acordo com concretizações da invenção. Será entendido que cada diagrama pode ser implementado por instruções do programa de computador. Estas instruções de programa de computador podem ser fornecidas a um processador de um computador de uso geral, computador de aplicação específica, processador integrado ou outros aparelhos de processamento de dados programáveis para produzir uma máquina, de modo que as instruções, que executam através do processador do computador ou outro aparelho de processamento de dados programável, criar meios para implementar as funções especificadas aqui.

[0048] Estas instruções de programa de computador também podem ser armazenadas em uma memória legível por computador que pode direcionar um computador ou outro aparelho de processamento de dados a funcionar de uma forma particular, de modo que as instruções armazenadas na memória legível por computador produzam um artigo de fabricação incluindo meio de instruções que implementa as funções aqui especificadas.

[0049] As instruções de programa de computador também podem ser carregadas em um aparelho de processamento de dados legível por computador ou outro programável para realizar uma série de etapas operacionais a serem realizadas no computador ou outro aparelho programável para produzir um processo implementado por computador de modo que instruções que executam no computador ou outro aparelho programável fornecem etapas para implementar as funções aqui especificadas.

[0050] Embora a invenção tenha sido mostrada e descrita de forma particular em relação às concretizações

Petição 870160076655, de 19/12/2016, pág. 46/58

31/31 ilustrativas e pré-formadas da mesma, será entendido por aqueles versados na técnica que as acima e outras modificações na forma e detalhes podem ser feitas na mesma sem se afastar do espírito e escopo da invenção que deveria estar limitado somente pelo escopo das reivindicações anexas.

Claims

REIVINDICAÇÕES

1. Método para comunicação de mensagens caracterizado pelo fato de que compreende:

atribuir uma quantidade de um primeiro armazenamento de cache em cada um de um dispositivo emissor e um dispositivo receptor, o referido cache para armazenar cadeias de caracteres correspondendo as cadeias de mensagens comunicadas e recebidas nos respectivos dispositivos emissor e receptor, e construir uma estrutura de dados intermediária que representa uma mensagem a ser comunicada, a referida estrutura de dados intermediária adaptada para armazenamento em um segundo armazenamento de cache no referido dispositivo emissor; e construir uma cadeia de mensagem para ser comunicada com base na referida estrutura de dados intermediária construída; e para cada mensagem subsequente a ser comunicada:

identificar porções em uma estrutura de dados intermediária construída para uma mensagem atual sendo construída com porções que são idênticas a porções semelhantes presentes em uma estrutura de dados intermediária construída correspondendo a uma cadeia de

mensagem comunicada anteriormente;

construir uma cadeia de mensagem a ser comunicada com base na estrutura de dados intermediária construída atual e substituir cada porção identificada na cadeia de mensagens com indicador de referência para um local no referido primeiro armazenamento de cache que corresponde a uma porção de cadeia de caracteres idêntica associada com a mensagem anterior que foi comunicada; e

Petição 870190033836, de 08/04/2019, pág. 22/53
2/6 no referido dispositivo receptor, identificar um indicador de referência em uma cadeia de mensagem recebida e substituindo uma ou mais porções de cadeia de caracteres idênticas armazenadas em cache no referido primeiro armazenamento em cache no referido dispositivo receptor para construir a mensagem recebida, em que os recursos de infraestrutura de comunicação de mensagem no dispositivo emissor e receptor são conservados.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que as referidas etapas de construção de uma cadeia de mensagem a ser comunicada compreendem a serialização da referida estrutura de dados intermediária construída para formar uma cadeia de mensagem.
3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que a referida estrutura de dados intermediária compreende uma representação de árvore estruturada de uma mensagem, as referidas porções de cadeia identificadas compreendendo uma ou mais sub-árvores ou fragmentos de arvore.
4. Método, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que a referida alocação do referido primeiro armazenamento em cache no referido dispositivo emissor e receptor compreende: implementar protocolo de handshake inicial entre os referidos dispositivos para comunicar a primeira quantidade de armazenamento em cache a ser atribuída.
5. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que o indicador de referência se refere a atributos de uma porção de cadeia de mensagem serializada correspondendo a uma porção de fragmento ou subárvore em uma estrutura de dados intermediária construída

Petição 870190033836, de 08/04/2019, pág. 23/53

3/6 que é idêntica a uma sub-árvore ou porção de fragmento presente em uma estrutura de dados intermediária construída que corresponde a uma cadeia de mensagem comunicada anterior.
6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que um atributo compreende uma indicação de uma mensagem enviada anteriormente.
7. Método, de acordo com a reivindicação 5 ou 6, caracterizado pelo fato de que um atributo compreende uma ID de mensagem identificando a representação de árvore de uma mensagem anterior comunicada.
8. Método, de acordo com a reivindicação 5, 6 ou 7, caracterizado pelo fato de que um atributo compreende o comprimento da cadeia correspondente à arvore identificada.
9. Método, de acordo com a reivindicação 5, 6, 7 ou 8, caracterizado pelo fato de que um atributo compreende o comprimento do deslocamento na mensagem anterior comunicada.
10. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que ainda compreende no referido dispositivo receptor, a etapa de identificar porções compreendendo:

analisar a referida cadeia de mensagem recebida e construir uma representação de árvore estruturada para armazenamento em um segundo armazenamento em cache no referido dispositivo receptor, a referida representação de árvore estruturada sendo armazenada para posterior utilização na construção de mensagens recebidas no referido receptor.
11. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que a quantidade do referido primeiro armazenamento em cache alocado em cada dispositivo emissor cliente e um dispositivo receptor é fixa, sendo que,

Petição 870190033836, de 08/04/2019, pág. 24/53

4/6 à medida que novas mensagens são enviadas ou recebidas, uma ou mais sub-árvores mais velhas ou fragmentos de sub-árvore são descartados à medida que mensagens de cadeia correspondentes são descartadas no referido primeiro armazenamento em cache.
12. Aparelho para comunicar mensagens em um ambiente da web caracterizado pelo fato de que inclui:

meio em um dispositivo emissor para suportar uma implementação de pilha de serviços Web (WS) para a geração de cadeias de mensagem de WS a serem comunicadas para um dispositivo receptor, um primeiro dispositivo de armazenamento em cache no referido dispositivo remetente e um primeiro armazenamento em cache no referido dispositivo receptor para armazenar as referidas cadeias de mensagem comunicadas;

meio em um dispositivo receptor suportando uma implementação de pilha WS para responder às cadeias de solicitações de mensagens WS recebidas comunicadas para o referido dispositivo receptor, cada referida implementação de pilha WS nos referidos dispositivos emissor e receptor construindo e armazenando estruturas de dados intermediárias (255, 260) representando conteúdo de cadeia de mensagem WS enviado e recebido e armazenando localmente estruturas de dados intermediárias construídas nos respectivos dispositivos emissor e receptor;

a referida implementação de pilha WS no dispositivo emissor implementando meios para identificar porções em uma estrutura de dados intermediária construída para uma mensagem atual sendo construída com porções que são idênticas às porções similares presentes em uma estrutura de dados intermediária construída correspondente a uma cadeia de

Petição 870190033836, de 08/04/2019, pág. 25/53

5/6 mensagem comunicada anterior; e meios para construir uma cadeia de mensagem a ser comunicada com base na estrutura de dados intermediária construída atual e substituir cada porção identificada na cadeia de mensagens com um indicador de referência para um local no referido primeiro armazenamento em cache que corresponde a uma porção de cadeia de caracteres idêntica associada com a mensagem anterior que foi comunicada; e a referida implementação de pilha WS no dispositivo receptor identificando um indicador de referência em uma cadeia de mensagem recebida e substituindo uma ou mais porções de cadeia de caracteres idênticas armazenadas em cache no referido primeiro armazenamento em cache no referido dispositivo receptor para construir a mensagem recebida, em que os recursos de infraestrutura de comunicação de mensagem WS no dispositivo emissor e receptor são conservados.
13. Aparelho, de acordo com a reivindicação 12, caracterizado pelo fato de que ainda compreende meio para implementar um protocolo de handshake inicial entre os dispositivos emissor e receptor para a negociação de uma quantidade da primeira memória de armazenamento em cache para armazenamento local de um histórico de cadeia de mensagem nos respectivos dispositivos emissor e receptor, com a quantidade do primeiro armazenamento em cache para o referido dispositivo receptor sempre igual ou maior do que o primeiro armazenamento em cache do emissor.
14. Aparelho, de acordo com a reivindicação 12 ou 13, caracterizado pelo fato de que a referida estrutura de dados intermediária construída compreende uma representação de árvore estruturada de uma mensagem, as referidas porções de

Petição 870190033836, de 08/04/2019, pág. 26/53

6/6 cadeia identificadas compreendendo uma ou mais sub-árvores ou fragmentos de árvore, em que uma quantidade do referido primeiro armazenamento de histórico de cache alocado em cada dispositivo emissor e um dispositivo receptor cliente é fixa, sendo que, à medida que novas mensagens são enviadas ou recebidas, uma ou mais sub-árvores mais velhas ou fragmentos de árvore são descartados à medida que mensagens de cadeia correspondentes são eliminadas no referido primeiro armazenamento em cache, ou uma quantidade do primeiro armazenamento em cache alocado em cada dispositivo emissor cliente e um dispositivo receptor é adaptável para a expansão, desde que cada quantidade de armazenamento de histórico de cache no referido receptor seja igual ou superior em cada dispositivo emissor cliente.