UNIVERSIDADE FEDERAL DE SANTA CATARINA
MODELO DE REGISTRO DE SERVIÇOS EM REPOSITÓRIOS DISTRIBUÍDOS
ANDRÉ PASTORE GOMES DE SANTANA
FLORIANÓPOLIS, SANTA CATARINA 2009.1
UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
MODELO DE REGISTRO DE SERVIÇOS EM REPOSITÓRIOS DISTRIBUÍDOS
ANDRÉ PASTORE GOMES DE SANTANA
Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção de grau de Bacharel em Ciências da Computação
FLORIANÓPOLIS, SANTA CATARINA 2009.1
ANDRÉ PASTORE GOMES DE SANTANA
MODELO DE REGISTRO DE SERVIÇOS EM REPOSITÓRIOS DISTRIBUÍDOS
Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em ciências da Computação
Orientador: Frank Augusto Siqueira
Banca Examinadores Renato Fileto
ABSTRACT
This work presents a registration model for mobile service providers into distributed service repositories. This model offers reduction for cost and messages complexity of registry events for that agents. The model considers the transport protocol choose flexibility and the multiplicity of registration technologies. This issue is relevant nowadays due to fast advance of mobile service technologies and growing of embeded
RESUMO
Este trabalho apresenta um modelo de registro de provedores de serviços móveis em repositórios de serviços distribuídos. A implantação deste modelo propõe a redução do custo e da complexidade do evento de registro destes agentes. Além do custo, considera-se a flexibilidade quanto ao protocolo de transporte para emissão e a multiplicidade de tecnologias de registro. Este tema torna-se relevante aos dias atuais devido ao rápido avanço das tecnologias de serviços móveis e aumento de capacidade de processamento de dispositivos embarcados.
Sumário 1. Introdução ... 3 1.1. Objetivo Geral... 5 1.2. Objetivos Específicos ... 5 1.3. Estrutura do Trabalho ... 5 2. Motivação ... 1 3. Fundamentação Teórica ... 4 3.1. Sistemas Distribuídos ... 4
3.2. Arquitetura Orientada a Serviços (SOA) ... 4
3.3. Web Services ... 10
3.4. UDDI ... 13
3.5. Barramento de Serviços Corporativo ... 16
3.6. Mobilidade ... 18
3.7. Protocolo de Inicialização de Sessão (SIP) ... 21
4. Contextualização ... 28
4.1. Computação Orientada a Serviços ... 28
4.2. A próxima geração da SOA ... 29
4.3. Previsão: Mobilidade Real ... 31
4.4. Sistemas Heterogêneos ... 31
4.5. Localização de Serviços ... 32
4.6. Registro de Serviços ... 33
4.7. Registro de Presença ... 33
4.8. Repositório de Serviços ... 34
5. Registro de Serviços em Repositórios Distribuídos ... 35
5.1. Arquitetura Geral ... 35
5.2. Requisição de Registro ... 39
5.3. Estrutura do Registro ... 40
5.4. Distribuição do Registro aos Repositórios ... 41
5.5. Tratamento de Falhas Parciais ... 42
6. Implementação e Testes... 45 6.1. Preparo de Ambiente ... 45 6.1.1. Ambiente Operacional ... 45 6.1.2. Ferramentas utilizadas ... 45 6.1.3. Repositório de Registros ... 46 6.1.4. tModel ... 46
6.2. Camada de Mediação de Registro ... 47
6.2.1. Recebimento da Mensagem... 47
6.2.2. Repasse de Mensagens ... 49
6.3. Camada de Conectores de Repositório ... 51
6.4. Caso de Estudo... 51
6.4.1. Caso de Estudo: Serviço de Relatório de Distribuição utilizando FTP ... 51
7. Finalização ... 53
7.1. Conclusões ... 53
7.2. Proposta para Trabalhos Futuros... 54
1. INTRODUÇÃO
A Arquitetura Orientada a Serviços (Service Oriented Architecture, SOA) proporciona um modelo de componentes distribuídos a aplicações presentes sob contextos heterogêneos, independentes da localização dos serviços, das redes de acesso e dos protocolos de transporte utilizados. Estes serviços são identificados e localizados através de repositórios virtuais, situados em diversas redes e sob diferentes protocolos de comunicação. Isto caracteriza um modelo onde três camadas essenciais do provimento dos serviços são independentes e podem operar entre si através de modelos heterogêneos: Aplicação, Transporte e Rede (Lei & Coulton, 2008).
Neste contexto, três entidades são fundamentais na constituição de um ecossistema orientado a serviços1: Provedores de Serviços, responsáveis pelas funcionalidades de um conjunto de serviços; Consumidores, usuários dos serviços fornecidos pelos Provedores; e os Repositórios de Serviços, diretórios de registros e mediadores da localização de serviços entre Provedores e Consumidores.
O registro de Provedores e seus respectivos Serviços em um Repositório é realizado através de mecanismos inerentes a cada diretório. Além da compatibilidade dos softwares emissores com as tecnologias dos Repositórios, é necessário possuir credenciais de acesso a estes Repositórios.
Na interação entre estas duas camadas, Provedor e Repositório, ainda há uma dependência de protocolos e formatos de mensagens específicos para efetivar o registro dos dados de um serviço. Isto força a conexões bilaterais entre provedores e repositórios, exigindo múltiplas requisições de registro, cada qual contendo a complexidade da tecnologia de registro definida pelo fornecedor do repositório de serviços, porém todas com a mesma finalidade: registrar o mesmo provedor.
Além da manutenção das mensagens de registro, a mobilidade dos agentes provedores pode acarretar no aumento de emissões de mensagens de registro, ou seja, aumento no tráfego de rede, devido à atualização recorrente de registros.
A complexidade na comunicação entre estas duas camadas pode ser reduzida e padronizada através do uso de uma camada intermediária, definida por um canal de registro
1 Neste trabalho, Ecossistema Orientado a Serviços corresponde a uma coleção de serviços relacionados. Esta coleção, em geral, provê um conjunto de funcionalidades definidas em um mesmo domínio (Apte & Mehta, 2003)
independente de protocolo de comunicação, com o objetivo de simplificar a livre comunicação de um Provedor de Serviço com múltiplos Repositórios de Registros.
Este trabalho apresenta um modelo de registro de Provedores de Serviços em múltiplos Repositórios de Serviços simplificado e unificado. A simplicidade é justificada através da flexibilidade de extensão a múltiplos protocolos de comunicação e tecnologias de repositório, sem a necessidade de mudanças estruturais para o tratamento de compatibilidade entre emissores e a plataforma proposta.
Como validação do modelo proposto, uma implementação básica de registro será apresentada ao final, exemplificando a estrutura de registro, a independência de tecnologias de transporte e formatos de aplicação.
Aspectos inerentes à consistência das informações de registros nos repositórios, tratamento de falhas nas requisições entre Consumidores e Repositório, dentre outros problemas externos ao modelo de registro, não serão especificadas neste trabalho. A interação entre os provedores e repositórios será tratada sob o fluxo normal de funcionamento. No entanto, falhas parciais de provedores de serviços serão consideradas e introduzidas, porém nenhuma técnica de manutenção de falhas será detalhada no contexto geral.
1.1. Objetivo Geral
O objetivo geral do trabalho consiste na proposta de um modelo de registro de Provedores de Serviços, móveis ou não, em Repositórios de Registro, que opere na camada de aplicação e seja independente de protocolo de comunicação e tecnologia de implementação do repositório.
Em geral, a proposta de registro corresponde à manutenção da associação da identidade e da localidade do agente Provedor de Serviços.
1.2. Objetivos Específicos
O presente trabalho visa ainda
Apresentar um modelo de registro de presença de provedores de serviços móveis;
Propor uma arquitetura de registros independente de protocolo de Aplicação, Transporte e Repositório de Registros utilizados;
1.3. Estrutura do Trabalho
No capítulo de Fundamentação Teórica, serão apresentadas as ferramentas conceituais e tecnológicas utilizadas para a elaboração do trabalho. O conjunto apresentado é composto por especificações, modelos de sistemas e artefatos técnicos e teóricos.
Utilizando-se dos dispositivos da primeira parte do trabalho, o capítulo Contextualização apresenta a aplicação destes mecanismos conceituais de integração de sistemas ao contexto da arquitetura apresentada no capítulo seguinte, sobre a arquitetura de registro de Agentes de Serviço.
Apoiado nos conceitos do capítulo anterior, o capítulo Registro de Serviços contém a arquitetura geral do modelo de registro proposto, o formato da mensagem de registro e sua respectiva transformação ao Repositório de Serviços Destinatário.
No capítulo de Implementação e Testes, será apresentada uma implementação utilizando o Protocolo de Inicialização de Sessão e um Repositório de Registros de propósito geral, sob o modelo de Barramento de Serviços Corporativo, seguida de dois exemplos de aplicação da arquitetura proposta.
Finalizando, serão apresentadas as conclusões do trabalho e as perspectivas de sua
1
2. MOTIVAÇÃO
Ao analisar o modelo da Arquitetura Orientada a Serviços como um modelo de Sistema Distribuído, considera-se cada objeto definido no contexto como um serviço. A localização deste objeto não é decisiva para o funcionamento global do sistema, no entanto, para ser descoberto e consumido, informações de identificação, localidade e interfaces de interação devem ser registradas em algum ponto do ecossistema de serviços, tornando este serviço disponível e acessível sempre que necessário.
Normalmente, interações negócio-a-negócio (B2B2) são realizadas em um processo colaborativo entre duas partes engajadas em uma parceria bilateral composta pelo Provedor de Serviços e pelo Consumidor de Serviços. Um Repositório de Registros é um terceiro participante, neutro, facilitador da comunicação entre as primeiras entidades, basicamente com a finalidade de manutenção do registro e da localização de serviços. Um ecossistema SOA pode possuir diversos Repositórios de Registros disponíveis para facilitar a publicação, descoberta e o consumo de serviços (Sun Microsystems Inc., 2002).
Normalmente, o formato de mensagens e o método de registro de Serviços dependem da tecnologia utilizada como repositório destes registros. Atualmente, existem diversas especificações de mediadores de serviços. Entre elas, pode-se destacar a OASIS eCo Framework, ebXML, UDDI e JAXR. Embora haja similaridades nos aspectos funcionais destes modelos, eles são definidos por especificações distintas.
Quando um Provedor de Serviço necessita registrar-se em um Repositório de Serviços, este deve gerar uma chamada ao Serviço de Registro deste repositório, utilizando um formato de mensagens específicas definidas pelo repositório de registros destino. Isto pode ser simples em casos onde há apenas um ou dois repositórios disponíveis, e um administrador dedicado a realizar a atividade de atualização de registros. Porém, a complexidade de gestão deste ambiente sofre um crescimento exponencial, devido ao aumento da freqüência de mudanças e da quantidade de Repositórios de Serviços destinatários destas informações.
Basicamente, registros em um repositório compreendem dados de taxonomia auxiliares à descoberta do Provedor de Serviços no Repositório de Serviços, informações sobre a corporação detentora do serviço e, principalmente, o método de interação com a
2
2 instância remota. O método de interação envolve dados referentes à camada de rede e transporte de dados, endereçamento, credenciais e protocolo de acesso.
A mudança de informações sobre um serviço possui menor ou maior freqüência devido à natureza do conteúdo atualizado. A mudança no nome da entidade detentora dos direitos do serviço, por exemplo, ocorre em menor freqüência. Por outro lado, o endereçamento de serviços possui maior volatilidade, principalmente se considerarmos um ambiente de agentes móveis, o que ocasiona mudanças assíncronas de na associação de identidade e localização dos objetos.
O tratamento de mudanças menos freqüentes, principalmente em ambientes de variáveis pouco voláteis, não são críticos. No entanto, em mudanças freqüentes no registro de serviços, a manipulação estática pode ser um empecilho à viabilidade da tecnologia de provimento conforme a complexidade da aplicação aumenta, devido ao esforço e ao tempo gasto para o registro manual da modificação. Dois casos típicos para mudanças freqüentes são: mudança de endereço de localização em um ambiente com suporte a mobilidade contínua, onde a atualização de registros é necessária a cada mudança na rede de acesso onde o Agente Móvel está inserido; registro de uma Unidade de Serviço em múltiplos Repositórios de Registro, conforme será apresentado ao final do trabalho, durante o estudo de casos.
O processo de configuração de um registro é equivalente tanto em um processo estático, onde é necessária a atuação de um administrador, quanto por processos dinâmicos, onde a interação entre Provedor de Serviço e Repositório de Registros é automatizada. Para realizar o registro de um serviço, deve-se inicialmente conhecer e possuir acesso a um repositório de registros.
Quando configurado manualmente, a tarefa é executada por um administrador de integração de serviços. No contexto de aplicações móveis, onde os agentes Provedores de Serviço podem localizar-se em qualquer rede de acesso, a qualquer instante, a manutenção de identidade e localidade dos agentes é constante. O conhecimento das informações sobre a interação entre Agente Consumidor e Provedor são requisitos essenciais para a instalação, descoberta e continuidade da entrega do serviço. Claramente, o modelo de manutenção manual é inadequado nestes ambientes de mobilidade contínua.
No entanto, o registro de serviços pode ser automatizado através de artefatos dedicados ao acesso e manipulação de registros em repositórios utilizando-se, geralmente, linguagens de programação de propósito geral. Desta forma, um Provedor de Serviços pode
3 realizar a manutenção de seus registros sem a interferência do administrador dos registros no Repositório. Da mesma forma, consumidores de serviços podem automatizar seus acessos ao repositório para descobrirem Provedores e obterem informações mais detalhadas sobre os métodos de acesso aos serviços publicados.
Porém, um novo conceito tem-se desenvolvido no contexto de computação distribuída, onde os agentes participantes de uma comunicação estão em constante mobilidade, atualizando suas localizações em tempo de execução e em tempo real, mantendo a continuidade do consumo e provimento de serviços.
Devido ao recorrente problema de vínculo de identidade e localidade, novamente pode-se recair sobre problemas associados a aplicações desta natureza. Neste trabalho, será proposto um modelo de registro de serviços em repositórios distribuidos, buscando-se métodos simplificados para o tratamento do processo de handoff. Handoff3 é o nome dado ao evento de troca de rede de acesso de um agente, seja este agente móvel ou fixo.
O objetivo geral deste trabalho é apresentar um modelo de registro de serviços em repositórios distribuídos, considerando a manutenção endereçamento do Agente Provedor de Serviço e a multiplicidade de tecnologias de Repositórios de Serviços disponíveis.
3
4
3. FUNDAMENTAÇÃO TEÓRICA
3.1. Sistemas Distribuídos
Um sistema distribuído consiste de um conjunto de agentes de software discretos que trabalham juntos para atingir funcionalidades desejadas. No entanto, agentes em um sistema distribuído não operam no mesmo ambiente de processamento, mas devem comunicar-se entre si através de hardware ou software, utilizando algum protocolo de compreensão mútua. Comparados à execução de invocações entre dois processos com memória e processamento sob um mesmo ambiente operacional, em sistemas distribuídos o protocolo e o meio de comunicação são menos confiáveis e performáticos. Isto implica diretamente na arquitetura, pois requer de desenvolvedores e analistas a consideração da latência imprevisível do acesso remoto, além das questões de concorrência e tratamento de possíveis falhas fatais à execução da aplicação (Waldo, Wyant, Wollrath, & Kendall, 1994).
3.2. Arquitetura Orientada a Serviços (SOA)
Ao modelar uma aplicação seguindo a proposta da Arquitetura Orientada a Serviços, aplica-se um padrão de interoperação entre diferentes aplicações de software, executados em diferentes ambientes operacionais, independentes entre si, tanto da plataforma de execução, quanto de frameworks utilizados em sua implementação.
O modelo de sistema distribuído proposto por esta arquitetura suporta a interação de objetos distribuídos sob ambientes operacionais utilizando diferentes padrões e tecnologias de comunicação. SOA promove a interoperabilidade de serviços através da declaração de funcionalidades, protocolos de comunicação, tipos de entidades e dados, além de outros critérios, durante a exposição do Serviço no ecossistema.
A arquitetura não foca na forma como os serviços são implementados e também não impõe nenhuma restrição de como os serviços serão combinados. Desta forma, não são definidos aspectos específicos da modelagem de interação entre serviços, mas apenas um conjunto de mensagens e formatos de dados que serão consumidos por muitos, porém não todos, agentes consumidores.
Anteriormente ao amadurecimento da especificação da Arquitetura de Serviços, fato ocorrido na última década, produtos de integração de sistemas heterogêneos estavam restritos a soluções limitadas e customizadas. Tais soluções eram produzidas por grandes fornecedores
5 de software e responsáveis pelo efeito “vendor lock-in”4
, ou então produzidas in house5, normalmente sem aplicação em ambientes computacionais de outras corporações, ou até mesmo em diferentes unidades de uma mesma corporação, devido a arquiteturas distintas de suas aplicações. Estas soluções, embora customizáveis, produziam aplicações definidas a contextos específicos, sem relação com contextos genéricos, proporcionando apenas uma integração parcial de sistemas legados.
A concepção da Arquitetura Orientada a Serviços promoveu uma saudável mistura de interoperabilidade e inovação à integração de sistemas heterogêneos. Desta forma, uma implantação deste modelo deve suportar a manipulação de diversos documentos de regras de negócio, focando na interatividade entre as partes envolvidas no sistema.
Essencialmente, os principais componentes da Arquitetura Orientada a Serviços envolvem as mensagens trocadas entre entidades, agentes atuando como provedores e consumidores, repositórios de informações sobre serviços e mecanismos de transporte que permitem o fluxo de mensagens.
Segundo a W3C6, uma arquitetura SOA deve possuir as seguintes características básicas (Booth, et al., 2003):
Interoperabilidade
Extensibilidade
Segurança
Integração Web
Implantação e Gerenciamento
1. SOA como um modelo de sistemas distribuídos
Por definição, SOA é um tipo de sistema distribuído onde os agentes e objetos distribuídos são serviços com operações bem definidas e expostas a aplicações externas ao seu ambiente operacional. A exposição destes objetos a outras aplicações é formalizada através de um Contrato de Serviços, onde são definidos formatos de mensagens e assinatura de operações. Desta forma, promove-se um baixo acoplamento entre entidades heterogêneas, pois as mensagens seguem padrões abertos, portáveis e com baixa complexidade de
4
Tornar um consumidor dependente por produtos e serviços de um vendedor, incapaz de mudar de fornecedor sem substanciais custos para a migração. (Arthur, 1989)
5 Processo de desenvolvimento de software com o objetivo de desenvolver software com propósitos internos de uma corporação (Derniame, Kaba, & Wastell, 1999)
6
6 processamento. Através do Contrato bem definido, promove-se também a coesão das responsabilidades de cada provedor.
2. Serviço
Um Serviço é um entidade abstrata criada para tratar alguma tarefa técnica ou alguma regra de negócios.
No contexto da SOA, um Serviço pode ser definido por tecnicamente ou ontologicamente.
Segundo a definição técnica do W3C para Web Services (Booth, et al., 2003), determina-se um Serviço o sistema de software projetado para suportar interoperabilidade interativa máquina-a-máquina através de alguma camada de transporte de dados.
Ontologicamente, sob uma descrição geral, um serviço é algo que origina, em determinado momento, um conjunto de objetivos que serão ou não atingidos. Um serviço é uma entidade existente por alguma razão, durável por determinado período de tempo, além de poder ou não sair do ambiente operacional devido a diversas circunstâncias. Em SOA, um serviço é um dispositivo de software incorporado criado com o propósito de resolver um problema técnico ou de negócios, mas também é uma peça de software que pode coexistir com diversos outros artefatos de software (Bell, 2008).
Ainda segundo Booth (Booth, et al., 2003), duas características fundamentam os papéis encapsulados por um Serviço:
A implementação de um serviço representa um agente concreto. Um Agente7 é um objeto que envia e recebe mensagens, enquanto o Serviço é o conjunto abstrato de funcionalidades que este provê. Por esta definição, pode-se implementar diversos agentes de forma distinta, e substituir um agente por outro, sem que as funcionalidades que estes provêem sejam modificadas. Da mesma forma, pode-se modificar a estrutura interna de um serviço, sem que suas responsabilidades públicas, ou seja, a maneira como os Agentes Consumidores o acessam, sejam modificadas8. Pode-se considerar os Agentes e a estrutura interna como requisitos não-funcionais e a descrição do Serviço como requisito funcional do componente.
7 Por definição, também denominado Agente de Serviço 8
7
O propósito de um serviço é fornecer um conjunto de funcionalidades em nome de seu dono. A entidade fornecedora do Serviço é denominada Provedora9. A entidade Provedora é responsável por fornecer um determinado Agente de Serviço para expor aos consumidores um serviço em particular.
3. Provedor de Serviços
Um Provedor de Serviço é uma entidade endereçável responsável pela execução das funcionalidades definidas por um Contrato de Serviço.
Um Provedor de Serviço fornece as funcionalidades de interação com um determinado serviço. Normalmente, um provedor de serviços atende a grande parte das necessidades de seus consumidores. Devido ao encapsulamento proporcionado pela arquitetura, um Provedor de Serviço não necessita conhecer as funcionalidades específicas ou o ambiente operacional de cada Consumidor.
Outra funcionalidade de um Provedor é a divulgação de Contratos nos Repositórios de Serviços de um ecossistema.
4. Distribuidor de Serviços
Como citado, um Provedor de Serviços não deve possuir nenhuma dependência explícita com o ambiente operacional de seus consumidores. No entanto, um Distribuidor de Serviços é bastante sensível ao ambiente operacional, pois seu objetivo é fornecer a base ideal de gerenciamento, provimento e consumo de serviços a todas as entidades relacionadas ao ecossistema operacional.
A função de um Distribuidor de Serviços é a de operar com os Provedores a fim de publicar seus Serviços, fornecendo um ambiente de execução adequado.
A separação clara e objetiva entre o Provedor e o Distribuidor de serviços garante o melhor modelo de divisão de competências entre estas duas entidades. Um Provedor de Serviços deve considerar a funcionalidade da lógica de negócios, independente de consumidores e plataformas de execução. Contrário a esta flexibilidade e portabilidade, um Distribuidor de Serviços deve ser adequado a um ambiente operacional específico, comportando e isolando a instalação de diversos Provedores.
9
8
5. Consumidor de Serviços
O Consumidor de Serviços é uma entidade que deseja utilizar as funcionalidades fornecidas pelos Serviços de Provedores de Serviços através dos Agentes de Serviço, a fim de satisfazer suas necessidades operacionais. Em um ecossistema de serviços, há diversos serviços disponíveis para atender a um Consumidor. A interação para o consumo deve ser simples e atender às requisições de qualidade de serviço necessárias.
O processo de consumo de um serviço inicia-se com a troca de mensagens entre o Agente Provedor e o Agente Consumidor, de forma a ambas concordarem com os critérios sintáticos, semânticos e dos mecanismos de troca de mensagens para efetivar a comunicação.
No contexto da Arquitetura Orientada a Serviços, uma Entidade é uma pessoa ou organização participante de uma transação de provimento ou consumo de Serviços (Booth, et al., 2003).
6. Contrato de Serviço
A exposição de um Serviço em um ecossistema SOA é definida através de um Contrato de Serviços. Este artefato descreve os mecanismos de troca de mensagens definidos pelos Provedores para um determinado Serviço, estabelecendo a interface compartilhada com os consumidores. Sob a ótica de sistemas distribuídos, estes mecanismos seguem uma especificação passível de processamento máquina-a-máquina, sem a interferência humana.
Um Contrato é uma entidade conceitual abstrata. Esta entidade prescreve aos projetistas de serviços a definirem uma especificação de interface de serviço formal, precisa e verificável, baseado em entidades abstratas e com a metáfora conceitual de um contrato de negócios (Meyer, 1992).
Como forma de materialização, um Contrato é implementado através de um Descritor do Serviço. Um mesmo contrato pode ser implementado por diversos Descritores do Serviço, mantendo seus aspectos funcionais equivalentes e compatíveis com sua referência abstrata, diferenciando-se apenas na camada não-funcional do serviço, como protocolo de transporte e formato de entrega do serviço, por exemplo. Além dos dados de transporte e entrega do serviço, um Descritor do Serviço contém um ou mais endereços de acesso10 para que os provedores possam ser invocados por respectivos consumidores, além de poderem apresentar outras informações sobre os padrões de trocas de mensagens suportados e esperados.
10
9 Pode-se definir, então, um Descritor de Serviço como um representante do contrato que governa a interação com um serviço em particular, enquanto o Contrato de Serviço é uma entidade abstrata e semântica para determinação do propósito desta interação.
Um Contrato, na visão de um Consumidor do Serviço descrito, pode ser dividido em duas seções: Funcional e Não-Funcional.
A seção funcional engloba a especificação semântica das mensagens trocadas entre o Provedor e o Consumidor. Basicamente, estes aspectos semânticos consideram os propósitos e conseqüências da interação, ambos definidos pelo modelo funcional do serviço.
Na seção não-funcional do descritor, são considerados os detalhes adicionais ao modelo semântico, incluindo os mecanismos de troca de mensagens inderentes ao Provedor ou Distribuidor de Serviço, como critérios de transporte de dados, protocolo de comunicação, dentre outros aspectos.
7. Gerenciamento de Contratos
Embora o propósito de SOA seja melhorar e, quando possível, automatizar processos de integração, é fundamental a participação de humanos representando papel na concepção, gerenciamento e implantação de uma arquitetura orientada a serviços.
A participação se dá em duas fases distintas. Na primeira, são necessárias concordâncias entre ambas as partes envolvidas na troca de mensagens, tanto na análise semântica, quanto no Descritor de Serviço. Certamente, a exposição de funcionalidades semânticas e descritivas do serviço obriga aos consumidores a seguirem o Contrato de Serviço proposto, sem modificar as condições de uso e comunicação. Nada impede, porém, que haja concordâncias e adaptações específicas entre Consumidor e Provedor realizados por meio de outros mecanismos de mediação, como um Barramento de Serviços ou outros padrões de integração.
8. Implementação de Contratos
A Arquitetura Orientada a Serviços propõe a independência de implementação dos serviços em relação ao Contrato que se segue. A fim de facilitar o alinhamento de esforços entre Provedores de Serviços e Consumidores, há duas metodologias de desenvolvimento de Descritores de Serviços e seus respectivos Agentes provedores, denominadas Top-Down e
10 existir antes da construção do serviço. Ao contrário, o método Bottom-Up inicia-se quando o serviço já existente e os Contratos de sua exposição são então estabelecidos (Bell, 2008).
9. Compartilhamento de Contratos
Independente da estratégia adotada, em algum momento o contrato e o descritor do serviço devem ser compartilhados entre as entidades interessadas no Serviço. Esta etapa deve ocorrer antes do início do provimento e consumo do Serviço.
3.3. Web Services
Web Service constitui uma classe específica de implementação de serviços. Esta classe de provedores de serviços são altamente interoperáveis, pois baseiam-se em protocolos simplificados e bem estabelecidos, como HTTP, SOAP, REST, XML-RPC, dentre outros. Conforme escrito anteriormente, um Agente de Serviço é uma realização de um Serviço. Portanto, pode-se considerar um Web Service como um Agente de Serviço.
Agente implementados como Web Services estão distribuídos em redes de computadores e são implementados através de um framework de descrição e exposição de suas funcionalidades. A exposição de serviços favorece a potencial integração dos serviços publicados com outros objetos distribuídos em um contexto SOA, sejam Web Services ou outros artefatos.
Comparados a outros componentes de uma aplicação, Serviços sob SOA podem ser construídos, instalados e desinstalados em tempo de execução. Seguindo esta premissa, a tecnologia de Web Services opera de forma que a instalação, falha ou remoção de um Web Service não afeta outros componentes inseridos na mesma arquitetura de maneira global, mas podem influenciar parcialmente em determinadas funcionalidades do sistema.
10. Endereçamento de Web Services
Cada instância do serviço é endereçada individualmente no sistema. Isto permite aos Consumidores alcançarem o Web Service publicado. O endereçamento de um Web Service ou de um componente são resultados de uma decomposição funcional (Apte & Mehta, 2003) bem definida, desvinculada da identificação do serviço. Isto auxilia na mudança de endereço em tempo de execução de um serviço. Porém, é necessária a constante atualização das informações de localização por parte do cliente, caso contrário, um serviço pode tornar-se inalcançável por seus consumidores já existentes.
11 Segundo (Berners-Lee, 1998), um endereço de um artefato publicado na World Wide
Web (WWW) não deve mudar. O modelo da Internet não é adequado para mudanças no
endereçamento, pois não se conhece os clientes de um serviço, nem a forma como os endereços são armazenados. Portanto, há estratégias adequadas para modelar um endereço público, de forma a evitar ou reduzir inconsistências durante a pesquisa de serviços. No entanto, devido à alta volatilidade das informações sobre um determinado objeto distribuído, este trabalho busca fornecer um mecanismo de registro flexível para entidades com esta característica.
11. Estrutura Geral de um Web Service
Embora a Arquitetura Orientada a Serviços e Web Services possuam estrutura conceitual de fácil compreensão e baixa complexidade de processamento, há uma vasta teoria por trás da elaboração da especificação de Web Services. A necessidade de conhecimentos aprofundados sobre a tecnologia torna-se visível em projetos de proporções maiores, de forma que um sistema heterogêneo e integrado de serviços não seja simples. Portanto, é necessário entender a estrutura geral de um Web Service, com o intuito de elaborar sistemas bem definidos e evitar armadilhas em tempo de operação de um sistema. A operação de um Web
Service é definida sob as seguintes características:
Descrição: Um Web Service é descrito utilizando-se uma taxonomia padrão
(nomenclatura). A taxonomia anexa significados especiais aos termos utilizados na descrição do serviço. A descrição também consiste no significado das operações do serviço e os mecanismos de operação.
Descoberta: A descrição padronizada de uma classe de Serviços pode ser utilizada
para descobrir um serviço específico para esta classe. Classificação baseada em taxonomia auxilia na filtragem de serviços que não possuem o mesmo significado dos termos utilizados na interação.
Interoperabilidade: Descrições padronizadas e mecanismos de descoberta tornam a
interoperabilidade mais simples e fácil para que os consumidores destes serviços reconstruam uma interface de serviço de acordo com suas implementações finais. Esta interface será utilizada durante o consumo do serviço. Os clientes podem escrever a comunicação com os Web Services em qualquer linguagem.
Composição: Web Services podem ser combinados para criar Web Services em alto
12 como a modularização, mais fáceis e o ajuste de serviços a uma descrição específica podem tornar-se parte de um Web Service em alto nível.
12. SOAP
O principal protocolo de comunicação utilizado em mecanismos de troca de mensagens em um ambiente operacional de Web Services é o SOAP11. Estruturalmente, SOAP é um documento XML trafegado sobre HTTP, com a finalidade de trocar mensagens entre componentes distribuídos em plataformas heterogêneas e independentes entre si.
A maior vantagem de utilizar um protocolo leve como este é a flexibilidade de construir Agentes de Serviço independentes da linguagem de propósito geral utilizada, como Java ou Haskell, e comunicá-los com outros serviços operando sob outra arquitetura, desenvolvida em outra linguagem de programação, como .NET ou C++, por exemplo. Para efetuar a interação entre estes componentes heterogêneos, tanto Consumidor e Provedor, necessitam de um agente que implemente HTTP, atualmente bastante popular em plataformas computacionais, desde grandes servidores, estações de trabalho e celulares até sistemas embarcados, como televisores e tocadores de música digital. Utilizando-se XML sobre HTTP, aproveita-se um conjunto de tecnologias já existentes e consolidadas, permitindo a comunicação padronizada de entidades heterogêneas distribuídas.
SOAP é um protocolo leve, desenhado com o intuito de trocar informações estruturadas em um ambiente computacional descentralizado e distribuído. O uso de tecnologias XML favorece a operação entre diversas aplicações através da definição dos mecanismos de construção de mensagens que serão transportadas independentes de protocolos. O protocolo foi projetado de modo a ser independente de qualquer modelo de programação e de outras especificações semânticas (Martin, et al., 2007). Estas características da troca de mensagens justificam a consolidação de SOAP aplicado ao paradigma de Orientação a Serviços: interoperabilidade e compatibilidade com os mecanismos de redes existentes através de um conjunto de padrões e protocolos simplificados.
13. Pilha de Serviços
O paradigma de Web Services consiste de componentes que visam facilitar todos os estágios de criação e uso de um serviço.
11 Originalmente, o acrônimo para Simple Object Access Protocol, porém não mais utilizado a partir da versão 1.2 de sua especificação (Martin, et al., 2007)
13 A descrição do serviço define as capacidades de um serviço para comunicar suas operações, como invocá-lo e onde sua localização. A Linguagem de Descrição para Web
Services (WSDL12), suporta as capacidades de um serviço no paradigma de Web Services. Um arquivo WSDL é baseado em uma gramática XML e é utilizado para descrever os serviços que uma entidade oferece, além de prover um meio eletrônico de acesso a entidades interessadas em seu consumo.
Um WSDL descreve quatro partes fundamentais de um Web Service:
Informações da Interface que descreve os métodos públicos do serviço;
Tipos de dados para todas as mensagens de requisição e resposta;
Dados sobre o protocolo de transporte/aplicação utilizado;
Localização e Endereçamento de um serviço no formato de uma URL
14. Repositório de Serviços
Um Repositório de Serviços é uma entidade lógica responsável por armazenar informações e localizar participantes ou membros de um ecossistema de serviços. O número de entidades de um ecossistema de serviços pode ser bastante extenso. O valor agregado de um repositório destes serviços é proporcional à sua quantidade e qualidade de registros. Nestes registros, encontram-se informações específicas sobre cada serviço localizado por este repositório. A robustez de um Repositório está na sua capacidade efetiva de seus mecanismos de descoberta de serviços.
A importância de um Repositório de Serviços é amplamente aceita pela indústria de software, tanto que muitas especificações relacionadas ao tema estão disponíveis, dentre elas, UDDI, JAXR, ebXML e Barramento de Serviços, conforme descrito no decorrer por este trabalho.
3.4. UDDI
O protocolo de Descrição, Descoberta e Integração Universal (UDDI13) é um elemento central no grupo de padrões relacionados a ecossistemas de Web Services. A especificação UDDI define um método padrão de publicação e descoberta de componentes distribuídos da Arquitetura Orientada a Serviços (OASIS, 2004). Basicamente, um registro UDDI provê
12 Web Service Description Language 13
14 mecanismos de divulgação, localização e gerenciamento serviços de software baseados em padrões da indústria.
Atualmente, o desenvolvimento da especificação é liderado pelo consórcio OASIS, constituído por diversas empresas provedoras e consumidoras de serviços distribuídos. A versão mais recente da especificação é a 3.0. No entanto, poucas implementações são inteiramente compatíveis com esta última.
Esta especificação é amplamente utilizada para a publicação de Web Services, e sua abordagem de registro de serviços ainda é bastante importante para o funcionamento de diversas aplicações corporativas existentes.
15. Propósito Geral
A configuração de interação entre Consumidores e Provedores de Serviços pode ser realizada por cada consumidor. Em geral, esta configuração consiste no mesmo formato para diversos consumidores. Evitando uma replicação e inconsistências devido à volatilidade no endereçamento de alguns Agentes de Serviços, pode-se abstrair esta entidade de registro e transformá-la em uma entidade intermediária para a descoberta de serviços em um ecossistema. Desta forma, ao invés de forçar uma aplicação a inserir o mapeamento de serviços através de um modelo próprio de registro e baseado em um modelo ponto-a-ponto de comunicação, o registro UDDI provê o mapeamento dinâmico de informações em tempo de execução.
Alguns dos benefícios desta concepção são:
Transparência e a distinção entre a localidade do serviço e sua respectiva identificação;
Manutenção dinâmica de informações técnicas de interação do serviço, como mudança nas operações e mensagens trafegadas.
Um registro UDDI, além de fornecer os mecanismos de transparência de localização simplificada a serviços distribuídos, provê também um framework avançado de definição e requisição de funcionalidades através da taxonomia definida na descrição do serviço. O benefício essencial de um registro UDDI é o suporte à manutenção de ambientes ad hoc, caóticos e não-seriais de interações não-escalonáveis (OASIS, 2004).
Dentre suas principais responsabilidades, temos:
Encapsulamento de funcionalidades (Meyer, 1992) de gramáticas comuns;
15
Flexibilidade na pesquisa e localização de Serviços.
Representando o papel de Mediador, situado ao centro de um ecossistema de serviços, a UDDI incorpora um diretório de metadados sobre objetos distribuídos, facilitando a comunicação entre Consumidores e Produtores de Serviços.
O projeto de um repositório UDDI está baseado em padrões e especificações abertos como fundamentos para as atividades de um ecossistema de serviços de diversas naturezas. Suas principais funcionalidades centram nos seguintes pontos:
Descrição de Serviços;
Descoberta de negócios e serviços;
Incorporação de serviços através de Web Services ou outros agentes;
Criação e entrega de um registro baseado em XML.
Neste contexto, há uma conexão direta com o modelo proposto pela SOA com o ciclo de vida de Provedores, Mediadores e Consumidores de Serviços.
O modelo UDDI promove o estabelecimento de relacionamentos muitos-para-muitos entre diferentes entidades de negócios, provê flexibilidade de manutenção de entidades no repositório para adicionar e remover membros rápida e facilmente, provê uma interface simples, além de possibilitar a visão de aplicações complexas apenas como serviços simples. Novamente, conceitos de modelagem OO14, como o encapsulamento, a alta coesão e o baixo acoplamento são representados por este artefato orientado a serviços. Isto permite a corporações efetivaram o modelo B2B e negócio-a-consumidor (B2C15), através de construções padronizadas, modulares e extensíveis de componentes distribuídos em ecossistemas de serviços.
16. Aplicações Típicas de um Registro UDDI
O propósito funcional de um registro UDDI é organizar a representação de dados e metadados sobre serviços distribuídos. Um Repositório de Serviços UDDI oferece um mecanismo padronizado de classificação, catalogação e gerenciamento de diversas naturezas de serviços, tanto para serem descobertos quanto consumidos por outras aplicações.
Dentre os benefícios do uso de um registro UDDI na estratégia de gerenciamento de sistemas distribuídos, tanto em tempo de projeto quanto execução, está a reutilização de código e a promoção do gerenciamento de infra-estrutura.
14 Orientada a Objetos 15
16 Dos papéis desempenhados pela estrutura lógica de um UDDI, a especificação fornecida (OASIS, 2004) considera as seguintes:
Publicação de informação sobre Web Services e regras de categorização específicas para uma dada corporação;
Busca por Serviços que correspondam a um conjunto de critérios de pesquisa;
Determinação dos parâmetros de segurança e protocolos de transporte suportados no ambiente operacional de um serviço;
Definição de operação das funcionalidades de serviços;
Mecanismos de isolamento de aplicações frente a falhas parciais ou mudanças dos serviços utilizados.
17. Conceitos Fundamentais da Especificação UDDI
UDDI descreve um repositório e interfaces públicas para publicação, recuperação e gerenciamento de informações sobre serviços e suas descrições. Fundamentalmente, UDDI é representado por um conjunto de Web Services (OASIS, 2004).
A especificação UDDI, desenvolvida e suportada pelo consórcio OASIS, fornece os seguintes serviços:
Serviços de Descrição e Descoberta de negócios, corporações e outros provedores de Serviços;
Catálogo de Serviços publicados e disponíveis;
Interfaces disponíveis para acessar, consumir e gerenciar estes serviços;
Todas as operações suportadas por um UDDI são baseadas em padrões estabelecidos pela indústria de software, incluindo HTTP, XML, XML Schema (XSD), SOAP e WSDL.
3.5. Barramento de Serviços Corporativo
16Nos últimos anos, pode-se observar o surgimento de tecnologias de integração como a Arquitetura Orientada a Serviços (SOA), Integração de Aplicações Corporativas (EAI), estruturas B2B e Web Services. Estas tecnologias promoveram mudanças positivas nos resultados e proporcionaram o valor agregado a soluções de integração de processos de negócio. Este cenário positivo conseguiu obter a atenção de especialistas em TI, analistas de diversas indústrias e vendedores. Neste contexto, o modelo de Barramento de Serviços (ESB), surge como um caminho de interligação destas tecnologias.
16
17 O conceito de Barramento de Serviços é uma moderna concepção de integração que promove a base para o baixo acoplamento, uma rede de alta integração distribuída além do modelo hub-and-spoke da EAI17 (Chappell, 2004).
Em um modelo hub-and-spoke, o gerenciador de componentes do sistema distribuído EAI fica ao centro de todos os serviços, representado um hub. Conectado a este hub, estão os serviços, acessíveis através dos denominados spokes. Para que dois spokes se comuniquem, o Consumidor deve conhecer o endereçamento ao Provedor, porém a mensagem deve passar pelo hub, inicialmente, para que o endereçamento seja realizado. Claramente, este modelo apresenta desvantagens, pois os Provedores devem ser conhecidos, o que gera um catálogo distribuído sobre cada nova filial, necessitando de contínua manutenção entre os identificadores de nodos existentes no ecossistema.
Um Barramento de Serviços (ESB) é um tópico ainda em amadurecimento no contexto da Tecnologia da Informação. Algumas vezes, este é definido como um padrão arquitetural, o qual descreve um modo construtivo e flexível de modelar aplicações distribuídas. O ESB pode ser tratado como uma forma livre de implementar a integração de diversos contextos de processamento computacionais, sem implicações e dependências entre provedores de serviços heterogêneos, além de considerar a manutenção do direcionamento, transformação, segurança e orquestração de serviços. A heterogeneidade corresponde às diferentes implementações, aos domínios computacionais distintos
Outra perspectiva de ESB é a sua importante participação como componente da Arquitetura Orientada a Serviços (SOA). Pela perspectiva SOA, um Barramento de Serviços opera como uma plataforma de integração de soluções de TI, inclusive aplicações já existentes, de forma a expô-los como serviços. Embora especificações e estratégias de modelagem para SOA e ESB considerarem padrões abertos de comunicação, sistemas proprietários podem ser inseridos neste contexto através destes mesmos padrões abertos utilizando-se tecnologias modernas como Web Services e Serviços de Mensagens, dentre outras.
Diversas implementações de ESB existentes são baseadas no modelo de Integração de Aplicações Corporativas (EAI). Por esta razão, a mistura de conceitos dificulta uma explicação sucinta da diferença entre ferramentas EAI e ESB.
17
18 No entanto, identifica-se duas grandes diferenças entre estes dois conceitos. Em contextos EAI, a topologia mais comum é a hub-and-spoke. Já em um ambiente ESB, a topologia é baseada em barramento de serviços. O modelo hub-and-spoke é de arquitetura centralizada, onde toda a troca de dados é processada por um hub. Este modelo é considerado como um sucessor do modelo de conexão ponto-a-ponto (Dirksen & Rademakers, 2008). Por outro lado, o modelo de barramento utiliza arquitetura distribuída, onde a funcionalidade do ESB pode ser implementada por funções fisicamente separadas, considerando-se cada funcionalidade como um serviço coeso e distinto, conectado ao barramento central.
A segunda diferença principal entre EAI e ESB é o uso de padrões abertos de integração por parte de ESB. Há diversos produtos de EAI existentes no mercado utilizando tecnologias proprietárias, como Websphere Message Broker, da IBM, TIBCO BusinessWorks e Sonic XQ. Neste conjunto, as tecnologias utilizadas para troca de mensagens e lógica de transformação são tipicamente proprietárias e operam sob licenças caríssimas. Este modelo acarreta o efeito lock-in, onde os consumidores tornam-se dependentes dos forcencedores destas ferramentas e de soluções relacionadas. Implementações ESB são baseadas em padrões e especificações abertas, como JMS (Sun Microsystems Inc., 2002), XML (World Wide Web Consortium, 2009), JEE Connector Architecture e padrões relacionados à especificação de
Web Service.
Tecnicamente, um ESB é um produto modelado para resolver problemas de integração entre aplicações heterogêneas. Para explicar os benefícios de um ESB, é importante análisar outros modelos de integração.
Sob outro ponto de vista, ESB representa uma plataforma de EAI mais moderna, robusta, flexível e sem as restrições de lock-in junto aos fornecedores de provedores e distribuidores de serviços.
Assim como em sistemas EAI, o Barramento de Serviço não opera na camada de negócios dos serviços publicados. Esta tarefa é delegada à camada de negócio e técnica. O Barramento opera na camada de infra-estrutura lógica de um ecossistema de serviços. Embora haja diversas definições para o conceito, todas concordam que um Barramento de Serviços é parte integrante de um ecossistema da SOA (Chappell, 2004).
Por diversas razões, sistemas heterogêneos necessitam de integração de aplicações, componentes e serviços, elevando sistemas legados a novos sistemas. Além disso, as
19 mensagens trocadas entre estes sistemas podem ser síncronas ou assíncronas. Um sistema ESB possui suporte a estas duas características básicas em sua implementação.
3.6. Mobilidade
Devido ao avanço de diferentes tecnologias de comunicação móveis, a fim de simplificar o dia-a-dia de usuários das múltiplas tecnologias de telecomunicações, evidencia-se a demanda por melhorias no provimento de evidencia-serviços a estes clientes. Muitas vezes, estes clientes necessitam conectar-se a um único serviço, como o acesso ao serviço bancário a partir de sua casa, automóvel ou escritório. No entanto, a cada instante, este consumo de serviços é realizado através de diferentes terminais de acesso, sejam eles notebooks, computadores de mesa e, como tendência global, através de dispositivos sem-fio, como os telefones celulares.
Da mesma forma, pode-se considerar o provimento de serviços a partir de um Agente Móvel. As regras de mobilidade são equivalentes aos consumidores destes serviços, porém, necessita-se a manutenção da localização destes provedores de serviços, de acordo com a mudança de localidade deste agente.
18. Nomadismo
Atualmente, o provimento de serviços é entregue de forma nômade, onde o terminal do usuário final deve estar conectado a um único ponto de acesso durante o consumo de um serviço. Caso o usuário necessite mudar sua conexão, é necessário desconectá-lo da rede corrente e estabelecer a comunicação com outro ponto de acesso. Este processo é denominado
handover. Após o handover, é necessário reconectar este usuário ao Provedor de Serviços e
então reiniciar a transmissão de dados da sessão anterior, caso esta ainda seja válida no novo contexto. Segundo Dib Karam (Karam Junior, 2006), este modelo é denominado nomadismo.
O handover pode ocorrer devido a requisitos espaciais, parâmetros de Qualidade de Serviço, dentre outros fatores.
La Porta (La Porta, 1996) define o nomadismo como o movimento freqüente com fixação temporária. No contexto de aplicações móveis, o usuário se fixa a algum ponto, independente do meio, seja ele com ou sem fio, para então consumir recursos ou serviços móveis, permanecendo desconectado quando estiver em trânsito (Karam Junior, 2006).
19. Mobilidade Real
No modelo de referência para da ITU-T (International Telecommunication Union, 2004), o advento dos serviços móveis, as diferentes tecnologias e a intercomunicação entre
20 diferentes plataformas aumentaram a complexidade das questões de tratamento de nomeação, indexação e endereçamento de entidades relacionadas em uma conexão. Neste cenário, especial atenção deve ser dada aos terminais, aos dispositivos de comutação e aos sistemas operacionais que atendem às aplicações de usuários.
Segundo a proposta da ITU-T para redes de novas gerações, para estabelecer um modelo ideal de mobilidade, provimento de serviços continuamente, portabilidade numérica, dentre outras características de telecomunicação, não deve haver uma relação estática entre a identidade e a localidade de um objeto participante da atividade de telecomunicação. Desta forma, uma relação transiente deve ser estabelecida entre o objeto e sua localização corrente. (International Telecommunication Union, 2004).
20. Always Best Connected
No contexto onde os requisitos e a complexidade da conexão dos terminais são indefinidos previamente, necessitamos de propostas de trabalho e de implantação viáveis, tanto tecnicamente, quanto economicamente. Como proposta para mobilidade no provimento e consumo de aplicações móveis, foi proposto o modelo de redes Always Best Connected (ABC) (Gustafsson & Johnson, 2003).
Segundo o modelo ABC, um terminal consumidor determina a melhor rede de acesso disponível em qualquer instante do tempo (Gustafsson & Johnson, 2003). Porém, para analisar e aplicar este conceito deve-se considerar a complexidade citada pela ITU-T em (International Telecommunication Union, 2004), não somente nos aspectos técnicos, mas também no relacionamento em regras de negócio entre os diversos fornecedores, operadores e consumidores de serviços.
O presente trabalho considera o modelo das redes ABC como base contextual de implantação de um ambiente onde a mobilidade é real, porém desconsiderando diversos detalhes técnicos e definições de interoperabilidade de serviços entre os pontos deste contexto.
Neste ambiente, o Modelo de Registro de Serviços considera o gerenciamento e manutenção da conectividade do usuário nas camadas de Transporte e Aplicação do modelo de camadas da Internet. No entanto, a proposta também é consistente ao modelo de camadas Open Systems Interconnection (OSI) (International Telecommunication Union, 1994), referente às camadas de transporte, sessão, apresentação e aplicação (Fodor & Tuoriniemi, 2003).
21 Para converter um modelo nômade em um modelo de mobilidade generalizada, onde são desprezadas a localização e movimentação do usuário sem interrupção do provimento e consumo do serviço, busca-se a especificação de métodos de implantação de novas tecnologias. Estas tecnologias devem ser eficientes, possuir complexidade de implantação viável, causando baixo impacto na infra-estrutura das redes já existentes, além de exigir reduzido tempo da computação associada ao tratamento de nomeação e endereçamento dos dispositivos móveis.
A mobilidade generalizada (International Telecommunication Union, 2004), ou simplesmente mobilidade, compreende o uso de diferentes tecnologias, desprezadas as diferentes localizações, enquanto o usuário se movimenta. Isto proporciona ao usuário comunicação, uso e gerenciamento consistente de sua aplicação ou serviço através das fronteiras das redes existentes. Mobilidade ainda inclui a capacidade de usar uma determinada aplicação, ou serviço, sem a interrupção de sua atividade, através de várias tecnologias, permitindo o movimento entre pontos de acesso com ou sem fio (Karam Junior, 2006).
Alguns estudos apresentam o Protocolo de Inicialização de Sessão como uma possibilidade para suportar a mobilidade dos dispositivos, devido à flexibilidade já citada, e ser compatível com as propriedades das redes ABC18.
3.7. Protocolo de Inicialização de Sessão (SIP)
O protocolo de inicialização de sessão surgiu em meio ao projeto de definição de padrões de comunicação o protocolo de controle de sessão multi-usuários, MMUSIC. Em 1996, a equipe do Professor Associado Henning Schulzrinne, da Universidade de Columbia, Estados Unidos, submeteu o projeto para a Internet Engineering Task Force (IETF) os elementos-chave da especificação SIP. Em 1999, após revisões, o projeto chegou a sua primeira versão final, sob a referência RFC19 2543. Em 2001, com a continuidade dos trabalhos pela IETF, uma nova versão do protocolo foi emitida sob a referência RFC 3261. Esta versão está estabelecida no mercado de telecomunicações é referência para as implementações atuais do protocolo. Além da última versão da especificação, outras versões e referências foram propostas, aprimorando a segurança e outros procedimentos do protocolo-base. Algumas referências destes projetos podem ser encontradas em (Schulzrinne, 2008).
18 (Gustafsson & Johnson, 2003) 19
22 A flexibilidade do protocolo se deve ao fato de ser simplesmente um protocolo de estabelecimento de sessões. Neste caso, detalhes da sessão não são conhecidos, tão pouco considerados. Esta simplicidade fortalece o SIP na forma como opera eficientemente com protocolos de naturezas distintas, como SOAP, UDDI, HTTP, XML, WSDL, SDP, RTP, dentre outros. Por esta flexibilidade, este trabalho utiliza-se desta portabilidade e utiliza o SIP para o tráfego de mensagens de registros em Repositórios de Serviços distintos.
Além de ser bastante simples e exigir capacidade computacional baixa para seu processamento, pode-se instalar uma ferramenta de produção e consumo de mensagens SIP por dispositivos com baixo poder de processamento, como microcontroladores de Sistemas de Posicionamento Global (GPS), sistemas automotivos, mesmo telefones celulares, dentre outros.
Assim como os protocolos HTTP, SMTP e FTP, a operação do SIP ocorre na camada de aplicação do modelo de comunicação OSI (Open Systems Intercomunnication – Model and Notation, 1994). A camada de aplicação é o nível responsável por assegurar que a comunicação é possível. Com o uso de SIP, é possível iniciar, modificar e finalizar uma sessão de comunicação. Pelo fato de SIP suportar o mapeamento de nomes e serviços de redirecionamento, é possível aos usuários iniciarem uma comunicação independente da localidade inicial, intermediária e final do usuário, através da distinção entre identidade e localidade fornecida pelo protocolo.
Diversas aplicações na Internet requisitam a criação e o gerenciamento de sessão, onde uma sessão é considerada a troca de dados entre uma associação de participantes. A implementação destas múltiplas aplicações são complexas, devido ao comportamento de seus participantes. Usuários podem mover-se entre diferentes pontos de acesso, podem ser localizados por múltiplos endereços e pode se comunicar através de diversos formatos de mídia, em alguns casos, simultaneamente. Diversos protocolos foram criados para suportar os diferentes tipos de mídia trafegados entre estes pontos de comunicação, como RTP, RTSP, RTCP, dentre outros. O Protocolo de Inicialização de Sessão opera em consonância com outros protocolos, com o objetivo de permitir pontos de acesso da Internet descubram outro ponto de acesso e concordem com a as características da sessão compartilhadas antes e durante a comunicação.
23 Para a determinação de participantes da sessão e de outras funcionalidades, SIP cria uma infraestrutura de servidores onde os agentes podem se registrar, enviar chamadas para novas sessões e outras requisições.
Além disso, SIP é um protocolo leve, ágil, e de propósito geral para a criação, modificação e finalização de sessões de intercomunicação.
Sua portabilidade garante a independência do protocolo de transporte e independência do tipo de sessão que será trafegada.
SIP não provê serviços. Simplesmente, SIP provê primitivas que podem ser utilizadas para implementar diferentes serviços. Por exemplo, SIP pode localizar um Agente e entregar um objeto opaco20 de algum serviço para esta localidade atual. Neste caso, o objeto opaco é indiferente ao processo de transporte dos dados, sendo interpretado apenas pelos agentes terminais da comunicação.
Devido à natureza dos serviços trafegados utilizando SIP, a segurança deve ser tratada como um assunto particularmente importante. Para tornar as aplicações trafegadas mais seguras, SIP provê um conjunto de funcionalidades de segurança, que inclui prevenção de ataques de negação de serviço, autenticação, criptografia e serviços de privacidade.
21. Visão Geral
As características de portabilidade, simplicidade e modelo de requisição/resposta do SIP foram conceitualmente influenciadas pelos protocolos SMTP e HTTP, embora seus propósitos operacionais sejam bastante diferentes.
A simplicidade da especificação SIP favorece a regularidade e estabilidade de suas implementações. Esta regularidade torna a aplicação de modelos de aplicação, desde dados planos, como Web Services, troca de mensagens simples entre sistemas, como aos seus propósitos originais, na aplicação a sistemas de telecomunicações multimídia.
No contexto de aplicações SIP, os terminais podem operar com dois papéis. O primeiro corresponde à representação de Agente Usuário (UAC), definido como emissor da requisição de comunicação e envio da mensagem inicial de uma mensagem SIP. Por outro lado, o terminal receptor da comunicação é denominado Agente Servidor (UAS). Um terminal
20
Em computação, um objeto opaco é um tipo de dados que oculta sua implementação interna utilizando apenas uma referência para acessá-lo. Isto permite a implementação e encapsulamento de toda a interface ser
modificado sem a necessidade de recompilação dos módulos que utilizam este objeto. Este é um artefato importante para prover a compatibilidade binária entre diferentes versões de bibliotecas compartilhadas, por exemplo. (Eckel, 2000)
24 pode ser um software aplicativo de telefonia, um telefone IP, um dispositivo celular, além de outras aplicações. Atuando como nós das redes de telecomunicações SIP, há dispositivos servidores para estes usuários agentes, considerados os Registrars, Proxies e Servidores de Aplicações.
Por estas características, este trabalho propõe o uso do protocolo como meio de garantir os aspectos de mobilidade em redes Always Best Connected, além de aplicá-lo a um ambiente de registro sob um ecossistema SOA.
22. Primitivas SIP
Em sua especificação, são apresentadas cinco primitivas ao modelo de operação do SIP. São elas:
Localização de Usuários: Determinação do sistema final que será utilizado para a comunicação.
Disponibilidade do Usuário: Determinação da intençao de participação na sessão de comunicação
Capacidades do Usuário: Determinação da mídia e os parâmetros de mídia a serem utilizados
Configuração da Sessão: Estabelecimento dos parâmetros de comunicação antes e durante a comunicação.
Gerenciamento de Sessão: Transferência, inicialização e finalização de sessões, modificação de parâmetros de sessão e invocação de serviços.
23. Mecanismo de Registro
SIP oferece a funcionalidade de descoberta de localização de um agente através de troca de mensagens simples e desacoplamento entre a identidade de um agente e sua localidade durante sua execução. Se um usuário deseja iniciar uma sessão com outro usuário, SIP deve descobrir o endereço em que o destinatário poderá ser alcançado no momento de uma chamada e em qualquer momento da comunicação.
O processo de registro é uma operação comum em uma comunicação SIP. Esta é a forma de conhecimento da localização entre dois agentes usuários, sejam eles consumidores ou provedores. Periodicamente, durante a atividade de um agente, mensagens SIP REGISTER são emitidas ao servidor Registrar, com o objetivo de associar o endereço de registro (ex.:
25 <andrepgs@sip.ufsc.br>) ao endereço físico do dispositivo de acesso onde o usuário está registrado em um determinado instante.
Este procedimento de descoberta é fornecido por elementos da rede SIP como servidores Proxy, servidores de redirecionamento e Registrars. Estes elementos são responsáveis por receber uma requisição, determinar para onde o pacote deve ser enviado baseado no conhecimento da localidade atual do destinatário e, então, enviar o pacote. Para realizar este procedimento, os elementos da rede SIP consultam um serviço abstrato conhecido como servidor de localização, responsável por prover endereços para um determinado domínio. Estes mapas de endereçamentos são responsáveis por relacionar endereços de registro (por exemplo: <andrepgs@voip.ufsc.br>) para os endereços de conexão atuais do usuário referente (por exemplo: <sip:3813@150.162.245.64:5060>).
O processo de Registro possui um serviço de localização para um determinado domínio, responsável por criar uma amarração entre o endereço de registro (URI) com um ou mais endereços de contato para um mesmo URI. Assim, quando um servidor Proxy recebe uma requisição de troca de mensagens para um determinado endereço de registro, dado pelo campo Request-URI do pacote de requisição, o servidor proxy redirecionará a requisição para o endereço determinado pelo campo Contact determinado para este endereço de registro. Normalmente, faz sentido armazenar um endereço de registro em um Servidor de Localização de domínios quando para o dado Endereço de Registro for roteado por este domínio. Na maioria dos casos, isso requer que o domínio de registro corresponda ao domínio do URI do Endereço de Registro.
Há diversas maneiras de sincronizar os conteúdos de um serviço de localização. Uma maneira é administrativa, através do registro manual do mapeamento do endereço lógico ao endereço físico do destinatário de uma mensagem SIP. No entanto, SIP fornece mecanismos formais de registro para criar esta associação dinamicamente. Este processo é denominado Registro.
O processo de Registro SIP compreende enviar uma mensagem de requisição
REGISTER para um tipo especial de Agente-Servidor de um usuário, denominado Registrar. Internamente, o servidor Registrar opera junto a um Serviço de Localização para um domínio, escrevendo e obtendo mapeamentos baseado nos parâmetros da requisição REGISTER. Em um modelo típico, o Serviço de Localização é consultado por um servidor Proxy SIP, responsável
