UNIVERSIDADE. Sistemas Distribuídos

Transcrição

1 UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Web Services (continuação)

2 WSDL - Web Service Definition Language WSDL permite descrever o serviço que será oferecido que mensagens devem ser enviadas e qual a sua estrutura como usar vários protocolos de transporte onde o serviço está localizado, mais precisamente para que rede a mensagem deve ser enviada WSDL serve para descrever em XML todos os fatos relacionados ao serviço que são relevantes aos clientes

3 WSDL Descrição de um serviço Uma descrição de serviço é composta por uma parte abstrata e uma parte concreta A parte abstrata é formada por: Definições Tipos de dados Mensagens Interfaces A parte concreta é formada por: Bindings (escolha de protocolos) Serviços (endereço do servidor)

4 Principais elementos de WSDL Descreve: As operações que o serviço faz Onde está localizado Como invocá-lo Exemplos de protocolos de transporte: SOAP HTTP SMTP

5 Componente Interface do WSDL Conjunto de operações de web service dentro de um elemento XML (conhecido também como porttype) Parecido com uma interface IDL do CORBA Cada operação deve definir um padrão de troca de mensagens In-Out: cliente envia e servidor deve responder In-Only: cliente envia e não necessita de resposta Out-Only: servidor responde e não precisa de resposta Robust-In-Only e Robust-Out-Only: envio de mensagens com garantia de entrega

6 Padrões de troca de mensagens do WSDL

7 Componente Interface do WSDL <porttype name= InterfaceOperacao > <operation name= nomeoperacao pattern= in-out > </porttype> </operation> <input message= msg:mensagemrequisicao /> <output message= msg:mensagemresposta /> Descreve o que o serviço faz As mensagens permitem saber a assinatura dos métodos Normalmente um documento WSDL contem apenas um porttype por razões de reutilização

8 Componente Mensagem do WSDL Contém a assinatura das operações descrevendo o nome e os parâmetros da operação Geralmente são definidas duas mensagens para cada operação definida na interface. Uma para requisição: <message name= MensagemRequisicao > <part name= argumento type= xsd:string > </message> E outra para resposta: <message name= MensagemResposta > <part name= resultado type= xsd:double > </message>

9 Componente Tipos do WSDL Coleção de todos os tipos de dados usados na especificação de um serviço São declarados num XML Schema Tipos primitivos (int, double) possuem definições equivalentes em XML No entanto, para tipos estruturados utiliza complextype do XML que consiste de sequences para os tipos internos

10 Componente Tipos do WSDL <types> <xsd:schema targetnamespace= </types> xmlns:xsd= <xsd:element name= complexo type= tipocomplexo /> <xsd:complextype name= tipocomplexo > <wsd:sequence> <xsd:element name= elemento1 type= xsd:string /> <xsd:element name= elemento2 type= xsd:double /> </xsd:sequence> <xsd:attribute name= id type= xsd:positiveinteger /> </xsd:complextype> </xsd:schema>

11 Bindings do WSDL A função do binding é tornar concreto o serviço definindo a forma como o mesmo funciona Exemplos: Protocolo de transporte Estilo de invocação Formato da mensagem Representação de dados externa Uma interface WSDL pode ter um mais bindings associados, mas cada documento normalmente só tem um.

12 Bindings do WSDL <binding name= ExemploBinding type= tipobinding > <soap:binding style= rpc 1 transport= 2 <operation name= nomeoperacao > <input> </operation> </binding> </input> <output> </output> <soap:body use= encoded /> 3 <soap:body use= encoded /> 4

13 Bindings do WSDL O exemplo mostra um binding que indica que a invocação será do tipo requisição-resposta (linha 1) Na linha 2, o código indica que o protocolo de transporte utilizado será o HTTP As linhas 3 e 4 mostram que o formato da mensagem será o envelope SOAP e que utilizará apenas o corpo (body) Mostram também que a mensagem deverá ser codificada

14 Serviço de diretório UDDI Serviço para registro e localização de Web Services Permite informações sobre negócio e serviços sejam eletronicamente publicadas e consultadas. Register once, published everywhere Define como os negócios interagem sobre a Internet e compartilham informações em uma arquitetura de registro global. É um framework para integração de Web Services.

15 Serviço de diretório UDDI UDDI é uma especificação global. Toda empresa espalhada pelo mundo é capaz de se registrar em um UDDI Business Registry. Business Registry implementa a especificação UDDI. Nos Registries ocorre uma sincronização de seus conteúdos regularmente. Permissões de acesso Somente o usuário com as credenciais que conferem com as credenciais usadas para criação dos registros podem alterá-los.

16 Serviço de diretório UDDI Serviço de nomes permite que se busque um serviço através do nome da empresa Conhecido como páginas brancas Serviço de diretório permite que se busque um serviço através do tipo de serviço, produto, localização geográfica Conhecido como páginas amarelas Fornece também informações técnicas sobre o serviço exposto(regras de negócio, descrição do serviço,...) Conhecido como páginas verdes

