Conceitos, SOAP, WSDL, UDDI, Exemplos. Programação com Objetos Distribuídos (C. Geyer) Web Services 1

(1)

(2)

 

Autores

 Sérgio Mergen  Cláudio Geyer

 Emanuel Müller Ramos

 

Local

 Instituto de Informática – UFRGS  Versão

 V20

 Maio 2010  cursos:

 Sistemas Operacionais II

(3)

 

Súmula

 conceitos gerais sobre Web Services  conceitos de SOAP

 Introdução à biblioteca Axis  WS no J2EE

 conceitos de WSDL  conceitos de UDDI

 

Observações

(4)

 

Bibliografia

 Coulouris, G. Et al. Sistemas Distribuídos – Conceitos e Projeto.

Bookman, 2007.

 Cap. 19

 CERAMI Ethan. Web Services Essentials - Distributed Applications

with XML-RPC, SOAP, UDDI & WSDL. O'Reilly, 2002.

 NEWCOMER Eric. Understanding Web Services: XML, WSDL,

SOAP, and UDDI. David Chappell Series Editor. 2002.

 Wutka, M. Special Edition Using Java 2 Enterprise Edition. QUE,

2001.

  capítulo 25

 Tutoriais da Sun para J2EE e do NetBeans

(5)

 

Links

 Atividades do W3 em Web Services

  http://www.w3.org/2002/ws/

 XML Protocol Working Group

  http://www.w3.org/2000/xp/Group/

 Projetos WS do grupo Apache

  http://ws.apache.org/

  Implementações de Java SOAP

  Axis 2

  http://ws.apache.org/axis2/   Axis 1

(6)

 

Links

 Links SOAP do W3

  SOAP Message Transmission Optimization Mechanism

  http://www.w3.org/TR/soap12-mtom

  SOAP Resource Representation Header

  http://www.w3.org/TR/soap12-rep

  SOAP Version 1.2 Part 0: Primer

  http://www.w3.org/TR/soap12-part0/

  SOAP Version 1.2 Part 1: Messaging Framework

(7)

 

Links

 Links SOAP do W3

  SOAP Version 1.2 Part 2: Adjuncts

  http://www.w3.org/TR/soap12-part2/

  SOAP Version 1.2 Specification Assertions and Test

Collection

(8)

 

Links

 Links WSDL do W3

  Semantic Annotations for WSDL and XML Schema

  http://www.w3.org/TR/sawsdl

  Web Services Description Language (WSDL) Version 2.0

Part 0: Primer

  http://www.w3.org/TR/wsdl20-primer

Part 1: Core Language

  http://www.w3.org/TR/wsdl20

Part 2: Adjuncts as Recommendation.

(9)

 

Súmula

 Conceitos gerais sobre Web Services

  motivação para o uso de Web Services

  definição   arquitetura

  componentes

(10)

 

Súmula

 Conceitos de SOAP

  Introdução ao SOAP

  Vantagens do SOAP

  Desvantagens do SOAP

  Estrutura de uma mensagem SOAP

  Exemplo de WS/SOAP com Apache Axis

(11)

 

Súmula

 WS no J2EE  Características  Tipos  JAX-WS  RESTFul  WSDL  UDDI

(12)

 

A Internet Tradicional

 Ótima forma para troca de informações  Independência de plataforma

  Abstração do hardware, software e sistema operacional

utilizados

 Problemas:

  WWW era centrada no ser humano

  pessoas acessam, modificam, inserem e removem

documentos remotos

  Aplicações que desejavam trocar informações pela Web

necessitavam utilizar soluções ad-hoc

 Necessidade de estender a Web para suportar esse novo tipo de

interação

(13)

 

Web Services – Objetivos

 Permitir uma comunicação fácil entre diferentes aplicações

utilizando a estrutura já existente da Web

 Determinam um conjunto de mecanismos (padrões, especificões,

etc.)

  que permitam estender a Internet

  para aceitar a troca de informações entre aplicações

 Adicionalmente: permitir que aplicações descubram

automaticamente qual serviço elas desejam utilizar

  Chamada automática de serviços

  Sem nenhuma intervenção do ser humano

(14)

 

Web Services – Conceito

 Um Web Service é uma aplicação que:

  Está disponível através da Internet

  Utiliza padrões baseados em XML para descrever as

mensagens enviadas e recebidas, bem como seus dados

  É independente de hardware, sistema operacional e

linguagem de programação

  Pode ser descrita utilizando XML (WSDL)

  Pode ser encontrada facilmente (usando UDDI por

exemplo)

 OBS.:

 Web Services baseados na arquitetura REST (REST WS)

não seguem exatamente esses conceitos

(15)

 

Exemplo Básico

-  Linguagens Java e C -  SOs Windows e Linux -  Mensagem XML

(16)

 

Arquitetura

 Pode ser descrita de duas formas

  Pelos componentes que a compõem

(17)

(18)

 

Pilha de Protocolos

(19)

 

Nível de transporte

 Responsável por transmitir os dados entre as aplicações

 Pode utilizar protocolos já disponíveis pela internet (HTTP, SMTP,

FTP, etc.)

 

Nível de mensagem

 Define o formato das mensagens enviadas entre as aplicações  Obs.:

 Formato XML puro não garante interoperabilidade entre

(20)

 

Nível de descrição

 Representa a interface de um Web Service aos clientes

  Nome das operações disponíveis

  Parâmetros

  Protocolos do nível de transporte utilizados

  Etc

 

Nível de descoberta

(21)

 

Súmula da parte SOAP

 Conceitos de SOAP

  Introdução ao SOAP

  Vantagens do SOAP

  Desvantagens do SOAP

  Estrutura de uma mensagem SOAP

  Exemplo de WS/SOAP com Apache

