BRPI0615661A2 - estrutura de serviço no lado do servidor - Google Patents

estrutura de serviço no lado do servidor Download PDF

Info

Publication number
BRPI0615661A2
BRPI0615661A2 BRPI0615661-4A BRPI0615661A BRPI0615661A2 BR PI0615661 A2 BRPI0615661 A2 BR PI0615661A2 BR PI0615661 A BRPI0615661 A BR PI0615661A BR PI0615661 A2 BRPI0615661 A2 BR PI0615661A2
Authority
BR
Brazil
Prior art keywords
service
pseudo
virtual path
server
client
Prior art date
Application number
BRPI0615661-4A
Other languages
English (en)
Inventor
Ting-Hao Yang
David Ebbo
Nikhil Kothari
Simon Calvert
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of BRPI0615661A2 publication Critical patent/BRPI0615661A2/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

ESTRUTURA DE SERVIçO NO LADO DO SERVIDOR Suplementando o dispositivo tradicional para expor um serviço do servidor através de um URL que mapeia para um arquivo físico com uma extensão especial contendo o serviço, um caminho pseudo-virtual mapeando diretamente para o serviço é proporcionado para clientes requisitando o serviço. O caminho pseudo-virtual mapeia diretamente para o serviço por identificar, por exemplo, a informação de tipo associada com o serviço. Um caminho pseudo-virtual pode ser gerado através de uma interface de programação de aplicação e também pode ser criptografado antes de ser passado adiante pára um cliente.

Description

