BRPI0709905A2 - Registro de serviço e método e sistema relevante - Google Patents

Registro de serviço e método e sistema relevante Download PDF

Info

Publication number
BRPI0709905A2
BRPI0709905A2 BRPI0709905-3A2A BRPI0709905A BRPI0709905A2 BR PI0709905 A2 BRPI0709905 A2 BR PI0709905A2 BR PI0709905 A BRPI0709905 A BR PI0709905A BR PI0709905 A2 BRPI0709905 A2 BR PI0709905A2
Authority
BR
Brazil
Prior art keywords
service
local
remote
registry
request
Prior art date
Application number
BRPI0709905-3A2A
Other languages
English (en)
Inventor
Yu Chen Zhou
Li Yi
Xin Sheng Mao
Original Assignee
Ibm
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 Ibm filed Critical Ibm
Publication of BRPI0709905A2 publication Critical patent/BRPI0709905A2/pt
Publication of BRPI0709905B1 publication Critical patent/BRPI0709905B1/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/51Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/465Distributed object oriented systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/46Indexing scheme relating to G06F9/46
    • G06F2209/462Lookup
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/50Indexing scheme relating to G06F9/50
    • G06F2209/5015Service provider selection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Multi Processors (AREA)
  • Exchange Systems With Centralized Control (AREA)

Description

