Web Services

1
Web Services Aluno Fabiano Costa
Teixeira Professor Dr. Edmundo R. M. Madeira
2
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

3
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?
4
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

5
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?
6
Agenda

• Durante a apresentação serão abordados os
  seguintes assuntos
• W3C
• XML
• Web Services
• SOAP
• WSDL
• UDDI

7
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

8
W3C O que é?

• 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/Con
  sortium/Member/List

9
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

10
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

11
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

12
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

13
W3C Publicação da Nota

• Muitas vezes uma submissão ao W3C torna-se 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

14
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

15
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

16
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

17
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

18
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

19
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 TAGs

20
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

21
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

22
XML x HTML

• Trecho HTML
• ltpgtltbgtFabiano Costa Teixeiralt/bgt
• ltbrgt
• Av. Albert Einstein, 1251
• ltbrgt
• UNICAMP. Campinas SPlt/pgt

23
XML x HTML

• Resultado voltado para seres humanos

24
XML x HTML

• Trecho XML
• ltenderecogt
• ltnomegtFabiano Costa Teixeiralt/nomegt
• ltruagtAlbert Einsteinlt/ruagt
• ltnumerogt1251lt/numerogt
• ltbairrogtUNICAMPlt/bairrogt
• ltcidadegtCampinaslt/cidadegt
• ltestadogtSPlt/estadogt
• lt/enderecogt
• Possível entendimento para máquinas!

25
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

26
Regras para Documentos XML

• 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

27
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

28
DTD Declaração Interna

• lt!DOCTYPE endereco
• lt!ELEMENT endereco (nome,rua,numero,bairro,
  cidade,estado)gt
• lt!ELEMENT nome (PCDATA)gt
• lt!ELEMENT rua (PCDATA)gt
• lt!ELEMENT numero (PCDATA)gt
• lt!ELEMENT bairro (PCDATA)gt
• lt!ELEMENT cidade (PCDATA)gt
• lt!ELEMENT estado (PCDATA)gt
• gt
• ltenderecogt
• ltnomegtFabiano Costa Teixeiralt/nomegt
• ltruagtAlbert Einsteinlt/ruagt
• ltnumerogt1251lt/numerogt
• ltbairrogtUNICAMPlt/bairrogt
• ltcidadegtCampinaslt/cidadegt
• ltestadogtSPlt/estadogt
• lt/enderecogt

29
DTD Declaração Externa

• lt!DOCTYPE endereco SYSTEM padrao.dtdgt
• ltenderecogt
• ltnomegtFabiano Costa Teixeiralt/nomegt
• ltruagtAlbert Einsteinlt/ruagt
• ltnumerogt1251lt/numerogt
• ltbairrogtUNICAMPlt/bairrogt
• ltcidadegtCampinaslt/cidadegt
• ltestadogtSPlt/estadogt
• lt/enderecogt
• lt!ELEMENT endereco (nome,rua,numero,bairro,cidade,
  estado)gt
• lt!ELEMENT nome (PCDATA)gt
• lt!ELEMENT rua (PCDATA)gt
• lt!ELEMENT numero (PCDATA)gt
• lt!ELEMENT bairro (PCDATA)gt
• lt!ELEMENT cidade (PCDATA)gt
• lt!ELEMENT estado (PCDATA)gt

padrao.dtd
30
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
• ltelement empregado (nome, departamento,
  dependente)gt
• ltelement nome (PCDATA)gt
• ltelement departamento (PCDATA)gt
• ltelement dependente (PCDATA)gt

31
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
• ltelement empregado (nome, departamento,
  (filhofilha))gt
• ltelement nome (PCDATA)gt
• ltelement departamento (PCDATA)gt
• ltelement filho (PCDATA)gt
• ltelement filha (PCDATA)gt

32
XML Schemas

• Inicialmente proposta pela Microsoft
• Tornou uma recomendação da W3C em Maio de 2001
• Sucessora do DTD
• Escrita em XML
• ltschemagt deve ser o elemento root
• É possível utilizar o mesmo editor XML
• Suporta tipos de dados

33
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
  tags 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
• ltxselement namenome typexsstringgt
• ltxselement nameidade typexsintegergt
• ltxselement namecontrato typexsdategt
• ltnomegtFabiano Costa Teixeiralt/nomegt
• ltidadegt18lt/idadegt
• ltcontratogt2005-09-22lt/contratogt

34
XML Schemas Atributos

• Elementos simples não possuem atributos
• Se um elemento possui atributo ele é considerado
  um elemento complexo
• Declaração de atributos
• ltxsatribute namesexo typexsstring
• Um atributo pode ser opcional ou requerido
• ltxsatribute namesexo typexsstring
  useoptionalgt
• ltxsatribute namesexo type xsstring
  userequiredgt

35
XML Schemas Restrições

• Através de XML Schemas é possível definir para
  cada elemento as restrições quanto ao conteúdo do
  mesmo
• ltxselement nameidadegt
• ltxssimpleTypegt
• ltxsrestriction basexsintegergt
• ltxsminInclusive value0/gt
• ltxsmaxInclusive value100/gt
• lt/xsrestrictiongt
• lt/xssimpleTypegt
• ltxs/elementgt
• Outros tipos de restrições como enumeração e
  padrões são também aceitos

36
XML Schemas Elem. Complexos

