Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com
Mecanismos de Comunicação Protocolos de Aplicação
Mecanismos de comunicação Middleware Candidatos atuais a mecanismos de comunicação? Protocolos de Aplicação (ex., HTTP, SMTP, SOAP, etc) IPCs Tradicionais (ex., SOCKET, Memória Compartilhada,etc)
Protocolos de Aplicação Serviços Web (ex., HTTP, SMTP, SOAP, etc)
Cenários Problemáticos Vamos tentar bolar soluções para aplicações corporativas avançadas Cenário 1: Portal de Turismo Cenário 2: Compra Automática Cenário 3: Supply Chain Management (SCM) Cenário 4: Pesquisa Google via Programa 5
Cenário 1: Portal de Turismo Implemente um portal realmente automático em que: O cliente lista seus desejos via HTML O portal pesquisa alternativas escolhe as melhores faz todas as reservas fatura o cartão de crédito do cliente efetua todos os pagamentos... automaticamente, sem intervenção humana Queremos que programas naveguem na Web, não só humanos 6
Cenário 2: Compra automática Implemente uma aplicação para um distribuidor regional de remédios que: Automaticamente detecte estoque baixo Procure o melhor lugar no mundo para comprar os produtos Preço, prazo de entrega, etc. Emita a ordem de compra eletronicamente 7
Cenário 3: Supply Chain Management Implemente aplicações de SCM que integrem sistemas de várias empresas (fornecedores, parceiros, clientes,...) 8
Cenário 4: Pesquisa Google via Programa Escreva um programa que recupere as primeiras 10 ocorrências de web services retornadas pelo Google 9
Características comuns aos cenários Todos são sistemas distribuídos Todos funcionam na Internet Vários envolvem achar (navegar) o que se quer antes de usar Todos envolvem domínios administrativos diferentes (empresas diferentes) Não temos controle sobre a plataforma, linguagem, etc. do outro lado O outro lado é essencialmente um sistema legado no qual não podemos mexer 10
Problemas técnicos resultantes 1. Como trocar informação em ambiente heterogêneo para que ambos os lados entendam? 2. Como acessar a funcionalidade remota? 3. Como achar o outro lado? 4. Como driblar firewalls na comunicação? 11
SOCKETS? Baixo nível Camada de REDE Preocupações com IPs. Camada de TRANSPORTE Preocupação com protocolos UDP, TCP. Gerencia das ligações (Binding) Preocupação com a representação dos dados. Como seria uma calculadora usando sockets? Difícil achar novos serviços. Serviços não padronizados (soma?, sum?, somar?)
Uma Solução melhor Web Services 1. Como trocar informação em ambiente heterogêneo para que ambos os lados entendam? Usar XML para toda a comunicação Usar SOAP fazer RPC 2. Como saber que métodos podem ser chamados e com que parâmetros? Usar uma arquitetura orientada a serviços Descrever o serviço remoto usando WSDL 13
Uma Solução melhor Web Services 1. Como achar o outro lado? Usar UDDI (Universal Description, Discovery and Integration) para localizar serviços 2. Como driblar firewalls na comunicação? Usar binding de SOAP para HTTP
Arquitetura WebService 15
Arquitetura orientada a serviços Serviço oferece uma API na Internet 16
Usar XML para toda a comunicação Extended Markup Language (XML) Oferece um formato ASCII para trocar qualquer tipo de informação estruturada Usa o estilo HTML de markup com tags <pessoa nome= João > <frutasfavoritas> <fruta>manga</fruta> <fruta>maçã</fruta> <fruta>uva</fruta> </frutasfavoritas> </pessoa> Os tags podem ser definidos para criar uma Aplicação XML ou Linguagem XML 17
Usar SOAP fazer RPC SOAP é uma forma de fazer Remote Procedure Call (RPC) usando documentos XML 18
Descrever o serviço remoto usando WSDL WSDL = Web Services Description Language Pronunciado wisdle É uma linguagem XML que contém informação sobre a interface, a semântica, e outros detalhes de chamadas a um Web Service 19
Exemplo http://www.service-repository.com/service/overview/1132083200
Descrição WSDL inclui Descrição/formato de mensagens que podem ser passadas Elementos <types>, <message> Semântica da passagem de mensagens (Requestonly, request-response, response-only) Dentro do elemento <porttype> Uma codificação usando um transporte particular Elemento <binding> O endpoint do serviço (uma URL) Dentro do elemento <service> 21
Usar UDDI para localizar serviços UDDI = Universal Description, Discovery, and Integration Permite cadastrar serviços e localizá-los Não é necessário usar UDDI se o cliente já souber a URI do documento WSDL UDDI Business Registry (UBR) é um diretório público de serviços disponíveis 22
Usar binding de SOAP para HTTP O binding sobre HTTP (porta 80) permite driblar firewalls com mais facilidade. Qualquer outro protocolo de transporte pode ser usado 23
Finalmente... O que é um Web Service? Um Web Service é um ponto de acesso a funcionalidade que pode ser Localizado dinamicamente Ter sua interface descoberta automaticamente, porque o serviço sabe se descrever Ser chamado na Web 24