Relatório Descritivo da Patente de Invenção para: "REGISTRO DE SERVIÇO E SISTEMA. E MÉTODO RELEVANTE".
Campo da tecnologia
A presente invenção se refere a uma arquitetura orientada a serviços. Mais particularmente, a presente invenção se refere a melhorias em um registro de serviço no SOA e melhorias na propagação de serviço relevante, consulta, seleção de serviços e métodos de roteamento durante a invocação de serviço.
Antecedentes da Técnica
SOA é a sigla de "arquitetura orientada a serviços" e indica que um aplicativo pode ser composto por um conjunto de independentes e mutuamente cooperativos sub-sistemas ou serviços. Essa arquitetura faz com que cada serviço independente e somente informa os outros serviços da interface necessária a ser declarada. A SOA permite não só construtores de sistema organizar e diminuir as relações de dependência em seus produtos concebidos, mas também oferece um conjunto de serviços aparadas em um ambiente de desenvolvimento. Este método pode ser usado para suportar os requisitos existentes, por exemplo, o conjunto de aplicativos empresariais, e para fornecer uma base para a extensão da plataforma de modo a atender necessidades especiais comerciais, por exemplo, a personalização rápida de soluções relacionadas ao comércio eletrônico.
Como forma de entrega básico da SOA, services da web são amplamente usados no dia a dia. Os serviços da web são os chamados serviços de aplicativos online publicados por uma empresa para satisfazer as suas necessidades especiais comerciais, e estes serviços on-line podem ser acessados e utilizados por aplicações de outras empresas e parceiros de cooperação através de redes (incluindo a Internet, redes internas da empresa e redes externas da empresa, etc.) Os serviços da web, como um mecanismo eficiente de integração de fluxo em uma empresa, são utilizados no comércio, na Nasdaq no sistema de troca de ações da Austrália e outros, são exemplos bem conhecidos que utilizam os serviços da web. De fato, os serviços da Web podem executar qualquer função de um simples pedido a uma complicada operação comercial.
Qualquer serviço SOA ou na Web é composto por três papéis: um solicitante de serviço (ou chamado de consumidor 20 de serviços) , um prestador de serviços e um registro de serviço, como mostrado na figura I. A arquitetura 100 mostrada na figura 1 compreende um solicitante de serviço 110, um prestador de serviços 120 e um registro de serviço 130. Entre estes, o prestador do serviço 120 é responsável pela construção de um serviço útil e estabelecer respectivos metadados dw serviço, e depois publica os metadados para um ou mais registros de serviço 130, para que o solicitante do serviço consulta metadados do serviço de um ou mais registros de serviço 130. Os metadados podem incluir descrição funcional e uma descrição não-funcional, políticas e dados relevantes, etc dos serviços.
0 registro do serviço 130 é um repositório de metadados para os serviços que participam de uma SOA e é responsável pela manutenção e promulgação metadados de serviço nela publicados pelo prestador do serviço 120, e permite que o solicitante do serviço 110 para executar a consulta em uma descrição de serviço pertencentes a um serviço local Registro 130. No SOA arte prévia, não é necessário para o registro do serviço 130 para participar num processo de interação entre o solicitante do serviço eo prestador do serviço.
Além disso, entre o solicitante do serviço 110 e 120 do prestador de serviços, alguns Intermediador como um gateway, um enterprise service bus (EBS) e assim por diante (não demonstrado) pode ainda ser prestado. Estes Intermediador têm uma função simples entrega de solicitação-resposta entre o solicitante do serviço 110 e o prestador do serviço 120.
figura 1 mostra ainda mais o SOA contém três operações entre o solicitante do serviço 110, o prestador de serviços 120 e 130 do registro de serviço: publicar, localizar e vincular, e essas operações definir um contrato entre os papéis da SOA.
Até o momento, a SOA ou o sistema de serviços da web, como descrito acima, o registro de serviço só podem empregar a Universal Description Discovery & Integration padrão (UDDI). Todos os fornecedores dos registros de serviço (tais como IBM, Microsoft, SUN, ΒΕΑ, Systinet, etc) suporte UDDI 3.0 em seus produtos. UDDI é um padrão definido pela OASIS e seu foco é a definição de um conjunto de serviços de apoio à descrição e descoberta de:
1) empresas, organizações e outros prestadores de serviços da web;
2) os serviços da web que estão disponíveis e 3) a interface técnica que pode ser usado para acessar os
serviços da web.
Baseado em um conjunto comum de padrões da indústria, UDDI fornece uma infra-estrutura fundamental para os serviços da web ambiente de computação baseado. No entanto, o uso de UDDI resultado padrão em limitações técnicas dos serviços SOA ou web em termos de controle de serviço e de partilha, etc Por um lado, quanto ao controle e gerenciamento de metadados do serviço, utilizando o padrão UDDI tem as seguintes desvantagens: 1) Falta de modelo de dados extensível e métodos para
consulta 0 formato fixo de metadados do serviço não poderia atender a necessidade de adicionar mais recursos ou serviço propriedades específicas;
2) Falta de gerenciamento de ciclo de vida do serviço; 3) Falta de controle de tempo de execução durante a
invocação de serviço Isto porque na arquitetura SOA existentes triangular, um registro de serviço apenas desempenha o seu papel em um processo de configuração estática de serviços, mas não participar de uma interação dinâmica processo entre um solicitante de serviço e um provedor de serviço (incluindo o gateway ou EBS, etc) durante a execução de serviços; e
4) Falta de mecanismo de extensão de funcionalidade. Por outro lado, com a ampla utilização de serviços da web atualmente, o número de serviços tornam-se grandes, com o advento de mais e mais serviços multado em que são compatíveis com diferentes normas (como WSRP, ÜPnP, etc.)
Assim, o número de registros de serviço aumenta rapidamente também. Nesta situação, o compartilhamento de β informações entre os registros associados UDDI se a necessidade urgente de promover as tecnologias de serviços da web.
De acordo com a estipulação da versão 3 da especificação UDDI, o compartilhamento de informações entre os registros UDDI é implementada através da replicação de metadados do serviço, isto é, o importador recebe todos os metadados de entidades UDDI dos registros de origem e, em seguida, replica metadados em registros de destino. 0 importador aqui é um editor que lê os dados através do inquérito ou API Assinatura de um ou mais registros de origem e publica-lo para um registro de destino. Para obter informações detalhadas de compartilhamento de informação UDDI, consulte "UDDI versão 3.0.2, UDDI Spec Comitê Técnico Projecto, datada 20041019". O mecanismo para implementar a partilha de serviços entre os registros UDDI pela replicação tem as seguintes desvantagens:
1) A topologia de registros UDDI é diferente da do domínio de internet, por isso é difícil de manipular a
informação de serviço em cada sistema autônomo intenet.
2) Como o número de registros UDDI e entidades torna- se grande, há pouco espaço de armazenamento suficiente para replicar todos os metadados de todos os entidades em um único registro. 3) Quando a partilha de informação é implementada através da replicação das entidades, não carece de um mecanismo para sincronizar duplicatas da mesma entidade registrada em diferentes registos.
4) Uma vez que nem todas as entidades compartilhada
UDDI pode ser replicado em um registro UDDI, um cliente UDDI deve consultar vários registros UDDI para procurar a entidade de destino UDDI.
5) Como a quantidade de registros se torna grande e não há informações sobre a localização centralizada de registros UDDIf é difícil para o cliente se encontrar e percorrer todos os registros de acesso (Especialmente para o cliente com poder computacional limitado e largura de banda de comunicação). Na função dos casos acima, é necessário melhorar os
registros de serviço da SOA e serviços da web, de modo a aumentar a flexibilidade e operacionalidade no que respeita à gestão e serviço de compartilhamento. Sumário da Invenção Portanto, a presente invenção apresenta um registro
novo serviço, uma arquitetura de sistema centralizado no registro de serviço, métodos de propagação de serviço e de consulta, e métodos de seleção de serviço e roteamento durante a invocação de serviço. As idéias fundamentais da presente invenção encontram-se: ampliar as funções de um registro de serviço de informações do serviço distribuído e índice de consulta; realizando serviço de partilha de apenas replicar os índices de serviços (em vez dos metadados de serviço) entre os registros de serviço, controle de tempo de execução sobre a realização dos serviços, fazendo com que um registro de serviço para participar de um processo dinâmico que corre entre um solicitante de serviço e um provedor de serviços, rompendo assim com limitações técnicas que decorrem da utilização do padrão UDDI.
De acordo com um primeiro aspecto da presente invenção, um registro de serviço é fornecido, que é conectado com um domínio de rede local e um registro de serviço remoto, e inclui: um gerente de informação do serviço local para registrar os serviços locais no domínio do serviço local, e um informações sobre o serviço de repositório local ligado ao gestor local do serviço de informação para armazenar metadados de serviço dos serviços locais; caracterizado em que registro de serviço inclui ainda: um gerente de informação remota de serviços relacionados com o gestor local do serviço de informação e registro de serviço remoto, para receber um índice de serviço remoto a partir do registro de serviço remoto, e um serviço de informação remota repositório conectado o gerente de serviço de informação remota, para armazenar o indice de serviço remoto recebido do registro de serviço remoto.
De acordo com um segundo aspecto da presente invenção,
uma estrutura de SOA é fornecida, compreendendo: uma rede de serviços, incluindo a meta de registro de serviços acima referidos; um paralelo com a rede de serviços da rede de serviços de meta e incluindo um ou mais endpomts, e em um ou mais Intermediador entre intervenientes endpomts, onde endpomts uma ou mais pessoas podem interagir com o registro de serviço correspondente diretamente ou através do referido um ou mais Intermediador.
De acordo com um terceiro aspecto da presente invenção, um método para o serviço de compartilhamento de informações entre os registros de serviço é prestado, cadastros de estar fisicamente e / ou logicamente interligadas, em que o dito método compreende: registrando metadados de serviço de um provedor de serviços para um registro de serviço local do referido prestador de serviços e de propagação, pelo referido registro de serviço local, o índice de serviço nos metadados do serviço, a um registro de serviço remoto. De acordo com um quarto aspecto da presente invenção, um método para um solicitante de serviço para informações sobre o serviço de consulta de um registro de serviço, cadastros de estar fisicamente e / ou logicamente interligadas, em que o dito método compreende: solicitante do serviço enviando um pedido para inquirir sobre serviço de informações para um registro de serviço local, que a transferência de registro de serviço que o pedido para um relevante registro de serviço remoto de destino, com base em um indice de serviço de serviços remotos, até que o pedido chega a um ou mais registros alvo de serviço remoto, que um ou mais de serviço remoto de destino registros de envio de volta para registro de serviço local, o metadados do serviço solicitado, como resposta, registro de serviço de envio local que a resposta à referida solicitante do serviço.
De acordo com um quinto aspecto da presente invenção, um método para um solicitante de serviço para invocar um serviço em um domínio de serviço remoto é fornecido, o referido método compreendendo: solicitante do serviço de envio de um intermediário de um pedido de invocação de um serviço na área de serviço remoto e intermediário a enviar a solicitação a um registro de serviço local; registro de serviço local de origem o pedido para o domínio do serviço remoto, perguntando sobre um índice de serviço; um intermediário do domínio do serviço de envio remoto mensagem a um registro de serviço associado com o dito remoto domínio do serviço, o registro de serviço associado com o dito domínio do serviço de envio remoto referido serviço através do intermediário do domínio de serviço remoto para declarou prestador de serviços, de modo a proporcionar solicitante do serviço com o dito serviço. Ao utilizar a presente invenção, os registros do serviço são dotados de efeitos e funções novas. Primeiro, cada registro de serviço é capaz de controlar completamente um ou mais domínios autônomos, que é conveniente para os proprietários (organização, empresa ou departamento) dos registros de serviços para manter a informação de serviço. Em segundo lugar, cada registro de serviço é capaz de fornecer as seguintes funções: gestão de metadados do serviço estáticos e dinâmicos (dados local e um índice de dados remota) em um domínio local, inquirindo sobre os metadados do serviço em todos os registos relacionados, e realizando a seleção do serviço e roteamento centrado sobre o registro de serviço dentro ou entre os domínios do serviço.
Ao utilizar a presente invenção, um mecanismo extensível que implanta um módulo de função para o serviço de encaminhamento é fornecido, que não só realiza uma função de reforço do mecanismo, como um servidor de aplicação, para o serviço de roteamento e de selecção, mas também atinge conexão com um sistema externo (por exemplo, o faturamento, as regras comerciais, segurança, monitoramento, etc.)
Além disso, usando a invenção, a ligação inter-domínio pode ser realizada, o que é refletido principalmente nos seguintes três pontos. Em primeiro lugar, a topologia do domínio de serviço no presente invenção é mais natural e é similar à topologia de um sistema autônomo de Internet que podem ser mapeados para um domínio de aplicativo de uma empresa ou organização. Em segundo lugar, a presente invenção, todos os registros são conectados por índice em vez de replicar os metadados do serviço. Finalmente, todos os solicitantes de serviços e Intermediador (ESB, WS gateway e assim por diante) não precisa ter informações relativas a serviços fora do domínio do serviço local. Breve descrição dos desenhos
20
Nos desenhos anexos, as mesmas peças compostas utilizam os mesmos sinais de referência ou semelhantes.
A figura 1 é uma visão esquemática da estrutura SOA da técnica anterior. A figura 2 é uma visão esquemática da topologia de um sistema centrado em um registro de serviço de acordo com a presente invenção.
A figura 3 é uma estrutura básica de um registro de
5
serviço de acordo com a presente invenção.
A figura 3 apresenta uma estrutura de dados exemplificativos de um índice de serviço de acordo com a presente invenção.
A figura 3B mostra uma vista estrutural de um registro
10
de serviço, incluindo informações adicionais.
A figura 4 mostra um processo de combinação de inscrição, propagação e inquirindo sobre os serviços de acordo com a presente invenção.
A figura 4A mostra um caminho de propagação exemplar.
15
A figura 4B mostra um caminho exemplar de consulta. A figura 5 mostra um processo para a transmissão da mensagem de encaminhamento e seleção durante a invocação de serviço de acordo com a presente invenção.
A figura 5A é uma visão esquemática mostrando a
20
execução do processo da figura 5, com referência à topologia na figura 2.
A figura 6 é um fluxograma que mostra um método de registro de serviço para registrar e propagar os serviços de acordo com a presente invenção. A figura 7 mostra um método para um solicitante de serviço para os metadados do serviço de consulta de um registro de serviço local, de acordo com a presente invenção.
5
A figura 8 mostra um método de execução de serviço de encaminhamento e seleção de acordo com a presente invenção.
A figura 8A mostra um método de execução de serviço de encaminhamento e seleção de acordo com a modalidade preferida da presente invenção.
10
Melhor modo para realizar a invenção
Os princípios da presente invenção são descritos a seguir, com referência aos desenhos anexos.
Antes de descrever um novo registro de serviço de acordo com a presente invenção, devemos primeiro saber uma
15
topologia geral de um sistema de registro de serviço que é aplicado, e Figo. 2 é uma visão esquemática da topologia. Esta topologia compreende um plano de serviço de meta (ou chamado de rede de serviços de meta) 105 e um plano de serviço (ou chamado de serviço de rede) 106. O plano de
20
serviço meta 105 inclui um número de registros de serviço 101, uma linha de conexão entre o que indica que eles estão fisicamente e / ou logicamente interligadas. O plano de serviço 106 pode incluir um número de domínios de serviço D1-D4 cercado por elipses, e cada um dos serviços de domínios D1-D4 contém ainda alguns parâmetros 103 e 102 Intermediador, eo plano de serviço 106 pode ainda incluir um único terminal e / ou intermediário (um único intermediário entre o 102 D2 e D3 domínios do serviço, como
5
mostrado na figura 2), que não forma um domínio de serviço. Deve-se salientar que figura 2 é um exemplo e não deve ser entendida como qualquer limitação sobre o número real e a forma de ligação dos registros do serviço 101, os 102 Intermediador, dos 103 terminais e o domínio do serviço
10
104, etc.
Na topologia mostrada na figura 2, cada um dos registros de serviço 101 é responsável pelo registro do serviço e à propagação de um domínio de serviços locais e para a dinâmica de monitoramento de informações de serviços
15
locais; responsável por responder a uma solicitação de consulta de serviço (função de consulta extensível para obter meta-informação de um serviço de destino) de um desenvolvedor de software cliente e um solicitante de serviço e responsável pela seleção de serviço e roteamento
20
baseado em coordenação com o intermediário 102. Os registros do serviço 101 interagem uns com os outros, e todos os registros de serviço, bem como construir o plano de serviço de meta. Na dependência do status de um domínio de aplicação, os registros de serviços pode ter uma pluralidade de topologias, por exemplo, uma estrutura em estrela, uma estrutura totalmente entrelaçada, uma estrutura super-peer baseada em uma estrutura peer-to-peer pura e assim por diante. Deve-se salientar que, o que
5
topologia e mecanismo de conexão é adotado entre os registros de serviço que não é relevante para a execução da presente invenção.
No plano de serviço, cada um dos serviços de domínios D1-D4 é uma lógica de conjunto de serviços da web
10
registrados em um registro de serviço especificado. 0 domínio do serviço poderia ser um domínio com fronteira explícita (como domínio de Internet), ou que, sem fronteira explícita (como parte do domínio de Internet). Cada registro de serviço pode corresponder a um domínio de
15
serviço, que é chamado de "um domínio de rede local" do registro do serviço.
No domínio do serviço, cada um dos Intermediador 102 é utilizado para transporte e transformação de informações dentro ou entre os registros de serviços e fornece um
20
caminho para o serviço de roteamento entre um solicitante de serviço e um provedor de serviços. As peças, como o Enterprise Service Bus (EBS) ou Serviço de Gateway e assim por diante pode atuar como Intermediador. Cada um dos pontos de extremidade 103 é um iniciador de mensagem ou um destino final e pode incluir um solicitante de serviço e um provedor de serviços. Todos os terminais conectados e Intermediador construir o
5
plano de serviço 106 que é paralelo com o serviço de plano de meta 105.
Referindo-se agora à figura 3, a estrutura básica de um registro de serviço 200 de acordo com a presente invenção é explicada abaixo. Na figura 3, o registro de
10
serviço 200 é conectado a um domínio de rede local 106 e um registro de serviço remoto 200'. Deve ser entendido que, por razões de clareza, a figura 3 mostra apenas um registro de serviço remoto 200', mas na verdade, o registro do serviço 200 pode ser conectado com qualquer número de
15
registros de serviço remoto. Além disso, o registro de serviço 200 dispõe de um gerenciador de informações locais de serviço 201, um serviço de informação local repositório 202, um gerente de informação remota de serviços 203 e um serviço de informação repositório remoto 204. Ao utilizar a
20
estrutura como mostrado na figura 3, os processos de registro de serviço local, de propagação e de atualização e os processos de solicitação de serviços e invocação podem ser realizadas na secretaria do serviço 200. Quanto aos processos de propagação do local de serviço de registo e actualização, o gerente de informação do serviço local é conectado com 201 prestadores de serviços ou ferramentas de gestão no domínio de serviço de 106
5
locais, para que os prestadores de serviços ou as ferramentas de gestão pode (por exemplo, via API) registrar os serviços ao gestor local do serviço de informações 201. 0 gerente de informação do serviço local 201 é ainda mais conectado com as informações do serviço repositório local
10
202, de modo a armazenar em informações do serviço local de repositório de metadados do serviço 202 registados no domínio do serviço local, por um lado, e por outro lado, a faixa dinâmica real tempo do status dos serviços locais, directamente ou indirectamente e atualizar os metadados de
15
serviço relevante em informações do serviço de repositório local 202 quando a mudança dos serviços locais. Além disso, o gerenciador de informações locais serviço 201 é mais ligado com o gerente de serviço de informação remota de 203 para notificar o gestor de informação remota de serviço 203
20
de informações de serviços locais e sua atualização (por exemplo, alteração do estatuto dos serviços), para que o local serviços de informação e sua atualização são propagadas para todos os outros registros de serviço directamente ligado 200'. Durante a propagação das informações do serviço local, o gerente de informação do serviço local 201 irá extrair informações adequadas para servir como um indice de serviço a partir dos metadados do serviço local.
5
Os metadados de serviço são metadados para descrever os serviços, por exemplo, a descrição funcional dos serviços, incluindo a descrição do serviço de interface, por exemplo, WSDL (Web Service Definition Language) Descrição de base (incluindo as operações, os formatos de
10
mensagens, etc), descrição dos não-funcionais do serviço (tais como o serviço do proprietário da IBM, XSD (XML Schema Definition), serviço de localização de Beijing); políticas de serviço (tais como descrição de serviço política baseada em padrões como WS-Policy (Política de Web
15
Service), por exemplo, operação, segurança e confiabilidade políticas, etc) e outros metadados.
0 termo "índice" ou "índice de serviço" é a informação relativa a serviços remotos armazenados em um registro de serviço local. Por exemplo, os registros do serviço 200 e
20
200 'servir como um registro de serviço remoto para o outro, onde o registro de serviço de 200 lojas, apenas um índice de serviço (em vez de metadados do serviço) relativos aos serviços do registo do serviço 200", e o registro de serviço 200 armazena também apenas um índice de serviço relativo aos serviços do registo do serviço 200.
As informações de metadados apropriadas para ser um índice ou índice de serviço compreende, mas não está
5
limitado a: a descrição WSDL, o proprietário do serviço ou local de serviço ou similares na descrição não-funcional, eo nome do atributo, o conjunto de atributos, o último salto endereço de um serviço e similares do serviço de metadados que estão aptos a ser um índice, como descrito
10
abaixo em detalhes. Além disso, as informações de metadados para servir como o índice de serviço pode ser extraído pelo gestor local serviço de informações 201 e também pode ser extraído por outros meios apropriados, ou pode ser designado por um prestador de serviços durante o registro
15
do serviço.
A figura 3 apresenta uma estrutura de dados exemplificativa de um índice de serviço de acordo com a presente invenção, que compreende pelo menos três campos: nome do atributo / tipo 280, série 281 e atribuem o
20
endereço hop passado 282. E compreensível que esse quadro índice pode ainda incluir quaisquer outros campos necessários, conforme necessário.
A Tabela 1 registra uma série de itens do índice da tabela, onde os itens de metadados pode ser usado para indexação.
Nome do atributo/ tipo Faixa do atributo Último endereço de hop Registro de serviço Ponto final/ intermediador Nome da empresa IBM SRl Il Telefone 66660000-66660010 SRl Il Localização Beij ing SRl Il data de emissão Ano de 2005 SRl Il Nome da interface de serviço http://www.ibm.com/ servicel/servicel- 5.wsdl SRl Il
Na Tabela 1, o campo gama atributo pode ser um valor
5
único atributo ou valores de atributos dentro de um intervalo. 0 endereço hop último indica o endereço do registro do último serviço eo correspondente mtermediator / endereço do ponto final no caminho de propagação do valor do índice em relação a um registro de serviço local.
10
Continuando a referir a figura 3, as informações de serviços locais 202 repositório está conectado com o gerente local serviço de informações 201, para armazenar metadados de serviço e sua atualização de um prestador de serviços em um domínio de rede local.
5
O gerente de informação remota de serviço 203 está conectada com o gerente local serviço de informações 201, de modo a, por exemplo, informações do serviço de propagar local para o registro de serviço remoto conectado 200 'de acordo com uma política de conexão quando um evento do
10
gestor local serviço de informações 201 é disparado. O gerente de informação remota de serviço 203 é mais ligado com o registro de serviço remoto 200 "para receber um índice de serviço remoto enviado pelo registro de serviço remoto 200" e propagá-lo para outro registro de serviço
15
remoto em uma mão, e o índice de propagação de serviço extraídas referentes aos serviços locais, por exemplo, o registro de serviço remoto 200 ", por outro lado. Além disso, o gerente de serviço remoto 203 está ainda ligado a um serviço de informações 204 repositório remoto para
20
armazenar o índice de serviço recebido remoto nele. As informações sobre o serviço repositório remoto 204 é usado para armazenar o índice de serviço propagada a partir do registo de serviço remoto 200 '. Nos processos de consulta de serviços e invocação, o gerenciador de informações locais serviço 201 e o gerente de serviço de informação remota 203 estão conectados com Intermediador em um domínio de rede local 106, de modo a
5
receber a partir do Intermediador uma solicitação de serviço feita por um solicitante de serviço.
Em resposta ao recebimento do pedido do Intermediador, o gerenciador de informações locais serviço 201 e o gerente de informação remota do serviço 203, respectivamente,
10
extrair, a partir de informações do serviço de repositório local 202 e informações do serviço de repositório remoto 204, metadados de serviço e um índice de serviços que satisfaçam as solicitação de serviço, e devolvê-los ao Intermediador. Deve-se salientar que, desde o processo de
15
invocação de um serviço local pertence à técnica anterior, enquanto a presente invenção tem por objectivo melhorar a invocação de um serviço remoto, a presente invenção geralmente assume que apenas o serviço remoto pode satisfazer o pedido de serviço.
20
A figura 3B mostra uma vista estrutural de um registro de serviço 200, incluindo detalhes adicionais, onde além das peças mostradas na figura 3, o registro de serviço 200 inclui ainda uma política de conexão básica repositório 205, uma parcela reglet 210 e um manipulador de consulta 209.
A política de conexão básica 205 repositório está conectado com o gerente remoto serviço de informações 203,
5
para armazenar a descrição de uma política de base para a construção de ligação entre os domínios do serviço (registros de serviço), com base no qual o registro de serviço ou intermediário pode determinar com o qual podiam trocar da informação. que a política de conexão pode
10
estipular o seguinte: se o registro de serviços estão fisicamente interligados, como aos registros de serviços conectados fisicamente, se é possível therebetween compartilhar informações de forma lógica, e se é logicamente necessário para proteger as informações off
15
especial em termos de serviço especial registros. Deve ser entendido que a estipulação da conexão política entre os registros de serviço pode melhorar ainda mais a inteligência e operacionalidade do sistema de SOA. No entanto, na verdade, os registros de serviço também pode
20
observar uma relação de ligação fixa, de modo que não é necessário armazenar uma política de conexão. A porção reglet rodeado por uma caixa de linha pontilhada é uma porção de expansão funções dos registros de serviços e compreende cerca de reglets uniformemente representada pelo sinal de referência 207 e um recipiente reglet 206. O reglets 207 pode incluir qualquer reglet estática ou dinâmica, que facilita o desempenho da funcionalidade de seleção de serviço e roteamento. Por exemplo, eles podem
5
ser os reglets contidos dentro dos registros do serviço e também pode ser o reglets realizado pela interação com um sistema externo de 208 (conforme descrito abaixo). O reglets 207 pode receber uma solicitação de serviço de roteamento de um domínio de serviço local e retornar uma
10
resposta encaminhamento para o domínio de serviço locais com base em uma política certa ligação (por exemplo, as políticas armazenadas na política de conexão básica repositório 205). 0 reglets 207 poderia implementar a lógica de seleção de serviço e roteamento.
15
reglets 207 são implantados no recipiente reglet 206 e formas aí uma lista ou uma malha. O recipiente reglet 206 proporciona ambiente de execução e informações de contexto para o 207 réguas. Por exemplo, durante a execução, o recipiente reglet 206 recebe a partir de um intermediário
20
de um pedido contendo as fontes e destino das mensagens. Depois disso, ele consulta a política de conexão de base e invoca todos os 207 relacionados reglets para seleção de serviço e roteamento. Por fim, o recipiente reglet 206 retorna uma resposta contendo o endereço do próximo salto. O sistema externo 208 está ligado com a parte reglet 210, e pode fornecer informações para a seleção e encaminhamento de serviço e também pode utilizar a informação a partir da porção reglet 210 (por exemplo, o reglets 207). O reglets
5
207 fornecer uma entrada para o sistema externo de 208 envolvidos. Os exemplos do sistema externo 208 compreendem, mas não estão limitados a: um sistema de segurança para as políticas de segurança global, um sistema de faturamento para serviços de uso comercial, um sistema de tráfego de
10
rede para QoS; um sistema de BI que as necessidades de informação estatística para mineração de dados e tomada de decisão; um sistema de regras de negócios para os contratos de negócios com base na seleção de serviço, e assim por diante.
15
0 manipulador de consulta 209 está conectada com o serviço de informação local 201 e gerencia o gerente de serviço remoto índice 203, para lidar com uma solicitação de consulta de um registro de serviço local. O manipulador de consulta 209 funciona em dois modos: no primeiro modo,
20
quando um pedido de um domínio de serviço local é recebida, o manipulador de 209 pedidos de consulta tanto o gerente de informação do serviço local 201 e o gerente de serviços remotos índice 203 para localizar o serviço e envia a resposta para o solicitante do serviço, no segundo modo, quando uma solicitação de outros registos é recebida, o manipulador de consulta 209 pedidos de informação do gestor local do serviço 201 e retorna as informações de serviços locais para o solicitante do serviço.
5
Os processos de transmissão de serviços de registro e consulta de acordo com a presente invenção são explicadas a seguir com referência à figura 4, figura 4A e Figo. 4B. Processo de registro e Propagação de Serviço Local do Registro de serviço.
10
Na figura 4, suponha que um prestador de serviços 9 em um domínio de serviço N tem um novo serviço a ser registrado em um Registro de serviços locais e 5 ° a ser compartilhada com os registros de outros serviços. Assim, em linha 1.1 (ou 1.1), o serviço do prestador de serviços 9
15
é registrado no registro de serviço de 5 °. Esse registro pode ser implementada de diferentes maneiras, por exemplo, o prestador de serviços ou a terceiros a realização de matrícula no registro de serviço de 5 (como mostra a linha 1.1), ou o registro de serviço de 5 alcançar a descoberta
20
automática do serviço (como mostra a linha de 1.1) . Posteriormente, na linha 1.2, o registro de serviço 5, por exemplo, com base na política de conexão básica, propaga o índice de serviço local para um registro de serviços remotos conectados com o registro do serviço 5. figura 4A é um caminho de propagação exemplar e mostra detalhes da linha 1.2. Na figura 4A, um quadrado representa um plano de serviço meta que contém registros de serviço representado por sinais de referência 06/01, no qual uma
5
linha sólida, por exemplo, entre os registros de serviço 1 e 2 representa que o índice de serviço poderia ser logicamente propagadas a partir do registro de serviço de 1 a o registro de serviço 2, enquanto uma linha pontilhada, por exemplo, entre os registros de serviço 2 e 3 representa
10
que o índice de serviço não poderia ser logicamente propagada a partir do registo de serviço 2 para o registro de serviço de 3. Na figura 4A, o serviço do prestador de serviços 9 é registrado no registro de serviço 5 e podem ser propagadas para os registros de serviço remoto 1-4.
15
Tendo o processo de propagação por registros de serviço 5D3D1 como exemplo, o registro de serviço de 3 recebe um índice, indicando que o endereço hop último registro de serviço de 5, enquanto o Registro de serviço 1 recebe um índice, indicando que o endereço do último hop é registro
20
de serviço 3.
O processo de solicitação de Metadados de serviço pelo solicitador de Serviço
Continuando a referir-se à figura 4, suponha que um solicitante de serviço 8 em um domínio de serviço de uma consulta, com parâmetros específicos (por exemplo, o menor tempo de serviço, a menor tarifa de serviço e assim por diante), a um registro de serviço local das mesmas, para todos os serviços disponíveis. Assim, na linha 2.1, o solicitante do serviço 8 envia uma solicitação de consulta ao registro de serviços 1. Em seguida, na linha 2.2, o registro de serviço 1, com base na sua tabela de índice (e possivelmente regras predefinidas conexão básica), encaminha o pedido para um registro de serviço do próximo salto, e este passo será repetido nos registros dos serviços relacionados.
A figura 4B mostra um exemplo de consulta de caminho detalhado na linha 2.2. Na figura 4B, um plano de serviço meta que é a mesma que a da figura 4A é usado. Após receber uma solicitação de consulta, o registro de serviço 1, ao considerar que o endereço do último salto no índice de serviço que satisfaça o pedido de registro de serviço é 3 (ou seja, o índice de serviço é propagada pelo registro do serviço 3), decide, então, encaminhar o pedido para o registro de serviço no próximo salto. Posteriormente, o registro de serviço 3, usando da mesma forma como o registro de serviço 1, determina para encaminhar a solicitação para o registro de serviço de 5 no próximo salto. Suponha que o registro de serviço de 5 é apenas o serviço de registo para o qual o índice de serviço que satisfaça a solicitação é registrada e, em seguida, a operação vai entrar em linha de 2,3 figura 4. On Line 2,3 na figura 4 o registro de serviço de 5 envia
5
os metadados do serviço solicitado para o registro de serviço 1 ao longo do caminho em que o pedido é encaminhado. Finalmente, na linha 2.4, após receber uma resposta, o registro de serviço envia a resposta para o solicitante do serviço da mesma.
10
0 processo de transmissão da mensagem de encaminhamento e seleção durante a invocação de serviço de acordo com a presente invenção é descrito a seguir, com referência à figura 5 e figura 5A. Na figura 5A, para maior clareza, as conexões entre os registros de serviço, as
15
ligações entre os terminais eo Intermediador relacionados com o processo mostrado na figura 5, e suas conexões com os registros de serviços são representadas por linhas sólidas, e outras são representadas por linhas pontilhadas. Além disso, os números de referência do lado esquerdo das linhas
20
de seta bidirecional representam linhas de uplink do Intermediador para os registros de serviço, e os números de referência do lado direito representam linhas de downlink dos registros de serviços para o Intermediador. Na figura 5 e figura 5A, suponha que um solicitante de serviço em um domínio de serviço Dl espera para obter um serviço de um provedor de serviços de G em um D3 domínio de serviço. Assim, na linha 3.1, o solicitante do serviço A,
5
no domínio do serviço Dl envia uma mensagem a um intermediário B e um endereço de destino da mensagem é o prestador do serviço G no D3 domínio de serviço. Em seguida, na linha 3.2, o intermediário B envia uma solicitação de encaminhamento para o registro de serviço 1
10
Posteriormente, em linha 3.3, o registro de serviço 1, consultando o índice de serviço, determina o endereço de próximo salto intermediário (por exemplo, um intermediário C) que o pedido é destinado a isso. O registro de um serviço, em seguida, notifica o intermediário B do endereço
15
do próximo salto. Como resultado, em linha 3.4, o intermediário B envia a mensagem para o intermediário C.
De acordo com a presente invenção, a linha 3.4 pode conter uma série de operações entre os intermediários e os registros de serviço, até que a mensagem chega a um F
20
intermediário em um domínio de destino D3 serviço. As operações específicas na Linha 3,4 são explicadas a seguir com referência à figura 5A.
Nas linhas 3,4-0, o intermediário B, com base no endereço retornado pelo registro de serviço 1, ainda envia o pedido ao intermediário C. Em seguida, o intermediário C continua a consultar o registro de serviço local através da linha de um uplink 3,4-1 para determinar o endereço do próximo salto (por exemplo, um intermediário D em um
5
domínio de serviço diferente D4) do pedido, bem como o endereço do próximo salto do pedido é devolvido á C intermediário através da linha de downlink 3,4-2. Depois disso, o C intermediário ainda envia o pedido ao intermediário D via Linha 3,4-3. Neste momento, o
10
intermediário D consultas ao registro de serviço local 5 ° através da linha de uplink 3,4-4. Tendo determinado o endereço do próximo salto do pedido (por exemplo, o E intermediário) , o registro de serviço de 5 retorna ao intermediário D através do downlink Line 3,4-5.
15
Posteriormente, o intermediário D envia o pedido ao intermediário E (Linha 3,4-6), e do intermediário E envia o pedido para o registro de serviço local η ° 4 (Linha 3,4- 7) . Tendo determinado o endereço do próximo salto (por exemplo, o F intermediário) , o registro do serviço 4
20
retorna para o E intermediário através do downlink Line 3,4-8. E então, o E intermediário envia o pedido para a F intermediário no domínio de destino D3 serviço via linha 3,4-9. Em seguida, as operações na Linha 3,4 estão concluídas. 0 processo subseqüente vai continuar a ser descrita abaixo, com referência à figura 5.
Como a linha 3.5 mostra, o intermediário F enviando a solicitação de encaminhamento ao registro de serviço 6, de
5
modo que o registro de serviço 6 seleciona um serviço de destino em um serviço de domínio N. Em seguida, na linha 3.6, o F intermediário recebe o endereço e os metadados do serviço de destino e transforma a mensagem de serviço para um formato adequado. Além disso, na linha 3.7, o F
10
intermediário envia a mensagem para o provedor de serviços. Por último, como linha 3.8 mostra, o prestador G fornece o serviço para o solicitante do serviço A. A meta prestador G oferece um serviço para o solicitante do serviço, de várias maneiras. Por exemplo, o serviço de
15
provedor de G poderia fornecer o serviço para o solicitante do serviço Um estritamente no sentido inverso do sentido de transmissão do pedido (ou seja, através de todos os intermediários e os registros de serviços envolvidos), e também poderia prestar o serviço para o solicitante do
20
serviço A no sentido inverso do sentido de transmissão pedido, mas apenas através do Intermediador no plano de serviço (ou seja, ignorando os registros de serviço). Como é sabido por aqueles hábeis na arte, o serviço de provedor de G podem transmitir um serviço para o solicitante do serviço A utilização de outros meios, mas eles não são listados um a um, na presente invenção.
A figura 6 é um fluxograma que mostra um método de registro do serviço e à propagação de um registro de
5
serviço de acordo com a presente invenção.
Este método começa com a etapa de 600 e depois vai para a etapa 610. Na etapa 610 metadados de serviço de um prestador de serviço é registrado em um registro de serviço local da mesma. Depois disso, na etapa 620, o registro de
10
serviço de notificação de um registro de serviço remoto de um indice de serviço. Este método termina na etapa 630.
A figura 7 mostra um método para consultar os metadados do serviço por um solicitante de serviço para um registro de serviço local, de acordo com a presente
15
invenção. Deve-se salientar que a presente invenção envolve principalmente a melhoria na consulta de serviço remoto, como resultado, o caso de consultar os metadados do serviço local é negligenciada.
Este método começa com a etapa de 7 00 e depois vai
20
para a etapa 710. Na etapa 710, um solicitante de serviço envia uma solicitação para consultar os metadados do serviço de um registro de serviço local, por exemplo, solicitar um serviço que satisfaça um requisito específico (por exemplo, a localização do serviço que está sendo "Pequim"). Na etapa 720, o registro de serviço encontra um índice de serviço que satisfaça as exigência consultando uma tabela de índice de serviços mantidos por um gerente de serviço de informação remota, e encaminha o pedido, de
5
acordo com o índice, para o próximo registro de serviço hop remoto. Em seguida, as operações na etapa 720 são repetidos, até que a solicitação é encaminhada para um registro de serviço remoto para o qual um serviço no índice de serviços pertence. Posteriormente, no passo 730, a meta
10
de registro de serviço remoto envia de volta os metadados do serviço solicitado, como resposta a esse registro de serviço local ao longo de um caminho no qual a solicitação foi transmitida. Além disso, na etapa 740, o registro de serviço local envia que a resposta à referida solicitante
15
do serviço. Finalmente, esse método acaba na etapa 750.
A figura 8 apresenta um método para o serviço de encaminhamento e seleção de acordo com a presente invenção. Da mesma forma, uma vez que a presente invenção envolve principalmente a melhoria na invocação de serviços remotos,
20
o caso de chamar os serviços locais é negligenciada.
Este método começa com a etapa de 800 e depois vai para a etapa 810. Na etapa 810, um solicitante de serviço envia uma mensagem relativa a um serviço em um domínio de serviço de destino para um intermediário, intermediário e ainda envia para um registro de serviço local. Depois disso, na etapa 820, o registro de serviço local oferece uma solicitação para o domínio do serviço de destino, consultando um índice de serviço remoto do mesmo. Na etapa
5
830, o intermediário no domínio do serviço de destino envia que a mensagem de um registro de serviço que lhe estão associados. Posteriormente, no passo 840, um registro de serviço associada ao domínio de serviço de destino escolhe um serviço adequado e envia-lo através do intermediário no
10
domínio de destino para um provedor de serviço de destino, para que o serviço é prestado para o solicitante do serviço na etapa 850. Finalmente, esse método acaba na etapa 8 60.
Na etapa 820 mostrada na figura 8, pode ser necessário para o pedido a ser enviado para o domínio de serviço de
15
destino através de uma pluralidade de lúpulo, como mostrado na figura 5 e figura 5A.
Além disso, de acordo com a modalidade preferida da presente invenção, é possível realizar a expansão da função do processo de invocação de serviço mostrado na figura 8
20
usando uma porção reglet. Por exemplo, é possível carregar a invocação de serviço usando um reglet que cobra uma solicitação de serviço através da interação com sistemas externos. Neste caso, a etapa 820 pode ainda compreender as operações indicadas na figura 8A. Na etapa 821, a parte reglet do registro de serviço local recebe um pedido de um solicitante de serviço. Na etapa 822, buscas de um recipiente para reglet uma política de conexão de uma política de conexão básica repositório de
5
um lado, e invoca o reglet correspondente cobrança, por outro lado. Na etapa 823, o reglet carregamento executa o processo de carregamento de um pedido de chamada de serviço, por exemplo, ligar ao sistema de correspondentes externos usados para carregar. Depois disso, na etapa 824,
10
o pedido de invocação que tenha sido carregada e tem a política de conexão específica é enviado aos gestores de informação local e remota de serviços, de modo que no passo 825, dos gestores de informação local e remota de serviços poderiam continuar consultando um índice de serviços
15
baseados no passo 824, para que o próximo endereço intermediário hop é obtida e é devolvido ao intermediário através do recipiente reglet na etapa 826. Depois, as operações subseqüentes mostrado na figura 8 continuarão a ser executadas.
20
De acordo com a descrição acima, a presente invenção melhora as limitações do SOA arte prévia ou serviço web resultantes da utilização do padrão UDDI, apenas por meio de um índice de serviço (em vez dos metadados de serviço) entre os registros do serviço. Além disso, aqueles versados na técnica perceberão que as concretizações da presente invenção pode ser fornecidas sob a forma de método, sistema ou um produto programa de computador. Assim, a presente invenção pode adotar a forma
5
de hardware completo concretizações, as concretizações de software completo ou concretizações da combinação de hardware e software. A combinação típica de hardware e software pode ser um sistema de computador universal com um programa de computador, quando o programa é carregado ou
10
executado, o método acima pode ser realizada através do controle do sistema de computador. A presente invenção pode ser incorporada em um produto de programa de computador, que compreende todas as funcionalidades que permitem que o método descrito para ser implementado. produto programa de
15
computador está contida em um ou mais suportes informáticos legível (incluindo mas não limitado a um dispositivo de armazenamento em disco, um CD-ROM, uma memória óptica e afins), e que a mídia legível em computador de armazenamento têm códigos de computador legível nele
20
contidas.
A presente invenção é explicada acima, com referência aos diagramas de fluxo e / ou diagramas de blocos do método sistema, e produto de programa de computador, de acordo com a presente invenção. Cada bloco nos fluxogramas e / ou diagramas de blocos e a combinação dos blocos pode ser, obviamente, realizada por comandos de programa de computador. Estes comandos de programa de computador podem ser fornecidos a um processador de um computador universal, um computador dedicado, um processador embutido ou outros dispositivos de processamento de dados programáveis para produzir uma máquina, de modo que os comandos (através do processador de um computador ou outros dispositivos programáveis de processamento de dados) produz um aparelho para realizar as funções especificadas em um ou mais blocos nos fluxogramas e / ou diagramas de blocos.
Estes comandos de programa de computador também podem ser armazenados para ler as memórias de um ou mais computadores, e cada uma das memórias ROM podem direcionar o computador ou outros dispositivos de processamento de dados programáveis para funcionar de acordo com o modo especificado. Assim, os comandos armazenados no computador fazem as leituras das memórias, produzem um produto de fabricoação que compreende meios de comando para realizar as funções especificadas em um ou mais blocos nos fluxogramas e / ou diagramas de blocos.
Os comandos de programa de computador também podem ser carregados para um ou mais computadores ou outros dispositivos de processamento de dados programáveis, de modo a realizar uma série de etapas em funcionamento, computadores ou outros dispositivos de processamento de dados programáveis, de modo que um computador de processo de execução pode ser produzido em cada um destes
5
dispositivos. Assim, os comandos executados nesses dispositivos fornecem as etapas especificadas em um ou mais blocos nos fluxogramas e / ou diagramas de blocos.
Referindo-se aos modos preferidos para a realização da presente invenção, os princípios da presente invenção são
10
explicados acima. No entanto, essas explicações são apenas exemplificativas, mas não deve ser entendida como qualquer limitação com a presente invenção. Aqueles versados na técnica podem modificar e transformar a presente invenção, sem se afastar do escopo definido pelas reivindicações
15
anexas.