• Elementos complexos podem ter outros elementos
  e/ou atributos
• Exemplo de um elemento complexo
• ltalunogt
• ltnomegtFabiano Costa Teixeiralt/nomegt
• ltinstitutogtIClt/institutogt
• lt/alunogt
• Declaração
• ltxselement namealunogt
• ltxsComplexTypegt
• ltxssequencegt
• ltxselement namenome typexsstringgt
• ltxselement nameinstituto
  typexsstring
• lt/xssequencegt
• lt/xscomplexTypegt
• lt/xselementgt

37
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)
• ltdate typedategt2005-09-01lt/dategt garantiria a
  comunicação pois o tipo date sempre é AAAA-MM-DD

38
XML Schemas Tipos de Dados

• Os tipos de dados mais comuns no XML Schema são
• xsstring
• xsdecimal
• xsinteger
• xsboolean
• xsdate
• xstime

39
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

40
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)

41
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

42
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

43
Web Services Papéis
44
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

45
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

46
SOAP Estrutura
47
SOAP Estrutura

• 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

48
SOAP Estrutura

• 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
  Document-Style e RPC-Style

49
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

50
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

51
SOAP Exemplo

• Método
• void myMethod(int x, int y)
• Invocação
• myObject.myMethod(5,10)
• Mensagem SOAP enviada
• ltsoap envelopegt
• ltsoapbodygt
• ltmyMethodgt
• ltxgt5lt/xgt
• ltygt10lt/ygt
• ltmyMethodgt
• lt/soapbodygt
• lt/soapenvelopegt

52
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

53
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

54
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

55
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

56
SOAP Binding

• Como exemplo, a primitiva POST do HTTP poderia
  ser utilizada em uma invocação RPC

HTTP Post
SOAP Envelope
SOAP Header
Contexto
Soap Body
Requisitante do Serviço
Fornecedor do Serviço
Nome do Proc.
HTTP Engine
HTTP Engine
Parâmetro 1
SOAP Engine
SOAP Engine
HTTP
Implementação do Serviço
Implementação do Cliente
SOAP Envelope
SOAP Header
Contexto
Soap Envelope
Resposta
57
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

58
SOAP WS-Routing

• 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)

59
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
• ltsHeadergt
• ltmpath xmlnsmhttp//schemas.xmlsoap.org/rp/gt
  
• ltmtogthttp//d.comlt/mtogt
• ltmfwdgt
• ltmviagthttp//.b.comlt/mviagt
• ltmviagthttp//c.comlt/mviagt
• lt/mfwdgt
• ltmfromgthttp//a.comlt/mfromgt
• lt/mpathgt
• lt/sHeadergt

60
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

61
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

62
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

63
WSDL Estrutura
64
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

65
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

66
WSDL Estrutura (Parte Abstrata)

• ltdefinitionsgt
• ltmessage namedadosLivrogt
• ltpart nameisbn typexsstring/gt
• lt/messagegt
• ltmessage nameestoqueAtualgt
• ltpart nameestoque typexsinteger/gt
• lt/messagegt
• ltportType nameinformacoesLivrogt
• ltoperation namerequisitaEstoquegt
• ltinput messagedadosLivro/gt
• ltoutput messageestoqueAtualgt
• lt/operationgt
• lt/portTypegt
• ...

67
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

68
WSDL Estrutura (Parte Concreta)

• ...
• ltbinding namelivroBinding typeinformacoesLivr
  ogt
• ltsoapbinding stylerpc transportehttp//sc
  hemas.xmlsoap.org/soap/http/gt
• ltoperation namerequisitaEstoquegt
• ltsoapoperation soapActionhttp//exemplo.com/
  estoque/gt
• ltinputgt
• ltsoapbody useliteralgt
• lt/inputgt
• ltoutputgt
• ltsoapbody useliteralgt
• lt/outputgt
• lt/operationgt
• lt/bindinggt
• ltservice nameservicoEstoquegt
• ltport nameestoquePort bindinglivroBindinggt
• ltsoapaddress locationhttp//exemplo.com/cons
  ultaEstoque/gt
• lt/portgt
• lt/servicegt
• lt/definitionsgt

69
WSDL Stubs

• A partir do WSDL um compilador gera as stubs
  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

70
WSDL Stubs
WSDL
Compilador WSDL (Lado do cliente)
Compilador WSDL (Lado do serv.)
Aplicação Cliente
Aplicação Servidora
Skeleton
Stub
71
Web Services Arquitetura
HTTP Post
SOAP Envelope
SOAP Header
Contexto
Soap Body
Requisitante do Serviço
Fornecedor do Serviço
Nome do Proc.
HTTP Engine
HTTP Engine
Parâmetro 1
SOAP Engine
SOAP Engine
HTTP
SOAP Envelope
Stub
Skeleton
SOAP Header
Contexto
Implementação do Cliente
Implementação do Servidor
Soap Envelope
Resposta
72
UDDI

• 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

73
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

74
UDDI Estrutura de Dados
75
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

76
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

77
UDDI APIs

• Registros UDDI possuem três tipos de usuários
  para os quais ele expõe suas APIs
• 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

78
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
• UBRs 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

79
UDDI Registros Públicos e Privados
http//uddi.microsoft.com
80
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

81
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!

82

• Fabiano Costa Teixeira
• fabiano.teixeira_at_ic.unicamp.br