BR112014008762B1 - Meio de armazenamento legível por computador, sistema e método para cumprir solicitações em um dispositivo - Google Patents

Abstract

meio de armazenamento legível por computador e sistema e método para satisfazer as solicitações em um dispositivo. a invenção refere-se a arquiteturas de servidor/cliente (100), o aplicativo de servidor (104) e os aplicativos de cliente (108) que são, frequentemente, desenvolvidos em diferentes linguagens e executados em diferentes ambientes especializados para diferentes contextos de cada aplicativo (como, baixo nível, grande rendimento, plataforma especializada, e sem instruções de monitoramento de estado no servidor, e linguagens de alto nível, flexíveis, de plataforma independente e monitoramento de estado no cliente) e são, frequentemente, executadas em diferentes dispositivos. a convergência desses ambientes (como, javascript de lado do servidor com o uso de node.js) permite que um servidor preste serviços a aplicativos de cliente (108) executados no mesmo dispositivo. o servidor local pode monitorar eventos locais e executar um ou mais scripts (202) de servidor associados a eventos locais particulares em nome de clientes locais. técnicas que permitem desenvolvimento de serviços de evento local (206) na mesma linguagem e ambiente que aplicativos de cliente, e o uso do código de lado do servidor no fornecimento de serviço de evento local.

Description

ANTECEDENTES

[001] Dentro do campo de computação, muitos cenários envol vem uma arquitetura servidor-cliente a fim de permitir uma execução de um aplicativo no cliente. Como um primeiro exemplo, um dispositivo de servidor Web pode fornecer instruções e/ou conteúdo que compreende um aplicativo da web para um segundo dispositivo para execução dentro de um navegador da web. Como um segundo exemplo, uma loja de aplicativo pode fornecer instruções que compreendem um aplicativo local implantável que pode executar inteiramente em um segundo dispositivo. Como um terceiro exemplo, um servidor de banco de dados pode fornecer dados para facilitar a execução de um aplicativo em um segundo dispositivo.

[002] Em vista desses e outros cenários, a arquitetura servi- dor/cliente levou a tecnologias especializadas que executam em cada dispositivo. Em alguns casos, tal especialização leva a um desenvolvimento diretamente oposto em vista das diferentes circunstâncias do servidor e do cliente. Por exemplo, o dispositivo de servidor frequentemente envolve um código especializado para o contexto de servidor, tal como executar ao mesmo tempo aplicativos em favor de diversos clientes; cumprir solicitações de maneira desempenhável e em escala (por exemplo, que executam código altamente aperfeiçoado a fim de agilizar o cumprimento de solicitações, e a redução ou a eliminação de dependência de uma interface de usuário); reduzir interações classificadas, em que o servidor armazena dados associados a uma primeira transação a fim de cumprir uma segunda transação; e validar e isolar os contextos de execução de solicitações recebidas de diferentes cli-entes a fim de reduzir vulnerabilidades de segurança. Similarmente, o dispositivo de cliente frequentemente envolve código especializado para o contexto de cliente, tal como a codificação de instruções em uma linguagem de plataforma agnóstica que não depende de uma configuração de dispositivo particular; a configuração de instruções para executar dentro de um navegador da web; a provisão de uma interface de usuário robusta; e o armazenamento de informações sobre o cliente (por exemplo, na forma de cookies armazenados em um cache de navegador da web) a fim de persistir informações de uma primeiratransação com o apoio de uma segunda transação. Nesses e outros modos, a especialização do servidor e contextos de cliente levaram a muitos tipos diferentes de instruções que executam nesses diferentes dispositivos.

SUMÁRIO

[003] Esse Sumário é fornecido para introduzir uma seleção de conceitos em uma forma simplificada que são adicionalmente descritos abaixo na Descrição Detalhada. Esse Sumário não se destina a identificar fatores chave ou características essenciais da matéria reivindicada, nem se destina a ser usado para limitar o escopo da matéria reivindicada.

[004] Embora a especialização divergente do servidor e contex tos de cliente tenha facilitado o desempenho de cada tipo de dispositivo, tal divergência causa várias dificuldades. Como um exemplo, se o servidor executa um tipo de código (por exemplo, instruções que são particularmente configuradas para as capacidades do servidor) e o cliente executa um segundo tipo de código (por exemplo, instruções de plataforma agnóstica e flexíveis que podem executar de modo equivalente em muitos dispositivos), tais diferenças podem complicar o desenvolvimento interoperativo de um aplicativo de servidor e um aplicativo de cliente devido a diferenças nas linguagens, interfaces de programação de aplicativo (APIs), e padrões de dados. Adicionalmente, os desenvolvedores precisam entender duas linguagens diferentes e ambientes de execução, e técnicas para converter tipos de dados e objetos trocados entre os mesmos. Como resultado, recentes desenvolvimentos envolveram a convergência no desenvolvimento desses ambientes, tal como o desenvolvimento e popularidade do modelo No- de.js, envolvendo código JavaScript no lado do servidor com constru- tos de linguagem e APIs especializadas para o contexto de servidor, permitindo, assim, o desenvolvimento de código de servidor e código de cliente na mesma linguagem e compartilhar APIs e tipos de dados. Entretanto, tais ambientes de desenvolvimento de servidor e cliente convergentes são tipicamente aplicados na interação de um aplicativo de servidor que executa em um dispositivo de servidor e aplicativos de cliente que executam em um ou mais dispositivo de clientes.

[005] São apresentadas no presente documento técnicas para aplicar ambientes de desenvolvimento de servidor e cliente convergentes para uso em um único dispositivo. Em particular, tais técnicas podem permitir a um dispositivo desempenhar processamento relacionado a eventos locais em favor de um aplicativo de cliente que executa no dispositivo, através de um servidor local fornecido no mesmo dispositivo. Por exemplo, o dispositivo pode executar um servidor local (tal como um servidor Web) configurado para monitorar eventos de dispositivo local, e para aceitar solicitações por aplicativos de cliente no mesmo dispositivo para subscrever a um ou mais eventos locais. O servidor local também pode associar um ou mais scripts de servidor, e mediante a detecção de uma ocorrência de um evento local ao qual um aplicativo de cliente é subscrito, o servidor local pode executar o(s) script(s) de servidor associado(s) ao evento local em favor do local dispositivo.

[006] Por exemplo, o evento local pode compreender um evento móvel, tal como uma sessão de comunicação de voz recebida, e um aplicativo de cliente pode pedir algum processamento particular para a sessão de comunicação de voz, tal como gravar a sessão. Entretanto, aplicativos de cliente que executam em um dispositivo móvel podem não ser executados no momento da sessão de comunicação de voz recebida, e assim podem não estar monitorando a ocorrência de tal evento local. Alternativamente, o modelo de segurança de um dispositivomóvel pode proibir comumente que aplicativos de cliente interajam com tais eventos locais como uma medida de segurança ou qualidade de serviço (por exemplo, o aplicativo local pode estar executando dentro de um construto de isolamento do dispositivo, tal como dentro de um navegador da web). Ao invés disso, e de acordo com as técnicas apresentadas no presente documento, o aplicativo de cliente pode emitir para um servidor local no mesmo dispositivo (que executa continuamente e fora do navegador da web) um pedido de assinatura que identifica o evento local de sessão de comunicação de voz recebida. Mediante a detecção de tal evento, o servidor local pode executar um ou mais scripts de servidor relacionados ao evento local em nome do aplicativo de cliente. Ademais, o script de servidor pode ser projetado em um ambiente de desenvolvimento similar ao aplicativo de cliente (por exemplo, ambos o script de servidor e o aplicativo de cliente local podem ser escritos em JavaScript, em que o script de servidor utiliza um API de lado de servidor Node.js), facilitando, assim, o desenvolvimento desses aplicativos interativos de maneira consistente e compatível. Tais vantagens podem ser alcançadas através das variações da arquitetura servidor/cliente apresentadas no presente documento.

[001] Para a realização do que foi relatado anteriormente e finali dades relacionadas, a descrição a seguir e desenhos anexos apresentam certos aspectos e implantações ilustrativos. Esses são indicativos de apenas algumas das várias maneiras na qual um ou mais aspectos podem ser empregados. Outros aspectos, vantagens e características inovadores da revelação se tornarão aparentes a partir da Descrição Detalhada a seguir, quando considerados em conjunto com os desenhos anexos.

DESCRIÇÃO DOS DESENHOS

[002] A Figura 1 é uma ilustração de um cenário exemplificativo que ilustra uma arquitetura cliente/servidor para cumprir solicitações de aplicativos de cliente relacionados a eventos que surgem em um dispositivo de cliente e um dispositivo de servidor.

[003] A Figura 2 é uma ilustração de um cenário exemplificativo que ilustra uma arquitetura cliente/servidor para cumprir solicitações de aplicativos de cliente relacionados a eventos locais em conformidade com as técnicas apresentadas no presente documento.

[004] A Figura 3 é uma ilustração de um método exemplificativo para configurar um dispositivo para cumprir solicitações de aplicativos de cliente relacionados a eventos locais em conformidade com as técnicas apresentadas no presente documento.

