Relatório Descritivo da Patente de Invenção para "SISTEMA E MÉTODO DE PROCESSAMENTO DE REQUISIÇÕES DE SERVIÇO PARA UMA ARQUITETURA DE TELECOMUNICAÇÕES". FUNDAMENTO DA INVENÇÃO 1. Reivindicação de Prioridade.
[0001] Este pedido reivindica o benefício de prioridade do Pedido EPO No 05425764.7, depositado em 28 de Outubro de 2005, e do Pedido da Itália No MI2005A002073, depositado em 28 de Outubro de 2005, ambos os quais são incorporados neste documento por referência em sua totalidade. 2. Campo Técnico.
[0002] Esta invenção relaciona-se com arquiteturas de sistema de processamento de telecomunicações. Em particular, esta invenção relaciona-se com uma camada em uma arquitetura de sistema de telecomunicações que processa requisições de serviço de telecomunicações de entidades externas. 3. Técnica Relacionada.
[0003] Os rápidos avanços nas tecnologias de processamento de dados e de telecomunicações resultaram em uma grande matriz de serviços de comunicação disponíveis ao consumidor. Tais serviços de telecomunicações incluem serviços tradicionais de telefone, serviços da Internet, serviços de televisão a cabo, serviços de telefone celular, serviços de paging, serviços de distribuição combinada de voz e dados e muitos outros serviços. Além disso, muitos serviços podem ser baseados em tecnologia sem fio ou com fio.
[0004] Os provedores de serviço de telecomunicações reconhecidos investiram enormes quantidades de tempo, dinheiro e tecnologia avançada para implantar e proporcionar de forma confiável um amplo espectro de produtos e serviços de telecomunicações. Antigamente, esse investimento só beneficiava o provedor de serviço de telecomuni cações, ou seja, os provedores de serviço de telecomunicações mantinham internamente suas próprias tecnologias em segredo e para seu próprio uso.
[0005] Tendo em vista este pano de fundo das sofisticadas arquiteturas de telecomunicações, os provedores de serviço de telecomunicações desejam explorar e desenvolver novas oportunidades de negócios que acarretem novas fontes de renda. A tecnologia existente nas arquiteturas de provedor de serviço poderia impulsionar tais novos meios de arrecadação. Entretanto, antigamente não havia um mecanismo que fosse suficientemente seguro, flexível e eficiente para permitir que entidades externas possam acessar a funcionalidade subjacente nas arquiteturas de provedor de serviço.
[0006] Além disso, mesmo se as entidades externas pudessem acessar a funcionalidade na arquitetura de provedor de serviço, não havia arquitetura de suporte para gerenciar as requisições de serviço de entidades externas. Não basta apenas garantir que uma entidade externa possa requisitar serviços de telecomunicações a partir de um provedor de serviços; sem uma arquitetura de processamento de suporte, as requisições das entidades externas não são respondidas.
[0007] Existe há muito tempo a necessidade de arquiteturas aperfeiçoadas de provedor de serviço de telecomunicações.
SUMÁRIO
[0008] O estabelecimento de arquiteturas aperfeiçoadas de provedor de serviço de telecomunicações representa desafios técnicos significativos. Como exemplo, há um desafio técnico na recepção e organização do número muito grande de requisições de serviço de probabilidade simultânea ou quase simultânea que pode ser recebido a partir de entidades externas. Como outro exemplo, há um desafio técnico ao determinar quais requisições de serviço processar de um modo organizado e eficiente. Também existem desafios técnicos ao executar as requisições de serviço extraídas para de fato completar com êxito o processamento requisitado, ao proporcionar um processamento de requisições de serviço tolerante a falhas e ao maximizar a performance do processamento de requisições de serviço.
[0009] Um aspecto da Invenção é uma camada de corretor de serviços que proporciona um sistema de processamento de requisições de serviço para uma arquitetura de telecomunicações. O sistema de processamento de requisições de serviço inclui uma interface de requisição de serviços, um sistema de expedição, um sistema de busca e um mecanismo de fluxo de trabalho. Componentes adicionais ou diferentes podem ser incluídos no sistema de processamento de requisições de serviço.
[00010] O corretor de serviços é parte de uma plataforma de distribuição de serviços e proporciona diversas vantagens técnicas. A primeira vantagem é a capacidade de configuração, obtida através de definições de ordem técnica da base de dados de gerenciamento, sendo elas fluxos de trabalho, tarefas e ações. O corretor de serviços permite a um provedor de serviços de telecomunicações criar novos serviços iniciando a partir de blocos de construção existentes, e permite ao provedor de serviços criar novos blocos de construção a partir de modelos predefinidos. Deste modo, o corretor de serviços proporciona ao provedor de serviços uma extensa flexibilidade ao definir serviços, sem limitar o provedor de serviços a uma infra-estrutura personalizada completa e inflexível.
[00011] A segunda vantagem é o controle. O corretor de serviços proporciona tratamento de erros, controle de entrada e saída do sistema e controle sobre fluxos de trabalho (especialmente fluxos de trabalho assíncronos) que são executados para distribuir os serviços. O corretor de serviços proporciona uma interface gráfica com o usuário para tratamento de erros. Por meio da interface, um operador experiente pode completar, submeter novamente, alterar, reformular ou de outra forma corrigir o processamento de um fluxo de trabalho que distribui um serviço.
[00012] A terceira vantagem é a manutenção. Em geral, o corretor de serviços evita a codificação fixa dos fluxos de trabalho, mensagens e elementos de dados. Em vez disso, o corretor de serviços utiliza fluxos de trabalhos, mensagens e elementos baseados em XML e metadados reconfiguráveis. Como resultado, as funcionalidades do corretor de serviços são bem mais fáceis de manter, revisar, estender e aprimorar, quando comparado com uma implementação de codificação fixa.
[00013] Além disso, o corretor de serviços proporciona a capacidade de executar fluxos de trabalho síncronos e assíncronos, o que resulta em performance aperfeiçoada. Em algumas implementações, podem ser processadas 500 ou mais transações por segundo.
[00014] A interface de requisições de serviço recebe requisições de serviço para serviços de telecomunicações a partir de entidades externas. Cada requisição de serviço inclui um campo identificador do serviço. O campo identificador do serviço informa o corretor de serviços quanto ao tipo de serviço requisitado na requisição de serviço.
[00015] O expedidor no corretor de serviços recebe cada requisição de serviço. Com base nos campos identificadores de serviço, o expedidor distribui as requisições de serviço para diferentes filas de serviço. Podem ser estabelecidas filas de serviço individuais para colocar em fila, de forma independente, as requisições para entidades requisitan-tes específicas e/ou tipos de serviço. Por exemplo, as filas de serviço podem incluir uma fila de requisição de serviço de distribuição de mensagem (por exemplo, SMS ou MMS), uma fila de requisição de serviço de cobrança, uma fila de requisição de ativação de serviço, ou outros tipos de filas de serviço.
[00016] O corretor de serviços também inclui um sistema de busca. O sistema de busca recupera para processamento as requisições de serviço colocadas em fila a partir das filas de serviço individuais. Em algumas implementações, o corretor de serviços pode incluir vários sistemas de busca que proporcionam vários mecanismos de busca independentes. Um conjunto de parâmetros de controle de tráfego governa a recuperação das requisições de serviço colocadas em fila a partir das filas de serviço individuais pelo sistema de busca.
[00017] Os mecanismos de fluxo de trabalho iniciam sequências de etapas de fluxo de trabalho que satisfazem as requisições de serviço recuperadas. O corretor de serviços pode executar vários mecanismos de fluxo de trabalho independentes. Os mecanismos de fluxo de trabalho podem processar fluxos de trabalho definidos para requisições de serviço selecionadas, por exemplo, por um sistema de busca específico.
[00018] Aspectos adicionais da invenção incluem métodos e sistemas para sequenciar eficientemente o processamento de requisições de serviço de telecomunicações. Em particular, o corretor de serviços estabelece várias filas de serviço e distribui vários registros de requisição de serviço de telecomunicações colocados em fila para as filas de serviço. O corretor de serviços também inicia a execução simultânea de vários mecanismos de busca para recuperar as requisições de serviço.
[00019] Em seguida, um primeiro mecanismo de busca recupera parte de um registro de requisição de serviço de telecomunicações (por exemplo, um Identificador de Ordem de Serviço Técnica (TSO_ID)) armazenado nas filas de serviço. O registro de requisição de serviço representa uma primeira requisição de serviço submetida por uma entidade externa. De forma similar, um segundo mecanismo de busca recupera parte de outra requisição de serviço de telecomuni cações armazenada nas filas de serviço. O registro de requisição de serviço representa uma segunda requisição de serviço submetida por uma entidade externa.
[00020] Em seguida, o corretor de serviços emprega diferentes técnicas de distribuição de requisição de fluxo de trabalho para iniciar a execução do fluxo de trabalho para implementar a primeira requisição de serviço e a segunda requisição de serviço. Por exemplo, o corretor de serviços pode implementar a primeira requisição de fluxo de trabalho por publicar uma mensagem de requisição de fluxo de trabalho através de um sistema de publicação de mensagem/assinatura para o qual um mecanismo de fluxo de trabalho se inscreveu. Como uma técnica suplente de distribuição de requisição de fluxo de trabalho, o corretor de serviços pode chamar diretamente um segundo mecanismo de fluxo de trabalho, especificando a segunda requisição de serviço.
[00021] Desse modo, a arquitetura do corretor de serviços supera os desafios técnicos associados com o processamento de requisições de serviço externas. A distribuição das requisições de serviço em filas atende ao desafio técnico de receber e organizar um grande número de requisições de serviço simultâneas ou quase simultâneas. A arquitetura do mecanismo de fluxo de trabalho e de múltipla busca atende ao desafio técnico de extrair as requisições de serviço de modo organizado e eficiente, de executar as requisições de serviço extraídas para realmente completar com êxito o processamento requisitado, de proporcionar o processamento de requisições de serviço tolerante a falhas e de maximizar a performance do processamento de requisições de serviço.
[00022] Outros sistemas, métodos, aspectos e vantagens da invenção serão, ou irão se tornar aparentes para os com conhecimento na técnica quando do exame das figuras seguintes e da descrição detalhada. É pretendido que todos tais sistemas, métodos, aspectos e van tagens adicionais sejam incluídos nesta descrição, sejam incluídos dentro do escopo da invenção e sejam protegidos pelas concretizações.
Breve Descrição dos Desenhos [00023] A invenção pode ser entendida com maior plenitude com referência aos desenhos e descrição seguintes. Os componentes nas figuras não são pretendidos de representarem a escala real, e em vez disso é dada ênfase à ilustração dos princípios da invenção. Além disso, nas figuras, números referenciados iguais designam partes ou elementos correspondentes por todas as diferentes vistas.
[00024] A figura 1 apresenta parte de uma arquitetura de telecomunicações que inclui um corretor de serviços conectado a um circuito de conexão de rede de acesso externo.
[00025] A figura 2 apresenta um corretor de serviços em uma arquitetura de telecomunicações.
[00026] A figura 3 apresenta uma implementação alternativa de um corretor de serviços em uma arquitetura de telecomunicações.
[00027] A figura 4 ilustra parâmetros de controle de tráfego para um sistema de busca em um corretor de serviços.
[00028] A figura 5 ilustra um sistema de expedição para um corretor de serviços em uma arquitetura de telecomunicações.
[00029] A figura 6 apresenta um primeiro sistema de busca para um corretor de serviços em uma arquitetura de telecomunicações.
[00030] A figura 7 ilustra uma base de dados de gerenciamento de ordem técnica para um sistema de busca em uma arquitetura de telecomunicações.
[00031] A figura 8 apresenta um segundo sistema de busca para um corretor de serviços em uma arquitetura de telecomunicações.
[00032] A figura 9 ilustra uma base de dados de gerenciamento de ordem técnica aperfeiçoada para um sistema de busca em uma arqui tetura de telecomunicações.
[00033] A figura 10 apresenta as ações que podem ser realizadas por um gerenciador de requisição de entrada para processar uma requisição de serviço de telecomunicações.
[00034] A figura 11 apresenta as ações que podem ser realizadas por um mecanismo de fluxo de trabalho para processar uma requisição de serviço de telecomunicações.
[00035] A figura 12 apresenta as ações que podem ser realizadas por um gerenciador de tarefas paralelo para processar uma requisição de serviço de telecomunicações.
[00036] A figura 13 ilustra um fluxo de mensagem através do corretor de serviços para processar uma requisição de Autenticação.
[00037] A figura 14 ilustra um fluxo de mensagem através do corretor de serviços para processar uma requisição de Cobrança.
[00038] A figura 15 ilustra um fluxo de mensagem através do corretor de serviços para processar uma requisição de distribuição SMS e cobrança.
[00039] A figura 16 ilustra um fluxo de mensagem através do corretor de serviços para processar uma requisição de distribuição MMS e cobrança.
[00040] A figura 17 ilustra um fluxo de mensagem através do corretor de serviços para processar uma requisição de chamada SIP.
[00041] A figura 18 ilustra um fluxo de mensagem através do corretor de serviços para processar uma requisição de Situação do usuário.
[00042] A figura 19 ilustra um fluxo de mensagem através do corretor de serviços para processar uma requisição de Autenticação do usuário móvel.
[00043] A figura 20 ilustra um fluxo de mensagem através do corretor de serviços para processar uma requisição de Autenticação de usuário IPTV.
Descrição Detalhada das Modalidades Preferidas [00044] A figura 1 apresenta uma arquitetura de telecomunicações 100 que interage com entidades externas 102. As entidades externas 102 podem variar muito em sua forma e implementação. Por exemplo, as entidades externas 102 podem incluir: dispositivos do assinante 104, tais como telefones celulares, assistentes de dados pessoais, dispositivos de comunicação em rede (por exemplo, Internet); os aplicativos 106, tais como os aplicativos de serviço de telecomunicações implementados por outros provedores de serviço, tais como aplicativos de transferência de mensagens do Serviço de Mensagens Curtas (SMS), sistemas de Protocolo de Iniciação de Sessão (SIP), e aplicações de cobrança que cobram os clientes pelos produtos e serviços; e outros dispositivos, programas ou entidades 108.
[00045] A arquitetura de telecomunicações 100 implementa funcionalidades que suportam produtos e serviços de telecomunicações. A arquitetura de telecomunicações 100 expõe as funcionalidades selecionadas para as entidades externas 102. Em outras palavras, as entidades externas 102 podem se comunicar com a arquitetura de telecomunicações 100 para utilizar as funcionalidades que já estão em vigor na arquitetura 100. Como resultado, as entidades externas 102 não precisam gastar os recursos necessários para duplicar localmente as funcionalidades que já são proporcionadas pela arquitetura de telecomunicações 100.
[00046] Os produtos e serviços, e suas funcionalidades subjacentes expostas, podem variar, dependendo da implementação. Por exemplo, a arquitetura de telecomunicações 100 pode expor serviços de transferência de mensagens SMS (para distribuir e cobrar por uma mensagem SMS), serviços de transferência de mensagens do Sistema de Mensagens Multimídia (MMS) (para distribuir e cobrar por uma mensagem MMS) e serviços SIP (para estabelecer uma chamada SIP e cobrar pela chamada). Como exemplos adicionais, a arquitetura de telecomunicações 100 pode expor serviços de Cobrança (para requisitar uma cobrança a uma conta), serviços de Televisão por Protocolo Internet (IPTV) (para requisitar a distribuição de programação de televisão), serviços de Situação do Usuário (para requisitar uma situação atual do usuário, tal como ‘conectado’, ‘desconectado’, ‘ocupado’ ou ‘ausente’) e serviços de autenticação do usuário (por exemplo, para requisitar a verificação de quanto a se existe um usuário móvel, e se o usuário móvel possui os credenciais para adquirir um serviço desejado, tal como um serviço IPTV). Outras funcionalidades podem ser proporcionadas em adição ou como alternativas. Além disso, a arquitetura de telecomunicações 100 também pode fornecer acesso a serviços de rede de comunicações (por exemplo, serviços de navegação pela Internet) através do circuito de interconexão de rede de acesso externo 110.
[00047] A arquitetura de telecomunicações 100 assegura o acesso aos serviços expostos. Com este intuito, a arquitetura 100 proporciona um circuito de interconexão de rede de acesso externo 110. O circuito de interconexão de rede de acesso externo 110 atua como um ponto de contato único das entidades externas 102 para os serviços expostos.
[00048] Conforme apresentado na figura 1, o circuito de intercone-xão de rede de acesso externo 110 recebe requisições de serviço 112 a partir das entidades externas 102. Em resposta, o circuito de inter-conexão de rede de acesso externo 110 verifica se a requisição de serviço origina-se de uma entidade externa autenticada e autorizada. No caso de requisições de serviço de comunicações em rede (como exemplo), o circuito de interconexão de rede de acesso externo 110 processa requisições de serviço autorizadas e retransmite as requisições de serviço para os provedores de serviço 114. No caso de requi sições de serviço expostas, tais como requisições de serviço SMS, MMS e SIP, o circuito de interconexão de rede de acesso externo 100 pode processar e retransmitir as requisições de serviço autorizadas para o corretor de serviços 116.
[00049] O corretor de serviços 116 executa a requisição de serviço. Ao fazer isto, o corretor de serviços 116 pode se comunicar com Sistemas de Suporte de Negócio (BSS) e Sistemas de Suporte de Operação (OSS) 118 que a arquitetura 100 implementa para criar, implementar, gerenciar e manter produtos e serviços de telecomunicações. Por exemplo, os sistemas OSS/BSS 118 podem incluir sistemas de cobrança, sistemas de diretório e de presença, sistemas de autenticação, sistemas de provisão ou outros sistemas de suporte. Ao executar a requisição de serviço, o corretor de serviços 116 pode adicional ou alternativamente se comunicar com uma camada de rede 120 que pode distribuir ou retornar dados relacionados ao serviço para o corretor de serviços 116. As respostas a partir dos provedores de serviço 114 e do corretor de serviços 116 são retornadas ao circuito de interconexão de rede de acesso externo 110 para distribuição para a entidade externa requisitante de origem.
[00050] O circuito de interconexão de rede de acesso externo 110 proporciona uma camada de segurança entre as entidades externas 102 e a funcionalidade exposta implementada na arquitetura de telecomunicações 100. Ao mesmo tempo, o corretor de serviços 116 proporciona uma camada arquitetônica para processar as requisições de serviços de entidades externas com flexibilidade e eficiência. Desse modo, a arquitetura 100 permite que um provedor de serviços de telecomunicações exponha funcionalidades principais para as entidades externas 102 e processe as requisições de serviço a partir das entidades externas 102 de forma segura, padronizada e controlada.
[00051] A figura 1 também apresenta um sistema de gestão de re lacionamento com o cliente (CRM) 122 em comunicação com o corretor de serviços 116. Como será explicado em maiores detalhes abaixo, o sistema CRM 122 também pode emitir requisições de serviço de telecomunicações para o corretor de serviços 116. Por exemplo, as requisições de serviço submetidas pelo sistema CRM 122 podem incluir requisições de ativação, suspensão, continuação ou término de serviço. As requisições podem resultar da interação do pessoal de assistência ao cliente com o sistema CRM 122 para estabelecer, suspender ou terminar produtos e serviços de telecomunicações do cliente (por exemplo, serviço de telefone celular).
[00052] Cada requisição de serviço pode incluir um campo identificador de tipo de serviço e um campo identificador de requisição de serviço. Na discussão abaixo, o campo TSO_LABEL proporciona um campo identificador de tipo de serviço e o campo TSO_ID proporciona um campo identificador de requisição de serviço. O TSO_LABEL na requisição de serviço é um identificador de tipo de serviço que especifica o tipo de serviço requisitado (por exemplo, uma requisição para ativar um produto ou serviço de telecomunicações específico). O TSO_ID na requisição de serviço é um identificador de requisição de serviço que proporciona um identificador da própria requisição de serviço (por exemplo, um identificador único).
[00053] A figura 2 apresenta uma vista mais detalhada de uma implementação do corretor de serviços 116. Como notado anteriormente, o corretor de serviços 116 se conecta a sistemas externos, incluindo os sistemas OSS/BSS 118, o circuito de interconexão de rede de acesso externo 110 e o sistema CRM 122 através das interfaces de requisição de serviço 201. As interfaces de requisição de serviço podem incluir um adaptador físico, um adaptador lógico ou ambos os adaptadores físico e lógico. Os sistemas OSS/BSS se conectam ao corretor de serviços 116 através do adaptador físico 202 e do adapta dor lógico 208, o circuito de interconexão de rede de acesso externo se conecta ao corretor de serviços 116 através do adaptador físico 204 e do adaptador lógico 210, e o sistema CRM se conecta ao corretor de serviços através do adaptador físico 206 e do adaptador lógico 212.
[00054] Os adaptadores físicos 202 a 206 podem ser implementados pelo software de comunicação que gerencia a comunicação entre os sistemas externos e o corretor de serviços. Os adaptadores lógicos 208 a 212 representam tradutores, mapeadores e/ou transformadores de dados que executam o mapeamento de mensagens entre diferentes modelos de dados no corretor de serviços e nos sistemas externos. Os adaptadores lógicos 208 a 212 asseguram que os dados de mensagem a partir dos sistemas externos cheguem ao corretor de serviços 116 na forma esperada pelo corretor de serviços 116. Em uma implementação, os adaptadores 208 a 212 suportam a transformação de mensagens e/ou de conteúdo de mensagem a partir de um formato definido por um esquema (por exemplo, um esquema XML para mensagens a se unirem ao circuito de interconexão de rede de acesso externo 110) para outro formato definido por outro esquema (por exemplo, um esquema XML para mensagens recebidas pelo corretor de serviços 116).
[00055] Um sistema de publicação de mensagens 214 proporciona um barramento de mensagens que comunica mensagens entre os sistemas externos e o corretor de serviços 116. Adicionalmente, o barra-mento de mensagens pode comunicar mensagens entre os componentes do próprio corretor de serviços 116. O sistema de publicação de mensagens 214 recebe as mensagens designadas para um tópico e publica as mensagens para os assinantes deste tópico. Os assinantes podem ser sistemas de processamento (por exemplo, os sistemas 110, 118 e 122), programas, ou outras entidades. Entretanto, outras técnicas de comunicação de mensagens podem ser utilizadas em ou tras implementações, incluindo transferência de arquivos em lote, arquivos compartilhados ou memória, ou outras técnicas de comunicação entre processos.
[00056] O sistema de publicação de mensagens e os adaptadores 202 a 212 podem ser implementados, por exemplo, com adaptadores TIBCO (SM) e sistema de mensagens TIBCO Rendezvous (®), disponíveis pela TIBCO Software Inc. of Palo Alto, CA. Em outras implementações, os adaptadores físicos podem ser implementados com controles de integração Weblogic BEA disponíveis pela BEA Systems of San Jose, CA. Em uma implementação, as mensagens são mensagens da Linguagem de Marcação Extensível (XML) e os adaptadores realizam a transformação de acordo com as folhas de estilo da Linguagem de Folha de Estilos Extensível para Transformações (XSLT). As transformações podem transformar dados entre esquemas para XML, Protocolo de Transporte de Hipertexto (HTTP), Protocolo Simples de Acesso a Objeto (SOAP), Linguagem de Definição de Serviços da Rede (WSDL), Diagrama de Esquema Extensível (XSD), Conectividade de Base de Dados Java/Conectividade Aberta de Base de Dados (JDBC/ODBC) ou outro formato de mensagem, padrões de conteúdo ou protocolos de comunicação.
[00057] O corretor de serviços 116 também inclui um sistema de expedição 216 que distribui requisições de serviço de entrada para as filas de requisições de serviço 218. As filas de requisições de serviço 218 podem incluir uma ou mais filas independentes designadas para tipos específicos de requisições de serviço. No exemplo apresentado na figura 2, as filas de serviço 218 incluem uma ou mais filas de requisições de serviço do circuito de interconexão de rede de acesso externo 220 que colocam em fila requisições de serviço recebidas a partir do circuito de interconexão de rede de acesso externo 110 e uma ou mais filas de gestão de relacionamento com o cliente 222 que colocam em fila requisições de serviço a partir do sistema CRM 122.
[00058] Por exemplo, as filas de requisições de serviço do circuito de interconexão de rede de acesso externo 220 podem incluir uma fila de requisições de serviço de mensagem 224 (para colocar em fila, por exemplo, requisições de distribuição de mensagem SMS ou MMS) e uma fila de requisições de serviço de Cobrança 226 (para colocar em fila, por exemplo, uma requisição de cobrança). Exemplos adicionais de filas 220 incluem uma fila de requisições de Autenticação e uma fila de requisições de Situação. De forma similar, as filas CRM 222 podem incluir uma fila de requisições Ativar Serviço 228, uma fila de requisições Terminar Serviço 230 e outras filas para requisições de serviço recebidas a partir do sistema CRM 122. As filas 220 e 222 não estão limitadas ao tipo e número descritos acima. Em vez disso, uma ou mais filas podem ser implementadas e designadas para colocar em fila qualquer um dentre um ou mais tipos de requisições de serviço recebidas a partir de qualquer um dentre um ou mais requisitantes de serviço.
[00059] O corretor de serviços 116 inclui um sistema de busca 232. Sob controle dos parâmetros de controle de tráfego 234, o sistema de busca 232 recupera requisições de serviço colocadas em fila a partir das filas de serviço 218. Em seguida, o sistema de busca 232 distribui as requisições de serviço recuperadas para um sistema de fluxo de trabalho 236. O sistema de fluxo de trabalho 236 inicia a execução dos mecanismos de fluxo de trabalho (por exemplo, os mecanismos de fluxo de trabalho 238, 240, 242) que determinam e requisitam a execução de etapas de fluxo de trabalho em uma ordem predefinida para implementar as requisições de serviço.
[00060] Por exemplo, para distribuir uma mensagem SMS e cobrar pela mesma, o sistema de fluxo de trabalho 236 pode iniciar a execução de um mecanismo de fluxo de trabalho SMS que, como uma eta pa, emite uma requisição de cobrança para um sistema de cobrança para cobrar pela mensagem SMS, e que, como outra etapa, emite uma requisição de transmissão de mensagem para um sistema SMS para enviar a mensagem. O sistema de fluxo de trabalho 236 pode ser implementado com um mecanismo de fluxo de trabalho Tibco InConcert (®) disponível pela TIBCO Software Inc. of Palo Alto, CA, ou com outros sistemas de fluxo de trabalho.
[00061] O corretor de serviços também inclui uma base de dados de gerenciamento de ordem técnica (TOM) 240. A base de dados TOM 240 armazena regras de configuração que definem um conjunto de etapas de ordem de serviço técnica a serem executadas em um fluxo de trabalho que satisfaz a requisição de serviço. A base de dados TOM 240 é explicada em maiores detalhes abaixo.
[00062] A figura 3 apresenta uma implementação alternativa de um corretor de serviços 302. O corretor de serviços 302 inclui um segundo sistema de busca 304. O segundo sistema de busca 304 também recupera requisições de serviço a partir das filas de serviço 218 sob controle dos parâmetros de controle de tráfego 234. De forma alternativa, o segundo sistema de busca 304 pode operar sob controle de um conjunto independente de parâmetros de controle de tráfego. Sistemas de busca e conjuntos de parâmetros de controle de tráfego adicionais podem ser proporcionados.
[00063] O segundo sistema de busca 304 emprega uma técnica de distribuição de requisição de fluxo de trabalho diferente do sistema de busca 232. Em particular, o segundo sistema de busca 304 publica mensagens de requisição de fluxo de trabalho para um sistema de publicação de mensagens, tal como o sistema 214. Em seguida, o sistema de publicação de mensagens 214 pode distribuir a mensagem de requisição de fluxo de trabalho para o segundo sistema de fluxo de trabalho 306, o qual se inscreve para as mensagens de requisição de fluxo de trabalho no sistema de publicação de mensagens 214. Em outras palavras, o sistema de publicação de mensagens 214 libera o segundo sistema de busca 304 do encargo e gargalo de diretamente chamar sequências de fluxo de trabalho.
[00064] Em vez disso, o segundo sistema de fluxo de trabalho 306 recebe a mensagem de requisição de fluxo de trabalho publicada e inicia a execução dos fluxos de trabalho para implementar a requisição de serviço. O segundo sistema de fluxo de trabalho 306 não precisa ser implementado da mesma forma que o primeiro sistema de fluxo de trabalho 236. No exemplo apresentado na figura 3, o segundo sistema de fluxo de trabalho 306 inclui um gerenciador de requisições de entrada 308, um mecanismo de fluxo de trabalho 310 e um gerenciador de tarefas paralelas 312. Um mecanismo de ação 318, incluindo um gerenciador de ações 320 e um criador de ações 322, executa ações de provisão da rede dentro da um fluxo de trabalho. Cada um deles é explicado em maiores detalhes abaixo.
[00065] A inclusão do segundo sistema de fluxo de trabalho 306 produz vários benefícios. Em particular, o segundo sistema de fluxo de trabalho 306 ajuda a remover o gargalo potencial do processamento das requisições de serviço por chamar diretamente o sistema de fluxo de trabalho 236 através do primeiro sistema de busca 232. Além disso, o primeiro sistema de busca 232 e o segundo sistema de busca 304 podem ser executados juntos, o que não somente aumenta a performance total por processar as requisições de serviço em paralelo, mas também proporciona um mecanismo robusto tolerante a falhas por proporcionar dois sistemas de mecanismo de busca/fluxo de trabalho independentes para processar requisições de serviço.
[00066] Os corretores de serviços 302 ou 116 também podem incluir uma interface gráfica com o usuário (GUI) de erros de rede. A figura 3 apresenta um exemplo de uma GUI de erros de rede 314 proporcio nada para o segundo sistema de busca 304. A GUI de erros de rede 314 pode ser implementada como um aplicativo de Rede de páginas de servidor Java executando um servidor da Rede (por exemplo, um servidor Weblogic Application disponível pela BEA Systems of San Jo-se, CA).
[00067] A GUI de erros de rede 314 preenche um meio de exibição de interface com o usuário com informações relacionando-se a quaisquer erros encontrados durante o processamento das requisições de serviço. A GUI de erros de rede 314 também pode proporcionar mecanismos de entrada através dos quais um revisor fornece entrada corretiva (por exemplo, entrada que altera os dados ou completa dados inexistentes na requisição de serviço ou tarefa de fluxo de trabalho de suporte para corrigir a requisição de serviço ou tarefa), completa manualmente a requisição de serviço ou tarefa, ou submete novamente requisições de serviço ou tarefas para processamento.
[00068] Em uma implementação, cada requisição de serviço que encontrou um erro pode ser representada na GUI de erros de rede com um título descritivo e uma hiperligação para detalhes adicionais das características da requisição de serviço. A GUI de erros de rede 314 pode adicionalmente proporcionar uma interface de pesquisa. A interface de pesquisa aceita critérios de pesquisa (por exemplo, número MSISDN, TSO_ID, faixa de dados, tipo de requisição de serviço, código de erro, cliente ou outro identificador, ou qualquer outra característica de uma requisição de serviço) e executa uma pesquisa e exibição responsiva dos registros de erro correspondentes. Clicar em uma hiperligação faz com que a GUI de erros de rede 314 preencha o meio de exibição com informações de erro específicas em relação à requisição de serviço selecionada e as características adicionais disponíveis para esta requisição de serviço (por exemplo, tipo de requisição, número IMSI, número MSISDN, emissor, destinatário, texto da mensagem, nome e endereço do cliente, ou qualquer outra característica).
[00069] A GUI de erros de rede 314 aceita entrada corretiva pelo revisor. O revisor pode orientar a GUI de erros de rede 314 a republicar o serviço, tarefa ou ação corrigida para o sistema de busca 304. O sistema de busca 403 recebe a mensagem de requisição de serviço corrigida e processa a requisição de serviço, tarefa ou ação corrigida em vez da original. Dessa forma, o sistema de busca 304 poupa um tempo precioso, e também recursos de processamento, por continuar um fluxo de trabalho já instanciado no ponto em que a requisição de serviço original encontrou o erro.
[00070] Uma GUI de erros de rede separada também pode ser proporcionada para o primeiro sistema de busca 232. Em vez de utilizar o sistema de publicação de mensagem 214, a GUI de erros de rede para o primeiro sistema de busca 232 pode comunicar informações de erro através de chamadas de função definidas em uma API. As chamadas de função podem ser proporcionadas pelo mecanismo de fluxo de trabalho Tibco InConcert (®), e a GUI de erros de rede pode relatar informações de erro e aceitar entrada corretiva, como observado acima para a GUI de erros de rede 314.
[00071] O corretor de serviços também pode proporcionar uma GUI de fluxo de trabalho 324. A GUI de fluxo de trabalho 324 fornece uma interface gráfica para a definição de fluxo de trabalho que proporciona extensa capacidade de configuração ao corretor de serviços. A GUI de fluxo de trabalho 324 implementa uma interface do tipo "arrastar e soltar" através da qual um operador pode selecionar e ordenar tarefas para criar novos fluxos de trabalho.
[00072] A figura 3 apresenta um exemplo no qual o operador organizou quatro tarefas 326, 328, 330 e 332 sequencialmente para formar um novo fluxo de trabalho 334. Pode-se organizar qualquer número de tarefas em qualquer ordem para definir novos fluxos de trabalho que personalizam o corretor de serviços para qualquer funcionalidade desejada pelo provedor de serviços. A GUI de fluxo de trabalho 324 pode proporcionar representações gráficas de fluxos de trabalho, tarefas e ações para um ou mais dos fluxos de trabalho, tarefas e ações prede-finidas na base de dados TOM 316. Os fluxos de trabalho, tarefas e ações podem representar os fluxos de trabalho, tarefas e ações definidas na tabela de fluxo de trabalho 902, na tabela de configuração de tarefa 904 e/ou na tabela de ações 906, as quais são descritas abaixo. [00073] Uma base de dados TOM aprimorada 316 também está presente no corretor de serviços 302. A base de dados TOM aprimorada 316 estende a primeira base de dados TOM 244 para suportar o segundo sistema de fluxo de trabalho 306 e a GUI de erros da rede 314. Como será explicado em maiores detalhes abaixo, a base de dados TOM aprimorada 316 define seqüências de tarefas e ações a serem executadas para implementar requisições de serviço específicas, e proporciona tabelas de relatórios para a GUI de erros de rede 314.
[00074] A figura 4 mostra exemplos dos parâmetros de controle de tráfego 234. Em particular, a figura 4 apresenta um parâmetro "functio-nality name" 402, um parâmetro "pool size" 404 e um parâmetro "pol-ling time" 406. A figura 4 também apresenta um parâmetro "submit ti-mer" 408, um parâmetro "criteria" 410 e um parâmetro "standby" 412. Parâmetros adicionais de controle de tráfego incluem um parâmetro "wait" 414, um parâmetro "control locked" 416 e um parâmetro "data" 418.
[00075] A Tabela 1 abaixo proporciona uma explanação para cada parâmetro de controle de tráfego 234: [00076] Os parâmetros de controle de tráfego 234 podem reconfigu-rar de forma dinâmica os sistemas de busca 232 e 304 durante o tempo de execução. Com esse intuito, os parâmetros de controle de tráfego 234 podem ser comunicados para um processo gerenciador de controle de tráfego dentro dos sistemas de busca 232 e 304 (por exemplo, via uma conexão HTTP, com os parâmetros embutidos no URL). Em seguida, o gerenciador de controle de tráfego pode estabelecer as variáveis internas com os novos parâmetros para a nova recuperação de um bloco de requisições de serviço.
[00077] A figura 5 apresenta um exemplo de uma implementação do expedidor 216. O expedidor 216 pode incluir um processador 502 acoplado a uma memória 504. A memória 504 armazena um programa de expedição 506. O programa de expedição 506 pode ser um processo multitarefa. A memória 504 também armazena mensagens de chegada 508 para processamento pelo programa de expedição 506. As mensagens de chegada 508 incluem um campo de rótulo de ordem de serviço técnica ("TSO_LABEL") 510, um campo "TSOJD" 511 e os dados de mensagem da requisição de serviço 512 que adicionalmente define a requisição de serviço (por exemplo, por especificar dados de mensagem SMS, destinatários, ou outros dados suportando a requisição de serviço). O campo "TSO_LABEL" proporciona um campo identificador do tipo de serviço que indica o serviço requisitado.
[00078] As mensagens de chegada 508 podem ser mensagens da Linguagem de Marcação Extensível (XML), as quais incluem marcas de identificação ao redor de cada elemento de dados na mensagem. O programa de expedição 506 examina os dados XML nas mensagens de chegada 508 e estabelece um registro de requisição de serviço nas filas de serviços 218 com base nos campos identificados por marca nos dados XML. Em particular, baseado no campo identificador de serviço (por exemplo, baseado no "TSO_LABEL"), o programa de expedição 506 estabelece um registro de requisição de serviço em uma fila de serviços particular com base no "TSO_LABEL" 510. Em outras palavras, o "TSO_LABEL" 510 identifica para o programa de expedição 506 o tipo de requisição de serviço e, portanto, a fila de serviços apropriada na qual a requisição de serviço deverá residir.
[00079] As filas de serviço 218 podem ser implementadas como tabelas de base de dados. A figura 5 apresenta um exemplo de um registro de requisição de serviço 514 que pode ser definido nas filas de serviço 218. Entretanto, podem ser implementadas outras definições de registro de requisição de serviço. Os campos do registro de requisição de serviço 514 são explicados abaixo na Tabela 2. "TSO_ID", "TSO_LABEL" e "TSO_DATE" são armazenados em campos separados. Quando o programa de expedição 506 recebe a mensagem de chegada 508, o programa de expedição pode extrair separadamente os dados "TSO_ID", "TSO_LABEL" e "TSO_DATE" a partir da mensagem 508 e armazená-los nos campos correspondentes no registro de requisição de serviço 514. Portanto, agora os sistemas de busca 232 e 304 podem extrair dados em fileira a partir das tabelas de filas por qualquer campo ou combinação de campos.
[00080] Em uma implementação, quando o programa de expedição 506 insere uma fileira em uma tabela de filas de serviço com um novo registro de requisição de serviço 514, o programa de expedição 506 insere os dados para os seguintes campos: "TSO_ID" "TSO_LABEL" "TSO_DATE" "XML_IN" "BP_FLAG" = 0 "AP_FLAG" = 0 "INS_TMS" = Data do Sistema [00081] A figura 6 apresenta uma implementação do sistema de busca 232. O sistema de busca 232 inclui um processador 604 acoplado a uma memória 604. A memória 604 armazena um programa de busca 606 (por exemplo, um processo multitarefa). A memória também armazena uma lista de fileiras de registro de requisição de serviço 608. As entradas na lista de fileiras de registro de requisição de serviço 608 apontam para requisições de serviço nas filas de serviços 218.
[00082] Guiado pelos parâmetros de controle de tráfego 234, o pro grama de busca 606 verifica as filas de serviços 218. O programa de busca 606 recupera grupos de TSO_IDs a partir dos registros de requisição de serviço selecionados. O programa de busca 606 pode chamar um procedimento armazenado da Linguagem de Consulta Estruturada (SQL) para acessar as tabelas nas filas de serviço 218.
[00083] O procedimento armazenado pode estabelecer o "BP_FLAG" como 1 para cada fileira nas filas de serviços 218 que corresponde aos critérios de pesquisa fornecidos pelo sistema de busca. O procedimento armazenado retorna uma lista de fileiras 608 das fileiras que correspondem aos critérios de pesquisa para o sistema de busca 232. A lista de fileiras 608 pode incluir o campo "TSO_ID" de cada registro de requisição de serviço correspondido.
[00084] O programa de busca 606 obtém a lista de fileiras 608 a partir do procedimento armazenado. Em seguida, o programa de busca 606 transmite a lista de fileiras 608 para um programa de chamada de fluxo de trabalho 610. O programa de chamada de fluxo de trabalho 610 chama o mecanismo de fluxo de trabalho 236 para iniciar a execução do fluxo de trabalho apropriado para executar cada requisição de serviço representada nos registros de requisição de serviço identificados na lista de fileiras.
[00085] De forma mais específica, o programa de chamada de fluxo de trabalho 610 processa a lista de fileiras 608 de forma assíncrona para cada fileira. O programa de chamada de fluxo de trabalho 610 aguarda durante o tempo "WAIT" especificado nos parâmetros de controle de tráfego 234. Quando o tempo "WAIT" tiver expirado, o programa de chamada de fluxo de trabalho 610 estabelece o "BP_FLAG" como ‘2’ para o registro de requisição de serviço sendo processado no momento.
[00086] Em seguida, o programa de chamada de fluxo de trabalho 610 chama diretamente o sistema de fluxo de trabalho 236 para iniciar o fluxo de trabalho que implementa a requisição de serviço associada à fileira atual. Na chamada para iniciar o fluxo de trabalho, o programa de chamada de fluxo de trabalho 610 pode transmitir de forma assíncrona o campo "TSOJD" para o sistema de fluxo de trabalho 236. Em seguida, o programa de chamada de fluxo de trabalho 610 estabelece o "BP_FLAG" como ‘3’ para indicar que o fluxo de trabalho foi chamado.
[00087] No sistema de fluxo de trabalho 236, os mecanismos de fluxo de trabalho executam etapas de fluxo de trabalho (por exemplo, tarefas, ações e TSOs) que implementam a requisição de serviço específica. Ao executar a requisição de serviço, a primeira tarefa que um mecanismo de fluxo de trabalho executa é a de recuperar os dados "XML_IN" a partir da tabela de filas. O mecanismo de fluxo de trabalho recupera os dados "XML_IN" a partir do registro de requisição de serviço correspondendo ao "TSOJD" proporcionado pelo sistema de busca 232. Deste modo, o fluxo de trabalho de serviço obtém uma definição completa do serviço requisitado, incluindo dados de suporte para o serviço requisitado. Por exemplo, os dados "XML_IN" para uma entrega de mensagem SMS irão incluir o texto da mensagem e identificadores de destinatários.
[00088] O campo "TSO_LABEL" especifica o serviço requisitado. O fluxo de trabalho executa as tarefas que efetuam o serviço requisitado. Por exemplo, para uma entrega de mensagem SMS, o mecanismo de fluxo de trabalho pode enviar uma mensagem de cobrança para um sistema de cobrança, e em seguida enviar o texto da mensagem para um subsistema de distribuição SMS. O mecanismo de fluxo de trabalho também retorna um resultado do processamento da requisição de serviço. Por exemplo, o fluxo de trabalho pode retornar uma mensagem de sucesso ou mensagem de erro, opcionalmente com explanação detalhada, ou qualquer outra informação que resulte do processamento da requisição de serviço.
[00089] O fluxo de trabalho termina por atualizar o registro de requisição de serviço para o "TSOJD" aplicável. O mecanismo de fluxo de trabalho grava a seqüência de caracteres "XML_OUT" no registro de requisição de serviço. A seqüência de caracteres "XML_OUT" pode incluir o resultado do processamento da requisição de serviço. Em adição, o mecanismo de fluxo de trabalho estabelece o "AP_FLAG" como ‘1’ para indicar que o fluxo de trabalho terminou e estabelece o "END_TMS" como a data atual do sistema (ou seja, a data/hora da conclusão do fluxo de trabalho).
[00090] Os mecanismos de fluxo de trabalho determinam as tarefas e ações a serem executadas e a ordem de execução das mesmas por consultar a base de dados de gerenciamento de ordem técnica (TOM) 244. A figura 7 apresenta uma implementação do modelo de dados para a base de dados TOM 244. O modelo de dados não está limitado à implementação apresentada na figura 7, podendo variar extensamente, de acordo com a implementação particular na qual o modelo de dados é empregado. A base de dados TOM 244 inclui uma tabela de Catálogo de Ordem Técnica de Serviço ("STOC") 702, uma tabela "Ac-tions" 704 e uma tabela "STOC parameter" 706. A base de dados TOM 244 adicionalmente inclui uma tabela "ClassBuild" 708, uma Tabela "PutSequenceInClass" 710 e uma Tabela "SequenceBuild" 712.
[00091] A tabela "STOC" inclui um campo "STOCJD" 714 como chave primária e campos adicionais 716. A tabela "Actions" inclui um campo "ActionJD" 718 como chave primária e campos adicionais 720. A tabela "STOCParam" 706 inclui um campo "STOCParamJD" 722 como chave primária e campos adicionais 724. A tabela "ClassBuild" 708 inclui um campo "ParamJD" 726 como chave primária e campos adicionais 728. A tabela "PutSequenceInClass" 710 inclui um campo "PutSequenceJD" 730 como chave primária e campos adicionais 732. A tabela "SequenceBuild" 712 inclui um campo "SequenceJD" 734 como chave primária e campos adicionais 736.
[00092] A tabela "STOC" 702 define um modelo de fluxo de trabalho das etapas de fluxo de trabalho referidas como Ordens de Serviço Técnicas (TSOs) para manipular uma requisição de serviço. A tabela "Actions" 704 define, e liga-se de volta à tabela "STOC", as TSOs (ou seja, as ações) a serem executadas e sua ordem de execução para completar com êxito qualquer dada requisição de serviço. Em algumas implementações, a base de dados 228 pode definir uma tabela "Inver-se Action" similar à tabela "Actions" 704. Quando ocorrer um erro durante o processamento de uma ação em um fluxo de trabalho, a "In-verse Action" ("Ação Inversa") associada pode ser executada. A "In-verse Action" pode sincronizar a situação da conta do cliente, a situação do pedido, ou outros dados entre sistemas de processamento independentes. A base de dados TOM 244 adicionalmente define parâmetros para as ações, os quais podem ser recebidos a partir do requi-sitante de serviço, ou os quais podem ser proporcionados pelo próprio mecanismo de fluxo de trabalho. Cada tabela 702 a 712, incluindo os campos adicionais, é explicada em maiores detalhes abaixo.
[00093] O sistema de fluxo de trabalho 236 divide o processamento das ordens de serviço em duas tarefas. A primeira tarefa é determinar como uma requisição de serviço é dividida em TSOs por pesquisar as definições de fluxo de trabalho na base de dados TOM 244. A segunda tarefa é gerenciar as TSOs por enviá-las na seqüência correta, receber respostas e tratar erros.
[00094] Com base no TSO_LABEL e nas definições estabelecidas na base de dados TOM 244, o sistema de fluxo de trabalho 236 determina o conjunto de TSOs a ser executado e sua ordem. O sistema de fluxo de trabalho 236 também constrói uma lista de atributos para cada TSO a ser executada. Os atributos podem ser especificados completamente ou em parte pelo requisitante de serviço (por exemplo, o sistema CRM 122) e também podem ser especificados completa mente ou em parte pela base de dados TOM 244. À medida que as TSOs são executadas, o mecanismo de fluxo de trabalho incrementa um índice que aponta para a TSO a ser executada no momento.
[00095] O mecanismo de fluxo de trabalho constrói uma mensagem requisitando a execução da TSO. Por exemplo, a mensagem pode ser publicada para um sistema de provisão que executa uma ação especificada na mensagem, como parte da implementação da requisição de serviço geral. A base de dados TOM 244 suporta a construção das mensagens e fornece a ordem na qual a TSO deve ser executada, atributos para a TSO (por exemplo, atributos estáticos especificados dentro da base de dados TOM 244 e atributos dinâmicos submetidos pelo requisitante de serviço), um assunto junto ao qual a mensagem será publicada e outros parâmetros descritos anteriormente.
[00096] Assim, a base de dados TOM 244 proporciona as regras de configuração que dividem um fluxo de trabalho de requisição de serviço associado a um TSO_LABEL em um conjunto de TSOs que implementam a requisição de serviço. Deste modo, a base de dados TOM 244 proporciona um mecanismo extremamente flexível, reconfigurável e extensível para definir fluxos de trabalho, TSOs que implementam os fluxos de trabalho, e a ordem na qual as TSOs são executadas.
[00097] A figura 8 apresenta uma implementação ilustrativa do segundo sistema de busca 304. O sistema de busca 304 pode incluir um processador 802 acoplado a uma memória 804. A memória 804 armazena um programa de busca 806 (por exemplo, um processo multitare-fa). A memória também armazena uma lista de fileiras de registro de requisição de serviço 808. As entradas na lista de fileiras de registro de requisição de serviço 608 apontam para requisições de serviço colocadas em fila nas filas de serviços 218 e submetidas pelo circuito de interconexão de rede externo 110, pelo sistema CRM 122 ou qualquer outro requisitante de serviços externo.
[00098] Guiado pelos parâmetros de controle de tráfego 234 (ou por um conjunto independente de parâmetros de controle de tráfego estabelecido para o sistema de busca 304), o programa de busca 806 verifica as filas de serviços 218. O programa de busca 806 recupera blocos de TSO_IDs a partir de registros de requisição de serviço correspondentes. O programa de busca 806 pode executar um procedimento armazenado da Linguagem de Consulta Estrutura (SQL) para acesso às tabelas nas filas de serviços 218.
[00099] Para cada requisição de serviço a ser processada, o programa de busca chama um programa gerenciador de instâncias 814. O programa gerenciador de instâncias preenche as tabelas na base de dados TOM 316 para criar instâncias de tabelas de fluxo de trabalho para a requisição de serviço. As tabelas da base de dados TOM são descritas em maiores detalhes abaixo.
[000100] O programa de busca 806 transmite a lista de fileiras 808 para um programa de publicação de mensagem 810. O programa de publicação de mensagem 810 publica mensagens de requisição de fluxo de trabalho 812 (as quais especificam requisições de serviço) para o segundo sistema de fluxo de trabalho 306. Deste modo, o sistema de busca 304 remove o possível gargalo que ocorreria ao chamar diretamente um mecanismo de fluxo de trabalho por permitir ao sistema de publicação de mensagem 214 distribuir as mensagens de requisição de fluxo de trabalho para o segundo sistema de fluxo de trabalho 306. A mensagem de requisição de fluxo de trabalho pode especificar o TSO_ID (em um campo TSO_ID 814) e o TSO_LABEL (em um campo TSO_LABEL 816). O TSO_ID e o TSO_LABEL são obtidos a partir dos registros de serviço nas filas de serviços 218. O sistema de busca 304 pode aguardar uma resposta do sistema de publicação de mensagem 214 após o sistema de busca 304 publicar cada mensagem de requisição de fluxo de trabalho.
[000101] De forma mais específica, as mensagens de requisi-ção/resposta podem ser definidas conforme apresentado nas Tabelas 9 a 12 abaixo: [000102] A figura 9 apresenta os aprimoramentos que estão presentes na base de dados TOM 316 que suporta o segundo sistema de busca 304. As seqüências das etapas a serem efetuadas para implementar uma requisição de serviço são definidas pela tabela Workflows 902, tabela Task_cfg 904 e a tabela Actions 906. Em particular, a tabela Workflows 902 define um modelo de fluxo de trabalho, a tabela Task_cfg 904 define tarefas que implementam o fluxo de tarefa e a tabela Actions 906 define ações associadas a cada tarefa. As tarefas e ações podem ser executadas, por exemplo, por processos em andamento em um sistema de processamento externo Tibco BusinessWorks (®). Uma tabela "supporting task instance" 908 e uma tabela "supporting actions instance" 910 também estão presentes. Cada tabela é descrita em maiores detalhes abaixo.
[000103] A tabela TASK_INS 908 pode incluir os mesmos campos que a tabela TASK_CFG 904 e os seguintes campos adicionais: [000104] A tabela ACTION_INST 910 pode incluir os mesmos campos que a tabela ACTIONS 906 e os seguintes campos adicionais: [000105] Em adição, a base de dados TOM aprimorada 316 fornece suporte para a GUI de erros de rede 314. Em particular, a base de da- dos TOM aprimorada 316 inclui uma tabela GUI User 912, tabela GUI role 914 e uma tabela GUI status 916. Também está incluída uma tabela GUI history 918. Cada tabela é descrita em maiores detalhes abaixo.
[000106] Para cada requisição de serviço, e antes de publicar uma mensagem de requisição de serviço correspondente, o programa gerenciador de instâncias 814 preenche a tabela TASK_INST 908 com as tarefas de fluxo de trabalho a serem executadas. O programa gerenciador de instâncias 814 também preenche a tabela ACTION_INST 910 com as ações de provisão dentro de cada tarefa. Os dados que preenchem as tabelas 908 e 910 são obtidos a partir dos modelos definidos nas tabelas de catálogo 902, 904 e 906. Assim, cada requisição de serviço a ser processada possui um fluxo de trabalho instanciado pronto na tabela TASK_INST 908 e na tabela ACTION_INST 910.
[000107] O segundo sistema de fluxo de trabalho 306 recebe as mensagens de requisição de fluxo de trabalho publicadas a partir do sistema de publicação de mensagem 214. O sistema de fluxo de trabalho 306 primeiro processa as mensagens de requisição de fluxo de trabalho através de um gerenciador de requisições de entrada 308. [000108] A figura 10 apresenta um fluxograma ilustrativo das ações 1000 realizadas pelo gerenciador de requisições de entrada 308. O gerenciador de requisições de entrada 308 recebe a mensagem de requisição de serviço publicada que foi publicada pelo sistema de publicação de mensagem 214 (Ação 1002). O gerenciador de requisições de entrada extrai um TSO_ID a partir da mensagem de requisição de serviço (Ação 1004) e um TSO_LABEL a partir da mensagem de requisição de serviço (Ação 1006).
[000109] Com o TSO_ID, o gerenciador de requisição de entrada 308 pesquisa a base de dados TOM aprimorada 314 em busca de um modelo de fluxo de trabalho instanciado que implemente a requisição de serviço representada pelo TSO_ID. Se nenhum modelo tiver sido definido, o gerenciador de requisições de entrada 308 retorna uma confirmação Negativa ao sistema de busca 304 (Ação 1010). Senão, o gerenciador de requisições de entrada 308 retorna uma confirmação Positiva ao sistema de busca 304 (Ação 1012) e chama o mecanismo de Fluxo de Trabalho 310 com o TSO_ID e TSO_LABEL (Ação 1014).
[000110] A figura 11 apresenta um fluxograma ilustrativo das ações 1100 realizadas pelo gerenciador de fluxo de trabalho 310. O gerenciador de fluxo de trabalho 310 recebe o TSO_ID e o TSO_LABEL a partir do gerenciador de requisições de entrada 308 (Ação 1102). O mecanismo de fluxo de trabalho 310 então recupera as tarefas de fluxo de trabalho dentro do modelo de fluxo de trabalho a partir da tabela TASK_INST 808 (Ação 1104).
[000111] Se houver mais tarefas no fluxo de trabalho, o mecanismo de fluxo de trabalho 310 executa a próxima tarefa na ordem (Ação 1106). Para isto, o mecanismo de fluxo de trabalho 310 invoca o sub-processo identificado para a tarefa na tabela TASK_INST 808. Para tarefas que são invocadas de forma seqüencial, o mecanismo de fluxo de trabalho 310 invoca o sub-processo da tarefa e aguarda uma resposta do sub-processo (Ação 1100). Para tarefas que podem ser invocadas em paralelo a outras tarefas, o mecanismo de fluxo de trabalho 310 invoca o sub-processo da tarefa e avança para a próxima tarefa sem aguardar (Ação 1110).
[000112] Várias condições são definidas para as tarefas. O mecanismo de fluxo de trabalho 304 e a GUI de erros de rede 314 podem estabelecer e manter as condições durante a execução das tarefas. A situação inicial para uma tarefa é ‘I’ (inicial) e a situação final pode ser tanto ‘D’ (finalizado) ou ‘C’ (finalização forçada). Inicialmente, cada tarefa pode possuir uma situação estabelecida como ‘I’. Quando o mecanismo de fluxo de trabalho 310 invocar o sub-processo para executar a tarefa, a situação da tarefa é alterada para ‘X’ (execução). A situação ‘X’ indica que o sub-processo está executando a tarefa.
[000113] A conclusão com êxito da tarefa e da recepção de uma resposta a partir do sub-processo faz com que a tarefa mude para a situação ‘D’ (finalizado). Em seguida, o mecanismo de fluxo de trabalho 310 no sistema de fluxo de trabalho 306 pode se mover para a próxima tarefa no fluxo de trabalho. Se o sub-processo responder com um erro, o mecanismo de fluxo de trabalho 310 pode estabelecer a situação da tarefa como ‘E’ (erro). Em resposta, o mecanismo de fluxo de trabalho 310 passa a tarefa para a GUI de erros de rede 314.
[000114] Como observado acima, a GUI de erros de rede 314 proporciona uma interface através da qual um operador pode corrigir o conteúdo da mensagem, ignorar a tarefa ou submeter novamente a tarefa (já corrigida) para processamento. Quando a tarefa é submetida novamente, a situação da tarefa muda para ‘R’ (submetida novamente). O sistema de fluxo de trabalho 306 recebe a tarefa submetida novamente, executa o sub-processo que manipula a tarefa e estabelecer a situação da tarefa novamente como ‘X’. Para tarefas com uma situa ção de erro ‘E’, o mecanismo de fluxo de trabalho 310 para a execução da tarefa. A GUI de erros de rede 314 pode reiniciar a tarefa por publicar uma mensagem de requisição/resposta para o sistema de fluxo de trabalho 306 para requisitar o processamento da tarefa.
[000115] A GUI de erros de rede 314 ignora a tarefa, a situação da tarefa é estabelecida como ‘C’ (concluída). Em adição, o operador pode controlar a execução das tarefas através da GUI de erros de rede 314. O operador pode emitir uma requisição através da GUI de erros de rede 314 para forçar a tarefa a ser imediatamente finalizada (mudando a tarefa para a situação ‘C’), ou pode forçar a tarefa a ser submetida novamente (mudando a tarefa para a situação ‘R’). O sistema de fluxo de trabalho 306 considera uma situação ‘C’ como sendo uma situação final, e em resposta avança para a próxima tarefa na seqüência de fluxo de trabalho.
[000116] A figura 12 apresenta um exemplo das ações 1200 realizadas pelo gerenciador de tarefas paralelas 312. Certas tarefas podem ser designadas como tarefas paralelas que podem funcionar ao mesmo tempo em que outras tarefas. Contudo, algumas tarefas podem precisar dos resultados obtidos por outras tarefas a serem realizadas. Deste modo, o gerenciador de tarefas paralelas 312 aguarda pela recepção de uma resposta a partir de um sub-processo executando uma tarefa paralela (Ação 1202), obtém a resposta (Ação 1204) e fornece a resposta para outras tarefas (por exemplo, através do mecanismo de fluxo de trabalho 310) que aguardam pela resposta antes de poderem continuar (Ação 1206). Deste modo, o gerenciador de tarefas paralelas 312 atua desbloqueando tarefas que estão pendentes, aguardando por dados de entrada.
[000117] Como observado acima, o sistema de fluxo de trabalho 306 também inclui o mecanismo de ação 318. O mecanismo de ação 318 executa ações de provisão de rede dentro de tarefas individuais. Em outras palavras, se a base de dados TOM aprimorada 316 especificar ações de provisão de rede para determinadas tarefas, o segundo sistema de fluxo de trabalho 306 pode chamar o mecanismo de ação 318 para processar as ações.
[000118] O mecanismo de ação 318 inclui duas camadas: um gerenciador de ações 320 e um criador de ações 322. O gerenciador de ações 320 determina e inicia a execução das ações de provisão na seqüência correta, conforme definida na base de dados TOM 316. O criador de ações 322 cria e envia a mensagem apropriada para o sistema de publicação de mensagem 214 para requisitar a execução da ação, e também recebe respostas a partir do sistema de publicação de mensagem 214.
[000119] O mecanismo de ação 318 funciona de forma similar ao mecanismo de fluxo de trabalho 310 (figura 11). De forma mais específica, o mecanismo de ação 318 recebe uma requisição para processar uma tarefa em um fluxo de trabalho. Em resposta, o gerenciador de ações 320 recupera as ações a serem executadas para a tarefa a partir da tabela ACTION_INST 810.
[000120] Para cada ação a ser executada, o gerenciador de ações 320 chama o criador de ações 322. Se a ação não for separada (ou seja, não é executada em paralelo), então o gerenciador de ações 320 aguarda uma resposta do criador de ações 322. Senão, o gerenciador de ações 320 inicia a execução da próxima ação na seqüência, sem aguardar uma resposta do criador de ações 322. A GUI de erros de rede 314 também pode gerenciar erros que ocorrem durante a execução das ações da mesma forma que, e com as mesmas transições de situação que os erros de tarefa.
[000121] O criador de ações 322 cria e envia mensagens de requisição de ação para o sistema de publicação de mensagem 214 para distribuição ao sistema ou processo que irá executar a ação. O criador de ações 322 recebe respostas originando-se da execução da ação a partir do sistema de publicação de mensagem 214. O criador de ações 322 envia a resposta de volta para o gerenciador de ações 320. Dependendo da resposta, o gerenciador de ações 320 pode tratar de quaisquer erros (por exemplo, através da GUI de erros de rede 314) ou pode executar a próxima ação da rede, se houver.
[000122] Os fluxos de trabalhos, tarefas e ações podem ser definidos para uma ampla faixa de requisições de serviço. Por exemplo, um fluxo de trabalho para ativar um Módulo de Identidade do Assinante UMTS (USIM) pode ser associado a um TSO_LABEL de "ACTIVA-TE_USM" e pode ser dividido nas seguintes tarefas: Ativar o serviço básico núcleo (proporcionar, por exemplo, o IMSI e MSISDN associados), Alterar o serviço de mensagem (por exemplo, para fornecer o MSISDN e nome do cliente para serviços de troca de mensagem associados) e Alterar o serviço de alertas (por exemplo, para fornecer o nome do cliente, data de nascimento, endereço ou outras informações do cliente para um dispositivo de alerta). Exemplos adicionais de fluxo de trabalho associados com requisições de serviço a partir do sistema CRM 122 incluem fluxos de trabalho para Alterar um USIM, Suspender um USIM, Retomar um USIM, Alterar um número MSISDN, Desativar um telefone de mão, Pré-Ativar USIMs pré-pagos ou pós-pagos, Ativar um serviço, Terminar um serviço e Terminar um USIM.
[000123] O corretor de serviços 116 processa requisições de serviço para uma grande variedade de serviços de telecomunicações. Em uma função, o corretor de serviços 116 processa requisições de serviço recebidas a partir do circuito de interconexão de rede externo 110. Em geral, o corretor de serviços 116 mapeia a requisição de serviço de entrada em uma seqüência de etapas (por exemplo, tarefas e ações) a ser realizada para implementar a requisição de serviço. O corretor de serviços 116 distribui uma requisição para execução de cada etapa ao sistema ou pro- cesso apropriado, determina o resultado e se comunica com o circuito de interconexão de rede externo 110 com respeito ao resultado.
[000124] A figura 13 apresenta um exemplo do fluxo de mensagens resultando de uma requisição de serviço de Autenticação recebida a partir do circuito de interconexão de rede externo 10 (Fluxo 1302). O circuito de interconexão de rede externo 110 pode enviar a requisição de Autenticação (incluindo as informações utilizadas para reconhecer o usuário, tais como números MSISDN e/ou IMSI) quando, por exemplo, um usuário precisar ser identificado antes de poder adquirir um serviço. O corretor de serviços 116 submete uma requisição pelo perfil do usuário para um sistema de diretórios (Fluxo 1304) que retorna o perfil do usuário (Fluxo 1306).
[000125] O corretor de serviços 116 retorna um resultado para o circuito de interconexão de rede externo 110 (Fluxo 1308). Se a autenticação do usuário pelo sistema de diretórios não foi possível, o corretor de serviços 116 retorna uma mensagem "Não Autorizado" para o circuito de interconexão de rede externo. Senão, o corretor de serviços 116 retorna uma mensagem "Autorizado" com os dados do perfil do usuário. Quando o usuário é autorizado, o corretor de serviços 116 pode então requisitar informações adicionais sobre o usuário na forma de uma requisição pelo perfil de serviço do usuário (Fluxo 1310) para o sistema de diretórios, o qual retorna o perfil (Fluxo 1312).
[000126] O corretor de serviços 116 retorna um resultado para o circuito de interconexão de rede externo 110 (Fluxo 1314). Se a informação do perfil não estava disponível, o corretor de serviços 116 retorna uma mensagem "Não Autorizado" ao circuito de interconexão de rede externo 110. Senão, o corretor de serviços 116 retorna uma mensagem "Autorizado" com os dados de perfil de serviço.
[000127] As tabelas 22 e 23 ilustram exemplos da mensagem e resposta de requisição de serviço de Autenticação.
[000128] A figura 14 apresenta um exemplo do fluxo de mensagens resultando de uma requisição de serviço de Cobrança recebida a partir do circuito de interconexão de rede externo 110 (Fluxo 1402). O circuito de interconexão de rede externo 110 pode enviar a requisição de Cobrança para cobrar por uma quantidade de serviço de uma conta de usuário. O corretor de serviços 116 submete a requisição de cobrança para o sistema de cobrança, incluindo a quantidade de cobrança (Fluxo 1404). O sistema de cobrança cobra pelo serviço da conta e retorna uma situação de resultado ao corretor de serviços 116 (Fluxo 1406). O corretor de serviços 116 retorna a situação do resultado para o circuito de interconexão de rede externo 110 (Fluxo 1408).
[000129] As tabelas 24 e 25 ilustram exemplos da mensagem e resposta de requisição de serviço de Cobrança.
[000130] A figura 15 apresenta um exemplo do fluxo de mensagem resultando a partir de uma requisição de serviço de distribuição SMS recebida a partir do circuito de interconexão de rede externo 110 (Fluxo 1502). O circuito de interconexão de rede externo 110 pode enviar a requisição SMS para cobrar por, e distribuir uma mensagem SMS para uma conta de usuário. O corretor de serviços 116 requisita o sistema de cobrança para cobrar a conta pelo serviço (Fluxo 1504) e recebe uma situação de resultado a partir do sistema de cobrança (Fluxo 1506). O corretor de serviços 116 retorna a situação do resultado para o circuito de interconexão de rede externo 110 (Fluxo 1508). Em seguida, o corretor de serviços 116 chama o processo ou sistema SMS através da interface de rede para enviar o SMS (Fluxo 1510) e recebe uma confirmação (Fluxo 1512). O corretor de serviços 116 pode continuar a tentar enviar novamente a mensagem SMS em caso de erros.
[000131] As Tabelas 26 e 27 ilustram exemplos da mensagem e resposta de requisição de serviço SMS.
[000132] A figura 16 apresenta um exemplo do fluxo de mensagem resultando a partir de uma requisição de serviço de distribuição MMS recebida a partir do circuito de interconexão de rede externo 110 (Fluxo 1602). O circuito de interconexão de rede externo 110 pode enviar a requisição MMS para cobrar por, e distribuir uma mensagem MMS para uma conta de usuário. O corretor de serviços 116 requisita o sistema de cobrança para cobrar a conta pelo serviço (Fluxo 1604) e recebe uma situação de resultado a partir do sistema de cobrança (Fluxo 1606). O corretor de serviços 116 retorna a situação de resultado para o circuito de interconexão de rede externo 110 (Fluxo 1608). Em seguida, o corretor de serviços 116 chama o processo ou sistema MMS através da interface de rede para enviar o MMS (Fluxo 1610) e recebe uma confirmação (Fluxo 1612). O corretor de serviços 116 pode continuar a tentar enviar novamente a mensagem MMS em caso de erros.
[000133] As Tabelas 28 e 29 ilustram exemplos da mensagem e resposta de requisição de serviço MMS.
[000134] A figura 17 apresenta um exemplo do fluxo de mensagem resultando a partir de uma requisição de serviço do Protocolo de Iniciação de Sessão (DIP) recebida a partir do circuito de interconexão de rede externo 110 (Fluxo 1702). O circuito de interconexão de rede externo 110 pode enviar a requisição SIP para estabelecer uma chamada SIP e cobrar da conta de um usuário. O corretor de serviços 116 requisita o sistema de cobrança para cobrar a conta pelo serviço (Fluxo 1704) e recebe uma situação de resultado a partir do sistema de cobrança (Fluxo 1706). O corretor de serviços 116 retorna a situação do resultado para o circuito de interconexão de rede externo 110 (Fluxo 1708). Em seguida, o corretor de serviços 116 chama o processo ou sistema SIP através da interface de rede para estabelecer a conexão SIP (Fluxo 1710) e recebe uma confirmação (Fluxo 1712). O corretor de serviços 116 pode continuar a tentar estabelecer novamente a conexão SIP em caso de erros.
[000135] As Tabelas 30 e 31 ilustram exemplos da mensagem e resposta de requisição de serviço SIP.
[000136] A figura 18 apresenta um exemplo do fluxo de mensagem resultando a partir de uma requisição de Serviço de Situação do Usuário recebida a partir do circuito de interconexão de rede externo 110 (Fluxo 1802). O circuito de interconexão de rede externo 110 pode enviar a requisição de Situação para executar uma verificação de presença em tempo real de outros usuários. O corretor de serviços 116 envia uma mensagem de requisição de situação para um sistema de diretórios (Fluxo 1804) que retorna a situação do usuário (Fluxo 1806). O corretor de serviços 116 retorna a situação do usuário para o circuito de interconexão de rede externo (Fluxo 1808).
[000137] As Tabelas 32 e 33 ilustram exemplos da mensagem e resposta de requisição de serviço de Situação.
[000138] A figura 19 apresenta um exemplo do fluxo de mensagem resultando a partir de uma requisição de serviço de autenticação de Situação do Usuário Móvel recebida a partir do circuito de intercone-xão de rede externo 110 (Fluxo 1902). O circuito de interconexão de rede externo 110 pode enviar a requisição de Autenticação (incluindo as informações utilizadas para reconhecer o usuário, tais como números MSISDN e/ou IMSI) quando, por exemplo, um usuário precisar ser identificado antes de poder adquirir um serviço, tal como o serviço de Televisão por protocolo Internet (IPTV). O corretor de serviços 116 submete uma requisição pelos dados de serviço do usuário (por exemplo, características de rede para o usuário) para um sistema de diretórios (Fluxo 1904) que retorna os dados de serviço do usuário (Fluxo 1906).
[000139] O corretor de serviços 116 retorna um resultado para o circuito de interconexão de rede externo 110 (Fluxo 1908). Se a autenticação do usuário pelo sistema de diretórios não foi possível, o corretor de serviços 116 retorna uma mensagem "Não Autorizado" para o circuito de interconexão de rede externo. Senão, o corretor de serviços 116 retorna uma mensagem "Autorizado" com os dados de serviço do usuário. Quando o usuário é autorizado, o corretor de serviços 116 pode então requisitar informações adicionais sobre o usuário, na forma de uma requisição pelo perfil de serviço de aplicação do usuário (Fluxo 1910) para o sistema de diretórios, que retorna o perfil (Fluxo 1912).
[000140] O corretor de serviços 116 retorna um resultado para o circuito de interconexão de rede externo 110 (Fluxo 1914). Se a informação de serviço de aplicação não estava disponível, o corretor de serviços 116 retorna uma mensagem "Não Autorizado" para o circuito de interconexão de rede externo 110. Senão, o corretor de serviços 116 retorna uma mensagem "Autorizado" com os dados de serviço de aplicação.
[000141] As Tabelas 34 e 35 ilustram exemplos da mensagem e resposta de requisição de serviço de autenticação do usuário móvel.
[000142] A figura 20 apresenta um exemplo do fluxo de mensagem resultando a partir de uma requisição de autenticação de usuário IPTV recebida a partir do circuito de interconexão de rede externo 110 (Fluxo 2002). O circuito de interconexão de rede externo 110 pode enviar a requisição de Autenticação (incluindo as informações utilizadas para reconhecer o usuário, tais como números MSISDN e/ou IMSI, e permitir ao usuário utilizar o serviço) quando, por exemplo, um usuário tentar se conectar a uma aplicação IPTV móvel. O corretor de serviços 116 submete uma requisição pelos dados de serviço do usuário (por exemplo, características de rede para o usuário) para um sistema de diretórios (Fluxo 2004) que retorna os dados de serviço do usuário (Fluxo 2006).
[000143] O corretor de serviços 116 retorna um resultado para o circuito de interconexão de rede externo 110 (Fluxo 2008). Se a autenticação do usuário pelo sistema de diretórios não foi possível, o corretor de serviços 116 retorna uma mensagem "Não Autorizado" para o circuito de interconexão de rede externo. Senão, o corretor de serviços 116 retorna uma mensagem "Autorizado" com dados de serviço do usuário. Quando o usuário é autorizado, o corretor de serviços 116 pode então requisitar informações adicionais sobre o usuário na forma de uma requisição pelo perfil de serviço de aplicação do usuário (Fluxo 2010) para o sistema de diretórios, que retorna o perfil (Fluxo 2012). [000144] O corretor de serviços 116 retorna um resultado para o circuito de interconexão de rede externo 110 (Fluxo 2014). Se a informação de serviço de aplicação não estava disponível, o corretor de serviços 116 retorna uma mensagem "Não Autorizado" para o circuito de interconexão de rede externo 110. Senão, o corretor de serviços 116 retorna uma mensagem "Autorizado" com os dados de serviço de aplicação.
[000145] As Tabelas 36 e 37 ilustram exemplos da mensagem e resposta de requisição de serviço de autenticação de usuário IPTV.
[000146] Toda a discussão anterior, independentemente da implementação particular sendo descrita, é de natureza ilustrativa e não li-mitativa. Por exemplo, apesar dos aspectos, características ou componentes selecionados das implementações serem descritos como sendo armazenados em memórias, todos ou parte dos sistemas e métodos em consonância com o corretor de serviços podem ser armazenados, distribuídos ou lidos a partir de outros meios legíveis por máquina, por exemplo, dispositivos de armazenamento secundário tais como discos rígidos, discos flexíveis e CD-ROMs; um sinal recebido a partir de uma rede; ou outras formas de ROM ou RAM conhecidas atualmente ou posteriormente desenvolvidas.
[000147] Além disso, apesar de serem descritos componentes específicos da arquitetura do corretor de serviços, métodos, sistemas e artigos de fabricação em consonância com a arquitetura do corretor de serviços podem incluir componentes adicionais ou diferentes. Por exemplo, um processador pode ser implementado como um microprocessador, um microcontrolador, um circuito integrado para aplicação específica (ASIC), lógica separada, ou uma combinação de outros tipos de circuito ou lógica. De forma similar, bases de dados, tabelas e outras estruturas de dados podem ser armazenadas e gerenciadas separadamente, podem ser incorporadas em uma única memória ou base de dados, podem ser distribuídas, ou podem ser organizadas lógica e fisicamente de várias formas diferentes. Os programas podem ser partes de um único programa, programas separados ou distribuídos por várias memórias e processadores. Os sistemas podem ser implementados em hardware, software, ou em uma combinação de hardware e software em um sistema de processamento, ou distribuídos em vários sistemas de processamento.
[000148] A camada do corretor de serviços supera os desafios técnicos associados com o processamento de requisições de serviço externas. A distribuição das requisições de serviço em filas soluciona o desafio técnico de receber e organizar um grande número de requisições de serviço simultâneas, ou quase simultâneas. A arquitetura múltipla do mecanismo de busca e de fluxo de trabalho soluciona o desafio técnico de extrair as requisições de serviço de forma organizada e eficiente, de executar as requisições de serviço extraídas para completar com êxito o processamento requisitado, de proporcionar processamento de requisições de serviço tolerante a falhas e de maximizar a performance do processamento das requisições de serviço.
[000149] Embora tenham sido descritas várias modalidades da invenção, será aparente aos com conhecimento comum na técnica que são possíveis várias outras modalidades e implementações dentro do escopo da invenção. Por consequência, a invenção não deve ser restrita, a não ser à luz das concretizações anexas e seus equivalentes.
REIVINDICAÇÕES