"ESTRUTURA DE SERVIÇO NO LADO DO SERVIDOR"ANTECEDENTES
Em um sistema incluindo um componente cliente("cliente") e um componente servidor ("servidor"), o servi-dor pode querer expor um serviço que o cliente pode utili-zar. Tradicionalmente, para expor um serviço, um programadorgrava um arquivo especial com uma extensão especial para oserviço. Por exemplo, na plataforma Microsoft .NET , umserviço da Rede é exposto como resultado da existência de umarquivo ASMX no servidor; a extensão especial é ASMX. Umserviço da Rede geralmente proporciona um ou mais métodosexistentes no servidor que permitem ao cliente chamar paraobter certas informações. Um serviço da Rede normalmente échamado através do uso de um URL. Por exemplo, o URLhttp://www.xyz.com/app/login.asmx leva a um serviço de aces-so em um servidor para XYZ.com. Tipicamente, o URL apontapara um arquivo físico, tal como um arquivo ASMX existenteno servidor. 0 cliente pode chamar o serviço da Rede por u-tilizar o URL que leva ao arquivo ASMX no servidor.
Utilizando métodos tradicionais para expor um ser-viço, um programador do serviço precisa entender a sintaxedo arquivo especial, tal como o formato do arquivo ASMX. Emadição, para transformar o código do servidor existente emserviços da Rede expostos, um programador precisa convertero código do servidor existente para a sintaxe ASMX. Assim,os dispositivos tradicionais para expor um serviço para umcliente utilizar exigem esforços de desenvolvimentos nãotriviais.Enquanto desvantagens específicas dos sistemas e-xistentes foram ilustradas e descritas na Seção de Antece-dentes, os versados na técnica e outros irão reconhecer queo assunto reivindicado neste documento não está limitado aqualquer implementação específica para resolver qualquer umaou todas das desvantagens descritas.
SUMÁRIO
Este sumário é proporcionado para introduzir umaseleção de conceitos de uma forma simplificada que são adi-cionalmente descritos abaixo na Descrição Detalhada. Estesumário não é pretendido para identificar os aspectos prin-cipais do assunto reivindicado, nem é pretendido para serutilizado como um auxílio ao determinar o escopo do assuntoreivindicado.
Os aspectos da invenção completam o mecanismo tra-dicional para expor um serviço oferecido por um servidor pa-ra um cliente por proporcionarem um caminho pseudo-virtualpara o serviço. 0 caminho pseudo-virtual permite què um pro-gramador exponha um serviço sem criar um arquivo físico comuma extensão especial. Tal caminho pseudo-virtual também po-de ser criptografado de modo que as informações com respeitoao serviço possam não ser desnecessariamente expostas.
De acordo com um aspecto da invenção, em um ambi-ente de computação distribuído, incluindo pelo menos um ser-vidor e um cliente, um serviço no servidor é exposto peloservidor gerando um caminho pseudo-virtual para o serviço. 0caminho pseudo-virtual mapeia diretamente para o serviço, aoinvés de para um arquivo físico contendo o serviço. De pre-ferência, uma interface com o usuário de programação de a-plicação é proporcionada, a qual pega o serviço como um pa-râmetro e gera um caminho pseudo-virtual para o serviço.
De preferência, o caminho pseudo-virtual para oserviço exposto é integrado em uma classe proxy para o ser-vidor. A classe proxy pode identificar serviços proporciona-dos pelo servidor e informação sobre como chamar os servi-ços. A classe proxy pode incluir uma descrição e informaçãode tipo de um serviço exposto. A classe proxy pode incluirinformação sobre como acessar o serviço exposto, por exem-plo, por proporcionar um caminho pseudo-virtual ou um cami-nho tradicional para o serviço. Uma vez que um cliente enviauma requisição para a classe proxy, a classe proxy é enviadapara o cliente. O cliente pode identificar que serviço re-quisitar por examinar a classe proxy. 0 cliente pode utili-zar o caminho para o serviço na classe proxy para requisitaro serviço.
De acordo com outro aspecto da invenção, ao rece-ber uma requisição de serviço a partir de um cliente, o ser-vidor determina se a requisição de serviço inclui um caminhopseudo-virtual. Se a requisição de serviço ~incluir um.cami-nho pseudo-virtual, o servidor proporciona para o cliente oserviço requisitado diretamente. Tipicamente, um caminhopseudo-virtual inclui uma indicação especial indicando que ocaminho é um caminho pseudo-virtual. 0 conteúdo no caminhoseguindo o sinal especial é uma sintaxe especial represen-tando o serviço. Portanto, quando determinando se uma requi-sição de serviço inclui um caminho pseudo-virtual, o servi-dor decide se um caminho inclui a indicação especial. Se umcaminho inclui a indicação especial identificando a existên-cia de um caminho pseudo-virtual, o servidor trata a sintaxeespecial seguindo a indicação especial como informação re-5 presentando o serviço. De preferência, de modo a impedir ex-posição desnecessária de um serviço do servidor, um caminhopseudo-virtual pode ser criptografado antes de ser integradona classe proxy. A criptografia pode cobrir somente a indi-cação especial, ou tanto a indicação especial como a sintaxeespecial.
DESCRIÇÃO DOS DESENHOS
Os aspectos precedentes e várias das vantagens a-companhantes desta invenção serão mais prontamente aprecia-dos à medida que os mesmos sejam mais bem entendidos por re-ferência à descrição detalhada seguinte, quando feita emconjunto com os desenhos acompanhantes, onde:
A FIGURA 1 é um diagrama de blocos ilustrando in-terações ilustrativas entre um cliente e um servidor;
A FIGURA 2A é um diagrama de blocos ilustrando umcaminho tradicional ilustrativo levando a um serviço expostodo servidor;
A FIGURA 2B é um caminho pseudo-virtual ilustrati-vo levando a um serviço exposto do servidor;
A FIGURA 2C é um diagrama de blocos ilustrando umcaminho criptografado ilustrativo levando a um serviço ex-posto do servidor;
A FIGURA 3 é um fluxograma ilustrando um processoilustrativo para expor um serviço do servidor;A FIGURA 4 é um fluxograma ilustrando uma rotinailustrativa para proporcionar um caminho pseudo-virtual ma-peando para o serviço exposto, adequado para uso na FIGURA 3;
A FIGURA 5 é um fluxograma ilustrando uma rotinailustrativa para determinar se uma requisição de serviço in-clui um caminho pseudo-virtual, adequado para uso na FIGURA 3; e
A FIGURA 6 é um diagrama de blocos ilustrando umainterface de programação de aplicação ilustrativa para gerarum caminho pseudo-virtual.
DESCRIÇÃO DETALHADA
O texto seguinte ilustra e descreve modalidadesilustrativas da invenção. Entretanto, os versados na técnicairão apreciar que várias alterações podem ser feitas nasmesmas sem se afastar do espirito e do escopo da invenção.
As modalidades da invenção podem ser descritas nocontexto geral de instruções executáveis por computador, talcomo módulos de programa, sendo executadas por um computadorpossuindo pelo menos um processador e uma memória. Geralmen-te descritos, os módulos de programa incluem rotinas, pro-gramas, símbolos gráficos, objetos, componentes, estruturasde dados e assim por diante, que executam tarefas particula-res ou implementam tipos de dados abstratos particulares. Asmodalidades da invenção também podem ser praticadas em umambiente de computação distribuído, onde os serviços de com-putação são proporcionados por algumas entidades ("servido-res") para outras entidades ("clientes"). As entidades podemser locais a um mesmo sistema de computação ou serem ligadasatravés de uma rede de comunicações. Em um ambiente de com-putação distribuído, os módulos de programa proporcionandoos serviços podem estar localizados no meio de armazenamentodo computador local e / ou remoto.
A FIGURA 1 ilustra um sistema de computação dis-tribuído ilustrativo 100 que inclui pelo menos um cliente102 e pelo menos um servidor 104. 0 servidor 104 proporcionapelo menos um serviço exposto 105, tal como um serviço da
Rede que o cliente 102 pode utilizar. Um serviço da Rede ge-ralmente proporciona um ou mais métodos existentes no servi-dor que permitem ao cliente chamar para obter certas infor-mações. O código seguinte ilustra um serviço da Rede ilus-trativo SimpleService exposto no servidor 104.
using System;
using System.Web.Services;
using System.Web;
using System.Web.Profile;
namespace Acme {
public class SimpleService {[WebMethod]
public string HelloWorldO {return "Hello from a web service that doesn't usean asmx file";
}}}De modo a expor um serviço 105 oferecido pelo ser-vidor 104, as modalidades ilustrativas da invenção utilizamuma classe proxy 108. A classe proxy 108 pode incluir infor-mação a cerca de quais serviços estão disponíveis para ocliente 102 utilizar. A classe proxy 108 também pode propor-cionar descrições básicas do serviço 105 e informação a cer-ca de como chamar o serviço 105. Tipicamente, a classe proxy108 proporciona ao cliente 102 uma representação do serviço105 oferecido pelo servidor 104. A classe proxy pode adicio-nalmente incluir informação descrevendo o tipo de informaçãoassociada com o serviço 105. Em modalidades ilustrativas dainvenção, cada serviço exposto 105 no servidor 104 está as-sociado com a classe proxy 108.
Em uma modalidade ilustrativa da invenção, uma Ii-gação com a classe proxy 108 para o servidor 104 é propor-cionada para o cliente 102, por exemplo, por um programadorno cliente 103 que sabe que o cliente 102 pode precisar uti-lizar um serviço exposto 105 proporcionado pelo servidor104. Assim, uma vez que o cliente 102 determina que ele ne-cessita utilizar o serviço 105 descrito na classe proxy 108,o cliente 102 envia uma requisição 106 em relação à classeproxy para o servidor 104, utilizando a ligação. 0 servidor104 então retorna a classe proxy 108. 0 cliente 102 determi-na o que é oferecido pelo servidor 104 por examinar a classeproxy 108. Através do exame, o cliente 102 toma conhecimentode quais métodos ele pode chamar de modo a utilizar o servi-ço exposto 105. O cliente 102 então faz uma requisição 110em relação ao serviço exposto 105 por utilizar informaçãoproporcionada na classe proxy 108. Por exemplo, o cliente102 pode chamar um método especifico oferecido pelo servidorexposto 105.
O texto seguinte ilustra um conteúdo ilustrativona classe proxy 108 para o serviço exposto SimpleService.
Type.registerNamespace('Acme');
Acme.SimpleService =
path:
"/app/AtlasServices/Acme/SimpleService.asmx",
HelloWorld:function(onMethodComplete, onMethod-Timeout) {return
At-
las. Net.ServiceMethodRequest.calIMethod(this.path, "HeiIoWorld", {},
OnMethodComplete, onMethodTimeout); } }
Nas modalidades da invenção, a informação de tipocontida na classe proxy 108 em relação a um serviço, tal co-mo o serviço 105, proporciona um identificador para o servi-dor 104 para localizar o serviço. A informação de tipo podeser, por exemplo, um nome de tipo do serviço, um URL levandoao serviço, e / ou um nome de método do serviço. Por exem-plo, no conteúdo ilustrativo na classe proxy 108 em relaçãoao serviço exposto SimpleService apresentado acima, a infor-mação de tipo para o serviço exposto SimpleService inclui umnome de tipo Acme. SimpleService, um URL"/app/AtlasServices/Acme/SimpleService. asmx", e um nome demétodo "Hello World".
Também apresentado no conteúdo ilustrativo acimana classe proxy 108 para o SimpleService ilustrativo, aclasse proxy 108 inclui um caminho que leva ao serviço ex-posto 105 tal como o SimpleService ilustrativo no servidor104. Nas modalidades da invenção, o caminho levando a umserviço exposto 105 pode ser um caminho tradicional, um ca-minho pseudo-virtual, ou um caminho criptografado. AsFIGURAS 2A e 2C proporcionam um exemplo para cada um dostrês tipos de caminho.
Tipicamente, um caminho tradicional leva a um ar-quivo físico no servidor 104 que contém o serviço exposto105. A FIGURA 2A ilustra um caminho tradicional ilustrativo200 - htpp://server/app/folder/SimpleService.asmx. 0 caminhotradicional 200 aponta para um arquivo físico - SimpleServi-ce.asmx - no servidor 104.
A FIGURA 2B ilustra um caminho pseudo-virtual i-lustrativo 240. Em aparência, o caminho pseudo-virtual 240parece similar ao caminho tradicional 200. Entretanto, o ca-minho pseudo-virtual 240 não realmente mapeia para uma ar-quivo físico, como o caminho tradicional 200 faz. O caminhopseudo-virtual 240 na verdade mapeia para o serviço exposto105. Como apresentado na FIGURA 2B, o caminho pseudo-virtual240 inclui uma indicação especial 242 e uma sintaxe especial244. Nas modalidades da invenção, a indicação especial 242 ea sintaxe especial 244 podem ser compostas de qualquer sin-taxe ou formato que o servidor 102 possa reconhecer. Por e-xemplo, em algumas modalidades da invenção, a indicação es-pecial 242 e a sintaxe especial 244 aparecem como uma enti-dade, apesar do servidor 104 poder reconhecer as partes daindicação especial 242 e da sintaxe especial 244 na entida-de. 0 código acima para a classe proxy ilustrativa em rela-ção ao serviço exposto SimpleService ilustra um caminhopseudo-virtual em relação ao SimpleService ilustrativo. Ocaminho é lido como"/app/AtlasServices/Acme/SimpleService.asmx". 0 "AtlasServi-ces/Acme" no caminho funciona como a indicação especial 242indicando que o caminho é um caminho pseudo-virtual. O "Sim-pleService.asmx" no caminho é uma sintaxe especial ilustra-tiva 244 mapeando para o SimpleService exposto.
Nas modalidades da invenção, a existência da indi-cação especial 242 em um caminho ajuda ao servidor 104 a de-terminar que o caminho funciona como um caminho pseudo-virtual 240, não como um caminho tradicional 200 que leva álocalização de um arquivo físico. A indicação especial 242indica que o conteúdo seguindo à indicação especial 242 nocaminho é a sintaxe especial 244. A sintaxe especial 244proporciona uma descrição de o que é o serviço exposto 105.A sintaxe especial 244 não mapeia o caminho pseudo-virtual240 para um arquivo físico no servidor 104. A sintaxe espe-cial, apesar de ela parecer muito um caminho normal, tipica-mente contém a informação de tipo associada com o serviçoexposto 105. Por exemplo, a informação de tipo pode revelaro nome de tipo do serviço exposto 105.Quando apresentada claramente, a informação de ti-po revelada na sintaxe especial 244 pode permitir ao cliente103 especular e chamar os métodos de serviço, para os quaiso cliente 102 não deve ter acesso. Por exemplo, o cliente102 pode especular que o serviço proporcionado pelohtpp://Server/Special_Token/Forbidden..asmx poderia conterum método "Forbidden()" e produzir uma chamada de método"Forbidden()", onde, na realidade, o método "Forbidden()" éproporcionado pelo serviço mas o cliente 102 não deve teracesso.
Para impedir revelação desnecessária de informaçãodo servidor, as modalidades da invenção criptografam o cami-nho pseudo-virtual 240. A FIGURA 2C ilustra um caminho crip-tografado ilustrativo 260. O caminho criptografado 260 podeconter um caminho tradicional 200 ou um caminho pseudovirtu-al 240. Em uma modalidade ilustrativa da invenção, o conteú-do criptografado 262 em um caminho pseudovirtual criptogra-fado contém somente a sintaxe especial 244 que mapeia dire-tamente para o serviço exposto 105. Em uma modalidade alter-nativa da invenção, o conteúdo criptografado 262 em um cami-nho pseudo-virtual criptografado contém tanto a indicaçãoespecial 242 como a sintaxe especial 244.
Nas modalidades ilustrativas da invenção, não im-portando o tipo do caminho, por exemplo, um caminho tradi-cional ou um caminho pseudo-virtual, que é utilizado naclasse proxy 108 para representar o serviço exposto 105, tu-do que o cliente 102 percebe do caminho é um URL para o ser-viço exposto 105. O cliente 102 envia o caminho, isto é, oURL, para o servidor para requisitar o serviço exposto 105.O servidor 104 interpreta o caminho recebido para determinarse o caminho recebido é um caminho tradicional 200, um cami-nho pseudo-virtual 240, ou um caminho criptografado 260.
Quando o servidor 104 detecta a informação criptografada nocaminho, ele primeiro decriptografa a informação criptogra-fada. O servidor 104 então utiliza a informação decriptogra-fada para determinar se o caminho é um caminho pseudo-virtual ou um caminho tradicional. Por exemplo, se o servi-dor 104 detectar a indicação especial 242 no caminho recebi-do, o servidor 104 determina que o caminho recebido é um ca-minho pseudo-virtual 240 e que o conteúdo após a indicaçãoespecial 242 é a sintaxe especial 244 mapeando diretamentepara o serviço exposto 105.
Como ilustrado na FIGURA 6, em uma modalidade i-lustrativa da presente invenção, para expor um serviço 105de modo que ele possa ser chamado pelo cliente 102, o servi-ço 105 é primeiro registrado através de uma interface deprogramação de aplicação ("API") 600. A API 600 cria o cami-nho pseudo-virtual 240 para o serviço 105. O caminho pseudo-virtual 240 então é incluído na classe proxy 108 para o ser-vidor 104. Como apresentado na FIGURA 1, quando o cliente102 requisita a calasse proxy 108, o servidor 104 envia aclasse proxy 108 contendo o caminho pseudo-virtual 240 parao cliente 102. O cliente 102 pode, desse modo, acessar oserviço exposto 105 utilizando o caminho pseudo-virtual 240.
A FIGURA 3A ilustra um processo ilustrativo 300para expor um serviço do servidor utilizando um caminhopseudo-virtual. Tipicamente, o processo 300 gera um caminhopseudo-virtual para cada serviço exposto em um servidor. Aoreceber uma requisição a partir de um cliente em relação aum serviço exposto, o servidor determinar se a requisiçãoinclui um caminho pseudo-virtual ou um caminho tradicional epor conseqüência fornece o serviço exposto. Em uma modalida-de ilustrativa da invenção, como ilustrado, o processo 300inicia pela execução de uma rotina 302 que gera e proporcio-na aos clientes potenciais um caminho pseudo-virtual em re-lação a um serviço exposto no servidor. A FIGURA 4 ilustrauma implementação ilustrativa da rotina 302 e será descritaem detalhes a seguir. Alternativamente, um cliente potencialpara o serviço exposto pode receber um caminho tradicionalpara o serviço. Um cliente que deseja acessar o serviço ex-posto irá enviar uma requisição em relação ao serviço para oservidor. Tal requisição pode conter um caminho pseudo-virtual, um caminho tradicional, ou um caminho criptografadoque inclui um caminho pseudo-virtual ou um caminho tradicio-nal. Portanto, ao determinar que o servidor recebeu uma re-quisição de serviço a partir de um cliente (veja o bloco dedecisão 304), o processo 300 continua para executar outrarotina 306 que determina se a requisição de serviço recebidainclui um caminho pseudo-virtual. Veja o bloco 306. A FIGURA5 ilustra uma implementação ilustrativa da rotina 306 e serádescrita em detalhes a seguir.
Após executar a rotina 306, o processo 300 conti-nua para determinar se a requisição de serviço a partir docliente inclui um caminho pseudo-virtual. Veja o bloco dedecisão 308. Se a resposta para o bloco de decisão 308 forNÃO, o processo 300 continua para tratar a requisição deserviço como incluindo um caminho tradicional que mapeia pa-ra um arquivo fisico para o serviço exposto e proporciona oarquivo fisico para o cliente. Veja o bloco 310. O processo300 então termina. Se a resposta para o bloco de decisão 308for SIM, então a requisição de serviço realmente inclui umcaminho pseudo-virtual; o processo 300 continua para propor-cionar ao cliente o serviço representado na sintaxe especialdo caminho pseudo-virtual. Veja o bloco 312. 0 processo 300então termina.
A FIGURA 4 ilustra uma rotina ilustrativa 302 paraproporcionar um caminho pseudo-virtual para qualquer clienteque pretenda utilizar os serviços expostos em um servidor. Arotina 302 primeiro gera um caminho pseudo-virtual para umserviço exposto do servidor. Veja o bloco 402. Nas modalida-des da invenção, um caminho pseudo-virtual pode ser geradopor diferentes meios. Por exemplo, como citado acima, o ser-viço exposto pode ser passado para uma API, a qual cria umcaminho pseudo-virtual para o serviço. Alternativamente, ocaminho pseudo-virtual pode ser criado manualmente ou por umscript.
A rotina 302 então inclui o caminho pseudo-virtualpara o serviço em uma classe proxy que descreve os serviçosproporcionados pelo servidor. Veja o bloco 404. Como citadoacima, a classe proxy ode também incluir informação a cercade que quais serviços estão disponíveis no servidor para umcliente utilizar. A classe proxy também pode incluir descri-ções básicas de um serviço e informação a cerca de como cha-mar um serviço. A classe proxy pode adicionalmente incluirinformação de tipo associada com um serviço. Em uma modali-dade ilustrativa da invenção, quando um cliente possui o po-tencial de chamar um servidor em relação aos serviços ofere-cidos pelo servidor, um programador para o cliente incorporano cliente uma ligação com a classe proxy para o servidor.Quando o cliente pretende utilizar serviços oferecidos peloservidor, o cliente envia uma requisição para o servidor emrelação à classe proxy, utilizando a ligação com a classeproxy. Portanto, a rotina 302 proporciona a classe proxy pa-ra um cliente ao receber uma requisição a partir do clienteem relação á classe proxy. Veja o bloco 406. 0 cliente podeentão enviar uma requisição de serviço para o servidor, uti-lizando a informação proporcionada na classe proxy com res-peito ao serviço. Como será apreciado pelos versados na téc-nica, a rotina ilustrativa 302 somente proporciona um meioilustrativo para proporcionar um caminho pseudo-virtual emrelação a um serviço exposto do servidor. Meios alternativospodem incluir, por exemplo, utilizar um script para gerar umcaminho pseudo-virtual em relação a um serviço exposto doservidor e fornecer o caminho pseudo-virtual ao receber umarequisição a partir de um cliente em relação aos serviçosexpostos em um servidor.
A FIGURA 5 ilustra uma rotina ilustrativa 306 quedetermina se uma requisição de serviço enviada por um clien-te inclui um caminho pseudo-virtual. A rotina 306 inicia pe-la análise da requisição de serviço. Veja o bloco 502. A ro-tina 306 então decide se a requisição de serviço contémqualquer conteúdo criptografado. Veja o bloco de decisão504. Se a requisição de serviço inclui o conteúdo criptogra-fado, a rotina 306 continua para decriptografar o conteúdocriptografado. Veja o bloco 506. Se a resposta para o blocode decisão 504 for NÃO, significando que a requisição deserviço contém texto sem formatação, ou se a rotina 306 de-criptografou qualquer conteúdo decriptografado, a rotina 306continua para determinar se a requisição de serviço incluiuma indicação especial indicando a presença de um caminhopseudo-virtual. Veja o bloco de decisão 508. Se a respostapara o bloco de decisão 508 for SIM, significando que a re-quisição de serviço inclui um caminho pseudo-virtual, a ro-tina 306 retorna VERDADEIRO e termina. Veja o bloco 512. Sea resposta para o bloco de decisão 508 for NÃO, significandoque a requisição de serviço não inclui um caminho pseudo-virtual, a rotina 306 retorna FALSO e termina. Veja o bloco510.
E resumo, as modalidades da invenção proporcionamoutra abordagem para um cliente para acesso a um serviço ex-posto por um servidor. A abordagem de caminho pseudo-virtualpermite que um programador exponha um serviço do servidorsem gravar um arquivo especial com uma extensão especial pa-ra o serviço. Assim, o programador pode expor um serviço doservidor sem a necessidade de entender a sintaxe do arquivoespecial ou de converter o código do serviço existente paraa sintaxe do arquivo especial. Como resultado, a abordagemde caminho pseudo-virtual reduz os esforços de desenvolvi-mento necessários para expor um serviço do servidor.
Apesar dos aspectos da invenção terem sido descri-tos em linguagem especifica para os aspectos estruturais e /ou metodológicos, é para ser entendido que o assunto defini-do nas reivindicações anexas não está necessariamente limi-tado aos aspectos específicos ou atos descritos acima. Aoinvés disso, os aspectos ou atos específicos descritos acimasão revelados como formas ilustrativas de implementar asreivindicações.
As modalidades das invenção nas quais uma proprie-dade ou privilégio exclusivo é reivindicado são definidascomo se segue:

Claims (20)

1. Método implementado por computador para exporum serviço (105) proporcionado pelo servidor (104), em umsistema de computação distribuído, incluindo um componenteservidor ("servidor") (104) e um componente cliente ("clien-te") (102), CARACTERIZADO por compreender:proporcionar ao cliente (102) um caminho pseudo-virtual (240) que mapeia diretamente para o .serviço (105),ao invés de mapear para um arquivo físico contendo o serviço(105);ao receber uma requisição (110) em relação ao ser-viço (105) a partir do cliente (102), determinando se a re-quisição (110) inclui o caminho pseudo-virtual (240); ese a requisição (11) inclui o caminho pseudo-virtual (240), proporcionar ao cliente (102) o serviço (105)cie acordo com a informação no caminho pseudo-virtual (240) .
2. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o caminho pseudo-virtual in-clui uma indicação especial indicando que um caminho é umcaminho pseudo-virtual que mapeia diretamente para o servi-ço .
3. Método, de acordo com a reivindicação 2,CARACTERIZADO pelo fato de que o caminho pseudo-virtual tam-bém inclui uma sintaxe especial representando o serviço.
4. Método, de acordo com a reivindicação 3,CARACTERIZADO pelo fato de que a sintaxe especial proporcio-na informação de tipo do serviço.
5. Método, de acordo com a reivindicação 3,CARACTERIZADO pelo fato de que o caminho pseudo-virtual écriptografado.
6. Método, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que somente a sintaxe especial nocaminho pseudo-virtual é criptografada.
7. Método, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que tanto a indicação especialcomo a sintaxe especial no caminho pseudo-virtual são crip-tografadas .
8. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que proporcionar para o clienteum caminho pseudo-virtual inclui:gerar o caminho pseudo-virtual;incluir o caminho pseudo-virtual em uma classeproxy; eproporcionar a classe proxy para o cliente ao re-ceber uma requisição a partir do cliente em relação à classeproxy.
9. Método implementado por computador, de acordocom a reivindicação 8, CARACTERIZADO pelo fato de que a ge-ração do caminho pseudo-virtual para o serviço inclui chamaruma interface de programação de aplicação utilizando o ser-viço como um parâmetro, onde a interface de programação deaplicação gera e retorna o caminho pseudo-virtual.
10. Método implementado por computador, de acordocom a reivindicação 8, CARACTERIZADO pelo fato de que aclasse proxy identifica pelo menos um serviço exposto peloservidor.
11. Interface de programação de aplicação incorpo-rada em um ou mais meios legíveis por computador,CARACTERIZADA pelo fato de compreender uma função relaciona-da com gerar um caminho pseudo-virtual (240) em relação a umserviço exposto (105) em um servidor (104), onde o caminhopseudo-virtual (240) mapeia diretamente para o serviço ex-posto (105), ao invés de mapear para um arquivo físico noservidor (104) contendo o serviço (105).
12. Sistema de computador proporcionando pelo me-nos um serviço (105), CARACTERIZADO por compreender:(a) memória; e(b) um processador, acoplado com a memória, o qualexecuta instruções executáveis por computador para:proporcionar (302) um caminho pseudo-virtual (240)que mapeia diretamente para o serviço (105);ao receber (304) uma requisição (110) em relaçãoao serviço a partir de um cliente (102), determinar (306) sea requisição (110) inclui o caminho pseudo-virtual (240); ese a requisição (110) incluir o caminho pseudo-virtual (240), proporcionar (312) para o cliente (102) oserviço (105) de acordo com a informação no caminho pseudo-virtual (240).
13. Sistema de computador, de acordo com a reivin-dicação 12, CARACTERIZADO pelo fato de que o caminho pseudo-virtual inclui uma indicação especial indicando que um cami-nho é um caminho pseudo-virtual que mapeia diretamente parao serviço.
14. Sistema de computador, de acordo com a reivin-dicação 13, CARACTERIZADO pelo fato de que o caminho pseudo-virtual também inclui uma sintaxe especial representando oserviço.
15. Sistema de computador, de acordo com a reivin-dicação 14, CARACTERIZADO pelo fato de que a sintaxe especi-al proporciona informação de tipo do serviço.
16. Sistema de computador, de acordo com a reivin-dicação 14, CARACTERIZADO pelo fato de que o caminho pseudo-virtual é criptografado.
17. Sistema de computador, de acordo com a reivin-dicação 16, CARACTERIZADO pelo fato de que somente a sintaxeespecial no caminho pseudo-virtual é criptografada.
18. Sistema de computador, de acordo com a reivin-dicação 12, CARACTERIZADO pelo fato de que o processador e-xecuta as instruções executáveis por computador para propor-cionar um caminho pseudo-virtual que mapeia diretamente parao serviço por:gerar o caminho pseudo-virtual;incluir o caminho pseudo-virtual em uma classeproxy; eproporcionar a classe proxy para o cliente ao re-ceber uma requisição a partir do cliente em relação à classeproxy.
19. Sistema de computador, de acordo com a reivin-dicação 18, CARACTERIZADO pelo fato de que o processador e-xecuta as instruções executáveis por computador para gerar ocaminho pseudo-virtual em relação ao serviço por chamar umainterface de programação de aplicação utilizando o serviçocomo um parâmetro, onde a interface de programação de apli-cação gera e retorna o caminho pseudo-virtual.
20. Sistema de computador, de acordo com a reivin-dicação 18, CARACTERIZADO pelo fato de que a classe proxyidentifica pelo menos um serviço exposto pelo servidor.
BRPI0615661-4A 2005-09-12 2006-08-22 estrutura de serviço no lado do servidor BRPI0615661A2 (pt)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US71605505P 2005-09-12 2005-09-12
US60/716.055 2005-09-12
US11/318.226 2005-12-23
US11/318,226 US20070078927A1 (en) 2005-09-12 2005-12-23 Server-side service framework
PCT/US2006/032881 WO2007032871A2 (en) 2005-09-12 2006-08-22 Server-side service framework