(22)

 

O que é SOAP?

 Protocolo para troca de mensagens distribuídas

  Pode ser usado como o nível de mensagem da arquitetura

WS

 Concorrente de IIOP (Corba), JRMP (Java RMI), XML-RPC,

REST-WS e outros

 Proposto a IETF e ao W3

  W3: World Wide Web Consortium

  IETF: organização que publica padrões para Internet como

TCP, FTP, HTTP, …

 Especificação inicial desenvolvida por

  Microsoft, IBM/Lotus, Don Box (guru COM), Dave Winer

(23)

 

Características do SOAP

 Baseado em tecnologias já existentes

  HTTP, SMTP como nível de transporte

  XML

 Utiliza mensagens no formato XML  Unidirecional

 Sem estado

 Não define um modelo de objetos

 Não define um modelo para troca de mensagens  Não está necessariamente ligado a Web Services

(24)

 

Características do SOAP

 Quando usado em chamada de WS

  Aplica modelo requisição – resposta (cliente/servidor) com 2

mensagens SOAP

  Chamada pode ser:

  Síncrona (normal em RPC)   Assíncrona

(25)

 

Vantagens do SOAP

 Firewall Friendly

  uso de protocolos Web como HTTP

 Infraestrutura já conhecida  Amplo suporte a XML

 Suportado por grandes organizações

(26)

 

Vantagens SOAP

 Independe de linguagem (se utilizado seguindo corretamente os

padrões)

  RMI: só Java

  observação: RMI-IIOP permite Java x linguagens com

IIOP

  IIOP: exige biblioteca IIOP para a linguagem

  SOAP:

  somente um parser XML

  mais biblioteca para envio de requisições HTTP

 Independe de plataforma

  permitiria ponte entre mundos Linux e Microsoft

  obs: RMI e CORBA oferecem essa ponte, mas não com o

(27)

 

Desvantagens SOAP

 Brechas na segurança

  WS-Security tenta resolver esses problemas

  http://www.oasis-open.org/committees/tc_home.php?

wg_abbrev=wss

 Problemas de performance

  menos rápido que atuais competidores tipo RPC como

RMI (Java), IIOP (CORBA), DCOM e Remote (Microsoft)

  mais lento mesmo comparado a competidores que são

baseados em XML (XML-RPC, REST-WS)

  Muito complexo: overhead –

  aplicações geralmente não necessitam de tantas

(28)

 

Desvantagens SOAP

 Não oferece serviços avançados

  A revisar conforme novos padrões Web Services

  Como CORBA, J2EE, …

  CORBA possuía mais de 20 serviços como persistência,

transações, real-time, aluguel de objetos, ...

 Não possui noção de objeto com estado como em RMI  Não suporta passagem por referência

(29)

 

Versões

 SOAP 1.2

  http://www.w3.org/TR/2007/REC-soap12-part0-20070427/

 SOAP 1.1

(30)

 

Especificação (estrutura geral dos documentos)

 Parte 1:

  define o envelope, um framework geral para definir o

conteúdo de uma mensagem

  Também define os protocolos de ligação e o mapeamento

para um protocolo inferior

 Parte 2:

  Define um modelo de dados para o SOAP

 Representação de recurso

  Especifica um bloco de cabeçalho, no qual há a

representação de um recurso Web

(31)

  Envelope: define o começo da

mensagem SOAP

  Header: possui informações

específicas da aplicação  Dados de autenticação  Número de transação  Etc.

 opcional

  Body: contém a mensagem

propriamente dita

 Contém dados que devem ser

(32)

POST /Temperature HTTP/1.1X Host: www.weather.com Content-Type: text/xml Content-Length: <whatever> SOAPMethodName: <some-URI>#CurrentTemp <SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1"> <SOAP:Body> <m:CurrentTemp xmlns:m="some-URI"> <zip_code>37919</zip_code> <m:CurrentTemp> </SOAP:BODY> <SOAP:Envelope> Http Header Soap Extensions Xml Payload argumento Sem header

(33)

HTTP/1.1 200 OK Content-Type: text/xml Content-Length: <whatever> <SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1"> <SOAP:Header> <t:Transaction xmlns:t="some-URI"> 5 </t:Transaction> </SOAP:Header> <SOAP:Body> <m:CurrentTempResponse xmlns:m="some-URI"> <return>42</return> </m:CurrentTempResponse> </SOAP:Body> </SOAP:Envelope> Http Header Xml Payload resposta Com header

(34)

 

Estrutura XML das mensagens SOAP

 inicialmente complexa como exemplos anteriores  eliminando as informações de namespace como

  <SOAP:Envelope

xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">

  o resto é simples e legível (?)

(35)

 

Implementação Apache Axis

 para Java

 baseada em implementação anterior Apache SOAP  conjunto de

  bibliotecas clientes

  bibliotecas para o servidor

  servlet para processamento das chamadas

  Classe servidora

(36)

 

Implementação Apache

 programa cliente usa as suas bibliotecas para empacotar a

chamada (request)

  Diferentes níveis de abstração dependendo da abordagem

utilizada

 servidor

  decodifica a chamada

  chama o método do objeto servidor

  e empacota o resultado para o cliente

(37)

 

Exemplo Hello

 especificação

  cliente

  realiza uma chamada SOAP a uma operação de um

servidor Hello   servidor

  Interface: 2 (duas) operações

  responde à chamada de saudação

(38)

 

Exemplo Hello

 codificação do cliente  duas aproximações

  criar chamada manualmente

  parte mais complexa

  uso de vários métodos do pacote SOAP

  criação da chamada

  inclusão de cada argumento da chamada

  utilizar o arquivo WSDL (se disponível)

  WSDL: descrição (opcional) de um WS em xml

  aproximação estática (geração de Stubs) ou dinâmica