[005] A Figura 4 é um diagrama de blocos de componente que ilustra um sistema exemplificativo para cumprir solicitações de aplicativos de cliente relacionados a eventos locais em conformidade com as técnicas apresentadas no presente documento.

[006] A Figura 5 é uma ilustração de um meio legível em compu tador exemplificativo que compreende instruções executáveis por processador configuradas para incorporar uma ou mais das provisões apresentadas no presente documento.

[007] A Figura 6 é uma ilustração de um cenário exemplificativo que apresenta um modelo de assinatura de evento que permite que aplicativos locais subscrevam a eventos locais gerados por componentes do dispositivo, sendo respectivos componentes identificados por um endereço de componente.

[008] A Figura 7 é uma ilustração de um cenário exemplificativo que apresenta uma malha de dispositivo que compreende um conjunto de dispositivos, respectivamente, que executam um servidor local configurado para receber e cumprir pedidos de assinatura de evento recebidos de ambos os aplicativos de cliente local e aplicativos de cliente remoto que executam em outros dispositivos da malha de dispositivo.

[009] A Figura 8 ilustra um ambiente de computação exemplifica- tivo em que uma ou mais das provisões apresentadas no presente documento podem ser implantadas.

DESCRIÇÃO DETALHADA

[010] A matéria reivindicada é agora descrita com referência aos desenhos, em que numerais de referência similares são usados para se referir a elementos similares ao longo da mesma. Na descrição a seguir, para fins de explicação, inúmeros detalhes específicos são apresentados a fim de fornecer um entendimento completo da matéria reivindicada. Pode ser evidente, entretanto, que a matéria reivindicada possa ser praticada sem esses detalhes específicos. Em outros casos, estruturas e dispositivos são mostrados em forma de diagrama de blocos a fim de facilitar a descrever a matéria reivindicada.

Introdução

[011] Dentro do campo de computação, muitos cenários envol vem uma arquitetura servidor/cliente que compreende um aplicativo de servidor (por exemplo, um servidor Web) que fornece um ou mais serviços em favor de um ou mais aplicativos de cliente. Como um primeiro exemplo, o serviço pode incluir a provisão de conteúdo de web, incluindo páginas da web e aplicativos da web, para ser renderizado dentro de um navegador da web de um dispositivo de cliente. Como um segundo exemplo, o serviço pode incluir uma loja de aplicativo configurada para armazenar um conjunto de aplicativos executáveis em vários dispositivos, e para fornecer um dispositivo particular com um ou mais aplicativos que podem ser executados no mesmo. Como um terceiro exemplo, o serviço pode incluir o armazenamento de dados (por exemplo, em um banco de dados) e a provisão de tais dados para uso dentro de vários aplicativos "orientados por dados" que executam nos respectivos dispositivos de cliente. No modelo tradicional, um aplicativo de servidor funciona como um processo residente de um dispositivo para aguardar uma conexão iniciada por um aplicativo de cliente, recebersolicitações pelo aplicativo de cliente, e cumprir tais solicitações a fim de fornecer o serviço ao aplicativo de cliente.

[012] Em muitos tais cenários, o aplicativo de servidor executa em um dispositivo de servidor, e o aplicativo de cliente executa em um ou mais dispositivos de cliente. Os dispositivos podem apresentar diferentes capacidades adequadas para cada papel. Por exemplo, o dispositivo de cliente pode compreender um dispositivo orientado por usuário (por exemplo, uma estação de trabalho, computador do tipo laptop, dispositivo do tipo tablet, telefone móvel, ou outra ferramenta) que executa o aplicativo de cliente em favor de um usuário, e pode ser especializado para tais interações (por exemplo, incluindo dispositivos de entrada capacitados para toque e componentes de som e exibição de alta qualidade). Em contrapartida, o dispositivo de servidor pode compreender um dispositivo orientado por serviço (por exemplo, um componente de servidor "sem comando" que carece de um componente de exibição dedicado), e pode ser especializado para a satisfação de solicitações de serviço de maneira com alto desempenho (por exemplo, que tem processadores de alto rendimento, um cache de dados de grande capacidade, e recurso de rede abundante). O dispositivo de servidor pode compreender diversos dispositivos de servidor que operam entre si na maneira de um parque de servidores. Isto é, os dispositivos de cliente podem ser configurados para fornecer uma experiência de usuário atraente, enquanto os dispositivos de servidor podem ser configurados para agilizar o manuseio de solicitações de serviço e a confiabilidade de tais dispositivos (por exemplo, através de capacidades de failover (transferência automática por falha) fornecidas em um parque de servidores).

[013] Em vista dessas e outras considerações, as técnicas para desenvolver aplicativos de servidor têm sido tipicamente diferentes em diversos aspectos notáveis de técnicas para desenvolver aplicativos de cliente. Como um primeiro exemplo, aplicativos de cliente são frequentemente concebidos para executar em uma ampla variedade de dispositivos de cliente, e podem ser, portanto, desenvolvidos em uma linguagem de plataforma agnóstica (por exemplo, JavaScript, que tem capacidade de executar dentro de qualquer navegador da web). Em contrapartida, aplicativos de servidor são frequentemente desenvolvidos com o uso de técnicas de desenvolvimento que são altamente sintonizados e personalizados para a configuração particular do servidor a fim de promover o desempenho. Como um segundo exemplo, aplicativos de cliente podem ser concebidos como "classificados", isto é, que persistem algumas informações sobre um primeiro pedido emitido por um aplicativo de cliente ao servidor a fim de fornecer contexto e continuidade para um segundo pedido emitido pelo aplicativo de cliente para o dispositivo de servidor. Por exemplo, navegadores da web são frequentemente configurados para armazenar "cookies" na máquina do usuário para permitir que um servidor identifique o dispositivo de cliente novamente mais tarde. Em contrapartida, aplicativos de servidorsão frequentemente concebidos de maneira "sem estado", através da qual dados armazenados sobre qualquer primeira transação particular são reduzidos a fim de elevar a dimensionalidade do aplicativo de servidor quando do cumprimento em favor de muitos aplicativos de cliente.

[014] A Figura 1 apresenta uma ilustração de um cenário exem- plificativo 100 que apresenta uma interação de um aplicativo de servi- dor 104 que executa em um dispositivo de servidor 102 e um aplicativo de cliente 108 que executa em um dispositivo de cliente 106. O dispositivo de servidor 102 pode ser conectado a uma rede (por exemplo, a internet ou uma rede de área local (LAN)) e configurado para aguardar conexão de um ou mais aplicativos de cliente 108. Mediante tal conexão, o aplicativo de cliente 108 pode fornecer uma ou mais solicitações ao aplicativo de servidor 104, tal como um pedido para conteúdo de web, um aplicativo executável no dispositivo de cliente 106, ou dados utilizados por um aplicativo "orientado por dados". O aplicativo de servidor 104 pode cumprir tais solicitações em nome do aplicativo de cliente 108, e o dispositivo de cliente 106 pode apresentar os resultados de tal serviço para um usuário 110. A fim de satisfazer os diferentes papéis desses dispositivos, o aplicativo de servidor 104 é com frequência particularmente configurado para utilizar as capacidades parti-culares do dispositivo de servidor 102. Em contrapartida, o aplicativo de cliente 108 é frequentemente fornecido em uma linguagem de alto nível, tal como JavaScript, que pode executar em uma grande variedade de dispositivos de cliente 106 independentemente das capacidades do dispositivo de cliente particular 106.

[015] Como um exemplo particular, o aplicativo de servidor 104 pode ser fornecido para notificar aplicativos de cliente 108 e/ou dispositivos de cliente 106 de eventos de servidor 112 detectados pelo dispositivo de servidor 102, tal como o recebimento de novos dados pelo dispositivo de servidor 102 ou o monitoramento de condições ambientais locais (por exemplo, monitoramento de clima ou imagens capturadas de um ambiente no qual o dispositivo de servidor 102 é posicionado). O aplicativo de cliente 108 pode pedir notificação de tais eventos de servidor 112, e mediante a detecção de um evento de servidor 112, o aplicativo de servidor 104 pode enviar uma notificação de evento de servidor 114 ao aplicativo de cliente 108. Adicionalmente, o dispositivo de cliente 106 pode monitorar eventos de dispositivo de cliente 116, tal como entrada de usuário recebida do usuário 110 ou um componente de entrada, e pode executar o monitoramento de evento de dispositivo de cliente 118 para detectar e relatar tais serviços. Por exemplo, o dispositivo de cliente 106 pode incluir uma unidade de hardware que é configurada para monitorar eventos de hardware e para fornecer notificações de evento de dispositivo de cliente 120 que relatam tais eventos de hardware para aplicativos de cliente 108. Dessa maneira, o aplicativo de servidor 104 e o aplicativo de cliente 108, que executam em diferentes papéis e em diferentes dispositivos, podem operar entre si para informar o aplicativo de cliente 108 sobre os eventos de servidor 112 detectados pelo aplicativo de servidor 104 e os eventos de dispositivo de cliente 116 detectados pelo monitoramento de evento de dispositivo de cliente 118.