Publications (1)

Publication Number Publication Date
BRPI0615661A2 true BRPI0615661A2 (pt) 2011-05-24

Family

ID=37865430

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0615661-4A BRPI0615661A2 (pt) 2005-09-12 2006-08-22 estrutura de serviço no lado do servidor

Country Status (13)

Country Link
US (1) US20070078927A1 (pt)
EP (1) EP1934821A4 (pt)
JP (1) JP4929285B2 (pt)
KR (1) KR20080055794A (pt)
CN (1) CN101263481B (pt)
AU (1) AU2006291366B2 (pt)
BR (1) BRPI0615661A2 (pt)
CA (1) CA2618619A1 (pt)
MX (1) MX2008003412A (pt)
NO (1) NO20080598L (pt)
RU (1) RU2412471C2 (pt)
SG (1) SG165367A1 (pt)
WO (1) WO2007032871A2 (pt)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109086148A (zh) * 2018-08-01 2018-12-25 山东浪潮通软信息科技有限公司 一种跨平台调用Web Service服务的方法
JP7447407B2 (ja) * 2019-08-19 2024-03-12 ヤマハ株式会社 通信管理サーバ、通信管理システムおよび通信管理方法
CN113961311A (zh) * 2021-10-27 2022-01-21 阿波罗智联(北京)科技有限公司 业务数据处理方法、装置、电子设备和介质

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5930255A (en) * 1995-01-31 1999-07-27 Canon Kabushiki Kaisha Method of setting a relaying path in a communication network
US6453325B1 (en) * 1995-05-24 2002-09-17 International Business Machines Corporation Method and means for backup and restoration of a database system linked to a system for filing data
US6710786B1 (en) * 1997-02-03 2004-03-23 Oracle International Corporation Method and apparatus for incorporating state information into a URL
US6845505B1 (en) * 1997-02-03 2005-01-18 Oracle International Corporation Web request broker controlling multiple processes
US6247056B1 (en) * 1997-02-03 2001-06-12 Oracle Corporation Method and apparatus for handling client request with a distributed web application server
US6049877A (en) * 1997-07-16 2000-04-11 International Business Machines Corporation Systems, methods and computer program products for authorizing common gateway interface application requests
US6141759A (en) * 1997-12-10 2000-10-31 Bmc Software, Inc. System and architecture for distributing, monitoring, and managing information requests on a computer network
US6453362B1 (en) * 1998-08-12 2002-09-17 International Business Machines Corporation Systems, methods and computer program products for invoking server applications using tickets registered in client-side remote object registries
JP4146983B2 (ja) * 1999-02-26 2008-09-10 インターナショナル・ビジネス・マシーンズ・コーポレーション サーバ・オブジェクトのメソッドを呼び出すプロセス方法及びデータ処理システム
CA2280588C (en) * 1999-08-20 2005-07-05 Leonard W. Theivendra Code wrapping to simplify access to and use of enterprise java beans
US6529983B1 (en) * 1999-11-03 2003-03-04 Cisco Technology, Inc. Group and virtual locking mechanism for inter processor synchronization
US6587888B1 (en) * 1999-12-15 2003-07-01 Networks Associates Technology, Inc. Dynamic software wrapper
US7716163B2 (en) * 2000-06-06 2010-05-11 Microsoft Corporation Method and system for defining semantic categories and actions
US7000230B1 (en) * 2000-06-21 2006-02-14 Microsoft Corporation Network-based software extensions
US6954778B2 (en) * 2000-07-12 2005-10-11 Microsoft Corporation System and method for accessing directory service via an HTTP URL
US7117504B2 (en) * 2001-07-10 2006-10-03 Microsoft Corporation Application program interface that enables communication for a network software platform
US7512972B2 (en) * 2002-09-13 2009-03-31 Sun Microsystems, Inc. Synchronizing for digital content access control
US7206807B2 (en) * 2003-01-21 2007-04-17 Bea Systems, Inc. Asynchronous invoking a remote web service on a server by a client who passes on a received invoke request from application code residing on the client
US7797444B2 (en) * 2003-02-03 2010-09-14 Nippon Telegraph And Telephone Corporation Data transfer apparatus and data transfer system
US20050015491A1 (en) * 2003-05-16 2005-01-20 Markel Corporation Systems, methods, and articles of manufacture for dynamically providing web services
US7363487B2 (en) * 2003-07-01 2008-04-22 International Business Machines Corporation Method and system for dynamic client authentication in support of JAAS programming model
JP2005043938A (ja) * 2003-07-22 2005-02-17 Fuji Xerox Co Ltd アクセス制御装置およびその方法
JP2005043958A (ja) * 2003-07-22 2005-02-17 Seiko Epson Corp 駐車管理装置、駐車管理システム及びプログラム
US7529824B2 (en) * 2003-10-14 2009-05-05 International Business Machines Corporation Method for selecting a service binding protocol in a service-oriented architecture
US8135851B2 (en) * 2003-12-19 2012-03-13 Stmicroelectronics, Inc. Object request broker for accelerating object-oriented communications and method
US20050160153A1 (en) 2004-01-21 2005-07-21 International Business Machines Corp. Publishing multipart WSDL files to URL
EP1914636A4 (en) * 2005-07-27 2009-12-23 Mikhail Vasilyevich Belyaev CLIENT SERVER INFORMATION SYSTEM AND METHOD FOR PRESENTING A GRAPHIC USER INTERFACE