Claims (23)

1. Registro de serviço, relacionado com um domínio de serviço local e de um registro de serviço remoto, incluindo: um gerenciador de informações de serviço local para registrar os serviços locais no domínio de serviços locais, um repositório de informações de serviço local conectado com o gerenciador de informações de serviço local, para armazenamento de meta-dados dos serviços locais; caracterizado pelo fato do referido registro de serviço ainda incluir: um gerenciador de informações de serviço remoto conectado com o gerenciador de informações de serviços locais e o registro de serviço remoto, para receber um índice de serviço remoto a partir do registro de serviço remoto; e um repositório de informações de serviço remoto ligado ao referido gerenciador de informações de serviço remoto, para armazenar o índice de serviço remoto recebido do registro de serviço remoto.
2. Registro, de serviço de acordo com a reivindicação 1, caracterizado pelo fato de que referido gerenciador de informações de serviço local inclui ainda meio para monitoramento dinâmico do estado em tempo real dos serviços locais e para atualizar o repositório de informações de serviço local em resposta a uma mudança nos serviços locais.
3. Registro de serviço, de acordo com a reivindicação1 ou 2, caracterizado pelo fato de que o referido gerenciador de informações de serviço local inclui ainda meio para transmissão de um índice de serviço em meta-dados de serviço dos serviços locais e uma atualização dos mesmos para o referido gerenciador de informações de serviço remoto, e o referido gerenciador de informações de serviço remoto inclui ainda meio para a propagação do índice de serviço nos meta-dados de serviço dos serviços locais e a atualização dos mesmos para o registro de serviço remoto.
4. Registro de serviço, de acordo com a reivindicação1, caracterizado pelo fato de que o referido gerenciador de informações de serviço remoto ainda inclui um intermediário no domínio de serviço local e compreende meio para receber do intermediário um pedido efetuado por um solicitante de serviço para invocar serviços específicos em um domínio de serviço remoto, adquirir um endereço do próximo intermediário de hop para o qual a solicitação deve ser encaminhada de acordo com o índice de serviço dos serviços específicos, e retornar a solicitação para o referido intermediário.
5. Registro de serviço, de acordo com a reivindicação 4, caracterizado pelo fato de que inclui ainda: uma porção reglet conectada com o gerenciador de informações de serviço local e / ou gerenciador de informações de serviço remoto, para, antes da solicitação do intermediário ser enviada para o gerenciador de informações de serviço local e / ou o gerenciador de informações de serviço remoto, executar uma função reglet correspondente à mesma.
6. Registro de serviço, de acordo com a reivindicação5, caracterizado pelo fato de que a referida porção de reglet compreende: um ou mais reglets e um recipiente de reglet, onde o recipiente de reglet é usado para fornecer ambiente de tempo de execução e informações de conteúdo para os reglets, para receber o pedido do intermediário e levantar um política base e invocar todas os reglets relacionados, e ainda para retornar informações de índice de serviço ao intermediário, onde a um ou mais reglets estão associados com os referidos recipientes de reglet, para desempenhar as funções de reglet correspondentes da solicitação de serviço recebida do intermediário e, em seguida, fornecendo a solicitação de serviço para o gerenciador de informações de serviço local e / ou o gerenciador de informações de serviço remoto.
7. Registro de serviço, de acordo com a reivindicação 6, caracterizado pelo fato de que a referida porção de reglet está ainda conectada com um sistema externo e é usada como entrada para o referido sistema externo para o registro de serviço, o referido sistema externo compreendendo pelo menos um dos seguintes: um sistema de segurança para políticas de segurança global; um sistema de faturamento para serviços para uso comercial; um sistema de tráfego de rede para QoS; um sistema BI que precisa de informações estatísticas para mineração de dados e tomada de decisão; um sistema de regras para negócios para contratos de negócios com base em seleção de serviço.
8. Registro de serviço, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui ainda: um repositório de política de conexão básica conectado com o gerenciador de informações de serviços remoto para armazenamento de descrição de políticas básicas das conexões estabelecidas entre os registros de serviços.
9. Registro de serviço, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui um manipulador de levantamento conectado com o gerenciador de informações de serviço local e / ou um gerenciador de índice de serviço remoto, para o tratamento de um pedido para levantamento de informação de serviço para o registro de serviço.
10. Registro de serviço, de acordo com a reivindicação 1, caracterizado pelo fato de que o referido manipulador de levantamento tem os seguintes dois modos de operação: no primeiro modo, quando a solicitação de serviço para consultar informações de serviço a partir de um domínio de serviço local é recebida, solicitar tanto ao gerenciador de informações de serviço local e / ou gerenciador de índice de serviço remoto para localizar o serviço e enviar a resposta para o solicitante do serviço, e no segundo modo, quando uma solicitação a partir do registro de serviço remoto é recebida, solicitar o gerenciador de informações de serviço local e devolver a informação de serviço local ao referido registro de serviço remoto.
11. Registro de serviço, de acordo com a reivindicação 10, caracterizado pelo fato de que o referido gerenciador de informações de serviço local inclui ainda meio para extrair um índice de serviço dos meta-dados de serviço dos serviços locais.
12. Arquitetura SOA caracterizada pelo fato de que compreende: uma rede de serviço meta, incluindo um ou mais registros conforme definido na reivindicação 1; uma rede de serviço em paralela com a rede de serviço meta, incluindo: um ou mais pontos extremos; e um ou mais intermediadores intermediando os referidos pontos extremos; em que os referidos um ou mais pontos extremos são capazes de interagir com os registros de serviços correspondentes registros diretamente ou através de um ou mais referidos intermediadores.
13. Método para o compartilhamento de informação entre os registros de serviço, os referidos registros de serviço sendo fisicamente e / ou logicamente interligados, o referido método caracterizado pelo fato de que compreende: registrar meta-dados de serviço de um provedor de serviço para um registro de serviço local; e o referido registro de serviço propagar um índice de serviço nos referidos meta-dados de serviço para um registro de serviço remoto.
14. Método, de acordo com a reivindicação 13, caracterizado pelo fato de que ainda inclui o referido registro de serviço propagar o índice de serviço nos referidos meta-dados de serviço para o registro de serviço remoto, de acordo com uma política de ligação pré-definida.
15. Método, de acordo com a reivindicação 13 ou 14, caracterizado pelo fato de que a referida etapa de registro é executada por pelo menos uma das seguintes formas: o provedor de serviços ou um terceiro registra os serviços para o registro de serviço local, e o registro de serviço local descobre e registra os referidos serviços por meio de uma descoberta automática.
16. Método para um solicitante de serviço para consulta a informações de serviço para registros de serviço, os referidos registros sendo fisicamente e / ou logicamente interligados, o referido método caracterizado pelo fato de que compreende: o referido solicitante do serviço enviar um pedido de levantamento de informações de serviço para um registro de serviço local; o referido registro de serviço local, de acordo com um índice de serviços dos serviços remotos, encaminhar o referido pedido para o registro de serviço remoto relacionado, até que chegue em um ou mais registros de serviço remotos alvos; o referido um ou mais registros de serviço alvos remotos enviando, de volta para o registro de serviço local, os meta-dados de serviço solicitados, como uma resposta; e o referido de serviço local enviando a referida resposta ao referido solicitante de serviço.
17. Método, de acordo com a reivindicação 15, caracterizado pelo fato de que a etapa do referido solicitante de serviço enviar a solicitação de serviço para levantamento de informações de serviço para o registro de serviço local inclui o referido solicitante de serviço enviar uma solicitação para levantar todos os serviços com parâmetros específicos para o registro de serviço local.
18. Método, de acordo com a reivindicação 15, caracterizado pelo fato de que os referidos um ou mais registros de serviço remotos alvos enviam, de volta para o referido registro de serviço, os meta-dados de serviço solicitados como uma resposta ao longo de um caminho no qual o pedido foi transmitido.
19. Método para um solicitante de serviço invocar serviço em um domínio de serviço remoto caracterizado pelo fato de que compreende: O referido solicitante de serviço enviar uma solicitação para invocar os serviços no domínio de serviço remoto para um intermediário, o intermediário enviar o mesmo para um registro de serviço local; o referido registro de serviço local transmitindo o pedido para o domínio de serviço remoto por levantamento de um índice de serviço; um intermediário no domínio de serviço remoto enviando a referida mensagem para os registros associados com o referido domínio de serviço remoto; e os registros de serviço relacionados com o referido domínio de serviço remoto enviando os referidos serviços para o referido solicitante de serviço através do no referido domínio de serviço remoto, de modo a fornecer os referidos serviços ao referido solicitante de serviço.
20. Método, de acordo com a reivindicação 19, caracterizado pelo fato de que a etapa do referido registro de serviço local transmitir o pedido para o referido domínio de serviço remoto pelo levantamento do índice de serviço compreendendo ainda: o referido registro de serviço local adquire, por levantamento do índice de serviço, um endereço do próximo intermediário de hop para o qual a solicitação deve ser encaminhada, e retornar o referido endereço para o referido intermediário, de modo que o referido intermediário encaminha o pedido para o próximo intermediário de hop; e repetir a referida aquisição, retornar e encaminhar etapas, até que a referida mensagem chegue ao intermediário no domínio de serviço remoto.
21. Método, de acordo com a reivindicação 20, caracterizado pelo fato de que a etapa do referido registro de serviço local adquirir, pelo levantamento do índice de serviço, o próximo intermediário de endereço de hop para o qual a solicitação deve ser encaminhada ainda inclui: uma porção de reglet do registro de serviço local que recebe o pedido do solicitante de serviço; um recipiente de reglet na porção de reglet que busca uma política de ligação, em um repositório de política de conexão básica, e que invoca o reglet correspondente; o reglet que desempenha a função de reglet correspondente à referida solicitação de invocação de serviço; enviar o pedido de invocação para o qual a função de reglet correspondente foi executada, e a qual tem uma política de conexão específica, ao serviço de informação para os gerenciadores de informações de serviço local e remoto, e os gerenciadores de informações de serviço local e remoto levantando o índice de serviço para adquirir o intermediário de endereço de hop seguinte.
22. Método, de acordo com a reivindicação 21, caracterizado pelo fato de que os referidos reglets compreendem reglets realizados pelos registros de serviço e reglets realizados pela interação com um sistema externo, o referido sistema externo compreendendo pelo menos um dos seguintes: um sistema de segurança para políticas de segurança global; um sistema de faturamento para serviços para uso comercial; um sistema de tráfego de rede para QoS; um sistema BI que precisa de informações estatísticas para mineração de dados e tomada de decisão; um sistema de regras para negócios para contratos de negócios com base em seleção de serviço.
23. Produto de programa de computador caracterizado pelo fato de que contém uma pluralidade de instruções legíveis por um sistema de computador em uma ou mais mídias legíveis por computador, em que as referidas instruções são executadas no computador para realizar o método definido em qualquer uma das reivindicações de método acima.
BRPI0709905A 2006-03-31 2007-03-27 registro de serviço e sistema e método relevante BRPI0709905B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CNB2006100710383A CN100558038C (zh) 2006-03-31 2006-03-31 服务注册器以及相关系统和方法
CN200610071038.3 2006-03-31
PCT/EP2007/052894 WO2007113164A1 (en) 2006-03-31 2007-03-27 Service registry and relevant system and method