[016] Entretanto, a arquitetura apresentada no cenário exemplifi- cativo 100 da Figura 1 pode apresentar algumas desvantagens. Em particular, o desenvolvimento do aplicativo de servidor 104 em vista das propriedades especializadas do dispositivo de servidor 102 pode diferir significativamente do desenvolvimento do aplicativo de cliente 108 em uma linguagem de maneira generalizada para uma variedade de dispositivos. Devido aos diferentes ambientes e linguagens de desenvolvimento, desenvolvedores podem precisar entender ambos os ambientes de desenvolvimento e negociar as diferenças para a intero- peração do aplicativo de servidor 104 e do aplicativo de cliente 108 (por exemplo, que compete com diferenças em ambientes de progra-mação de aplicativo disponíveis (APIs) e conversão de formato de dados). A fim de reconciliar tais diferenças, modelos de desenvolvimento de aplicativo de servidor mais recentes têm convergido com desenvolvimento de aplicativo de cliente para fornecer consistência no desenvolvimento de tais aplicativos interoperativos. Como um primeiro exemplo, JavaScript tem sido tradicionalmente estimado como desempenho inadequado para aplicativos de servidor, mas a familiaridade difundida com JavaScript dentre a comunidade de desenvolvimento levou ao desenvolvimento de Node.js, um módulo de JavaScript que fornece execução no lado do servidor de código de JavaScript. Como um segundo exemplo, técnicas foram concebidas para permitir que servidores executem linguagens de alto nível (tal como JavaScript) com maior desempenho, por exemplo, compilando-se JavaScript em código nativo que pode executar mais rápido no dispositivo de servidor 102. Desenvolvedores podem, portanto, usar a mesma linguagem e APIs similares para desenvolver ambos os aplicativos de servidor 104 e os aplicativos de cliente 108. Em vista de tais tecnologias convergen-tes,técnicas podem ser concebidas para utilizar código de lado de servidor em novos cenários.

Técnicas Apresentadas

[017] É apresentado no presente documento tal cenário em que um aplicativo de servidor 104 pode fornecer serviços relacionados a eventos de dispositivo de cliente 116 associados a um dispositivo de cliente 106. Em particular, um aplicativo de servidor 104 pode executar em um dispositivo 106 para fornecer serviços relacionados a evento local para um ou mais aplicativos de cliente 108 que executam no mesmo dispositivo. Por exemplo, um servidor Web tradicional pode executar passivamente, mas continuamente, no dispositivo de cliente 107, e pode aguardar solicitações para serviços de evento local iniciados por um ou mais aplicativos da web de cliente local que executam dentro de um navegador da web no mesmo dispositivo de cliente 106. Tais solicitações podem incluir, por exemplo, notificar o dispositivo de cliente 106 sobre eventos locais, ou aplicar algum processamento relacionado ao evento local em nome do aplicativo de cliente 108. Ao permitir que o aplicativo de servidor 104 monitore tais eventos de dis- positivo de cliente 116 e aplique a execução aos eventos de dispositivo 116, esse modelo pode descarregar esse monitoramento e ônus computacional de aplicativos de cliente 108, que podem executar de maneira ad hoc altamente interativa no pedido do usuário 110 (por exemplo, monitoramento e manuseio de eventos de dispositivo de cliente 116 podem continuar mesmo após o aplicativo de cliente 108 ser encerrado pelo usuário 110). Adicionalmente, esse modelo pode permitir a interação do aplicativo de servidor 104 com eventos de dispositivo de cliente 116 em que tais interações podem não ser permitidas pelo aplicativo de cliente 108. Por exemplo, o aplicativo de cliente 108 pode executar dentro de um navegador da web que isola o aplicativo de cliente 108 de eventos de dispositivo de cliente local 116 por questões de segurança; entretanto, o aplicativo de cliente 108 pode pedir que o aplicativo de servidor 104, que executa fora do navegador da web e com um conjunto maior de capacidades permitidas, que interaja com os eventos de dispositivo de cliente 116 por meios verificáveis e confiáveis.

[018] A Figura 2 apresenta uma ilustração de um cenário exem- plificativo 200 que apresenta uma arquitetura cliente/servidor configurada de acordo com as técnicas apresentadas no presente documento. Nesse cenário exemplificativo 200, o dispositivo de cliente 106 executa ambos um aplicativo de servidor 104 e um ou mais aplicativos de cliente 108, e pode permitir que aplicativos de cliente 108 interajam com eventos locais 206 através de interação com o aplicativo de servidor de cliente 104. Em particular, o aplicativo de servidor 104 pode compreender um ou mais scripts de servidor 202 que fornecem tipos diferentes de processamento quando executados no contexto de vários eventos locais 206. Um aplicativo de cliente 108 pode apresentar ao aplicativo de servidor 104 um pedido de assinatura de evento 204 que identifica um ou mais eventos locais particulares 206 que podem surgir dentro do dispositivo de cliente 106. O aplicativo de servidor 104 pode cumprir o pedido de assinatura de evento 204 associando-se um ou mais scripts de servidor 202 ao evento local 206, de modo que, quando tais eventos locais 206 ocorrem, o aplicativo de servidor 104 pode desempenhar a execução de script de servidor 208 dos scripts de servidor 202 em favor do aplicativo de cliente assinado 108.

[019] O modelo arquitetônico apresentado no cenário exemplifi- cativo 200 da Figura 2 pode permitir várias vantagens em relação a outros modelos de processamento de evento local. Como um primeiro exemplo, essa arquitetura pode permitir que o aplicativo de servidor 104 desempenhe o monitoramento de planos de fundo contínuo dos eventos locais 206 e a execução de scripts de servidor confiável 202 que fornece processamento confiável dos eventos locais 206, enquanto o aplicativo de cliente não confiável 104 pode ser executado intermitentemente e de maneira não confiável (por exemplo, dentro do cons- truto de isolamento de um navegador da web). Como um segundo exemplo, fornecer um aplicativo de servidor 104 para monitorar uma ampla faixa de eventos locais 206 e para aplicar processamento ao mesmo pode ser mais eficaz do que configurar cada um de diversos aplicativos de cliente 108 para monitorar o mesmo conjunto de eventos locais 206. Como um terceiro exemplo, os scripts de servidor 202 po-dem ser desenvolvidos em um ambiente de desenvolvimento similar aos aplicativos de cliente 104 (por exemplo, o script de servidor 202 pode utilizar o Modelo de programação de lado de servidor de JavaScript Node.js, e o aplicativo de cliente 104 pode ser desenvolvido como JavaScript de lado de cliente que executa dentro do navegador da web do dispositivo de cliente 102). Por exemplo, os eventos locais 206 podem incluir eventos que aplicativos de cliente 104 são frequentemente não permitidos de processar diretamente, tal como eventos de hardware de baixo nível ou eventos que surgem dentro de diferentes proces- sos do dispositivo de cliente 102 a partir dos quais o aplicativo de cliente 104 é proibido de interagir. Como um quarto exemplo, ao processarinformações no mesmo dispositivo de usuário ao invés de enviar as informações como uma invocação de um serviço em um dispositivo remoto, essas técnicas promovem o isolamento de informações que o usuário pode não desejar disseminar, tal como informações que são pessoais ao usuário (por exemplo, a identidade e localização do usuário) e/ou informações de segurança (por exemplo, senhas). Como um quinto exemplo, o cenário de programação de aplicativos a serem executados por um servidor em serviço de aplicativos de cliente que executam no mesmo dispositivo pode fornecer um cenário de computação inovador, e pode permitir o desenvolvimento de um novo mercado ao redor de tais aplicativos. Essas e outras vantagens podem ser alcançadas através da arquitetura ilustrada no cenário exemplificativo 200 da Figura 2 e técnicas apresentadas no presente documento.

Modalidades Exemplificativas

[020] A Figura 3 apresenta uma primeira modalidade exemplifica- tiva das técnicas apresentadas no presente documento, ilustrada como um método exemplificativo 300 de cumprimento de solicitações em um dispositivo que tem um processador e que executa pelo menos um aplicativo de cliente local 108. O método exemplificativo 300 pode ser implantado, por exemplo, como um conjunto de instruções armazenado em um componente de memória do dispositivo, tal como um circuito de memória, uma placa de uma unidade de disco rígido, um dispositivo de armazenamento em estado sólido, ou um disco magnético ou óptico, e organizado de modo que, quando executado, o dispositivo faz com que o dispositivo opere de acordo com as técnicas apresentadas no presente documento. O método exemplificativo 300 começa em 302 e envolve executar 304 as instruções em um processador do dis-positivo. Especificamente, essas instruções podem ser configuradas para gerar 306 um servidor local que associa pelo menos um script de servidor 202 com pelo menos um evento local 206 que pode surgir no dispositivo. As instruções são também configuradas para, mediante recebimento de um aplicativo de cliente local 108 um pedido de assinatura de evento 204 que especifica um evento local selecionado 206 associa 308 o evento local selecionado 206 ao aplicativo de cliente local 108. As instruções são também configuradas para, mediante a detecção de um evento local associado a pelo menos um script de servidor 202 e um aplicativo de cliente local 108, executar 310 dentro do servidor local os scripts de servidor 202 associados a e relacionados ao evento local 206 em nome do aplicativo de cliente local 108. Ao alcançar o processamento do evento local 206 em nome do aplicativo de cliente local 108 através do uso de um servidor local que executa no mesmo dispositivo, o método exemplificativo 300 alcança as técni-cas apresentadas no presente documento e, portanto, termina em 312.

