IC-UNICAMP Web Services – Fabiano Costa Teixeira – 2005 1/82 Web Services Aluno: Fabiano Costa...

Web Services – Fabiano Costa Teixeira – 2005 1/82

IC-UNICAMP

Web ServicesAluno: Fabiano Costa Teixeira

Professor: Dr. Edmundo R. M. Madeira


IC-UNICAMP CenárioCená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;



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



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


IC-UNICAMPCenárioCená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?


IC-UNICAMP AgendaAgenda

• Durante a apresentação serão abordados os seguintes assuntos:

– W3C– XML– Web Services– SOAP– WSDL– UDDI


IC-UNICAMP W3C: O que é?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;



• 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



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


IC-UNICAMP W3C: RecomendaçõesW3C: 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;


IC-UNICAMP W3C: Passos da RecomendaçãoW3C: 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;


IC-UNICAMP W3C: SubmissãoW3C: 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;


IC-UNICAMP W3C: Publicação da NotaW3C: 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;


IC-UNICAMP W3C: Grupo de TrabalhoW3C: 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;


IC-UNICAMP W3C: Rascunhos de TrabalhoW3C: 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;


IC-UNICAMP W3C: Recomendações CandidatasW3C: 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;


IC-UNICAMP W3C: Recomendação PropostaW3C: 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;


IC-UNICAMP W3C: RecomendaçãoW3C: 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;


IC-UNICAMP XMLXML

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


IC-UNICAMPXMLXML

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


IC-UNICAMP XML x HTMLXML 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;



• Trecho HTML:

<p><b>Fabiano Costa Teixeira</b><br>Av. Albert Einstein, 1251<br>UNICAMP. Campinas – SP</p>



• Resultado voltado para seres humanos;



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


IC-UNICAMP Utilização da XMLUtilizaçã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;


IC-UNICAMP Regras para Documentos XMLRegras 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;


IC-UNICAMP DTDDTD

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


IC-UNICAMP DTD: Declaração InternaDTD: 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>


IC-UNICAMPDTD: Declaração ExternaDTD: 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 (#PCDATA)><!ELEMENT rua (#PCDATA)><!ELEMENT numero (#PCDATA)><!ELEMENT bairro (#PCDATA)><!ELEMENT cidade (#PCDATA)><!ELEMENT estado (#PCDATA)>

padrao.dtd


IC-UNICAMP DTD: Ocorrência de ElementosDTD: 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)>


IC-UNICAMPDTD: Seleção de ElementoDTD: 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)>


IC-UNICAMP XML SchemasXML 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;


IC-UNICAMPXML Schemas: Elemento SimplesXML 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>


IC-UNICAMPXML Schemas: AtributosXML 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”>


IC-UNICAMPXML Schemas: RestriçõesXML 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;


IC-UNICAMPXML Schemas: Elem. ComplexosXML 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>


IC-UNICAMP XML Schemas: Tipos de DadosXML 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;


IC-UNICAMPXML Schemas: Tipos de DadosXML Schemas: Tipos de Dados

• Os tipos de dados mais comuns no XML Schema são:– xs:string;– xs:decimal;– xs:integer;– xs:boolean;– xs:date;– xs:time;


IC-UNICAMPWeb ServicesWeb 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;


IC-UNICAMPWeb ServicesWeb 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);


IC-UNICAMPWeb Services: ArquiteturaWeb 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;


IC-UNICAMPWeb Services: PapéisWeb 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;


IC-UNICAMPWeb Services: PapéisWeb Services: Papéis


IC-UNICAMPSOAPSOAP

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


IC-UNICAMPSOAP: Por quê?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 ;


IC-UNICAMPSOAP: EstruturaSOAP: 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;



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


IC-UNICAMPSOAP: Document-StyleSOAP: 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;


IC-UNICAMPSOAP: RPC-StyleSOAP: 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;


IC-UNICAMPSOAP: ExemploSOAP: Exemplo

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

Corpo Envelope


IC-UNICAMPSOAP: ProcessamentoSOAP: 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;


IC-UNICAMPSOAP: ProcessamentoSOAP: 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;


IC-UNICAMPSOAP: ExtensibilidadeSOAP: 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;


IC-UNICAMPSOAP: BindingSOAP: 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;


IC-UNICAMPSOAP: BindingSOAP: Binding

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

Implementaçãodo Cliente

SOAP Engine HTTP Engine

Requisitante do Serviço

Implementaçãodo Serviço

HTTP Engine SOAP Engine

Fornecedor do Serviço

HTTP Post

SOAP Envelope

SOAP Header

Soap BodyNome do Proc.

Parâmetro 1

Contexto

SOAP Envelope

SOAP Header

Soap Envelope Resposta

Contexto

HTTP

POST /Exemplo HTTP/1.1Host: www.exemplo.com.brContent-Type: text/xml; charset=“utf-8”SOAPAction:”Some-URI”<soap: envelope>

<soap:body><myMethod>

<x>5</x><y>10</y>

<myMethod></soap:body>

</soap:envelope>


IC-UNICAMPSOAP: WS-RoutingSOAP: 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;



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



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



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



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


IC-UNICAMPWSDLWSDL

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


IC-UNICAMPWSDL: EstruturaWSDL: Estrutura

Parte Abstrata

Parte Concreta


IC-UNICAMPWSDL: Estrutura (Parte Abstrata)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;



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



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

...


IC-UNICAMPWSDL: Estrutura (Parte Concreta)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;


IC-UNICAMPWSDL: Estrutura (Parte Concreta)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>


IC-UNICAMPWSDL: Stub’sWSDL: 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;


IC-UNICAMPWSDL: Stub’sWSDL: Stub’s

WSDL

CompiladorWSDL

(Lado do cliente)

CompiladorWSDL

(Lado do serv.)

AplicaçãoCliente

AplicaçãoServidora

SkeletonStub


IC-UNICAMPWeb Services: ArquiteturaWeb Services: Arquitetura

Implementaçãodo Cliente

SOAP Engine HTTP Engine

Requisitante do Serviço

HTTP Engine SOAP Engine

Fornecedor do Serviço

HTTP Post

SOAP Envelope

SOAP Header

Soap BodyNome do Proc.

Parâmetro 1

Contexto

SOAP Envelope

SOAP Header

Soap Envelope Resposta

Contexto

HTTP

Stub

Implementaçãodo Servidor

Skeleton


IC-UNICAMPUDDIUDDI

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


IC-UNICAMPUDDI: InformaçõesUDDI: 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;


IC-UNICAMPUDDI: Estrutura de DadosUDDI: 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;



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


IC-UNICAMPUDDI: API’sUDDI: 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;


IC-UNICAMP

UDDI: Registros Públicos e UDDI: Registros Públicos e PrivadosPrivados

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


IC-UNICAMP


http://uddi.microsoft.com


IC-UNICAMP


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


IC-UNICAMP

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

ConclusãoConclusão


IC-UNICAMP

Fabiano Costa [email protected]

IC-UNICAMP Web Services – Fabiano Costa Teixeira – 2005 1/82 Web Services Aluno: Fabiano Costa...

Documents

Transcript of IC-UNICAMP Web Services – Fabiano Costa Teixeira – 2005 1/82 Web Services Aluno: Fabiano Costa...