Publications (2)

Publication Number Publication Date
BRPI0709905A2 true BRPI0709905A2 (pt) 2013-12-31
BRPI0709905B1 BRPI0709905B1 (pt) 2020-01-28

Family

ID=38199776

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0709905A BRPI0709905B1 (pt) 2006-03-31 2007-03-27 registro de serviço e sistema e método relevante

Country Status (8)

Country Link
US (1) US8306979B2 (pt)
EP (1) EP2005709B1 (pt)
JP (1) JP4897872B2 (pt)
CN (1) CN100558038C (pt)
AT (1) ATE527801T1 (pt)
BR (1) BRPI0709905B1 (pt)
CA (1) CA2646529A1 (pt)
WO (1) WO2007113164A1 (pt)

Families Citing this family (71)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8819080B2 (en) * 2007-06-13 2014-08-26 The Boeing Company System and method for collection, retrieval, and distribution of data
CN101441560B (zh) * 2007-11-23 2012-09-26 国际商业机器公司 执行基于上下文模型的面向服务架构的策略的方法和装置
CN101441561B (zh) * 2007-11-23 2012-05-23 国际商业机器公司 基于上下文模型生成面向服务架构的策略的方法和装置
US9721216B2 (en) 2007-11-26 2017-08-01 International Business Machines Corporation Solution that automatically recommends design assets when making architectural design decisions for information services
CN101471939B (zh) * 2007-12-28 2012-07-04 中国科学院声学研究所 Soa架构的融合业务系统中的多次用户认证鉴权方法
US8341155B2 (en) 2008-02-20 2012-12-25 International Business Machines Corporation Asset advisory intelligence engine for managing reusable software assets
US8762938B2 (en) 2008-04-28 2014-06-24 Salesforce.Com, Inc. Object-oriented system for creating and managing websites and their content
US8631094B1 (en) * 2008-08-08 2014-01-14 Google Inc. Distributed parallel determination of single and multiple source shortest paths in large directed graphs
CN101686247B (zh) * 2008-09-26 2013-01-09 华为技术有限公司 信息处理方法和系统
US8570905B2 (en) * 2008-09-26 2013-10-29 International Business Machines Corporation Adaptive enterprise service bus (ESB) runtime system and method
US8448185B2 (en) * 2009-03-23 2013-05-21 Siemens Aktiengesellschaft Method and system for dynamic discovery of services in a communication framework
MY164485A (en) * 2009-07-20 2017-12-29 Mimos Berhad A method and system for an intelligent framework of a service orientated architecture
US8607190B2 (en) 2009-10-23 2013-12-10 International Business Machines Corporation Automation of software application engineering using machine learning and reasoning
US9704130B2 (en) 2009-10-26 2017-07-11 International Business Machines Corporation Standard based mapping of industry vertical model to legacy environments
US8726236B2 (en) 2009-10-26 2014-05-13 International Business Machines Corporation Determining context specific content
US8645904B2 (en) 2009-10-26 2014-02-04 International Business Machines Corporation Cross repository impact analysis using topic maps
US8285672B2 (en) * 2009-10-29 2012-10-09 Oracle International Corporation Declarative federation of registries
US9026412B2 (en) 2009-12-17 2015-05-05 International Business Machines Corporation Managing and maintaining scope in a service oriented architecture industry model repository
US8775462B2 (en) 2009-12-17 2014-07-08 International Business Machines Corporation Service oriented architecture industry model repository meta-model component with a standard based index
US9111004B2 (en) 2009-12-17 2015-08-18 International Business Machines Corporation Temporal scope translation of meta-models using semantic web technologies
US8244768B2 (en) 2009-12-17 2012-08-14 International Business Machines Corporation Implementing service oriented architecture industry model repository using semantic web technologies
US8566358B2 (en) 2009-12-17 2013-10-22 International Business Machines Corporation Framework to populate and maintain a service oriented architecture industry model repository
US8631071B2 (en) 2009-12-17 2014-01-14 International Business Machines Corporation Recognition of and support for multiple versions of an enterprise canonical message model
CN101763428A (zh) * 2010-01-04 2010-06-30 山东浪潮齐鲁软件产业股份有限公司 一种SOA对web服务的注册存储管理应用系统
US8880586B2 (en) * 2010-04-08 2014-11-04 Microsoft Corporation Metadata subscription registry
CN102255935B (zh) * 2010-05-20 2016-06-15 中兴通讯股份有限公司 云服务消费方法、云服务中介及云系统
WO2012000553A1 (en) * 2010-07-01 2012-01-05 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for service sharing
US9483312B2 (en) 2010-08-16 2016-11-01 International Business Machines Corporation Locating service endpoints from a service registry
US9262474B2 (en) 2010-09-30 2016-02-16 Microsoft Technology Licensing, Llc Dynamic domain query and query translation
US9223892B2 (en) 2010-09-30 2015-12-29 Salesforce.Com, Inc. Device abstraction for page generation
US8935360B2 (en) 2010-12-03 2015-01-13 Salesforce.Com, Inc. Techniques for metadata-driven dynamic content serving
CN102546684A (zh) * 2010-12-13 2012-07-04 财团法人资讯工业策进会 云端服务系统及方法
KR101389140B1 (ko) * 2011-09-11 2014-04-28 한미아이티 주식회사 서비스 유알아이와 거점정보를 통한 메시지 중계 장치 및 그 방법
US8910186B2 (en) 2011-11-15 2014-12-09 International Business Machines Corporation Feed-based promotion of service registry objects
US8595251B2 (en) * 2011-11-16 2013-11-26 Verizon Patent And Licensing Inc. Flexible interface module
EP2629250A1 (en) * 2012-02-14 2013-08-21 Tata Consultancy Services Limited A system and method for providing enterprise information technology lifecycle tools synchronization platform
EP2860636A4 (en) * 2012-06-07 2016-04-06 Toshiba Kk PROGRAM AND DEVICE FOR CONNECTING BUS
US9519506B2 (en) 2012-06-29 2016-12-13 Nokia Technologies Oy Method and apparatus for enabling remote service task based access to functionality provided by one or more remote services
CN102833343A (zh) * 2012-09-03 2012-12-19 浙江财经学院 一种跨虚拟企业Web服务共享系统
GB2509723A (en) * 2013-01-10 2014-07-16 Ibm Invoking web services that are determined at the time of execution
US9858093B2 (en) * 2013-03-08 2018-01-02 Oracle International Corporation Model for configuration independent process templates and business catalog
CN105379313B (zh) * 2013-05-06 2020-06-09 康维达无线有限责任公司 M2m系统中的语义支持和管理
US9596295B2 (en) 2013-06-29 2017-03-14 Google Inc. Computing connected components in large graphs
US9852230B2 (en) 2013-06-29 2017-12-26 Google Llc Asynchronous message passing for large graph clustering
GB2516833A (en) * 2013-07-31 2015-02-11 Ibm Running software application with dynamic action delegation
CN105683984A (zh) 2013-09-28 2016-06-15 迈克菲股份有限公司 数据交换层上高效的请求-响应路由
US8793359B1 (en) * 2013-11-25 2014-07-29 Software Ag Systems and/or methods for intelligently detecting API key domains
US9407546B2 (en) 2014-02-24 2016-08-02 Red Hat, Inc. Routing a message using a routing table in a dynamic service mesh
US9984158B2 (en) * 2014-03-18 2018-05-29 Axis Ab Finding services in a service-oriented architecture (SOA) network
US9705995B2 (en) * 2014-03-18 2017-07-11 Axis Ab Capability monitoring in a service oriented architecture
CN103841183A (zh) * 2014-03-25 2014-06-04 浪潮电子信息产业股份有限公司 一种面向数据中心的SMI-S Provider注册请求方法
CN105450705B (zh) * 2014-08-29 2018-11-27 阿里巴巴集团控股有限公司 业务数据处理方法及设备
US10673852B2 (en) * 2014-12-23 2020-06-02 Mcafee, Llc Self-organizing trusted networks
CN104935485A (zh) * 2015-05-28 2015-09-23 北京海尔广科数字技术有限公司 家电服务调用方法、家电服务调用请求转发方法及装置
CN104935484A (zh) * 2015-05-28 2015-09-23 北京海尔广科数字技术有限公司 一种通过网关调用家电服务的方法及装置
CN106302596B (zh) * 2015-06-03 2019-09-20 北京京东尚科信息技术有限公司 一种服务发现的方法和装置
WO2017176178A1 (en) 2016-04-05 2017-10-12 Telefonaktiebolaget Lm Ericsson (Publ) Method and agent for sharing information about cloudlet properties in distributed cloud environments
CN108632299A (zh) * 2017-03-15 2018-10-09 北京京东尚科信息技术有限公司 增强注册中心可用性的方法、装置、电子设备和存储介质
US11467868B1 (en) * 2017-05-03 2022-10-11 Amazon Technologies, Inc. Service relationship orchestration service
US10742750B2 (en) * 2017-07-20 2020-08-11 Cisco Technology, Inc. Managing a distributed network of function execution environments
EP3655857A1 (en) * 2017-07-20 2020-05-27 Cisco Technology, Inc. Managing a distributed network of function execution environments
CN107580045A (zh) * 2017-08-31 2018-01-12 新华三大数据技术有限公司 服务的编目方法及装置
WO2019041206A1 (en) 2017-08-31 2019-03-07 Entit Software Llc CONTAINER MANAGEMENT USING PAIRS ATTRIBUTE / VALUE
US10469600B2 (en) * 2017-11-14 2019-11-05 Dell Products, L.P. Local Proxy for service discovery
CN110247944B (zh) * 2018-03-09 2022-06-24 阿里巴巴集团控股有限公司 跨区域的服务调用方法、装置、系统及电子设备
CN111045833B (zh) * 2018-10-15 2024-06-18 北京京东尚科信息技术有限公司 接口调用的方法和装置
EP3712768B1 (en) 2019-03-18 2024-05-01 Sony Group Corporation Management of services in an edge computing system
CN110334906A (zh) * 2019-05-30 2019-10-15 广东民航机场建设有限公司 业务数据处理方法、装置、计算机设备和存储介质
US10715484B1 (en) * 2019-12-11 2020-07-14 CallFire, Inc. Domain management and synchronization system
CN112153021B (zh) * 2020-09-10 2023-05-19 中国联合网络通信集团有限公司 一种业务数据的获取方法及装置
CN113839865B (zh) * 2021-11-30 2022-03-01 北京鲸鲮信息系统技术有限公司 一种跨域调用服务的管理方法及系统

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4271827B2 (ja) * 2000-05-09 2009-06-03 富士通株式会社 情報提供システムおよび仲介装置
US6922685B2 (en) * 2000-05-22 2005-07-26 Mci, Inc. Method and system for managing partitioned data resources
US6895444B1 (en) * 2000-09-15 2005-05-17 Motorola, Inc. Service framework with local proxy for representing remote services
US20030191802A1 (en) * 2002-04-03 2003-10-09 Koninklijke Philips Electronics N.V. Reshaped UDDI for intranet use
US7194482B2 (en) * 2002-09-26 2007-03-20 International Business Machines Corporation Web services data aggregation system and method
JP2004227140A (ja) * 2003-01-21 2004-08-12 Toshiba Corp 検索連携プログラム及び検索システム並びに検索方法
JP4254264B2 (ja) * 2003-02-17 2009-04-15 日本電信電話株式会社 Webサービス利用時におけるネットワーク提供方法、システム及びサーバ
JP4334253B2 (ja) * 2003-03-14 2009-09-30 株式会社東芝 データ整合プログラム及びシステム並びに方法
US20050216600A1 (en) * 2004-03-23 2005-09-29 Jonathan Maron System and method for providing a service in a controlled run-time environment