[021] A Figura 4 apresenta uma segunda modalidade exemplifi- cativa das técnicas apresentadas no presente documento, ilustrada como um cenário exemplificativo 400 que apresenta um sistema exemplificativo 406 configurado para cumprir solicitações em um dispositivo 402 que tem um processador 404 que executa pelo menos um aplicativo de cliente local 108. O sistema exemplificativo 406 pode ser implantado, por exemplo, como instruções armazenadas em um componente de memória do dispositivo 402 e configurado para, quando executado no processador 404, fazer com que o dispositivo 402 opere de acordo com as técnicas apresentadas no presente documento. O sistema exemplificativo 406 compreende um componente de servidor local 408 configurado para associar pelo menos um script de servidor 202 a pelo menos um evento local 206. O sistema exemplificativo 406 também compreende um componente de ligação de servidor local 410, que é configurado para, mediante recebimento do aplicativo de cliente 108 de um pedido de assinatura de evento 204 que especifica um evento local selecionado 206, associar o evento local selecionado 206 ao aplicativo de cliente local 108; e, mediante a detecção de um evento local 206 associado a pelo menos um script de servidor 202 e um aplicativo de cliente 108, executar dentro do componente de servidor local 408 os scripts de servidor 202 associados a e relacionados ao evento local 206 em nome do aplicativo de cliente 108. Ao monitorar a ocorrência de eventos locais 206 e executar scripts de servidor 202 em resposta aos eventos locais 206 em nome do aplicativo de cliente 108, o sistema exemplificativo 406 alcança dentro do dispositivo 402 o aplicativo das técnicas apresentadas no presente documento.

[022] Ainda outra modalidade envolve um meio legível em com putador que compreende instruções executáveis por processador con-figuradas para aplicar as técnicas apresentadas no presente documento. Tais meios legíveis em computador podem incluir, por exemplo, meios de armazenamento legíveis em computador envolvendo um dispositivo tangível, tal como um semicondutor de memória (por exemplo, um semicondutor que utiliza tecnologias de memória de acesso aleatório estática (SRAM), memória de acesso aleatório dinâmica (DRAM), e/ou memória de acesso aleatório dinâmica síncrona (SDRAM)), uma placa de uma unidade de disco rígido, um dispositivo de memória flash, ou um disco magnético ou óptico (tal como um CD- R, DVD-R ou disquete), que codifica um conjunto de instruções legíveis em computador que, quando executadas por um processador de um dispositivo, fazem com que o dispositivo implemente as técnicas apresentadas no presente documento. Tais meios legíveis em computadortambém podem incluir (como uma classe de tecnologias que são distintas de meios de armazenamento legíveis em computador) vários tipos de meios de comunicações, tal como um sinal que pode ser propagadoatravés de vários fenômenos físicos (por exemplo, um sinal eletromagnético, um sinal de onda de som, ou um sinal óptico) e em vários cenários com fio (por exemplo, por meio de uma Ethernet ou cabo de fibra óptica) e/ou cenários sem fio (por exemplo, uma rede de área local sem fio (WLAN), tal como WiFi, uma rede de área pessoal (PAN), tal como Bluetooth, ou uma rede de rádio ou celular), e que codifica um conjunto de instruções legíveis em computador que, quando executadas por um processador de um dispositivo, fazem com que o dispositivo implemente as técnicas apresentadas no presente documento.

[023] Um meio legível em computador exemplificativo que pode ser concebido nesses modos é ilustrado na Figura 5, em que a implantação 500 compreende um meio legível em computador 502 (por exemplo, um CD-R, DVD-R ou uma placa de uma unidade de disco rígido), no qual são codificados dados legíveis em computador 504. Esses dados legíveis em computador 504, por sua vez, compreendem um conjunto de instruções de computador 506 configuradas para operar de acordo com os princípios apresentados no presente documento. Em tal modalidade, as instruções executáveis por processador 506 podem ser configuradas para desempenhar um método 508 de cumprimento de solicitações de aplicativos de cliente 108 relacionado a eventos locais 105, tal como o método exemplificativo 300 da Figura 3. Em outra tal modalidade, as instruções executáveis por processador 506 podem ser configuradas para implantar um sistema para cumprir solicitações de aplicativos de cliente 108 relacionadas a eventos locais 206, tal como o sistema exemplificativo 406 da Figura 4. Algumas modalidades desse meio legível em computador podem compreender um meio de armazenamento legível em computador (por exemplo, uma unidade de disco rígido, um disco óptico ou um dispositivo de memória flash) que é configurado para armazenar instruções executáveis por processador configuradas dessa maneira. Muitos dos tais meios legí- veis em computador podem ser concebidos por aqueles de habilidade comum na técnica que são configurados para operar em conformidade com as técnicas apresentadas no presente documento.

Variações

[024] As técnicas discutidas no presente documento podem ser concebidas com variações em muitos aspectos, e algumas variações podem apresentar vantagens adicionais e/ou reduzir desvantagens em relação a outras variações dessas e outras técnicas. Ademais, algumasvariações podem ser implantadas em combinação, e algumas combinações podem incorporar vantagens adicionais e/ou desvantagens reduzidas através de cooperação sinergética. As variações podem ser incorporadas em várias modalidades (por exemplo, o método exemplificativo 300 da Figura 3 e o sistema exemplificativo 406 da Figura 4) para conferir vantagens individuais e/ou sinergéticas mediante tais modalidades.

D1. Cenários

[025] Um primeiro aspecto que pode variar dentre modalidades dessas técnicas se refere aos cenários em que tais técnicas podem ser utilizadas.

[026] Como uma primeira variação desse primeiro aspecto, as técnicas apresentadas no presente documento podem ser utilizadas com muitos tipos de dispositivo 402, tal como servidores, parques de servidores, estações de trabalho, computadores do tipo laptop, dispositivos do tipo tablet, telefones móveis, consoles de jogos e ferramentas de rede. Tais dispositivos 402 também podem fornecer uma variedade de componentes de computação, tal como dispositivos de comunicações com ou sem fio; dispositivos de entrada humana, tal como teclados, mouses, dispositivos do tipo touchpad, visores sensíveis ao toque, microfones e componentes de entrada com base em gestos; dispositivos de entrada automatizados, tal como câmeras estáticas ou de movimento, dispositivos de serviço de posicionamento global (GPS), e outros sensores; dispositivos de saída, tal como visores e alto-falantes; e dispositivos de comunicação, tal como componentes de rede com e/ou sem fio.

[027] Como uma segunda variação desse primeiro aspecto, as técnicas apresentadas no presente documento podem ser utilizadas com vários tipos de aplicativos de servidor 104, tal como servidores da Web, servidores de arquivo, servidores de aplicativo, servidores de meios, servidores de coordenação de compartilhamento ponto a ponto, servidores de banco de dados, servidores de e-mail, servidores de monitoramento métrico físico, e servidores de automatização de aquisição de dados e controle de supervisão (SCAD A).

[028] Como uma terceira variação desse primeiro aspecto, as técnicas apresentadas no presente documento podem ser utilizadas para o serviço de muitos tipos de aplicativos de cliente 108, tal como navegadores da web, aplicativos de compartilhamento de arquivos, aplicativos de renderização de meios, e aplicativos de cliente orientados por dados. Ademais, os aplicativos de cliente 108 podem executar em vários contextos, tal como execução nativa no dispositivo 402; execução gerenciada facilitada por um ou mais tempos de execução de gerenciamento; execução virtual dentro de um ambiente virtual, tal como um aplicativo da web que executa dentro de um navegador da web; e execução isolada dentro de um construto de isolamento. Tais aplicativos de cliente 108 também podem ser recebidos pelo dispositivo 402 através de várias técnicas, tal como aplicativos de cliente 108 agrupados com o dispositivo 402; aplicativos de cliente recuperados de vários serviços, tal como um servidor de aplicativo fornecido pela rede; conteúdo embutido em uma página da web; uma unidade de hardware ou software fornecida por um componente do dispositivo 402; ou um aplicativo de cliente 108 fornecido pelo aplicativo de servi- dor 104. Esses e outros cenários podem ser compatíveis com e podem utilizar vantajosamente as técnicas apresentadas no presente documento.

D2. Evento Local e Tipos de Script de Servidor

[029] Um segundo aspecto que pode variar dentre modalidades das técnicas apresentadas no presente documento envolve os tipos de eventos locais 206 que podem ser monitorados pelo aplicativo de servidor 104, e os tipos de scripts de servidor 202 que o aplicativo de servidor 104 pode executar em favor de um ou mais aplicativos de cliente 108 mediante a ocorrência de tais eventos locais 206.