Also Published As

Publication number Publication date
CN101263481B (zh) 2012-02-01
JP2009508251A (ja) 2009-02-26
AU2006291366A1 (en) 2007-03-22
CA2618619A1 (en) 2007-03-22
AU2006291366B2 (en) 2011-03-10
KR20080055794A (ko) 2008-06-19
WO2007032871A3 (en) 2007-05-03
NO20080598L (no) 2008-04-01
US20070078927A1 (en) 2007-04-05
RU2008109232A (ru) 2009-10-10
EP1934821A2 (en) 2008-06-25
JP4929285B2 (ja) 2012-05-09
SG165367A1 (en) 2010-10-28
MX2008003412A (es) 2008-03-27
EP1934821A4 (en) 2009-08-19
WO2007032871A2 (en) 2007-03-22
CN101263481A (zh) 2008-09-10
RU2412471C2 (ru) 2011-02-20

Similar Documents

Publication Publication Date Title
US11188353B2 (en) Runtime extension system for bundled web application
US11150893B2 (en) Collaborative software development tool for resolving potential code-change conflicts in real time
KR101384085B1 (ko) 보안 브라우저 기반 애플리케이션
US10509690B2 (en) Exposing server functions to browser code
KR20090063636A (ko) Ａｐｉ 서비스 방법과 ａｐｉ 매쉬업 생성 방법, 장치 및기록매체
US12254069B2 (en) Identifying and consenting to permissions for workflow and code execution
US20090063946A1 (en) Anchor store for transmitting multiple dynamic anchors
CN110348225A (zh) 针对应用程序接口的安全漏洞确定方法和装置
JP6951442B2 (ja) シブリング・コール処理のためのコンピュータ・プログラム製品、コンピュータ・システムおよびコンピュータによって実施される方法
CN110321504A (zh) 一种页面处理方法及装置
US8195766B2 (en) Dynamic implicit localization of web content
US8250226B2 (en) Generating one or more clients for generating one or more synthetic transactions with one or more web service operations
BRPI0615661A2 (pt) estrutura de serviço no lado do servidor
US20090049423A1 (en) Javascripttm programming extension
CN115268985B (zh) 一种用于RPC服务的Mock方法、装置及计算机可读存储介质
US20130067458A1 (en) Application site of origin reference scheme
CN111506301B (zh) 绕过系统限制反射调用的方法及相关设备
Papenfuss Containerizing a User-space Storage Framework for Reproducibility
US7523442B2 (en) JNDI validation
CN117193769A (zh) 页面渲染方法及装置、电子设备和计算机可读存储介质
Wallis et al. The super-browser: a new paradigm for web applications
US20060106864A1 (en) System, computer program product and method of narrowing an enterprise Java bean (EJB) object reference to a home implementation class name
Eriksson et al. Comparative study of containment strategies in solaris and security enhanced Linux
Scagliotti et al. Web services dynamic client guide
Ciliberti Getting the Most from the Built-in Templates

Legal Events

Date Code Title Description
B08F Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]

Free format text: REFERENTE A 7A ANUI DADE.

B08K Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette]

Free format text: REFERENTE AO DESPACHO 8.6 PUBLICADO NA RPI 2215 DE 18/06/2013.