Also Published As

Publication number Publication date
WO2007113164A1 (en) 2007-10-11
CN101047512A (zh) 2007-10-03
JP4897872B2 (ja) 2012-03-14
ATE527801T1 (de) 2011-10-15
US8306979B2 (en) 2012-11-06
EP2005709B1 (en) 2011-10-05
JP2009531760A (ja) 2009-09-03
EP2005709A1 (en) 2008-12-24
BRPI0709905B1 (pt) 2020-01-28
US20100017368A1 (en) 2010-01-21
CA2646529A1 (en) 2007-10-11
CN100558038C (zh) 2009-11-04

Similar Documents

Publication Publication Date Title
BRPI0709905A2 (pt) Registro de serviço e método e sistema relevante
JP5043937B2 (ja) 分散システム内の連合リソース発見のための方法およびコンピュータ・プログラム
JP5090450B2 (ja) 階層に編成され、ネットワークを介してリンクされた複数のノードに保管された複製データを更新するための方法、プログラム、およびコンピュータ可読媒体
Papazoglou et al. Leveraging web-services and peer-to-peer networks
Sivashanmugam et al. Discovery of web services in a federated registry environment
US10698969B2 (en) Representation/invocation of actions/functions in a hypermedia-driven environment
RU2404450C2 (ru) Способ и система для синхронизации множественных пользовательских ревизий совместно используемого объекта
JP4551899B2 (ja) 随時接続アプリケーションサーバー
US8095670B2 (en) Protocol for enabling dynamic and scalable federation of enterprise service buses
KR101109251B1 (ko) 웹 서비스 애플리케이션 프로토콜 및 soap 프로세싱모델
US20050086384A1 (en) System and method for replicating, integrating and synchronizing distributed information
US8380787B2 (en) Federation of master data management systems
US20060271384A1 (en) Reference data aggregate service population
Shafer An architecture for network management using netconf and yang
US20230096376A1 (en) Unified automation of application development
CN102316154B (zh) 优化对基于联盟基础结构的资源的访问
Hackmann et al. Extending BPEL for interoperable pervasive computing
Pahl et al. Information-centric iot middleware overlay: Vsl
Di Giovanni et al. Web services composition and geographic information
Oh et al. Manufacturing interoperability using a semantic mediation
Samaras et al. A Grid service framework for metadata management in self-e-learning networks
Kuehnhausen Service oriented architecture for monitoring Cargo in motion along trusted corridors
Stäber et al. Interoperability challenges and solutions in automotive collaborative product development
Ramsauer OPC UA/DDS gateway
Sarasa et al. Agrega: A distributed repository network of standardised learning objects

