BRPI0709905B1

BRPI0709905B1 - registro de serviço e sistema e método relevante

Info

Publication number: BRPI0709905B1
Application number: BRPI0709905A
Authority: BR
Inventors: Yi Li; Sheng Mao Xin; Chen Zhou Yu
Original assignee: Int Business Machine Corporation
Priority date: 2006-03-31
Filing date: 2007-03-27
Publication date: 2020-01-28
Also published as: CA2646529A1; US20100017368A1; WO2007113164A1; JP2009531760A; ATE527801T1; BRPI0709905A2; CN101047512A; CN100558038C; US8306979B2; EP2005709A1; EP2005709B1; JP4897872B2

Abstract

"registro de serviço e método e sistema relevante". a presente invenção revela melhorias em um registro de serviço no soa e melhorias relevantes na propagação de serviço, consulta e seleção de serviços e métodos de encaminhamento durante invocação de serviço. o referido registro de serviço é conectado com um domínio de serviço local e um serviço de registro remoto e compreende: um gerenciador de informações do serviço local para registrar os serviços locais no domínio do serviço local, um repositório de informações de serviço local relacionado com o gerenciador de serviço de informações local, para armazenar metadados de serviço dos serviços locais; onde o referido registro de serviço compreende ainda: um gerenciador de informações de serviço remoto conectado com o gerenciador serviço de informação local e o registro de serviço remoto, para receber um índice de atendimento remoto a partir do registro de serviço remoto, e um repositório de informações de serviço remoto conectado com o referido gerenciador de serviços de informação remota, para armazenar o índice de serviço remoto recebido do serviço de registro remoto. usar o referido registro de serviço, é fácil para a realização de controle de serviço e compartilhar entre os registros de serviços diferentes.

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 de serviços), um prestador de serviços e um registro de serviço, como mostrado na figura 1. 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.

O 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,	BEA,	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:

D	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 O 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, UPnP, 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. O importador agui é 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 tornase 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 UDDI, é 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 urn 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-dominio 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

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 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 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.

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 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.

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.

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 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 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 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
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 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 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 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 registrados em um registro de serviço especificado. O domínio do serviço poderia ser um domínio com fronteira explicita (como domínio de Internet), ou que, sem fronteira explicita (como parte do domínio de Internet). Cada registro de serviço pode corresponder a um domínio de 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 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 plano de serviço 106 gue é 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 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 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 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 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. O gerente de informação do serviço local 201 é ainda mais conectado com as informações do serviço repositório local 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 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 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 índice de serviço a partir dos metadados do serviço local.

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 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 Service), por exemplo, operação, segurança e confiabilidade políticas, etc) e outros metadados.

O 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 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á 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 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 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 endereço hop passado 282. É 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	Faixa do atributo	Último
atributo/		endereço de
tipo		hop
		Registro de	Ponto final/
		serviço	intermediador
Nome da	IBM	SR1	11
empresa
Telefone	66660000-66660010	SR1	11
Localização	Beij ing	SR1	11
data de	Ano de 2005	SR1	11
emissão
Nome da	http://www.ibm.com/	SR1	11
interface	servícel/servicel-
de serviço	5.wsdl

Na Tabela 1, o campo gama atributo pode ser um valor ú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.

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.

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 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 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 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, ο 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 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, 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 invocação de um serviço local pertence à técnica anterior, enquanto a presente invenção tem por objective 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.

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, 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 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 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 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 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 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.

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 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 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 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.

O 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, 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.

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.

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 é 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 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 linha sólida, por exemplo, entre os registros de serviço 1 e 2 representa que o índice de serviço podería 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 que o índice de serviço não podería 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. 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 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 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.

O 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 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 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, 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 °. 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 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 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 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 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. 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 n ° 4 (Linha 3,47) . Tendo determinado o endereço do próximo salto (por exemplo, o F intermediário) , o registro do serviço 4 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. O processo subsequente 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 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 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 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 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 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 serviço de notificação de um registro de serviço remoto de um índice 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 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 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 especifico (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 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 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 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, 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 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 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 860.

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 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 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 urn 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 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, 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 poderíam continuar consultando um índice de serviços 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 subsequentes mostrado na figura 8 continuarão a ser executadas.

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 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 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 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 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 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 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

Claims

REIVINDICAÇÕES

1. Registro de serviço (200), conectado com um domínio de serviço local (106) e de um registro de serviço remoto (200) , compreendendo: um gerenciador de informações de serviço local (201) para registro dos serviços locais no domínio de serviços locais, um repositório de informações de serviço local (202) conectado com o gerenciador de informações de serviço local (201), para armazenamento de meta-dados dos serviços locais; caracterizado pelo fato de que o referido registro de serviço ainda compreende: um gerenciador de informações de serviço remoto (203) conectado com o referido gerenciador de informações de serviços locais (201) 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 (204) conectado ao referido gerenciador de informações de serviço remoto (203), 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 compreende ainda meios 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ção 1, caracterizado pelo fato de que o referido gerenciador de informações de serviço remoto é ainda conectado a um intermediário no domínio de serviço local e compreende meios 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

Petição 870190110042, de 29/10/2019, pág. 7/20

2/4 encaminhada de acordo com o índice de serviço dos serviços específicos, e retornar a solicitação para o referido intermediário.
4. Registro de serviço, de acordo com a reivindicação

3, caracterizado pelo fato de que compreende 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.
5. Registro de serviço, de acordo com a reivindicação

4, caracterizado pelo fato de que a referida porção de reglet compreende: um ou mais reglets e um recipiente de reglet, em que 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 uma política base e invocar todas os reglets relacionados, e ainda para retornar informações de índice de serviço ao intermediário;

em que o 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.
6. Registro de serviço, de acordo com a reivindicação

5, caracterizado pelo fato de que a referida porção de reglet está ainda conectada com um sistema externo e é usada como uma 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

Petição 870190110042, de 29/10/2019, pág. 8/20

3/4 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.
7. Registro de serviço, de acordo com a reivindicação

1, caracterizado pelo fato de que compreende 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.
8. Registro de serviço, de acordo com a reivindicação

1, caracterizado pelo fato de que compreende ainda 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.
9. Registro de serviço, de acordo com a reivindicação

8, 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, solicitando 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, solicitando 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.

Petição 870190110042, de 29/10/2019, pág. 9/20

4/4
10. 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 compreendendo as etapas de:

registrar serviços locais em um domínio de serviço local, por um gerenciador de informações de serviço local (201);

armazenar metadados de serviço dos serviços locais em um repositório de informações de serviço local (202), conectado com o gerenciador de informações de serviço local (201);

caracterizado pelas etapas adicionais de receber um índice de serviço remoto do registro de serviço remoto, a partir de um gerenciador de informações de serviço remoto (203) conectado ao gerenciador de informações de serviço local (201) e a um registro de serviço remoto; e armazenar o índice de serviço remoto recebido do registro de serviço remoto em um repositório de informações de serviço remoto (204) conectado ao referido gerenciador de informações de serviço remoto (203).
11. Método, de acordo com a reivindicação 10, 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.
12. Método, de acordo com a reivindicação 10 ou 11, 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.