[030] Como uma primeira variação desse segundo aspecto, as técnicas apresentadas no presente documento podem dizer respeito ao monitoramento de muitos tipos de eventos locais 206 no dispositivo 402, tal como eventos de entrada local envolvendo um recebimento de entrada local por um componente de entrada do dispositivo 402; um evento de usuário local que indica uma detecção da presença de, identidade de, ou uma interação recebida de um usuário local por um detector de componente do dispositivo; um evento de processamento local que indica a completude de uma instância de processamento de dados locais pelo dispositivo; ou um pedido de assinatura de evento 204 direcionado ao aplicativo de servidor 104 por um aplicativo de cliente 108. Como tal exemplo, o evento local 206 pode compreender um evento de aplicativo local que surge durante uma execução de um terceiro aplicativo no dispositivo 402 (além do aplicativo de servidor 104 e do aplicativo de cliente 108), tal como uma unidade de hardware, um componente de sistema operacional, outro aplicativo de servidor 104, ou outro aplicativo de cliente 108. O aplicativo de servidor 104 pode, portanto, monitorar a execução do terceiro aplicativo no dispositivo 402 para detectar a ocorrência do evento de aplicativo local (por exemplo, uma instalação do terceiro aplicativo; uma suspensão, completude ou término do terceiro aplicativo; ou uma exceção lógica que surge dentro do terceiro aplicativo), e pode executar um ou mais scripts de servidor 202 associados ao evento de aplicativo local. Ademais, o terceiro aplicativo pode definir um ou mais eventos de aplicativo específicos que são personalizados ao terceiro aplicativo, e o aplicativo de servidor 104 pode associar um ou mais scripts de servidor 202 com os eventos de aplicativo específicos para execução em favor de outro aplicativo de cliente 108.

[031] Como uma segunda variação desse segundo aspecto, os scripts de servidor 202 podem especificar muitos tipos de processamento relacionados ao evento local 206, tal como relatar o evento local 206 ao aplicativo de cliente 108, registrar em log a ocorrência do evento local 206, ou aplicar lógica adicional durante o manuseio do evento local 206. Adicionalmente, os scripts de servidor 202 podem ser recebidos de muitas fontes; por exemplo, o script de servidor 202 pode ser incluído com o aplicativo de servidor 104, pode ser fornecido por um usuário 110, pode ser fornecido com e/ou automaticamente gerado pelo dispositivo 402, ou pode ser recebido do aplicativo de cliente 108 ou uma fonte externa. Ademais, o aplicativo de servidor 104 pode ser configurado para notificar o aplicativo de cliente 108 mediante a com- pletude do script de servidor 202. Por exemplo, o pedido de assinatura de evento 204 fornecido pelo aplicativo de cliente 108 pode especificar um retorno de chamada de aplicativo a ser invocado mediante uma detecção do evento local 206 e/ou mediante a completude de execução do(s) script(s) de servidor 202 associado ao evento local 206.

[032] Como uma terceira variação desse segundo aspecto, as técnicas apresentadas no presente documento podem envolver a execução de muitos tipos de scripts de servidor 202. Como um primeiro exemplo dessa terceira variação, tais scripts de servidor 202 podem ser projetados com o uso de uma variedade de tecnologias, incluindo JavaScript de lado de servidor que invoca um módulo Node.js e a serem executados por um servidor Web local.

[033] Como um segundo exemplo dessa terceira variação, o script de servidor 202 pode envolver um pedido de bloqueio que pode interromper a operação de um processo do dispositivo 402. Por exemplo, o script de servidor 202 pode envolver lógica complexa que envolvecomputação prolongada, ou pode envolver acesso a dados ou recursos que são atualmente utilizados exclusivamente por outro processo. Tais solicitações de bloqueio podem ser insustentáveis em um aplicativo de cliente 108 (por exemplo, um aplicativo da web que emite um pedido de bloqueio pode ser temporária ou indefinidamente suspenso, interrompendo, assim, a interface de usuário e/ou um navegador da web que contém o aplicativo da web, e/ou pode exceder um limiar de tempo limite de processamento resultando no término do aplicativo da web). Ao invés disso, o aplicativo de cliente 108 pode delegar tais solicitações de bloqueio ao aplicativo de servidor 104, em que o script de servidor 202 especifica o pedido de bloqueio e/ou lógica a ser executada após o pedido de bloqueio. O aplicativo de servidor 104 que executa no plano de fundo pode executar de modo sustentável tais solicitações de bloqueio como um encadeamento bloqueável sem interromper qualquer processo de primeiro plano do dispositivo 402, e/ou pode continuar de modo aceitável a processar o pedido de bloqueio (por exemplo, aguardar a completude do processo de longa execução ou disponibilidade de recursos) por uma duração estendida.

[034] Como um terceiro exemplo dessa terceira variação, o script de servidor 202 pode especificar um retorno de chamada de script de servidor a ser invocado mediante o alcance da completude do processoassíncrono. O retorno de chamada de script de servidor pode ser especificado pelo script de servidor 202, pelo aplicativo de servidor 104, pelo usuário 110 e/ou pelo aplicativo de cliente 108. Como tal exemplo, o pedido de assinatura do aplicativo de cliente 108 pode ser associado a um evento de interface de usuário de cliente (por exemplo, o aplicativo de cliente 108 pode aguardar alguma forma de entrada do usuário 110), e o aplicativo de cliente 108 pode especificar um retorno de chamada de aplicativo a ser invocado mediante a detecção da entrada. Mediante o recebimento do pedido de assinatura 204, o aplicativo de servidor 108 pode configurar ou gerar um script de servidor 202 para invocar o retorno de chamada de aplicativo do aplicativo de cliente 108, e pode associar o script de servidor 202 ao evento local 206, envolvendo a detecção da entrada de usuário. O dispositivo 402 pode realizar a execução contínua do aplicativo de cliente 108, incluindo um evento de interface de usuário de cliente apresentado aqui, permitindo, assim, que o aplicativo de cliente 108 seja notificado da detecção do evento de entrada de usuário sem ter que monitorar (por exemplo, por meio de sondagem) componentes de entrada para tal detecção. Esses e outros tipos de eventos locais 206 e/ou scripts de servidor 202 podem ser envolvidos na arquitetura servidor/cliente e técnicas apresentadas no presente documento.

D3. Assinatura e Execução de Script de Servidor

[035] Um terceiro aspecto que pode variar dentre modalidades dessas técnicas envolve a maneira através da qual o aplicativo de servidor 108 aceita pedidos de assinatura 204 de respectivos aplicativos de cliente 108 e/ou executa o(s) script(s) de servidor 202 associado a um evento local 206 em favor de um ou mais aplicativos de cliente 108.

[036] Como uma primeira variação desse terceiro aspecto, o apli cativo de servidor 104 pode facilitar a assinatura de aplicativos de cliente 108 a eventos locais 206 ao fornecer informações sobre os eventos locais disponíveis 206 aos quais os aplicativos de cliente 108 podem assinar. Por exemplo, mediante recebimento do aplicativo de cli- ente 108 de um pedido para identificar o conjunto de eventos locais assináveis 206, o aplicativo de servidor 104 pode enumerar os eventos locais 206 assináveis pelo aplicativo de cliente 108. Alternativamente, o aplicativo de servidor 104 pode simplesmente manter um diretório de eventos locais assináveis 206 consultáveis pelos aplicativos de cliente 108.

[037] Como uma segunda variação desse terceiro aspecto, o aplicativo de servidor local 104 pode identificar eventos locais assináveis 206 em muitas maneiras. Como tal exemplo, respectivos eventos locais 206 podem ser associados a um endereço de evento local, por exemplo, um endereço de protocolo de transporte de hipertexto (HTTP) através do qual aplicativos de cliente 108 podem pedir recursos do aplicativo de servidor local 104. Mediante recebimento de um pedido de cliente que especifica um endereço particular, o aplicativo de servidor local 104 pode determinar se o endereço é um endereço de evento local que é associado a um pedido de assinatura para um evento local 206, e caso seja, pode lidar com o pedido de cliente como um pedido de assinatura de evento 204 iniciado pelo aplicativo de cliente local 108. Como tal exemplo adicional, respectivos componentes do dispositivo 402 podem ser identificados por um endereço de evento local, incluindo um nome de componente do componente, e os aplicativos de cliente local 108 podem assinar aos eventos locais 206 envolvendo tais componentes iniciando-se um pedido de cliente que especifica um endereço de evento local, incluindo o nome de componente do componente.