Legal Events

Date Code Title Description
B06G Technical and formal requirements: other requirements [chapter 6.7 patent gazette]

Free format text: APRESENTE TRADUCAO COMPLETA DO PEDIDO, CONFORME DETERMINA O ITEM 9, E SUBITENS, DO ATO NORMATIVO NO 128/1997, BEM COMO FAZE-LA ADAPTADA AO ATO NORMATIVO NO 127/1997.

B06G Technical and formal requirements: other requirements [chapter 6.7 patent gazette]

Free format text: EM ADITAMENTOO A EXIGENCIA PUBLICADA NA RPI NO 2066 DE 10/08/2010, APRESENTE OS DESENHOS DO PEDIDO CONFORME PUBLICACAO WO 2007/113164 DE 11/10/2007, E ADAPTADOS AO AN NO 127/1997.

B06G Technical and formal requirements: other requirements [chapter 6.7 patent gazette]

Free format text: EM ADITAMENTO AS EXIGENCIAS PUBLICADAS NAS RPIS 2066 DE 10/08/2010 E 2097 DE 15/03/2011, SOLICITA-SE QUE O DEPOSITANTE APRESENTE NO PRAZO DE 60 (SESSENTA) DIAS, A TRADUCAO DO RESUMO DO PEDIDO, CONFORME DETERMINA O ART. 7O DA RESOLUCAO 291/2012, SOB PENA DA FASE NACIONAL NAO SER ACEITA, SENDO O PEDIDO INTERNACIONAL CONSIDERADO RETIRADO EM RELACAO AO BRASIL.

B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06T Formal requirements before examination [chapter 6.20 patent gazette]
B15K Others concerning applications: alteration of classification

Free format text: A CLASSIFICACAO ANTERIOR ERA: H04L 29/08

Ipc: H04L 29/08 (1990.01), G06F 9/50 (2000.01)

B06A Patent application procedure suspended [chapter 6.1 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 28/01/2020, OBSERVADAS AS CONDICOES LEGAIS.