Apresentação do PowerPoint - IC

IC-UNICAMP
Web Services
Aluno: Fabiano Costa Teixeira
Professor: Dr. Edmundo R. M. Madeira
Web Services – Fabiano Costa Teixeira – 2005
1/82
IC-UNICAMP
Cenário
• Considere uma agência de viagens que
quando vai vender um pacote precisa analisar:
– Empresas aéreas: Determinar a melhor opção entre
os horários e preços dos vôos;
– Hotéis: Melhores condições e preços;
• Atualmente a negociação com o cliente é feita
de forma “manual”. Ou seja, o cliente vai até à
agência, informa o local de destino, a data de
partida e retorno e o padrão de hotel e a
classe de vôo desejados;
Web Services – Fabiano Costa Teixeira – 2005
2/82
IC-UNICAMP
Cenário
• Com a finalidade de propiciar uma maior
comodidade aos clientes e agilizar o
atendimento a agência deseja automatizar
esse processo;
• É desejado que o site da agência possua
recursos de forma que o cliente informe os
dados e valor da viagem seja calculado;
Como esse processo pode ser
automatizado?
Web Services – Fabiano Costa Teixeira – 2005
3/82
IC-UNICAMP
Cenário
• As empresas aéreas precisam disponibilizar
formas para as agências consultarem suas
tabelas de vôos e preços,
• Os hotéis precisam disponibilizar formas para
as agências consultarem suas tabelas de
preços e reservas;
• O sistema da agência precisa acessar os
dados dos hotéis e das empresas aéreas para
analisar a melhor condição e oferece-lá ao
cliente;
Web Services – Fabiano Costa Teixeira – 2005
4/82
IC-UNICAMP
Cenário
• Diferentes hotéis e empresas aéreas
possuem diferentes estruturas de informática;
• Cada hotel e empresa aérea pode
disponibilizar seus dados utilizando uma
tecnologia e forma de acesso diferentes;
• Essa heterogeneidade complica o
desenvolvimento da solução;
• A agência precisa saber quais as empresas
aéreas e hotéis que oferecem tal recurso, de
forma que ela possa incluí-los na consulta;
Qual a solução para isso?
Web Services – Fabiano Costa Teixeira – 2005
5/82
Agenda
IC-UNICAMP
• Durante a apresentação serão abordados os
seguintes assuntos:
– W3C
– XML
– Web Services
– SOAP
– WSDL
– UDDI
Web Services – Fabiano Costa Teixeira – 2005
6/82
IC-UNICAMP
W3C: O que é?
• Criado em 1994 como colaboração entre o
Massachusetts Institute of Technology (MIT) e
a European Organization for Nuclear Research
(CERN) e com suporte da U.S. Defense
Advanced Research Projects Agency (DARPA)
e da Comissão Européia;
• Tim Berners-Lee é o atual diretor do W3C;
Web Services – Fabiano Costa Teixeira – 2005
7/82
W3C: O que é?
IC-UNICAMP
• Funciona como um consórcio. Alguns
membros bem conhecidos são:
–
–
–
–
–
–
–
IBM
Microsoft;
América Online
Apple
Adobe
Macromedia
Sun Microsystems;
• Lista completa de membros em
http://www.w3.org/Consortium/Member/List
Web Services – Fabiano Costa Teixeira – 2005
8/82
IC-UNICAMP
W3C: O que é?
• As operações do W3C são administradas, em
conjunto, por:
– MIT Computer Science and Artificial Intelligence
Laboratory (CSAIL);
– Europeam Reserarch Consortium for Informatics
and Mathematics (ERCIM);
– Keio University;
Web Services – Fabiano Costa Teixeira – 2005
9/82
IC-UNICAMP
W3C: Recomendações
• Um dos trabalhos mais importantes realizado
pelo W3C é o desenvolvimento de
especificações (também chamadas de
recomendações);
• Elas descrevem padrões como HTML, XML,
etc;
• Cada recomendação é realizada por um grupo
de trabalho consistido de membros e “experts”
convidados;
• Empresas podem submeter recomendações
ao W3C para uma recomendação formal;
Web Services – Fabiano Costa Teixeira – 2005
10/82
IC-UNICAMP
W3C: Passos da Recomendação
(1) Recebimento da submissão;
(2) Publicação da nota;
(3) Criação do grupo de trabalho;
(4) Publicação do rascunho do trabalho;
(5) Publicação da recomendação candidata;
(6) Publicação da recomendação proposta;
(7) Publicação da recomendação;
Web Services – Fabiano Costa Teixeira – 2005
11/82
IC-UNICAMP
W3C: Submissão
• Qualquer membro do W3C pode submeter
uma sugestão de padronização;
• A maioria das recomendações do W3C
surgiram como uma sugestão de
padronização;
• Após receber uma sugestão de padronização
o W3C irá decidir se iniciará um trabalho para
refinar a sugestão;
Web Services – Fabiano Costa Teixeira – 2005
12/82
IC-UNICAMP
W3C: Publicação da Nota
• Muitas vezes uma submissão ao W3C tornase uma nota;
• A nota é uma descrição (editada pelo membro
que efetuou a submissão) de uma sugestão
refinada como um documento público;
• Essa nota é publicada pela W3C somente
para discussão;
• A publicação de uma nota não indica
aprovação por parte do W3C nem mesmo
indica o início de qualquer trabalho por parte
do W3C;
Web Services – Fabiano Costa Teixeira – 2005
13/82
IC-UNICAMP
W3C: Grupo de Trabalho
• Quando uma submissão é reconhecida pelo
W3C é formado um grupo de trabalho
consituído de membros e outras partes
interessadas;
• O grupo de trabalho irá definir um cronograma
é um rascunho da padronização proposta;
Web Services – Fabiano Costa Teixeira – 2005
14/82
IC-UNICAMP
W3C: Rascunhos de Trabalho
• São normalmente postados no site do W3C;
• Incluem “chamadas” para comentários do
público;
• Indicam que o trabalho está em progresso;
• Não podem ser utilizados como material de
referência;
• O conteúdo pode ser substituído e/ou alterado
a qualquer momento;
Web Services – Fabiano Costa Teixeira – 2005
15/82
IC-UNICAMP
W3C: Recomendações Candidatas
• Algumas recomendações são mais
complexas;
• Precisam de mais tempo e mais testes;
• Essas recomendações são publicadas como
Candidatas;
• Possuem também um status de trabalho em
progresso;
• Pode ser atualizada e/ou substituída a
qualquer momento;
• Não devem ser utilizadas como documentos
de referência;
Web Services – Fabiano Costa Teixeira – 2005
16/82
IC-UNICAMP
W3C: Recomendação Proposta
• Representa o estágio final do trabalho do
grupo;
• Continua sendo um trabalho em progresso;
• Ainda pode ser atualizada e/ou substituída;
• Na maioria das vezes se torna a
recomendação propriamente dita;
Web Services – Fabiano Costa Teixeira – 2005
17/82
IC-UNICAMP
W3C: Recomendação
• Totalmente revisada pelo W3C;
• Possui o “carimbo” de APROVADA concedido
pelo diretor do W3C;
• Considerado um documento estável e pode
ser utilizado como material de referência;
Web Services – Fabiano Costa Teixeira – 2005
18/82
IC-UNICAMP
XML
• EXtensible Markup Language;
• Tornou-se uma recomendação do W3C em 10
de fevereiro de 1998;
• XML é uma “meta-linguagem” utilizada para
descrever dados e é focada no que os dados
são;
• Criada para estruturar, armazenar e enviar
informações;
• “Linguagem independente de plataforma,
hardware e software para transmissão de
informações” (W3Schools);
• Utilização de TAG`s;
Web Services – Fabiano Costa Teixeira – 2005
19/82
IC-UNICAMP
XML
• Está se tornando a principal forma para troca
de informações entre empresas através da
Internet;
• Pelo fato de ser independente de plataforma,
hardware e software, os dados descritos
utilizando XML podem ser acessíveis por
outros aplicativos além dos Browsers;
Web Services – Fabiano Costa Teixeira – 2005
20/82
IC-UNICAMP
XML x HTML
• XML não é uma substituta da HTML;
• Enquanto HTML é focada para descrever
como os dados devem ser “mostrados”, XML é
focada para descrever informações;
• HTML trabalha com TAGs pré-definidas;
• XML nos permite a criação de nossas próprias
TAGs;
Web Services – Fabiano Costa Teixeira – 2005
21/82
IC-UNICAMP
XML x HTML
• Trecho HTML:
<p><b>Fabiano Costa Teixeira</b>
<br>
Av. Albert Einstein, 1251
<br>
UNICAMP. Campinas – SP</p>
Web Services – Fabiano Costa Teixeira – 2005
22/82
IC-UNICAMP
XML x HTML
• Resultado voltado para seres humanos;
Web Services – Fabiano Costa Teixeira – 2005
23/82
IC-UNICAMP
XML x HTML
• Trecho XML:
<endereco>
<nome>Fabiano Costa Teixeira</nome>
<rua>Albert Einstein</rua>
<numero>1251</numero>
<bairro>UNICAMP</bairro>
<cidade>Campinas</cidade>
<estado>SP</estado>
</endereco>
• Possível entendimento para máquinas!
Web Services – Fabiano Costa Teixeira – 2005
24/82
IC-UNICAMP
Utilização da XML
• Na realidade, sistemas de computação e
sistemas de bancos de dados possuem dados
em formatos incompatíveis;
• Convertendo os dados para XML a troca de
informações entre esses sistemas se
simplifica;
• Os dados convertidos para XML podem ser
interpretados por diferentes tipos de
aplicações;
• Poder ser utilizada também para
armazenamento de dados;
Web Services – Fabiano Costa Teixeira – 2005
25/82
Regras para Documentos XML
IC-UNICAMP
• Requer um parser para rejeitar qualquer
documento inválido;
• Possui regras básicas como:
–
–
–
–
O documento deve ter apenas um elemento raíz;
Toda elemento requer uma tag inicial e uma final;
Elementos são case sensitive;
Etc
• Documento bem formado: Aquele que
obedece às regras de sintaxe;
• Documento válido: Aquele que obedece às
regras de sintaxe e a um formato pré-definido;
Web Services – Fabiano Costa Teixeira – 2005
26/82
IC-UNICAMP
DTD
• Document Type Definition;
• Um documento pode atender às regras
básicas, no entanto sua estrutura pode ser
inválida;
• O DTD define a estrutura do documento como
uma lista de elementos válidos;
• Declaração interna do tipo do documento: O
mesmo arquivo contém as regras DTD e o
documetno XML;
• Declaração externa do tipo do documento: O
documento e a declaração do tipo estão em
arquivos diferentes;
Web Services – Fabiano Costa Teixeira – 2005
27/82
IC-UNICAMP
DTD: Declaração Interna
<!DOCTYPE endereco [
<!ELEMENT endereco (nome,rua,numero,bairro,cidade,estado)>
<!ELEMENT nome
(#PCDATA)>
<!ELEMENT rua
(#PCDATA)>
<!ELEMENT numero
(#PCDATA)>
<!ELEMENT bairro
(#PCDATA)>
<!ELEMENT cidade
(#PCDATA)>
<!ELEMENT estado
(#PCDATA)>
]>
<endereco>
<nome>Fabiano Costa Teixeira</nome>
<rua>Albert Einstein</rua>
<numero>1251</numero>
<bairro>UNICAMP</bairro>
<cidade>Campinas</cidade>
<estado>SP</estado>
</endereco>
Web Services – Fabiano Costa Teixeira – 2005
28/82
IC-UNICAMP
DTD: Declaração Externa
<!DOCTYPE endereco SYSTEM “padrao.dtd”>
<endereco>
<nome>Fabiano Costa Teixeira</nome>
<rua>Albert Einstein</rua>
<numero>1251</numero>
<bairro>UNICAMP</bairro>
<cidade>Campinas</cidade>
<estado>SP</estado>
</endereco>
<!ELEMENT endereco (nome,rua,numero,bairro,cidade,estado)>
<!ELEMENT nome
<!ELEMENT rua
<!ELEMENT numero
<!ELEMENT bairro
<!ELEMENT cidade
<!ELEMENT estado
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
(#PCDATA)>
Web Services – Fabiano Costa Teixeira – 2005
padrao.dtd
29/82
IC-UNICAMP
DTD: Ocorrência de Elementos
• Define o número de vezes que um
determinado elemento deve aparecer;
• É representado por um símbolo que deve
aparecer imediatamente após o elemento;
– ?: Elemento opcional;
– +: Elemento deve aparecer pelo menos uma vez;
– *: Elemento pode aparecer zero ou mais vezes;
• Exemplo:
<element empregado (nome, departamento, dependente*)>
<element nome
(#PCDATA)>
<element departamento (#PCDATA)>
<element dependente
(#PCDATA)>
Web Services – Fabiano Costa Teixeira – 2005
30/82
IC-UNICAMP
DTD: Seleção de Elemento
• Uma seqüência de elementos pode conter
uma condição do tipo “um ou outro”;
• Essa condição deve aparecer entre
elementos:
– |: Indica a escolha de um dos elementos;
• Exemplo:
<element empregado (nome, departamento, (filho|filha)*)>
<element nome
(#PCDATA)>
<element departamento (#PCDATA)>
<element filho
(#PCDATA)>
<element filha
(#PCDATA)>
Web Services – Fabiano Costa Teixeira – 2005
31/82
IC-UNICAMP
XML Schemas
• Inicialmente proposta pela Microsoft;
• Tornou uma recomendação da W3C em Maio
de 2001;
• Sucessora do DTD;
• Escrita em XML:
– <schema> deve ser o elemento root;
– É possível utilizar o mesmo editor XML;
• Suporta tipos de dados;
Web Services – Fabiano Costa Teixeira – 2005
32/82
IC-UNICAMP
XML Schemas: Elemento Simples
• Elemento que contêm somente texto;
• Não contém outros elementos ou atributos;
• Expressão “somente texto” quer dizer que
entre as tag’s de início e fim do elemento não
existe outros elementos. No entanto o
elemento especificado por ser de um
determinado tipo de dado (string, date, etc);
• Exemplo:
<xs:element name=“nome” type=“xs:string”>
<xs:element name=“idade” type=“xs:integer”>
<xs:element name=“contrato” type=“xs:date”>
<nome>Fabiano Costa Teixeira</nome>
<idade>18</idade>
<contrato>2005-09-22</contrato>
Web Services – Fabiano Costa Teixeira – 2005
33/82
IC-UNICAMP
XML Schemas: Atributos
• Elementos simples não possuem atributos;
• Se um elemento possui atributo ele é
considerado um elemento complexo;
• Declaração de atributos:
<xs:atribute name=“sexo” type=“xs:string”
• Um atributo pode ser opcional ou requerido:
<xs:atribute name=“sexo” type=“xs:string” use=“optional”>
<xs:atribute name=“sexo” type “xs:string” use=“required”>
Web Services – Fabiano Costa Teixeira – 2005
34/82
IC-UNICAMP
XML Schemas: Restrições
• Através de XML Schemas é possível definir
para cada elemento as restrições quanto ao
conteúdo do mesmo:
<xs:element name=“idade”>
<xs:simpleType>
<xs:restriction base=“xs:integer”>
<xs:minInclusive value”0”/>
<xs:maxInclusive value=“100”/>
</xs:restriction>
</xs:simpleType>
<xs:/element>
• Outros tipos de restrições como enumeração
e padrões são também aceitos;
Web Services – Fabiano Costa Teixeira – 2005
35/82
IC-UNICAMP
XML Schemas: Elem. Complexos
• Elementos complexos podem ter outros
elementos e/ou atributos;
• Exemplo de um elemento complexo:
<aluno>
<nome>Fabiano Costa Teixeira</nome>
<instituto>IC</instituto>
</aluno>
• Declaração:
<xs:element name=“aluno”>
<xs:ComplexType>
<xs:sequence>
<xs:element name=“nome” type=“xs:string”>
<xs:element name=“instituto” type=“xs:string”
</xs:sequence>
</xs:complexType>
</xs:element>
Web Services – Fabiano Costa Teixeira – 2005
36/82
IC-UNICAMP
XML Schemas: Tipos de Dados
• Quando informações são trocadas é
necessário que o emissor e o receptor tenham
a mesma expectativa a respeito do conteúdo;
• Com XML Schemas o emissor irá inserir dados
de forma que o receptor possa entender;
• Uma data do tipo 01-09-2005 pode ser
interpretada de duas formas (mês sendo 01 ou
09);
• <date type=”date”>2005-09-01</date>
garantiria a comunicação pois o tipo date
sempre é AAAA-MM-DD;
Web Services – Fabiano Costa Teixeira – 2005
37/82
XML Schemas: Tipos de Dados
IC-UNICAMP
• Os tipos de dados mais comuns no XML
Schema são:
–
–
–
–
–
–
xs:string;
xs:decimal;
xs:integer;
xs:boolean;
xs:date;
xs:time;
Web Services – Fabiano Costa Teixeira – 2005
38/82
IC-UNICAMP
Web Services
• Implementam serviços que precisam ser
compartilhados;
• Podem ser desenvolvidos em qualquer
plataforma utilizando qualquer ambiente de
desenvolvimento;
• Devem ser capazes de comunicar com outros
Web Services utilizando protocolos padrões;
• No cenário proposto (no início da
apresentação) os hotéis e as empresas aéreas
podem disponibilizar Web Services com
operações para consulta de preços e
condições;
Web Services – Fabiano Costa Teixeira – 2005
39/82
IC-UNICAMP
Web Services
• O sistema da agência invocaria o Web Service
oferecido pelo hotel ou empresa aéra,
efetuando a consulta desejada;
• Middleware baseado em três padrões:
– Simple Object Access Protocol (SOAP);
– Web Services Description Language (WSDL);
– UDDI (Universal Description, Discovery and
Integration);
Web Services – Fabiano Costa Teixeira – 2005
40/82
IC-UNICAMP
Web Services: Arquitetura
• Camada de Transporte
– HTTP;
– SMTP;
– Etc;
• Camada de Mensagens:
– SOAP;
• Camada de Dados:
– XML (RPC Style, Document
Style);
• Camada de descrição:
– WSDL;
• Camada de descoberta:
– UDDI;
Web Services – Fabiano Costa Teixeira – 2005
41/82
IC-UNICAMP
Web Services: Papéis
• Provedor de Serviços: Disponibiliza um
serviço Web para que esse possa ser
invocado por um outro software;
• Registro de Serviços: Repositório que
mantém e fornece informações sobre Web
Services;
• Cliente de Serviços: Aplicação que localiza
um serviço, implementa sua interface e invoca
o serviço;
Web Services – Fabiano Costa Teixeira – 2005
42/82
IC-UNICAMP
Web Services: Papéis
Web Services – Fabiano Costa Teixeira – 2005
43/82
IC-UNICAMP
SOAP
• Simple Object Access Protocol;
• Versão 1.1 foi sugerida em maio de 2000 pela
IBM, Microsoft, etc;
• A especificação da versão 1.2 foi liberada em
24 de junho de 2003;
• Protocolo padrão baseado em XML para trocar
mensagens entre aplicações;
• Não está vinculado a nenhuma plataforma
específica, linguagem de programação e rede;
Web Services – Fabiano Costa Teixeira – 2005
44/82
IC-UNICAMP
SOAP: Por quê?
• Permite às aplicações a troca de informações;
• A comunicação entre aplicações pode ser feita
utilizando padrões já existentes como RPC,
CORBA, etc;
• Firewalls normalmente bloqueiam esse tipo de
tráfico;
• A melhor forma para efetuar a comunicação
entre aplicações é através do HTTP, pois ele é
suportado por todos os Web Servers ;
Web Services – Fabiano Costa Teixeira – 2005
45/82
IC-UNICAMP
SOAP: Estrutura
Web Services – Fabiano Costa Teixeira – 2005
46/82
SOAP: Estrutura
IC-UNICAMP
• Header:
– SOAP assume que toda mensagem possui um
emissor, um receptor e um número qualquer de
intermediários;
– O header contém informações que podem ser
processadas pelos intermediários;
– Um envelope SOAP pode conter 0 ou n header's;
– Podem ser utilizados para fornecer informações
para:
• Autenticação;
• Transação;
• Etc;
Web Services – Fabiano Costa Teixeira – 2005
47/82
SOAP: Estrutura
IC-UNICAMP
• Body:
– Contém a mensagem que deve ser recebida pelo
destinatário da mensagem;
– Teoricamente pode conter qualquer informação;
– Pode haver dois tipos de interação: DocumentStyle e RPC-Style;
Web Services – Fabiano Costa Teixeira – 2005
48/82
IC-UNICAMP
SOAP: Document-Style
• Nesse tipo de interação as duas
aplicações trocam documentos que
possuem uma estrutura pré-definida;
• O SOAP é utilizado para transportar
essas mensagens de uma aplicação até
a outra;
• Muito utilizado para comunicação
assíncrona, onde o servidor ao receber a
mensagem a insere em uma fila para
processamento posterior;
Web Services – Fabiano Costa Teixeira – 2005
49/82
IC-UNICAMP
SOAP: RPC-Style
• Nesse estilo de interação uma mensagem
SOAP encapsula uma requisição enquanto
outra mensagem encapsula uma resposta;
• O corpo da mensagem de requisição deve
conter:
– O nome do procedimento a ser invocado;
– Os parâmetros de entrada;
• O corpo da mensagem de resposta deve
conter:
– O resultado do processamento;
• O formato do corpo de uma mensagem de
requisição segue uma convenção;
Web Services – Fabiano Costa Teixeira – 2005
50/82
SOAP: Exemplo
IC-UNICAMP
• Método:
– void myMethod(int x, int y);
• Invocação:
– myObject.myMethod(5,10);
• Mensagem SOAP enviada:
<soap: envelope>
<soap:body>
<myMethod>
<x>5</x>
<y>10</y>
<myMethod>
</soap:body>
</soap:envelope>
Web Services – Fabiano Costa Teixeira – 2005
Corpo
Envelope
51/82
IC-UNICAMP
SOAP: Processamento
• O fato de um envelope SOAP separar os
cabeçalhos do corpo da mensagem fornece
uma forma para indicar como a mensagem
deve ser processada pelos diferentes nós
durante o caminho percorrido;
• Cada header possui atributo que descreve a
qual tipo de nó ele está associado;
• Existem três tipos (roles) de nós pré-definidos:
– Next;
– UltimateReceiver;
– None;
Web Services – Fabiano Costa Teixeira – 2005
52/82
IC-UNICAMP
SOAP: Processamento
• Um header pode possuir um atributo
denominado MustUnderstand:
– Se seu valor for igual a “true” o nó que está
processando a mensagem (desde que o nó esteja
classificado no role para o qual o header está
indicado) deverá, obrigatoriamente, processar o
bloco. Se não for possível deve ser gerada uma
mensagem de erro;
Web Services – Fabiano Costa Teixeira – 2005
53/82
IC-UNICAMP
SOAP: Extensibilidade
• SOAP é um “framework” que tem uma
preocupação com extensibilidade;
• Uma feature é uma extensão do SOAP
framework;
• Uma feature pode incluir recursos como
confiabilidade, segurança, roteamento, etc;
• O modelo de processamento do SOAP inclui
um mecanismo necessário para implementar
uma ou mais features através de um bloco
header;
• A “sintaxe” de um header em conjunto com
sua semântica cria o que é chamado de
SOAP Module;
Web Services – Fabiano Costa Teixeira – 2005
54/82
IC-UNICAMP
SOAP: Binding
• É necessária uma forma para transportar essa
mensagem SOAP entre dois nós;
• O transporte da mensagem é tipicamente
efetuado sobre o HTTP;
• Outros protocolos (como SMTP) também
podem ser utilizados;
• A especificação de qual protocolo a ser
utilizado no transporte é o que é chamado de
Binding;
• A mensagem SOAP será encapsulada pelo
protocolo selecionado para efetuar o
transporte;
Web Services – Fabiano Costa Teixeira – 2005
55/82
IC-UNICAMP
SOAP: Binding
• Como exemplo, a primitiva POST do HTTP
poderia ser utilizada em uma invocação RPC:
HTTP Post
SOAP Envelope
SOAP Header
/Exemplo Contexto
HTTP/1.1
POST
Host: www.exemplo.com.br
Soaptext/xml;
Body
Content-Type:
charset=“utf-8”
Requisitante do Serviço
Fornecedor do Serviço
Nome do Proc.
SOAPAction:”Some-URI”
HTTP
HTTP
Parâmetro 1
SOAP Engine
SOAP Engine
Engine<soap: envelope>
Engine
<soap:body>
HTTP
<myMethod>
Implementação
Implementação
do Serviço
SOAP<x>5</x>
Envelope
do Cliente
SOAP Header
<y>10</y>
Contexto
<myMethod>
Soap Envelope
</soap:body>
Resposta
</soap:envelope>
Web Services – Fabiano Costa Teixeira – 2005
56/82
IC-UNICAMP
SOAP: WS-Routing
• Usando o modelo de extensibilidade SOAP,
especificações baseadas em SOAP são
projetadas para fornecer ambientes de troca
de mensagens mais ricos;
• WS-Routing é um protocolo baseado no
SOAP para efetuar o roteamento de
mensagens SOAP;
• O caminho completo de uma mensagem é
estabelecido;
• O “caminho de volta” da mensagem também
pode ser definido;
Web Services – Fabiano Costa Teixeira – 2005
57/82
SOAP: WS-Routing
IC-UNICAMP
• Define um novo header (path) e o associa ao
modelo de processamento;
• Considerando que um determinado nó A
deseja enviar uma mensagem para D através
de B e C:
• Para expressar rotas o path contém os
seguintes elementos:
–
–
–
–
from: Contém o emissor original da mensagem;
to: Contém o destino final da mensagem;
fwd: Contém o caminho de encaminhamento;
rev: Contém o caminho reverso (volta);
Web Services – Fabiano Costa Teixeira – 2005
58/82
IC-UNICAMP
SOAP: WS-Routing
• O elemento rev é definido para possibilitar
troca de mensagens two-way;
• Os elementos fwd e rev possuem elementos
via para descrever cada intermediário;
• Exemplo:
<s:Header>
<m:path xmlns:m=“http://schemas.xmlsoap.org/rp/”>
<m:to>http://d.com</m:to>
<m:fwd>
<m:via>http://.b.com</m:via>
<m:via>http://c.com</m:via>
</m:fwd>
<m:from>http://a.com</m:from>
</m:path>
</s:Header>
Web Services – Fabiano Costa Teixeira – 2005
59/82
IC-UNICAMP
SOAP: WS-Routing
• Quando um intermediário recebe uma
mensagem SOAP ele analisa o cabeçalho e
verifica a necessidade de encaminhamento;
• Se existe elementos via dentro de fwd então
ele remove o primeiro da lista;
• Se não existe elementos via dentro de fwd
então esse nó é o destino final da
mensagem;
• Se após a remoção restou algum elemento
via dentro de fwd então a mensagem deve
ser encaminhada para o intermediário
indicado no topo da lista;
Web Services – Fabiano Costa Teixeira – 2005
60/82
IC-UNICAMP
SOAP: WS-Routing
• Se após a remoção não sobrou nenhum
elemento via dentro de fwd:
– Se não houver elemento to então o intermediário
atual é o destino final da mensagem;
– Se houver um elemento to então o intermediário
deve encaminhar a mensagem para o destino
final;
• Se o elemento rev existir, o caminho reverso
é montado automaticamente quando a
mensagem passa pelo intermediário:
– O elemento via é retirado do topo da lista fwd e
inserido no topo da lista rev;
Web Services – Fabiano Costa Teixeira – 2005
61/82
IC-UNICAMP
WSDL
• Web Services Definition Language;
• Originalmente criada pela Microsoft, IBM e
Ariba;
• Documento escrito em XML utilizado para
descrever Web Services;
• WSDL está para Web Services assim como
IDL está para Corba;
• Além de especificar as operações oferecidas
por um determinado serviço a WSDL também
descreve como acessar tal serviço;
Web Services – Fabiano Costa Teixeira – 2005
62/82
IC-UNICAMP
WSDL: Estrutura
Parte Abstrata
Parte Concreta
Web Services – Fabiano Costa Teixeira – 2005
63/82
IC-UNICAMP
WSDL: Estrutura (Parte Abstrata)
• types:
– Definem os tipos de dados que serão utilizados
pelo Web Service;
– Para obter a máxima neutralidade de plataforma
WSDL utiliza a mesma sintaxe do XML Schema
para definir tipos de dados;
• messages:
– Unidade de comunicação entre os Web Services;
– Representam a troca de informações entre eles;
– Composta por parts, cada qual representa um
parâmetro a ser enviado;
Web Services – Fabiano Costa Teixeira – 2005
64/82
IC-UNICAMP
WSDL: Estrutura (Parte Abstrata)
• portType:
– O elemento “muito importante” do WSDL;
– Ele define o Web Service (quais operações são
oferecidas e as mensagens envolvidas;
– Pode ser comparado a uma classe;
• operation:
– Define uma operação que é disponibilizada pelo
Web Service;
– Pode ser comparado a um método;
Web Services – Fabiano Costa Teixeira – 2005
65/82
IC-UNICAMP
WSDL: Estrutura (Parte Abstrata)
<definitions>
<message name=“dadosLivro”>
<part name=“isbn” type=“xs:string”/>
</message>
<message name=“estoqueAtual”>
<part name=“estoque” type=“xs:integer”/>
</message>
<portType name=“informacoesLivro”>
<operation name=“requisitaEstoque“>
<input message=“dadosLivro”/>
<output message=“estoqueAtual”>
</operation>
</portType>
...
Web Services – Fabiano Costa Teixeira – 2005
66/82
IC-UNICAMP
WSDL: Estrutura (Parte Concreta)
• binding:
– Especifica o mecanismo utilizado por um serviço
para se comunicar com um cliente;
– Define o tipo de interação RPC-Style ou
Document-Style;
– Define o serviço exato a ser invocado;
• port:
– EndPoint;
– Combina um binding com um endereço de rede;
– O endereço de rede refere-se ao local onde o a
implementação pode ser acessada;
Web Services – Fabiano Costa Teixeira – 2005
67/82
IC-UNICAMP
WSDL: Estrutura (Parte Concreta)
...
<binding name=“livroBinding” type=“informacoesLivro”>
<soap:binding style=“rpc”
transporte=“http://schemas.xmlsoap.org/soap/http”/>
<operation name=“requisitaEstoque”>
<soap:operation soapAction=“http://exemplo.com/estoque”/>
<input>
<soap:body use=“literal”>
</input>
<output>
<soap:body use=“literal”>
</output>
</operation>
</binding>
<service name=“servicoEstoque”>
<port name=“estoquePort” binding=“livroBinding”>
<soap:address location=“http://exemplo.com/consultaEstoque”/>
</port>
</service>
</definitions>
Web Services – Fabiano Costa Teixeira – 2005
68/82
IC-UNICAMP
WSDL: Stub’s
• A partir do WSDL um compilador gera as
stub’s para os aplicativos cliente e servidor;
• A stub oferece a “ligação” entre o aplicativo e
o módulo SOAP;
• No aplicativo cliente, a stub fornece uma
interface de forma que a chamada fica
semelhante a uma local;
• No aplicativo servidor, a stub ou (skeleton)
recebe uma chamada e invoca o método
desejado;
Web Services – Fabiano Costa Teixeira – 2005
69/82
IC-UNICAMP
WSDL: Stub’s
WSDL
Compilador
WSDL
(Lado do cliente)
Compilador
WSDL
(Lado do serv.)
Aplicação
Cliente
Aplicação
Servidora
Stub
Skeleton
Web Services – Fabiano Costa Teixeira – 2005
70/82
IC-UNICAMP
Web Services: Arquitetura
HTTP Post
SOAP Envelope
SOAP Header
Contexto
Requisitante do Serviço
SOAP Engine
Soap Body
Nome do Proc.
HTTP
Engine
Parâmetro 1
Fornecedor do Serviço
HTTP
Engine
SOAP Engine
HTTP
Stub
Implementação
do Cliente
SOAP Envelope
SOAP Header
Contexto
Skeleton
Implementação
do Servidor
Soap Envelope
Resposta
Web Services – Fabiano Costa Teixeira – 2005
71/82
UDDI
IC-UNICAMP
• Os clientes precisam de uma forma para
encontrar Web Services que atendem a uma
determinada necessidade;
• Exemplo:
– A agência de turismo precisa descobrir quais
hotéis oferecem consultas através de Web
Services;
• É necessário obter informações sobre o
serviço oferecido;
• UDDI (Universal Description, Discovery and
Integration) oferece a solução para tais
questões;
Web Services – Fabiano Costa Teixeira – 2005
72/82
IC-UNICAMP
UDDI: Informações
• Páginas brancas:
– Busca de organizações pelo nome;
– Informações sobre contato (e-mail, telefone, etc);
– Informações sobre os serviços oferecidos
• Páginas amarelas:
– Busca de organizações ou serviços por categoria;
– Categorias poder ser padronizadas ou definidas
pelo usuário;
• Páginas verdes:
– Busca de serviços com base em características
técnicas;
Web Services – Fabiano Costa Teixeira – 2005
73/82
IC-UNICAMP
UDDI: Estrutura de Dados
Web Services – Fabiano Costa Teixeira – 2005
74/82
IC-UNICAMP
UDDI: Estrutura de Dados
• businessEntity:
– Descreve uma organização que fornece Web
Services;
– Armazena nome da empresa, descrição,
contato,etc;
• businessService:
– Descreve um grupo de serviços oferecidos pela
empresa;
– Incluem informações de classificação;
– Cada serviço pode estar disponível em múltiplos
endereços, bindings diferentes, etc;
Web Services – Fabiano Costa Teixeira – 2005
75/82
IC-UNICAMP
UDDI: Estrutura de Dados
• bindingTemplate:
– Fornece as informações técnicas necessárias
para acessar um determinado serviço;
– Endereço no qual o Web Service se encontra
disponível;
– Referência para informações detalhadas
(tModels);
• tModels:
– “Container” genérico para qualquer tipo de
especificação;
– Pode ser referenciado por várias entidades;
– Aponta para um overviewDoc o qual contém a
descrição de uma interface (WSDL);
– Possibilidade de Binding dinâmico;
Web Services – Fabiano Costa Teixeira – 2005
76/82
IC-UNICAMP
UDDI: API’s
• Registros UDDI possuem três tipos de
usuários para os quais ele expõe suas API’s:
– Provedores: Para publicarem os serviços
oferecidos;
– Consumidores: Para procurarem por serviços
desejados;
– Outros registros UDDI: Para trocarem
informações;
• UDDI Inquiry API;
• UDDI Publishers API;
• etc;
Web Services – Fabiano Costa Teixeira – 2005
77/82
IC-UNICAMP
UDDI: Registros Públicos e
Privados
• Quando o UDDI foi lançado era esperado
que ele funcionasse como um UBR
(Universal Business Registry);
• Essa perspectiva foi suportada por poucas
empresas. Ex: IBM e Microsoft;
• UBR’s precisam seguir regras definidas pela
especificação UDDI e são supervisionados
pela OASIS;
• O conteúdo de um UBR precisa ser
consistente com o conteúdo dos demais e
alterações de conteúdos devem ser
propagados a eles;
Web Services – Fabiano Costa Teixeira – 2005
78/82
IC-UNICAMP
UDDI: Registros Públicos e
Privados
http://uddi.microsoft.com
Web Services – Fabiano Costa Teixeira – 2005
79/82
IC-UNICAMP
UDDI: Registros Públicos e
Privados
• Registros públicos:
– Provê acesso público ao registro;
– Pode ser disponibilizado como um Web Site bem
conhecido;
– Não precisa ser necessariamente um UBR;
• Registros privados:
– Registro interno isolado dentro de uma intranet;
• Registros compartilhados:
– É administrado por ambiente controlado;
– Pode ser compartilhado com uma rede de
parceiros;
Web Services – Fabiano Costa Teixeira – 2005
80/82
IC-UNICAMP
Conclusão
• Pelo fato de serem baseados em XML os
Web Services se tornam uma tecnologia
bastante atrativa para ambientes
heterogêneos;
• Processos B2B ganharam um forte aliado a
fim de prover soluções sólidas;
• O movimento de grandes empresas
demonstram uma forte “aposta” na
tecnologia;
• ComputerWorld de julho/2003 previu um
investimento em Web Services de U$ 34
Bilhões para 2007!
Web Services – Fabiano Costa Teixeira – 2005
81/82
IC-UNICAMP
Fabiano Costa Teixeira
[email protected]
Web Services – Fabiano Costa Teixeira – 2005
82/82