[038] A Figura 6 representa uma ilustração de um cenário exem- plificativo 600 que caracteriza diversas dessas variações das técnicas apresentadas no presente documento. Nesse cenário exemplificativo 600, o dispositivo 402 compreende um conjunto de componentes que pode gerar eventos locais 206 aos quais um ou mais aplicativos de cliente local 108 podem subscrever, tal como um componente de mouse 602 operável por um usuário 110 para gerar entrada de ponteiro; um componente de câmera 604 operável por um usuário 110 para capturar imagens paradas e em movimento; e um componente de processador 606 configurado para realizar tipos especializados de processamento (por exemplo, um processador de gráficos traçados por raio). O dispositivo 402 pode utilizar um aplicativo local de servidor 104 para preencher tais pedidos de assinatura de evento 204 associando- se com os respectivos componentes com um endereço de componente 612. Um aplicativo de cliente 108 pode enviar ao aplicativo local de servidor 104 um pedido de enumeração de evento 608 (por exemplo, um pedido para o aplicativo local de servidor 104 para enumerar os tipos de eventos locais 206 aos quais o aplicativo de cliente local 108 pode subscrever, incluindo os componentes que são acessíveis ao aplicativo de cliente local 108) e o aplicativo local de servidor 104 pode responder com uma numeração de evento passível de assinatura 610 que identifica, para respectivos componentes, um endereço de componente 612 que o aplicativo de cliente local 108 pode especificar para subscrever aos eventos locais 206 gerados pelo componente. Se o aplicativo de cliente local 108 enviar ao aplicativo de servidor 104 um pedido de assinatura de evento 204 que especifica o endereço de componente 614 de um componente, o aplicativo local de servidor 104 pode então associar o aplicativo local 108 aos eventos locais 206 gerados pelo componente, e, mediante detecção de tal um evento local 206, pode executar um script de servidor 202 associado ao evento local 206 gerado pelo componente do dispositivo 402 e relacionado ao mesmo. Dessa maneira, o aplicativo local de servidor 104 pode permitir e mediar a interação dos aplicativos de cliente local 108 com os componentes do dispositivo 402.

[039] Como uma terceira variação desse terceiro aspecto, adicio- nalmente para fornecer um aplicativo local de servidor 104 que fornece serviços de assinatura de evento local a um ou mais aplicativos de cliente local 108, o dispositivo 402 também pode incluir outros aplicativos que executam em outros dispositivos 402 (por exemplo, estender o modelo de serviço local fornecido no presente documento para incluir também arquiteturas tradicionais de servidor/cliente de múltiplos dispositivos). Como um primeiro tal exemplo, o dispositivo 402 pode permitir que aplicativos de cliente local 108 para direcionar pedidos de assinatura tanto a um aplicativo local de servidor 104 como a um apli-cativo de servidor remoto em execução em um dispositivo remoto. Mediante determinação de que o alvo de um pedido de assinatura de evento 204 de um aplicativo de cliente local 108 é o aplicativo local de servidor 104, o dispositivo 402 pode apresentar o pedido de assinatura de evento 204 ao aplicativo local de servidor 104; mas mediante determinação de que o alvo do pedido de assinatura de evento 204 compreende um aplicativo de servidor remoto de um dispositivo remoto, o dispositivo 402 pode encaminhar o pedido de assinatura 204 ao dispositivo remoto. Alternativa ou adicionalmente, em adição ao recebimento e prestação de serviço de pedidos de assinatura de evento 204 fornecidos por aplicativos de cliente local 108, o aplicativo local de servidor 104 pode receber pedidos de assinatura de evento 204 recebidos dos aplicativos de cliente remoto de execução em um segundo dispo-sitivo e pode cumprir tais pedidos de assinatura de evento 204 por, mediante detecção de um evento local 206 ao qual um aplicativo remoto é subscrito, executar um ou mais script(s) de servidor 202 associado ao evento local 206 e relacionado ao mesmo em nome do aplicativo de cliente remoto em execução no segundo dispositivo. Como tal exemplo, pode ser altamente vantajoso fornecer aplicativos locais de servidor 104 em cada um do conjunto de dispositivos que interope- ram como uma malha de dispositivo, em que cada aplicativo local de servidor 104 é configurado para prestar serviços de pedidos de assinatura de evento 204 aos eventos locais 206 em nome dos aplicativos de cliente local 108 em execução de forma localizada no mesmo dispositivo 402 assim como aplicativos de cliente remoto em execução em outros dispositivos 402 da malha de dispositivo.

[040] A Figura 7 representa uma ilustração de um cenário exem- plificativo 700 que caracteriza a interoperação de diversos dispositivos 704 que compreendem uma malha de dispositivo 702 de acordo com as técnicas apresentadas no presente documento. Nesse cenário exemplificativo 700, os respectivos dispositivos 704 da malha de dispositivo 702 pode intercomunicar (por exemplo, através de uma rede com fio ou sem fio) para compartilhar informações acerca dos eventos locais 206 que aparecem dentro de cada dispositivo 704. Para esse fim, cada dispositivo 704 pode compreender um aplicativo de servidor 104 configurado para receber e cumprir pedidos de assinatura de evento 204 fornecidos não somente pelos aplicativos de cliente local 108 em execução no mesmo dispositivo 704, mas também aplicativos de cliente remoto em execução em outro dispositivo 704 da malha de dispositivo 702. Adicionalmente, mediante um primeiro dispositivo 704 que recebe um pedido de assinatura de evento 204 de um aplicativo de cliente local 108 que especifica como o alvo do pedido um aplicativo de servidor remoto em execução em um segundo dispositivo 704 da malha de dispositivo 702, o primeiro dispositivo 704 pode encaminhar o pedido de assinatura de evento 204 ao segundo dispositivo. Mediante detecção da ocorrência de um evento local 206, o aplicativo de servidor 104 pode identificar os aplicativos de cliente local 108 e os aplicativos de cliente remoto em execução em outros dispositivos 704 e pode iniciar execução de script de servidor 208 de um ou mais scripts de servidor 202 associados ao evento local 206 em nome de cada tal aplicativo de cliente subscrito 108. Essa variação, portanto, estende o evento modelo de serviço local apresentado no presente documento para incluir outros aplicativos de cliente 106 em execução em outros dispositivos 704 em concordância com as técnicas apresentadas no presente documento.

[041] Conforme uma quarta variação desse terceiro aspecto, o dispositivo 402 pode ajustar a execução do aplicativo local de servidor 104 e/ou do aplicativo de cliente local(s) 108 de uma maneira que conserve os recursos do dispositivo 402, tal como um dispositivo móvel que opera uma bateria de capacidade limitada e/ou dentro de restrições de potência de baixa voltagem ou um processador que rende maior desempenho de dispositivo se o processamento e/ou memória são conservados.

[042] Conforme um primeiro exemplo dessa quarta variação, o aplicativo local de servidor 108 pode ser executado somente quando pedidos de assinatura de evento 204 estão pendentes de um ou mais aplicativos de cliente 108. Por exemplo, mediante recebimento de um pedido de assinatura de evento 204, o dispositivo 402 pode determinar se o aplicativo local de servidor 104 está em execução e se não, pode acionar a execução do aplicativo local de servidor 104 de modo a preencher os pedidos de assinatura de evento 204. Alternativa ou adicionalmente, mediante detecção de uma ausência de pedidos de assinatura de evento aos eventos locais 206 que o aplicativo local de servidor 104 tem capacidade de detecção, o dispositivo 402 pode temporária ou indefinidamente terminar a execução do aplicativo local de servidor 104. Dessa maneira, o dispositivo 402 pode operar o aplicativo local de servidor 104 de maneira ad-hoc e pode conservar de outro modo os recursos do dispositivo 402 quando o aplicativo local de servidor 104 não está em uso.

[043] Como um segundo exemplo dessa quarta variação, os res pectivos componentes de processamento do dispositivo 402 podem ser utilizados somente quando eventos locais 206 foram detectados. Por exemplo, se o evento local 206 compreende o processamento de entrada de usuário recebida através de um componente de entrada, o dispositivo 402 pode conter potência do componente de processamento quando tais eventos locais 206 não aparecem. Ademais, tal processamento pode ser contingente mediante a assinatura de um ou mais aplicativos de cliente 108 aos eventos locais 206 associados ao componente de processamento. Por exemplo, se o dispositivo 402 compreende um componente de processamento configurado para interpretar entrada de toque recebido através de um componente de exibição sensível ao toque, o dispositivo 402 pode reduzir ou eliminar a potência recebida ao componente de processamento quando o componente de exibição sensível ao toque não recebe entrada de toque, e, opcio-nalmente, contingente adicional mediante se quaisquer aplicativos de cliente 108 estão atualmente configurados para receber e processar entrada de toque através do componente de exibição sensível ao toque. Tais técnicas podem facilitar a conservação dos recursos do dispositivo (tais como potência, processador, memória e capacidade de comunicações) em concordância com as técnicas apresentadas no presente documento. Essas e outras variações da assinatura e execução de scripts de servidor 202 podem ser utilizadas pelo aplicativo de servidor 104 em nome de um ou mais aplicativos de cliente 108 em resposta à detecção de vários eventos locais 206 e associado aos mesmos em concordância com as técnicas apresentadas no presente documento.

Ambiente computacional

[044] A Figura 8 e a discussão a seguir fornecem uma breve des crição geral de um ambiente computacional adequado para implantar modalidades de uma ou mais das provisões apresentadas no presente documento. O ambiente operacional da Figura 8 é somente um exem- plo de um ambiente operacional adequado e não é destinado a sugerir nenhuma limitação como ao escopo de uso ou funcionalidade do ambiente operacional. Dispositivos computacionais exemplificativos incluem,porém, sem limitação, computadores pessoais, computadores de servidor, portáteis ou dispositivos laptop, dispositivos móveis (tais como telefones móveis, Assistentes Digitais Pessoais (PDAs), reprodutores de mídia e similares), sistemas de multiprocessador, eletrônicos de consumidor, minicomputadores, computadores principais, ambientes computacionais distribuídos que incluem quaisquer dos sistemas acima ou dispositivos e similares.

