Aula_12

UNIVERSIDADE
Sistemas Distribuídos
Ciência da Computação
Prof. Jesus José de Oliveira Neto
Web Services (continuação)
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
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)
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
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
Padrões de troca de mensagens do WSDL
Componente Interface do WSDL
<portType name=”InterfaceOperacao”>
<operation name=”nomeOperacao” pattern=”in-out”>
<input message=”msg:MensagemRequisicao”/>
<output message=”msg:MensagemResposta”/>
</operation>
</portType>
●
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
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>
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
Componente Tipos do WSDL
<types>
<xsd:schema
targetNamespace=http://www.exemplo.com/ns/tipoComplexo
xmlns:xsd=http://www.w3.org/2001/XMLSchema>
<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>
</types>
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.
Bindings do WSDL
<binding name=”ExemploBinding” type=”tipoBinding”>
<soap:binding style=”rpc”
1
transport=http://schemas.xmlsoap.org/soap/http/> 2
<operation name=”nomeOperacao”>
<input>
<soap:body use=”encoded”/>
3
</input>
<output>
<soap:body use=”encoded”/>
</output>
</operation>
</binding>
4
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
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.
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.
Serviço de diretório UDDI
●
Serviço de nomes permite que se busque um serviço
através do nome da empresa

●
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 brancas
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
Serviço de diretório UDDI
●
UDDI armazena informações em quatro estruturas que
podem ser acessadas individualmente através de uma
chave
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
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
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
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
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
Algoritmos para assinatura em XML
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
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
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
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
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
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
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.
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;
}
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
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
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) {}
}
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
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
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
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
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
}
}
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
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
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