17 Serviço de diretório UDDI UDDI armazena informações em quatro estruturas que podem ser acessadas individualmente através de uma chave

18 Serviço de diretório UDDI businessentity: fornece informações sobre a organização que oferece o web service businessservices: armazena os nomes e as descrições de um ou mais web services businesstemplate: guarda o endereço de um web service e referências a descrições de serviços tmodel: guarda descrições de serviços, geralmente do tipo WSDL e acessados por meio de URL

19 Serviço de diretório UDDI UDDI fornece uma API para buscar serviços baseados em dois tipos de operações Operações do tipo get para obter informações sobre detalhes de negócios, serviços, bindings, etc. Operaçoes do tipo find para descobrir serviços disponíveis e o conjuntos de empresas que fornecem aquele tipo de serviço

20 Segurança em XML Como pode-se observar o XML é um componente fundamental dentro de Web Services É importante que o XML forneça recursos de segurança tais como assinatura digital, encriptação e gerenciamento de chaves Permitir, por exemplo, aplicar diferentes níveis de permissão de acesso em diferentes partes de um documento XML pode fazer isso através da definição de novas tags que definam o começo e o fim de seções codificadas

21 Segurança em XML Requisitos XML deve fornecer pelo menos o mesmo nível de proteção que um TLS (Transport Layer Security) Ser capaz de encriptar um documento inteiro ou apenas parte dele. Ex.: transações financeiras. Ser capaz de fornecer assinatura para um documento inteiro apenas parte dele para garantir autenticidade Autorizar diferentes usuários a visualizarem diferentes partes de um documento

22 Segurança em XML Requisitos O XML deve fornecer um conjunto padrão de algoritmos para permitir o uso de segurança nos documentos Estes algoritmos devem estar explicitamente referenciados dentro do próprio documento XML XML deve definir elementos (tags, valores) que acessem estes recursos de segurança através de uma URI

23 Algoritmos para assinatura em XML

24 Algoritmos para encriptação em XML Algoritmos do tipos Block cipher são usados para encriptar dados Base64 é usado para assinatura digital e também encriptação de dados

25 Comparações entre Web services e CORBA No CORBA, é possível obter/publicar a referência de um objeto remoto através do serviço de nomes No Web services, o cliente utiliza o UDDI para obter e publicar a descrição de um serviço web IORs em CORBA podem utilizar um identificador de interface IDL para fornecer informações sobre um objeto remoto gravadas em repositório de informações No entanto cliente e servidor precisam utilizar o mesmo repositório de implementação

26 Comparações entre Web services e CORBA Impraticável ao tentar utilizar IOR para referenciar um objeto numa rede como a Internet Web services são mais eficientes pois utilizam URL para referenciar um serviço Um cliente em qualquer lugar na Internet pode fazer uma requisição ao serviço através da URL Web services são mais fáceis de serem utilizados pois, por exemplo, HTTP e XML já possuem suporte de sistemas operacionais e bibliotecas de linguagem Enquanto CORBA geralmente passa por um difícil processos de instalação

27 Comparações entre Web services e CORBA Ativação e localização de recursos Em Web services estas duas ações estão bem separadas No CORBA estas ações são feitas pelo repositório de implementação Desempenho CORBA utiliza CDR que é binário e mais eficiente Web services utiliza XML que é textual e portanto mais lento Apesar de haver estudos sobre a possibilidade de incluir dados binários no XML para melhor eficiência

28 Comparações entre Web services e CORBA CORBA é mais recomendado para a criação de aplicações mais complexas e que sejam utilizadas dentro de uma organização ou um pequeno grupo de organizações e que exija um melhor desempenho Web services é para aplicações que sejam projetadas para estar disponíveis, por exemplo, para acesso pela Internet e cujo desempenho não seja o foco principal

29 Web services em Java O desenvolvimento de web services com Java é feito através da API JAX-RPC Esta API oculta todos os detalhes do protocolo SOAP tanto para o cliente quanto para o servidor JAX-RPC mapeia tipos em Java para tipos em XML Ex.: Calendar, Date, String, tipos primitivos etc. Permite também que URIs sejam passadas como argumento e resultado

30 Web services em Java JAX-RPC permite também que classes sejam passadas como argumentos e resultados desde que: Seja um dos tipos permitidos pela API Tenha um construtor padrão (sem argumentos) Não implementem a interface Remote Interfaces em Java que implementam Remote não podem ser passadas como parâmetros Ex.: ShapeList.