[045] Embora não exigido, as modalidades são descritas no con texto geral de "instruções legíveis em computador" que são executadas por um ou mais dispositivos computacionais. As instruções legíveis em computador podem ser distribuídas por meio de meios legíveis em computador (discutido abaixo). As instruções legíveis em computador podem ser implantadas como módulos de programa, tais como funções, objetos, Interfaces de Programação de Aplicativo (APIs), estruturas de dados e similares, que realizam tarefas particulares ou implantam tipos de dados abstratos particulares. Tipicamente, a funcionalidade das instruções legíveis em computador pode ser combinada ou distribuída conforme desejado em vários ambientes.

[046] A Figura 8 ilustra um exemplo de um sistema 800 que com preende um dispositivo computacional 802 configurado para implantar uma ou mais modalidades fornecidas no presente documento. Em uma configuração, dispositivo computacional 802 inclui pelo menos uma unidade de processamento 806 e memória 808. Dependendo da configuração exata e do tipo de dispositivo computacional, a memória 808 pode ser volátil (tais como RAM, for exemplo), não volátil (tais como ROM, memória flash, etc., for exemplo) ou alguma combinação dos dois. Essa configuração é ilustrada na Figura 8 pela linha ponti- lhada 804.

[047] Em outras modalidades, o dispositivo 802 pode incluir ca racterísticas adicionais e/ou funcionalidade. Por exemplo, o dispositivo 802 também pode incluir armazenamento adicional (por exemplo, removível e/ou não removível) incluindo, porém, sem limitação, armazenamento adicional, armazenamento adicional e similares. Tal armazenamento adicional é ilustrado na Figura 8 por armazenamento 810. Em uma modalidade, as instruções legíveis em computador para implantar uma ou mais modalidades fornecidas no presente documento podem estar em armazenamento 810. O armazenamento 810 também pode armazenar outas instruções legíveis em computador para implantar um sistema operacional, um programa de aplicativo e similares. Instruções legíveis em computador podem ser carregadas na memória 808 para execução pela unidade de processamento 806, for exemplo.

[048] O termo "meios legíveis em computador" conforme usado no presente documento inclui meios de armazenamento em computador. Os meios de armazenamento em computador incluem meios volátil e não volátil, removível e não removível implantados em qualquer método ou tecnologia para armazenamento de informações tais como instruções legíveis em computador ou outros dados. A memória 808 e o armazenamento 810 são exemplos de meios de armazenamento em computador. Os meios de armazenamento em computador incluem, porém, sem limitação, RAM, ROM, EEPROM, memória flash ou outra tecnologia de memória, CD-ROM, Discos Versáteis Digitais (DVDs) ou outro armazenamento adicional, cassetes magnéticos, fita magnética, armazenamento em disco magnético ou outros dispositivos de armazenamento adicional ou qualquer outro meio que possa ser usado para armazenar as informações desejadas e que pode ser acessado pelo dispositivo 802. Quaisquer tais meios de armazenamento em computador podem ser parte do dispositivo 802.

[049] O dispositivo 802 também pode incluir conexão (ões) de comunicação 816 que permite que o dispositivo 802 se comunique com outros dispositivos. A(s) conexão(ões) de comunicação 816 podem incluir, porém, sem limitação, um modem, uma Placa de Interface de Rede (NIC), um interface de rede integrada, um transmis- sor/receptor de frequência de rádio, uma porta de infravermelho, uma conexão USB ou outras interfaces para conectar o dispositivo computacional 802 a outros dispositivos computacionais. A(s) conexão(ões) de comunicação 816 podem incluir uma conexão com fio ou uma conexão sem fio. A(s) conexão(ões) de comunicação 816 podem transmitir e/ou receber meios de comunicação.

[050] O termo "meios legíveis em computador" pode incluir meios de comunicação. Os meios de comunicação incorporam tipicamente instruções legíveis em computador ou outros dados em um "sinal de dados modulado" tais como uma onda portadora ou outro mecanismo de transporte e inclui quaisquer meios de distribuição de informações. O termo "sinal de dados modulado" pode incluir um sinal que tem um ou mais de suas características estabelecidas ou alteradas de tal maneira a codificar informações no sinal.

[051] O dispositivo 802 pode incluir dispositivo(s) de entrada 814 tais como teclado, mouse, caneta, dispositivo de entrada de voz, dispositivo de entrada de toque, câmeras infravermelhas, dispositivos de entrada de vídeo, e/ou qualquer outro dispositivo de entrada. Os dis- positivo(s) de saída 812 tais como um ou mais visores, alto-falantes, impressoras, e/ou qualquer outro dispositivo de saída também pode ser incluído no dispositivo 802. O(s) dispositivo(s) de entrada 814 e dispositivo de saída(s) 812 pode(m) ser conectados ao dispositivo 802 por meio de uma conexão com fio, conexão sem fio ou qualquer combinação das mesmas. Em uma modalidade, um dispositivo de entrada ou um dispositivo de saída de outro dispositivo computacional pode ser usado como dispositivo(s) de entrada 814 ou dispositivo de saí- da(s) 812 para o dispositivo computacional 802.

[052] Os componentes de dispositivo computacional 802 podem ser conectados por várias interconexões, tais como um barramento. Tais interconexões podem incluir uma Interconexão de Componente Periférico (PCI), tais como PCI Express, um Barramento Serial Universal (USB), Firewire (IEEE 1394), um estrutura de barramento óptico e similares. Em outra modalidade, os componentes do dispositivo computacional 802 podem estar interconectados por uma rede. Por exemplo, a memória 808 pode ser compreendida de múltiplas unidades de memória física localizadas em diferentes locais físicos interconectados por uma rede.

[053] Aqueles versados na técnica notarão que os dispositivos de armazenamento utilizados para armazenar instruções legíveis em computador podem ser distribuídos através de uma rede. Por exemplo, um dispositivo computacional 820 acessível por meio de rede 818 pode armazenar instruções legíveis em computador para implantar uma ou mais modalidades fornecidas no presente documento. O dispositivo computacional 802 pode acessar dispositivo computacional 820 e transferir por download uma parte ou todas as instruções legíveis em computador para execução. Alternativamente, o dispositivo computacional 802 pode transferir por download peças das instruções legíveis em computador, conforme necessário ou algumas instruções podem ser executadas no dispositivo computacional 802 e algumas no dispositivo computacional 820.

Uso de Termos

[054] Embora a matéria tenha sido descrita em linguagem espe cífica a características estruturais e/ou ações metodológicas, deve ser compreendido que a matéria definida nas reivindicações anexas não é necessariamente às características específicas ou ações descritas acima. Preferencialmente, as características específicas e ações descritas acima são reveladas como formas de exemplo de implantação das reivindicações.

[055] Conforme usado neste pedido, os termos "componente," "modulo,""sistema", "interface" e similares são geralmente destinados a se referir a uma entidade relacionada a computador, tanto hardware, uma combinação de hardware e software, software ou software em execução. Por exemplo, um componente pode ser, porém, sem limitação, um processo em execução em um processador, um processador, um objeto, um executável, um encadeamento de execução, um programa, e/ou um computador. A título de ilustração, tanto um aplicativo em execução em um controlador quanto o controlador podem ser um componente. Um ou mais componentes podem residir dentro de um processo e/ou encadeamento de execução e um componente pode ser localizado em um computador e/ou distribuído entre dois ou mais computadores.

[056] Ademais, a matéria reivindicada pode ser implantada como um método, aparelho ou artigo de fabricação com o uso de programação padrão e/ou técnicas de engenharia para produzir software, firmware, hardware ou qualquer combinação dos mesmos para controlar um computador para implantar a matéria revelada. O termo "artigo de fabricação"conforme usado no presente documento é destinado a englobar um programa de computador acessível a partir de qualquer dispositivolegível por computador, portadora ou meios. Evidentemente, aqueles versados na técnica reconhecerão que muitas modificações podem ser feitas a essa configuração sem se afastar do escopo ou espírito da matéria reivindicada.

[057] Várias operações de modalidades são fornecidas no pre sente documento. Em uma modalidade, uma ou mais das operações descritas pode constituir instruções legíveis em computador armaze- nadas em um ou mais meios legíveis em computador, que, se executadas por um dispositivo computacional, farão com que o dispositivo computacional realize as operações descritas. A ordem na qual algumas ou todas as operações são descritas não devem ser interpretadas como a implicar que essas operações são necessariamente dependentes de ordem. Ordenações alternativas serão apreciadas por alguém versado na técnica que tem o benefício desta descrição. Além disso, será entendido que nem todas as operações estão necessariamente presentes em cada modalidade fornecida no presente documento.