(39)

 

Exemplo Hello

 código do cliente – codificação manual  trabalhosa   import java.io.*; import java.net.*; import java.util.*; import org.w3c.dom.*; import org.apache.soap.*; import org.apache.soap.encoding.*; import org.apache.soap.encoding.soapenc.*; import org.apache.soap.rpc.*; import org.apache.soap.util.xml.*;

(40)

  public class GetHello {

public static void main(String[] args) throws Exception {

// The URL for the SOAP servlet (servidor WS)

URL url = new URL("http://localhost/soap/servlet/ rpcrouter");

// Create a new call

Call call = new Call();

// Tell SOAP which object you want (qual serviço)

call.setTargetObjectURI("urn:HelloApp");

// Tell SOAP which method to invoke

(41)

  // Tell SOAP to use the regular SOAP encoding style call.setEncodingStyleURI

(Constants.NS_URI_SOAP_ENC);

// Create a vector to hold the method parameters

Vector params = new Vector();

// Add a string parameter called extra1 with a value of "Hello info“

// Specify null for the encoding style

params.addElement(new Parameter("extra1", String.class, "Hello info", null));

(42)

  // Add an int parameter called extra2 with a value of 123

// Specify null for the encoding style

params.addElement(new Parameter("extra2", Integer.class, new Integer(123), null));

// Store the parameters in the request

call.setParams(params);

// Prepara uma variável para a resposta

(43)

  // Invoke the call method try { resp = call.invoke(url, ""); } catch (SOAPException e) { e.printStackTrace(); System.exit(0); }

(44)

  // See if the response contains an error if (!resp.generatedFault())

{

// If not, get the return value

Parameter ret = resp.getReturnValue();

// Expect it to be a string

String value = (String) ret.getValue(); System.out.println(value);

(45)

  else {

Fault fault = resp.getFault();

System.err.println("Generated fault: "); System.out.println (" Fault Code = " + fault.getFaultCode());

System.out.println (" Fault String = " + fault.getFaultString());

} } }

(46)

Hello WSDL Axis WSDL2Java Arquivo WSDL Hello Service .java Hello Service Locator .java Hello Port .java Hello BindingStub .java Stubs Gerados

  Código do cliente – geração de Stubs

 Outra alternativa para codificação

 Axis gera automaticamente classes para acessar o Web Service baseados em

SOAP/WSDL

 A partir dessas classes, o desenvolvedor necessita apenas instanciá-las para

(47)

 

Código do cliente – geração de Stubs

import HelloServiceLocator; import HelloService;

import HelloPort;

import HelloBindingStub; public class GetHello

{

public static void main(String[] args) throws Exception {

// localize the service; uso de métodos das classes geradas

HelloService locator = new HelloServiceLocator(); HelloPort port = locator.getHelloPort();

//execute the remote method

String result = port.getHello(“Hello Info”, new Integer(123)); System.out.println(result);

(48)

 

Exemplo Hello

 código do servidor

// standard Java

public class SoapHello {

protected String helloString; public SoapHello()

{

helloString = "Hello!"; }

(49)

  public String getHello(String extra1, int extra2) {

return helloString+" "+extra1+" "+extra2; }

public void setHello(String newHello) {

helloString = newHello; }

(50)

 

Publicando o servidor utilizando Apache Axis

 Duas formas principais

  Salvar código do servidor na pasta raiz do Axis com a

extensão .jws – instalação instantânea

  Extremamente simples;

  Necessita do código fonte (e não o binário);

  Web service é gerado no instante em que o cliente o

acessa: baixo desempenho;

  Utilizar um arquivo de configuração WSDD (Web Service

Deployment Descriptor)

  Mais complicado;

(51)

(52)

SOAP XML-RPC Protocolo de transporte qualquer um (preferência para HTTP) somente HTTP

Tipos extensível utilizando XML Schema restritos a um conjunto básico Ordem de parâmetros indiferente importante

Complexidade complicado simples

(53)

 

Pacote da Sun para Web Services

 

Obs.: em 2006

 nome: JWSDP - Java Web Services Developer Pack 1.2  link   http://java.sun.com/webservices/index.jsp   agora: http://java.sun.com/webservices/downloads/ previous/webservicespack.jsp   anteriormente: http://java.sun.com/webservices/downloads/ webservicespack.html

(54)

 

Pacote da Sun para Web Services

 conteúdo (obs. Versão 1.2):

  JavaServer Faces (JSF) v1.0 EA4

  XML and Web Services Security (xws-security) v1.0 EA

  Java Architecture for XML Binding (JAXB) v1.0.1

  Java API for XML Processing (JAXP) v1.2.3

  Java API for XML Registries (JAXR) v1.0.4

  Java API for XML-based RPC (JAX-RPC) v1.1 EA

  SOAP with Attachments API for Java (SAAJ) v1.2 EA

  JavaServer Pages Standard Tag Library (JSTL) v1.1 EA

  Java WSDP Registry Server v1.0_05

(55)

 

Pacote Sun Web Services

 pacote testado com

  plataformas

  Sun Solaris Operating Environment 8 and 9

  Windows 2000 Professional Edition

  Windows XP Professional Edition

  RedHat Linux 8.0

  ambiente Java

  Java 2 SDK, Standard Edition version 1.4.1_02

 plataforma de desenvolvimento e execução

(56)

 

WS no J2EE

 Tecnologias incluídas

  JAX-WS

  Java API para XML Web Services   JAX-RS

  Java API para RESTFul Web Services

 Conceito WS

  São aplicações cliente / servidor

  Comunicando sobre o protocolo HTTP

(57)

 

WS no J2EE

 Características

  Interoperabilidade via padrões

  Portabilidade sobre diversas plataformas e frameworks   Extensíveis

  Descrições processáveis graças a XML

  Combináveis de forma leve para obter operações complexas

 Tipos

  “Big” WS

  RESTFul WS

(58)

 

WS no J2EE

 “Big” WS

  Uso de XML e SOAP

  Descrição dos serviços em WSDL (linguagem em XML)   opcional

  Adotado por diversas ferramentas como   NetBeans IDE

(59)

 

WS no J2EE

 “Big” WS

  Elementos principais   Contrato formal

  Descreve a interface

  Mensagens, operações, localização do WS, ligações   Arquitetura

  Tratar diversos requisitos complexos não funcionais   Transações, segurança, endereçamento, confiança,

cordenação, ...

  Processamento e chamada assíncronos

(60)

 

WS no J2EE

 RESTFul

  Representational State Transfer

  Apropriado para cenários básicos e ad doc

  Melhor integração com HTTP que serviços SOAP   Não exigem mensagens XML nem WSDL

  Uso do projeto Jersey

  Segue padrão: JSR 311 JAX-RS   Permite anotações

  Mais funcionalidades extra JSR 311   Mais leves

  Exigem poucas ferramentas

  Também integrado no NetBeans IDE

(61)

 

WS no J2EE

 RESTFul

  Usos reais

  Muitos sites de blogs

  Download de arquivos XMl em formato RSS com listas de

links

  Twitter

  Amazon Simple Storage Service (S3)

(62)

 

WS no J2EE

 RESTFul

  Apropriado em/se   WS sem estado

  Teste: interação sobrevive a queda / “colocar-no-ar” do

servidor (restart)

  Infra-estrutura de cache pode ser mais simples   Quando dados de retorno são estáticos

  Técnicas de cache do servidor web mais simples   Cuidado: em geral limitado a método GET do HTTP

(63)

 

WS no J2EE

 RESTFul

  Apropriado em/se

  Contrato liente (consumidor) e serviço (produtor) em

formato ad hoc

  Sobre contexto e conteúdo

  Muitos serviços distribuem toolkits com

  Descrição de interfaces em linguagens

populares

  Quando banda é limitada

  Por exemplo para PDAs e smartphones   SOAP é “pesado”

(64)

 

WS no J2EE

 RESTFul

  Apropriado em/se

  Agregação de serviços é simples   Via uso de tecnologias como

  JAX-RS

  AJAX: Asynchronous JavaScript com XML   Toolkits como DWR (Direct Web Remoting)   Serviços já existentes podem ser expostos via

páginas HTML sem muito esforço

  Desenvolvimento mais produtivo   Não é uma “nova” tecnologia

(65)

 

WS no J2EE

 Big WS x RESTFul

  Usar JAX-WS quando

  Aplicação necessita de vários requisitos de QoS   Usualmente em aplicações coorporativas

  Mais fácil o uso de padrões de segurança e confiabilidade   Melhor interoperabilidade com outros WS

(66)

 

WS no J2EE

 Big WS x RESTFul

  Usar JAX-RS quando

  Desenvolvimento mais simples   Acoplamento reduzido

  Mais fácil o consumo (clientes)

  Facilita manutenção (extensão da app) e escalabilidade   Cliente pode consumir parte do serviço e combiná-lo

como outros serviços (mash-up)

  Artigo

  Pautasso, C. et al. RESTFul Web Services vs. Big Web

Services: Making the Right Architectural Decision. WWW ´08, pp. 805-814

(67)

 

WS no J2EE

 Desenvolvendo com JAX-WS

  Características

  Complexidade do SOAP escondida via APIs do JAX-WS   Lado servidor

  Operações definidas por métodos em interface Java   Implementação via classe(s) que implementam os

métodos da interface

  Lado cliente

  Cria um proxy

  Objeto local que representa o serviço   Chama métodos do proxy

(68)

 

WS no J2EE

  Características

  Portabilidade de Java

  Independência de plataforma   Interoperabilidade entre plataformas

  Cliente JAX-WS pode acessar WS não Java   Cliente não Java pode acessar serviço JAX-WS   Óbvio ... (?)

  Devido JAX-WS seguir padrões do W3C para WS

(69)

 

WS no J2EE

  Porta do servidor

  Diversos arquivos referenciam a porta do servidor   Padrão é 8080

  Pode ser alterada

(70)

 

WS no J2EE

  Exemplo Hello   Serviço

  Classe Java anotada com @WebService   Classe passa a ser um SEI

  SEI

  Service Endpoint Interface ou Service Endpoint

Implementation

  A interface não é obrigatória   Se interface

  Indicada por argumento “endpointInterface” na

anotação @WebService

(71)

 

WS no J2EE

  Exemplo Hello   Serviço

  Ferramenta (wsgen) gera todos os artefatos   Em uso

  Via o Enterprise Server (container)   Passos

  Codificação da classe   Compilação da classe

  Criação dos artefatos (wsgen)

  Empacotamento em arquivo WAR

(72)

 

WS no J2EE

  Exemplo Hello   Servidor

  Requisitos

  Anotar classe ou interface (se houver)   Métodos da classe devem ser

  Públicos

  Não static nem final   Métodos do WS

  Anotados com @WebMethod

(73)

 

WS no J2EE

  Exemplo Hello   Servidor   Código package helloservice.endpoint; import javax.jws.WebService; @WebService

public class Hello {

private String message = new String("Hello, "); public void Hello() {}

@WebMethod

public String sayHello(String name) { return message + name + ".";

(74)

 

WS no J2EE

  Exemplo Hello   Servidor

  Teste sem cliente

  Após WS instalado (no container do J2EE)

  Entrar com URL (local) do serviço mais função

de teste “?Tester”

  Na página de teste (resposta) entrar com

argumentos (se for o caso) e clicar no método

  Será mostrada a resposta do método

(75)

WS no J2EE

 

WS no J2EE

  Exemplo Hello / Cliente

  Instanciar a classe gerada

helloservice.endpoint.HelloService

  Ela representa o serviço na URI indicada no arquivo

WSDL instalado

  HelloService service = new HelloService();

  Recuperar um proxy ao serviço

  Também conhecido como “port”

  Chamando o método getHelloPort do serviço

  Hello port = service.getHelloPort();

(76)

WS no J2EE

 

WS no J2EE

  Exemplo Hello / Cliente   Código completo

  O exemplo completo é um pouco mais complexo   Mas o adicional não é exigido pelo JAX-WS

(77)

J2EE / RESTFul

(78)

RESTFul

 

RESTful WS

 Serviços desenvolvidos para funcionar melhor na web

 Melhor?

  Escalabilidade   Desempenho

  Capacidade de modificação

 REST

  REpresentational State Transfer

 Recurso

(79)

RESTFul

 

RESTful WS

 Identificação por URI

  Endereço global

 Protocolo de comunicação sem estado

  Por exemplo, HTTP

(80)

J2EE / RESTful

 

RESTful

 Objetivos

  Aplicações RESTful devem ser   Simples

  Leves

  Alto desempenho

 Interface (uniforme)

  4 operações

  PUT: cria um novo recurso

  DELETE: recurso (criado) é excluído   GET: recupera o estado de um recurso   POST: atualiza o estado de um recurso

(81)

J2EE / RESTful

 

RESTful

 Mensagens auto-descritas

  Recursos são independentes da sua representação

  Recursos podem ser acessados de diferentes formas como   HTML, XML, texto, PDF, JPEG, JSON e outras

  Metadados sobre o recurso usados para   Controlar cache

  Detectar erros de transmissão   Negociar forma de representação   Realizar autenticação

(82)

J2EE / RESTful

 

RESTful

 Interações com estado

  Cada interação com um recurso é sem estado   Mensagens são auto-contidas

  Interações com estado via conceito de “transferência explícita

de estado”

  Via técnicas como   Reescrita de URI   Cookies

  Campos escondidos de “form”

(83)

J2EE / RESTful

 

RESTful

 Jersey implementação

  Segue padrão JSR 311: JAX-RS   Suporte a anotações

  Documentação em:

  https://jsr311.dev.java.net/nonav/javadoc/index.html   A documentação teria que ser instalada (?) no Enterprise

(84)

J2EE/RESTful

 

RESTful

 Classes de recurso raiz

  Anotadas com @Path

  Ou ao menos um método anotado   com @Path

  ou com designador de método de requisição   @GET, @PUT, @POST ou @DELETE

 Métodos de recursos

(85)

J2EE/RESTful

 

RESTFul

 JAX-RS API

  Java API para facilitar o desenvolvimento de aplicações com

RSET

  Uso de anotações, específicas para HTTP

  Anotações são resolvidas durante execução (runtime)

  Uso de reflexão para gerar classes auxiliares e outros artefatos

para o recurso

  Classes e artefatos agrupados em arquivo WAR (web)   WAR deve ser instalado em container J2EE ou web

(86)

J2EE/RESTful

 

RESTful

 Principais anotações

  @Path

  Caminho relativo de URI

  Indica onde a classe Java será instalada

  Pode ser adicionada com variáveis para definir modelos

(templates)

  Exemplos

  /helloWorld

  Com controle de usuário/senha   /helloWorld{username}

(87)

J2EE/RESTful

 

RESTful

  @GET

  Métodos @GET devem processar requisições HTTP GET   @POST

  Métodos @POST devem processar requisições HTTP

POST   @PUT   Métodos @PUT ...   @DELETE   Métodos @DELETE ...   @HEAD

(88)

J2EE/RESTful

 

RESTful

  @PathParam

  Tipo de parâmetro que pode ser extraído para uso na

classe (em métodos por exemplo)

  Extraído da URI requisitada

  Nomes de parâmetros definidos na anotação @Path   @QueryParam

  Tipo de parâmetro que pode ser extraído para uso na

classe

(89)

J2EE/RESTful

 

RESTful

  @Consumes

  Para especificar tipos MIME a serem consumidos pelo

recurso quando enviados pelo cliente

  @Produces

  Para especificar tipos MIME a serem produzidos pelo

recurso e enviados ao cliente

(90)

J2EE/RESTful

 

RESTful

  @Provider

  Para especificar “qualquer objeto” (anything) de interesse

do ambiente de execução do JAX-RS; uma classe

  Exemplos

  MessageBodyReader

  Usado para mapear itens da requisição HTTP em

parâmetros de métodos da classe recurso

  MessageBodyWriter

  Usado para mapear retornos de método (classe

recurso) em itens da resposta HTTP

  ResponseBuilder

(91)

J2EE/RESTful

 

RESTful

 Exemplo básico: Aplicação HelloWorld

  Código recurso   package com.sun.jersey.samples.helloworld.resources; import javax.ws.rs.GET; import javax.ws.rs.Produces; import javax.ws.rs.Path;

// The Java class will be hosted at the URI // path "/helloworld"

@Path("/helloworld")

(92)

J2EE/RESTful

 

RESTful

 Exemplo básico: Aplicação HelloWorld

  Código recurso

  // The Java method process HTTP GET requests

@GET

// The Java method produces content identified // by the MIME Media type “text/plain

@Produces("text/plain")

public String getClichedMessage() {

// Return some cliched textual content

return "Hello World"; }

// The Java method process POST requests

@POST

// … method saves the new hello contents

@Consumes("text/plain")

public void postClichedMessage(String message { // Store the message

} }

(93)

J2EE/RESTful

 

RESTful

 Anotação @Path: mais detalhes

  É um caminho parcial (como no exemplo HelloWorld)   URI path templates

  URI com variáveis resolvidas em tempo de execução   Variáveis são anotadas com {}

  Exemplo

  @Path(“/users/{username}”}   username é a variável

  A URI de chamada do WS poderia ser (user Galileu):

(94)

J2EE/RESTful

 

RESTful

  @PathParam anotação

  Usada para obter o valor de uma variável em um método   Exemplo

  @Path("/users/{username}") public class UserResource { @GET @Produces("text/xml")

public String getUser(@PathParam("username” String userName) {

... }

(95)

J2EE/RESTful

 

RESTful

  Restrições nos valores de uma variável   Com uso de expressões regulares   Exemplo

  @Path("users/{username: [a-zA-Z][a-zA-Z_0-9]}")   Exige iniciar com letra seguida de zero ou mais alfas

ou underscore

  A barra inicial (/) não é obrigatória   Idem barra final

(96)

J2EE/RESTful

 

RESTful

 Anotação @Path: variáveis

  Anotadas com {}   Exemplo

  Recurso

  @Path(“/{name1}/{name2}/”)

public class SomeResource {...}

  Recurso deve responder a URI:

  http://example.com/myContextRoot/jerseybeans/

{name1}/{name2}/

  Instalar WAR em servidor Java EE que responde a:   http://example.com/myContextRoot

(97)

J2EE/RESTful

 

RESTful

 Anotação @Path: variáveis

  Uma variável pode ser usada várias vezes   Em conflito de caracteres: usar “%”+caracter

  Exemplo

  Valor de variável: “Rua%20da%20Praia”  

(98)

J2EE/RESTful

 

RESTful

 Respondendo a chamadas HTTP

  Comportamento de um recurso é determinado pelos métodos

HTTP (GET, POST, PUT e DELETE)

  Anotações de métodos

  “Request Method Designator annotation” é   Anotação dinâmica

  Definida em JAX-RS

  Corresponde a um método HTTP

  JAX-RS define anotações para métodos comuns   @GET, @POST, @PUT, @DELETE e @HED   Usuário pode criar designadores customizados

(99)

J2EE/RESTful

 

RESTful

 Respondendo a chamadas

  Anotações de método HTTP

  Métodos HTTP mapeados para método Java   Comportamento do método depende da anotação   Retornos possíveis

  Void

  Objeto Javax.ws.rs.core.Response

  Múltiplos parâmetros podem ser recuperados com anotações   Conversão entre tipos Java

(100)

J2EE/RESTful  

RESTful

 Respondendo a chamadas   Exemplo   Método PUT   Serviço de “storage”

(101)

J2EE/RESTful

 

RESTful

 Respondendo a chamadas

  Exemplo

  @PUT

public Response putContainer() {

System.out.println("PUT CONTAINER " + container); URI uri = uriInfo.getAbsolutePath();

// cria objeto container

Container c = new Container(container, uri.toString()); Response r;

// cria resposta se Memory Store tem container if (!MemoryStore.MS.hasContainer(c)) {

r = Response.created(uri).build(); } else {

r = Response.noContent().build(); }

(102)

J2EE/RESTful

 

RESTful

 Usando provedores de entidades

  Entity providers

  Provedores de entidades mapeiam representações de

argumentos e objetos Java

  Dois tipos

  MessageBodyReader   MessageBodyWriter   Message Body Reader

  Usado para mapear corpo de requisições HTTP em

parâmetros de métodos

  MessageBodyWriter

  Usado para mapear valores de retorno (métodos) em

(103)

J2EE/RESTful

 

RESTful

  Tipos suportados automaticamente

  Escrever um provedor somente se tipo fora da lista   Lista:

  byte[]: todos os tipos de m   java.lang.String

  java.io.InputStream   Java.ioReader

  Java.io.File

(104)

J2EE/RESTful

 

RESTFul

  Exemplo de anotação de MessageBodyReader

  @Consumes("application/x-www-form-urlencoded")

@Provider

public class FormReader

implements MessageBodyReader<NameValuePair> {

  Exemplo de anotação de MessageBodyWriter   @Produces("text/html")

@Provider

public class FormWriter

implements MessageBodyWriter<Hashtable<String, String>> {

(105)

J2EE/RESTful

 

RESTful

 Customizando requisições e respostas

  Corpo de requisições e respostas HTPP são MIME

  O tipo de MIME é especificado no header das mensagens

HTTP

  Usuário pode especificar o tipo usado por um recurso via:   Anotações @Produces para respostas

  Anotações @Consumes para requisições   Pelo padrão (default)

(106)

J2EE/RESTful

 

RESTful

  @Produces

  Se usada em nível de classe

  Aplica-se a todos os métodos   Se usada em nível de método

  Sobrescreve anotações em nível de classe   Exemplo de @Produces

(107)

J2EE/RESTful

 

RESTful

  Exemplo de uso de @Produces (sem provider)   @Path("/myResource")

@Produces("text/plain") // classe

public class SomeResource { @GET

public String doGetAsPlainText() { ...

}

@GET

@Produces(“text/html”) // método

public String doGetAsHtml() { ...

(108)

J2EE/RESTful

 

RESTful

  @Consumes

  Se usada em nível de classe

  Aplica-se a todos os métodos   Se usada em nível de método

  Sobrescreve anotações em nível de classe   Exemplo de @Consumes

(109)

J2EE/RESTful

 

RESTful

  Exemplo de uso de @Consumes   Observação: sem provider

  @Path("/myResource")

@Consumes("multipart/related") //classe

public class SomeResource { @POST

public String doPost(MimeMultipart mimeMultipartData) {

... }

(110)

J2EE/RESTful

 

RESTful

  Exemplo de uso de @Consumes (cont.)

  @POST

// método

@Consumes("application/x-www-form-urlencoded") public String doPost2(FormURLEncodedProperties formData) {

... } }

(111)

J2EE/RESTful

 

RESTful

 Extração de parâmetros de requisição

  Parâmetros de métodos podem ser anotados para extração de

informação

  Tipos de parâmetros que podem extraídos   De “query”

  Caminhos (path) de URIs   De “form”

  Cookies   Headers   Matrizes

(112)

J2EE/RESTful

 

RESTful

 Extração de parâmetros de requisição tipo Query

  Estão no corpo da requisição   Exemplo

  Parâmetro “step” é analizado; se não existe -> =2   @Path("smooth")

@GET

public Response smooth(

@DefaultValue("2") @QueryParam("step") int step, @DefaultValue("true") @QueryParam("min-m") boolean hasMin, @DefaultValue("true") @QueryParam("max-m") boolean hasMax, @DefaultValue("true") @QueryParam("last-m") boolean hasLast,

(113)

J2EE/RESTful

 

RESTful

 Extração de parâmetros de requisição

  Exemplo (cont.)   @DefaultValue("blue") @QueryParam("min-color") ColorParam minColor, @DefaultValue("green") @QueryParam("max-color") ColorParam maxColor, @DefaultValue("red") @QueryParam("last-color") ColorParam lastColor ) { ... }

(114)

J2EE/RESTful

 

RESTful

 Exemplo completo

  Seção final do capítulo sobre REST no tutorial Java EE   Inclui criação, geração, instalação e teste

(115)

J2EE/RESTful

 

Resumo

 Protocolo HTTP

 Serviço sem estado

 Serviço é uma classe Java com anotações

 Nome é uma URI

 Métodos de atendimento são métodos HTTP

  Métodos Java anotados

 Parâmetros na URI de chamada

 Parâmetros no corpo da consulta

 Conversão padrão e customizada entre corpo da requisição e

(116)

J2EE/RESTful

 

RESTful

 Considerações finais

  Legibilidade?

  Muito uso de anotação?   Porque é mais leve?

  (mais) simples? Que JAX-WS?   Outras funcionalidades de WS?

(117)

 

Súmula parte WSDL

 Conceitos de WSDL   Introdução ao WSDL   Estrutura de um arquivo WSDL   Exemplo   Vantagens/Desvantagens do WSDL

(118)

 

WSDL

 Web Service Description Language

 padrão para descrição de informações de serviços

 pode ser usado como camada de descrição da arquitetura WS  baseado em XML

 arquivos WSDL são criados pelos desenvolvedores dos serviços

Web

 cliente acessa as informações para usar os serviços

(119)

 

WSDL

 motivação

  Aplicações necessitam de uma série de informações para

poderem acessar um Web Service

  Quais os serviços disponíveis;

  Interface dos serviços;

  Estrutura das mensagens utilizadas;

  Protocolos de transporte;

  Localização;   Etc.

(120)

 

WSDL

 conceitos gerais

  documento WSDL

  contém conjuntos de definições que descrevem os

Web Services

  especifica as capacidades do serviço, sua localização

na Web e instruções a respeito de como acessá-los

  define a estrutura da mensagem que um WS envia e

recebe

  os dados que uma aplicação precisa fornecer a

(121)

 

WSDL

 conceitos gerais

  seleção

  usando esta informação, as aplicações que estão

procurando por um WS para preencher uma

necessidade específica podem analisar os arquivos WSDL de inúmeros serviços e fazer a escolha

  além disso, os arquivos WSDL fornecem informações

técnicas específicas

  possibilitam às aplicações se conectarem e

comunicarem com os Web Services

(122)

  WSDL descreve as

informações de um WS partindo de dados mais genéricos (alto nível) até as informações mais

(123)

 

Definition

 Elemento mais externo;  Namespaces utilizados;

 

Message

 Dados enviados e recebidos pelas operações de um serviço;  Suporte a tipos simples (inteiros, strings, booleanos);

 Suporte a tipos complexos (estruturados, listas…)

(124)

 

PortType

 Descreve de forma abstrata as operações disponíveis em um WS

  Seu nome;

  Um elemento do tipo “Message” para seus parâmetros de

entrada;

  Um elemento do tipo “Message” para seus resultados;

 Um elemento do tipo Message pode ser utilizado para descrever os

(125)

 

Binding

 Define informações de mais baixo nível para as operações

definidas nos elementos PortType

  Protocolo de Transporte (HTTP, FTP, …);

  Protocolo de Mensagem (SOAP, XML-RPC, …);

  Codificação da mensagem (rpc/encoded, document/literal,

…)

  Recomendado: document/literal;

  Comparação entre os diferentes estilos: http://

www-128.ibm.com/developerworks/webservices/ library/ws-whichwsdl/

(126)

 

Service

 Associa cada elemento do tipo Binding a um endereço (endpoint)

utilizado para acessá-lo;

 Um mesmo Binding pode estar associado a múltiplos elementos do

(127)

 

Web Service do Google

 Disponível em:

  http://www.google.com/apis/

 Três operações

  doGetCachedPage

  Retorna uma página armazenada na cache do Google

dada sua URL;

  doSpellingSuggestion

  Verificação ortográfica de uma frase fornecida;

  doGoogleSearch

(128)

 

Web Service do Google

 Por simplificação, apenas os elementos relacionados à operação

(129)

 

Elementos do tipo Message

<message name="doSpellingSuggestion">

<part name="key" type="xsd:string"/> <part name="phrase" type="xsd:string"/> </message>

<message name="doSpellingSuggestionResponse">

<part name="return" type="xsd:string"/> </message> senha do Google frase a ser verificada resultado da verificação

(130)

 

Elemento PortType

 <portType name="GoogleSearchPort"> <operation name="doSpellingSuggestion"> <input message="typens:doSpellingSuggestion"/> <output message="typens:doSpellingSuggestionResponse"/> </operation> </portType> nome da operação parâmetros resultados

(131)

 

Elemento Binding

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="doSpellingSuggestion"> <soap:operation soapAction="urn:GoogleSearchAction"/> <input> <soap:body use="literal" namespace="urn:GoogleSearch" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="literal" namespace="urn:GoogleSearch" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> Estilo: document/literal SOAP sobre HTTP

(132)

 

Elemento Service

 <service name="GoogleSearchService">

<port name="GoogleSearchPort" binding="typens:GoogleSearchBinding"> <soap:address location="http://api.google.com/search/beta2"/>

</port> </service>

(133)

 

Vantagens

 Automatização no processo de chamada de um WS;  Interoperabilidade

  diferentes aplicações em uma organização podem ser

integradas através de uma única interface;

(134)

 

Desvantagens

 Redundância

  Ex: nomes de operações e mensagens são repetidos

várias vezes nos diversos elementos de um arquivo WSDL;

 Falta de informação semântica

  WSDL apresenta apenas informação sintática dos

serviços;

  Obstáculo para uma total automatização da interação

entre aplicações;

  Semantic Annotations for WSDL Working Group: projeto

para criação de uma versão do WSDL com informações semânticas;

(135)

 

Súmula – parte UDDI

(136)

 

UDDI

 Universal Description, Discovery, and Integration  protocolo para publicação e procura dos serviços  organizado em páginas amarelas, brancas e verdes

 representa o nível de descoberta da pilha de protocolos de Web

(137)

 

UDDI

 conceitos gerais: passos

  1) tipos de anúncio do serviço Web

  separa-se as funções que estão realmente sendo

executadas pelo desenvolvedor

  separação é baseada na divisão de um serviço web

em

  tipo do serviço Web

  e uma ocorrência do serviço Web

  como se poderia separar um objeto entre uma classe

(138)

 

UDDI

  o tipo de serviço deve transpor mais de uma

companhia para fomentar o seu reuso

  explicitamente, quando dois serviços Web

compartilham a mesma definição de interface WSDL

  o consumidor pode facilmente trocar de um para

outro

  é um exemplo prático dos benefícos ganhos de se

(139)

 

UDDI

  2) anúncio do serviço Web

  responsabilidade dos negócios e dos

desenvolvedores de software

  anunciar os serviços Web de acordo com as

especificações anunciadas acima

  os tipos de anúncios de serviços Web e suas

implementações são feitos usando o SOAP

  segurança

  integridade dos dados em trânsito estão

protegidos via uma conta UDDI e o uso do HTTPS.

(140)

 

UDDI

  3) registrador de negócios e identificadores de serviço

  o negócio e os serviços são registrados

separadamente.

  relacionamento muitos-para-um permite

  que um negócio registre todos os serviços Web

que ele suporta debaixo da mesma entidade de negócio

(141)

 

UDDI

  4) pesquisa/pegunta a um Registro UDDI (Discovery)

  os negócios são registrados separadamente dos

serviços que eles fornecem

  o processo de pesquisa/pergunta (queryng) também

pode ser feito por negócios ou serviços

  a API para pesquisa/pergunta ao registro UDDI

  usa pacotes SOAP como um mecanismo

(142)

 

UDDI

  5) recuperação da descrição de um Serviço Web

  a informação vinda de um registro é somente uma

parte

  devido ao fato de que o UDDI é baseado num

modelo de diretório

  conceito de diretório tem sido usado pela industria de

software

  padrões para o compartilhamento de informações

sem que sejam repositórios de todas as informações   X.500

  bem conhecido LDAP (Lighwight directory

(143)

 

UDDI

  tipicamente, coisas como nome, uma pequena

descrição e o contato do negócio podem ser recuperados diretamente do UDDI

  porém um documento WSDL descrevendo uma

interface com os serviços Web e um ponto final será recuperado em outros passos

(144)

 

UDDI

  6) WSDL query

  a URL de um documento WSDL descrevendo os

serviços Web é retornada no passo anterior

  normalmente, isto será a URL de um serviço Web

seguido por ?WSDL como no exemplo: http:// meuservidor/Services/QtdeEmEstoque?WSDL

(145)

 

UDDI

  7) recuperação WSDL

  a WSDL requisitada no passo 6 é retornada usando

um protocolo de transporte como o HTTP

  pode-se notar que os passos de 1 a 3 constituem o

processo de anúncio

  o anúncio é modelado pela API de publicação

(publishing API)

  os passos de 4 a 7 correspondem ao processo de

pesquisa/pergunta

(146)

(147)

 

WSDL

 solução WSDL

  um cliente pode consultar um serviço de lookup

  também chamado registro de serviço

  é um repositório que armazena as URLs dos documentos

WSDLs

  registros armazenam arquivos que fornecem informações

técnicas específicas

  usando esses dados, as aplicações podem acessar e

comunicar-se com os serviços Web

  a aplicação cliente usa o WSDL, uma linguagem baseada

(148)

 

Outros protocolos Web Services

 UDDI

  Universal Description, Discovery, and Integration

  protocolo para publicação e procura dos serviços

(149)

 

Revisão

 O que são WS?

 Quais os objetivos e vantagens?  Características básicas?