31 Exemplo de Interface de Web Service em Java: ShapeList import java.rmi.*; public interface ShapeList extends Remote { int newshape(graphicalobject g) throws RemoteException; int numberofshapes()throws RemoteException; int getversion() throws RemoteException; int getgoversion(int i)throws RemoteException; GraphicalObject getallstate(int i) throws RemoteException; } Comparar com a interface de um serviço equivalente construído com objetos distribuídos: import java.rmi.*; import java.util.vector; public interface Shape extends Remote { int getversion() throws RemoteException; GraphicalObject getallstate() throws RemoteException; } public interface ShapeList extends Remote { Shape newshape(graphicalobject g) throws RemoteException; Vector allshapes() throws RemoteException; int getversion() throws RemoteException; }

32 Web services em Java A interface Java de um web service deve atender às seguintes regras: Deve estender a interface Remote Não deve ter constantes declaradas Devem lançar exceção do tipo RemoteException Tipos de dados passados e retornados somente aqueles permitidos pela API JAX-RPC

33 Web services em Java - Servidor O servidor não possui método principal (main) e não há construtor Servidor é apenas um objeto que fornece um conjunto de serviços Duas ferramentas chamadas wscompile e wsdeploy são usadas para gerar o skeleton e a descrição do serviço (documento WSDL) Estas informações são obtidas são obtidas de um arquivo de configuração XML

34 Implementação do servidor ShapeList em Java import java.util.vector; public class ShapeListImpl implements ShapeList { private Vector thelist = new Vector(); private int version = 0; private Vector theversions = new Vector(); public int newshape(graphicalobject g) throws RemoteException{ version++; thelist.addelement(g); theversions.addelement(new Integer(version)); return thelist.size(); } public int numberofshapes(){} public int getversion() {} public int getgoversion(int i){ } public GraphicalObject getallstate(int i) {} }

35 Container de servlets Para utilizar web services em Java podemos utilizar um container de servlets Carregar, inicializar e executar servlets Servlets são programas que servem para atender requisições de cliente de dentro de um web server As requisições são passadas para um skeleton através de um despachante O skeleton por sua vez converte a informação para Java e chama o método no servlet

36 Container de servlets - Tomcat O servlet atende a requisição e retorna uma resposta para o skeleton que traduz de volta para o formato SOAP Tomcat é um exemplo de container de servlets bastante utilizado Tomcat fornece acesso para as descrições de serviço do web service contidos nele

37 Container de servlets - Tomcat Facilita a criação de programas cliente e também a compilação de proxys Como a descrição do serviço está em XML é possível ler suas informações diretamente Importante lembrar que o uso de servlets não é obrigatório para o desenvolvimento de web services com Java

38 Web services em Java - Cliente O cliente pode acessar um serviço através de proxy estático ou dinâmico ou por invocação dinâmica O código a seguir usa proxy estático que é gerado pelo programa wscompile a partir da descrição de serviço do servidor O nome é formado pelo nome do serviço acrescentado de _Impl Ex.: MyShapeListService_Impl Proxys dinâmicos são criados em tempo de execução também a partir da descrição de serviço e não especifica nenhuma regra de nome

39 Implementação do cliente do serviço web ShapeList em Java package staticstub; import javax.xml.rpc.stub; public class ShapeListClient { public static void main(string[] args) { /* pass URL of service */ try { Stub proxy = createproxy(); 1 proxy._setproperty 2 (javax.xml.rpc.stub.endpoint_address_property, args[0]); ShapeList ashapelist = (ShapeList)proxy; 3 GraphicalObject g = ashapelist.getallstate(0); 4 } catch (Exception ex) { ex.printstacktrace(); } } private static Stub createproxy() { 5 return (Stub) (new MyShapeListService_Impl().getShapeListPort()); 6 } }

40 Web services em Java - Cliente Na linha 1 o proxy estático é criado As linhas 5 e 6 mostram o método responsável pela criação do proxy Na linha 2, a URL do servidor é fornecida para o proxy através do argumento passado pela linha de comando (args[0]) Na linha 3, o proxy é convertido para o tipo ShapeList e a linha 4 ocorre a chamada do método getallstate() que retorna um objeto gráfico

41 Invocação dinâmica e implementação do Java SOAP Invocação dinâmica de interface permite executar uma operação mesmo sem conhecimento de nome e assinatura em tempo de execução Obtém o nome e a assinatura por um conjunto de operações A implementação do SOAP no Java pode ser explicada com base na arquitetura RMI Os módulos de comunicação (cliente e servidor) utilizam o protocolo HTTP

42 Implementação do Java SOAP Módulo de comunicação do servidor seleciona o despachante com base na URL fornecida na mensagem de requisição Proxy conhece a URL do serviço, cria a mensagem e faz o marshalling para o XML. Depois recebe a resposta, faz o unmarshalling e retorna o resultado da requisição Despachante que recebe a mensagem de requisição e redireciona para o skeleton apropriado Skeleton que valida a mensagem, faz o unmarshalling e executa a operação