[058] Ademais, a palavra "exemplificativo"é usada no presente documento para significar servir como um exemplo, instância ou ilustração. Qualquer aspecto ou projeto descrito no presente documento como "exemplificativo"não deve ser necessariamente interpretado como vantajoso em outros aspectos ou projetos. Preferencialmente, o uso da palavra exemplificativo é destinado a apresentar conceitos de modo concreto. Conforme usado neste pedido, o termo "ou"é destinado a significar um inclusivo "ou"além de um exclusivo "ou". Ou seja, a menos que especificado de outro modo ou claro a partir do contexto, "X emprega A ou B"é destinado a significar qualquer uma das permutações inclusivas naturais. Ou seja, se X emprega A; X emprega B; ou X emprega tanto A quanto B, então "X emprega A ou B"é satisfeito sob qualquer uma das instâncias precedentes. Adicionalmente, os artigos"um" e "uma" conforme usado neste pedido e nas reivindicações anexas podem ser geralmente interpretados a significar "um ou mais" a menos que especificado de outro modo ou claro a partir do contexto a ser dirigido a uma forma singular.

[059] Além disso, embora a descrição tenha sido mostrada e descrita em relação a uma ou mais implantações, alterações e modificações equivalentes irão ocorrer a outros versados na técnica com ba se em uma leitura e entendimento deste relatório descritivo e os desenhos anexos. A revelação inclui todas as tais modificações e alterações e é limitada somente pelo escopo das reivindicações anexas. Em relação particular às várias funções realizadas pelos componentes descritos acima (por exemplo, elementos, recursos, etc.), os termos usados para descrever tais componentes são destinados a corresponder, a menos que de outro modo indicado, a qualquer componente que realize a função especificada ao componente descrito (por exemplo, que seja funcionalmente equivalente), mesmo que não estruturalmente equivalente à estrutura revelada que realize a função nas implantações exemplificativas ilustradas no presente documento da revelação. Adicionalmente, embora uma característica particular da revelação possa ter sido revelada em relação a somente uma das diversas im-plantações, tal característica pode ser combinada com uma ou mais outras características das outras implantações conforme pode ser desejado e vantajoso por qualquer aplicação dada ou particular. Ademais,à extensão de que os termos "inclui", "ter", "tem", "com" ou variantes dos mesmos são usadas tanto na descrição detalhada como nas reivindicações, tais termos são destinados a serem inclusivos de maneira similar ao termo "compreender".

Claims (14)

1. Meio de armazenamento legível por computador tendo um método caracterizado pelo fato de que compreende as etapas de: gerar um servidor local associando pelo menos um script de servidor a pelo menos um evento local; ao receber do aplicativo de cliente local uma solicitação de assinatura especificando um evento local selecionado, associar o evento local selecionado ao aplicativo de cliente local; ao detectar um evento local associado a pelo menos um script de servidor e um aplicativo de cliente local, executar no servidor local os scripts de servidor associados e relacionados ao evento local em nome do aplicativo de cliente local, ao receber uma solicitação de assinatura, especificar um destino do aplicativo de cliente local: determinar se o destino compreende o servidor local no dispositivo; e apresentar a solicitação de assinatura especificando o destino ao servidor local ao determinar que o destino compreende o servidor local no dispositivo; e enviar a solicitação de assinatura especificando o destino para um servidor remoto ao determinar que o destino compreende o servidor remoto fora do dispositivo.

2. Meio de armazenamento legível por computador, de acordo com a reivindicação 1, caracterizado pelo fato de que: o servidor local que compreende um servidor da web, incluindo um módulo Node.js; e pelo menos um script de servidor que contenha JavaScript chama o módulo Node.js do servidor da web em nome do aplicativo de cliente local.

3. Meio de armazenamento legível por computador, de acordo com a reivindicação 1, caracterizado pelo fato de que o evento local selecionado a partir de um conjunto de eventos local compreende: um evento de entrada local indicando um recebimento de entrada local por um componente de entrada do dispositivo; um evento de usuário local indicando a detecção de um usuário local por um componente detector do dispositivo; um evento de processamento local indicando a conclusão de uma instância local de processamento de dados pelo dispositivo; e uma solicitação do cliente direcionada ao servidor local por um aplicativo de cliente.

4. Meio de armazenamento legível por computador, de acordo com a reivindicação 1, caracterizado pelo fato de que: o evento local compreende um evento de aplicativo local que surge durante a execução de um terceiro aplicativo no dispositivo; e a detecção do evento local compreende o monitoramento da execução do terceiro aplicativo para detectar o evento do aplicativo local.

5. Sistema para cumprir solicitações em um dispositivo com um processador executando pelo menos um aplicativo de cliente local, caracterizado pelo fato de que compreende: um componente de servidor local configurado para associar pelo menos um script de servidor a pelo menos um evento local; um componente de ligação do servidor local configurado para: ao receber do aplicativo de cliente local uma solicitação de assinatura especificando um evento local selecionado, associe o evento local selecionado ao aplicativo de cliente local; e ao detectar um evento local associado a pelo menos um script de servidor e um aplicativo de cliente local, executar no servidor local os scripts de servidor associados e relacionados ao evento local em nome do aplicativo de cliente local; e um componente configurado para receber uma solicitação de assinatura especificando um destino do aplicativo de cliente local apresentar a solicitação de assinatura especificando o destino para o componente do servidor local, quando o destino for determinado como o componente do servidor local, e enviar a solicitação de assinatura especificando o destino para um componente de servidor remoto remoto do sistema, quando o destino é determinado como o componente do servidor remoto.

6. Sistema, de acordo com a reivindicação 5, caracterizado pelo fato de que o componente de ligação ao servidor local é configurado ainda mais, ao receber do aplicativo de cliente local uma solicitação para identificar os eventos locais assináveis pelo aplicativo de cliente local, enumerar os eventos locais assináveis pelo aplicativo de cliente local .

7. Sistema, de acordo com a reivindicação 5, caracterizado pelo fato de que o componente de ligação ao servidor local compreende ainda: ao receber uma solicitação de assinatura: determinar se o servidor local está executando e ao determinar que o servidor local não está executando, invocando a execução do servidor local; e ao detectar uma ausência de solicitações de inscrição nos eventos locais detectados pelo servidor local, encerrando a execução do servidor local.

8. Sistema, de acordo com a reivindicação 5, caracterizado pelo fato de que o componente de ligação do servidor local é ainda configurado para, após o servidor local concluir a conclusão dos scripts do servidor associado ao evento local, notificar o aplicativo de cliente local da conclusão do script do servidor em cumprimento a a solicitação do servidor.

9. Sistema, de acordo com a reivindicação 8, caracterizado pelo fato de que: o script do servidor compreende pelo menos uma solicitação de bloqueio; e o componente de ligação do servidor local está configurado para executar o script do servidor executando o script do servidor em um encadeamento bloqueado no servidor local.

10. Sistema, de acordo com a reivindicação 9, caracterizado pelo fato de que: o script do servidor inicia uma solicitação de bloqueio como um processo assíncrono e fornece um retorno de chamada de script do servidor a ser invocado após a conclusão do processo assíncrono; e o componente de ligação do servidor local está configurado para executar o script do servidor, ao concluir o processo assíncrono, invocando o retorno de chamada do script do servidor.

11. Sistema, de acordo com a reivindicação 8, caracterizado pelo fato de que: a solicitação de assinatura é recebida do aplicativo de cliente local, incluindo um retorno de chamada do aplicativo local a ser invocado na detecção do evento local; e o componente de ligação do servidor local está configurado para notificar o aplicativo cliente local chamando o retorno de chamada do aplicativo fornecido pelo aplicativo de cliente local.

12. Sistema, de acordo com a reivindicação 11, caracterizado pelo fato de que: a solicitação de assinatura do aplicativo de cliente local está associada a um evento da interface com o usuário do cliente; e o componente de ligação do servidor local ainda está configurado para, após receber a solicitação de assinatura e antes de detectar o evento local associado à solicitação de assinatura, continuar a execução do aplicativo de cliente local, incluindo o evento da interface com o usuário do cliente.

13. Método para cumprir solicitações em um dispositivo com um processador executando pelo menos um aplicativo de cliente local, o método caracterizado pelo fato de que compreende as etapas de: executar no dispositivo instruções configuradas para: gerar um servidor local associando pelo menos um script de servidor a pelo menos um evento local; ao receber do aplicativo de cliente local uma solicitação de assinatura especificando um evento local selecionado, associe o evento local selecionado ao aplicativo de cliente local; ao detectar um evento local associado a pelo menos um script de servidor e um aplicativo de cliente local, execute no servidor local os scripts de servidor associados e relacionados ao evento local em nome do aplicativo de cliente local; ao receber uma solicitação de assinatura, especificar um destino do aplicativo de cliente local: determinar se o destino compreende o servidor local no dispositivo; ao determinar que o destino compreende o servidor local no dispositivo, apresentar a solicitação de assinatura especificando o destino ao servidor local; e ao determinar que o destino compreende um servidor remoto fora do dispositivo, enviar a solicitação de assinatura especificando o destino ao servidor remoto.

14. Método, de acordo com a reivindicação 13, caracterizado pelo fato de que: o terceiro aplicativo define um evento específico do aplicativo; e as instruções são ainda configuradas para, ao receber do aplicativo de cliente local uma solicitação de assinatura que especifica o evento específico do aplicativo do terceiro aplicativo, associar o evento específico do aplicativo ao terceiro aplicativo.

Images