4-Web services 2010 · estrangulamentos, interblocagem •Sósão bem suportadas as interacções 1-para-1 (ou seja não suporta difusão) •Existem mais níveis de software que

Departamento de Engenharia Informática

Sistemas Distribuídos 2009/10

Resumo



RPC: comparação com API de Mensagens

Positivo Negativo� A interface do serviço encontra-se claramente especificada e não é apenas um conjunto de mensagens

�Mecanismo de estabelecimento da ligação entre o cliente e o servidor automático

� As funções do cliente e do servidor são consistentes, o sistema garante que são correctamente emparelhadas

� O modelo de invocação de uma função e respectiva sincronização simplificam a programação

� Os dados são automaticamente codificados e descodificados resolvendo o problema da heterogeneidade

� As Excepções adaptam-se bem ao tratamento de erros nas invocações remotas

• A sincronização pode dar origem a estrangulamentos, interblocagem

• Só são bem suportadas as interacções 1-para-1 (ou seja não suporta difusão)

• Existem mais níveis de software que implicam maior overhead na execução



Web Services



Evolução

• 1997– A Sun distribui o JDK 1.1 que inclui o Remote Method Invocation (RMI) que

define um modelo de computação distribuída usando objectos Java. O RMI ésemelhante ao CORBA e ao DCOM mas funciona só com objectos Java.

– Microsoft desenvolveu o COM+ sucessor do DCOM muito próximo do modelo CORBA.

• 1999– A SUN distribui o Java 2 Platform Entreprise Edition (J2EE) que integra o RMI e

o IIOP tornando mais simples a interoperação de sistemas entre sistemas Java e CORBA.

– O Simple Object Acess Protocol – SOAP apareceu pela primeira vez.• 2001

– A IBM e a Microsoft propõem as pilhas de protocolos dos Web Services à W3C (World Wide Web Consortium)• Wire stack• Description stack• Discovery stack



Motivação dos Web Services

• Protocolo muito simples para garantir a interoperação entre plataformas de múltiplos fabricantes

• Tratar todo o tipo de heterogeneidade de dados e informação com XML

• Mensagens codificadas em texto para passar através das firewalls• Permitir utilizar RPC ou MOM em sistemas de comunicação síncronos e assíncronos

• Usar de forma directa o HTTP e HTTPS como protocolos de transferência de informação

• Usar URL e URI como referências remotas para objectos• Permitir a transferência de todo o tipo de informação desde estruturas

de dados a documentos estruturados e informação multimédia.• Eliminar a distinção de sistemas para transferência de documentos e

sistemas para transferência de dados



Dinâmica do Mercado

• IBM– O produto principal é o Websphere que inclui o SOAP, WSDL, UDDI

• Microsoft– .NET suporta directamente Web Services mas é muito mais abrangente

incluindo uma nova linguagem de programação: o C #• Sun Microsystems

– O suporte da Sun ao Java faz com que esta plataforma seja uma das que incorpora a tecnologia Java Enterprise e os Web services.

• BEA– Weblogic: evolução da plataforma de J2EE

• Oracle:– Oracle 10i Web Service Broker. BPEL server

• SAP:– Netweaver – Application server, EAI, Business service architecture



Modelo dos Web Services

Find Publish

BindServiceProvider

ServiceRequestor

ServiceRegistry

Request /Response



Arquitectura dos WEB services

• Um serviço de Directório para registo e pesquisa dos serviços – UDDI

• Um protocolo de pedido-resposta para invocação do serviço – SOAP

• Uma especificação da interface do serviço –WSDL

• Páginas amarelas e directório

• Interacção

• Contratos



Web services

SOAP

WS-Policy

Transporte

Mensagem

Descrição do

Serviço

Componentes

XSD

WSDL

HTTP SMTPHTTPS

XML

WS-Addressing

UDDIWS-Metadata

Exchange

SegurançaComunicação

Fiável

Transacções

Descrição da

Mensagem

Descrição da

Localização

MTOM

BPEL4WSComposição

Coordenação



Web Services (standards)

Description

HTTP, JMS, SMTP Transport

XMLMessage

SOAP

WSDL

UDDI Discovery

Transactions

CoordinationWS-SecurityWS-ReliabilityQuality of

Service

Orchestration - BPEL4WS

Business

Processes

Context

Description

Managem

ent

Choreography - CDL4WS



Arquitectura de Integração da Informação

• Em muitos casos a integração tem de resolver o problema da troca de informação com múltiplas representações

• A solução mais simples para este problema é representar os dados num formato canónico que todos saibam utilizar

• Os dados originais de cada sistema têm de ser mapeado no formato canónico mas depois podem ser usados por todos que sigam o formato.

• Esta é a razão da grande importância do XML



Simple Object Access Protocol

SOAP

Protocolo de comunicação dos Web Services



Simple Object Access Protocol - SOAP

• Objectivo– Ubiquitous XML distributed computing infrastructure

• Características– Protocolo de comunicação distribuído permitindo o envio de qualquer tipo de informação entre aplicações

– Protocolo de representação de dados baseado em XML.

– Referências remotas baseadas em URI

– Protocolo extensível permitindo a incorporação de várias facetas : segurança, tolerância a faltas, através de headers associados às mensagens



Especificação SOAP

Define

• O protocolo de pedido resposta – estrutura das mensagens e da interacção entre cliente e servidor

• Como o XML deve ser usado para representar o conteúdo das mensagens

• As regras de como os receptores das mensagens deverão processar os elementos XML que as mensagens SOAP contêm

• O uso de protocolos como o HTTP e o SMTP para comunicar as mensagens SOAP



Envelope

Security

Extensions

XML Messaging

Data Encoding

Network Protocol

Manageability

Quality of Service

SOAP Headers

SOAP

XML and

HTTP(S),

sockets.SMTP, FTP,

SOAP

Wire stack – Visão dos Web Services



SOAP

• No SOAP toda a informação está incluída dentro de uma mensagem o envelope do SOAP.

• A mensagem tem um ou mais cabeçalhos (headers) e um corpo (body).• Extensões às mensagens são os SOAP headers• A heterogeneidade é tratada pelo XML assim como convenções para

representar tipos de dados abstractos ou tipos de dados complexos• Uma interacções do tipo pedido - resposta • Um mecanismo de ligação entre as mensagens SOAP e o protocolo HTTP, o

mais usado na Internet, contudo o SOAP pode utilizar outros protocolos de transporte como SMTP

• Um mecanismo para tratar as faltas – SOAP fault• Na base estão os protocolos de comunicação que podem ser usados: HTTP,

SMTP, FTP, ou API de comunicação como os sockets• A segurança pode aparecer a qualquer nível, por exemplo, utilizar SSL na

comunicação ou assinaturas digitais nos headers.



SOAP Simple Object Access Protocol

• Define:– Modelo de empacotamento

• SOAP Envelope

• Baseado em XML

• Pode usar vários transportes:– HTTP– SMTP– ...

SOAP 1.1 Message

Structure

SOAP

Envelope

Header

Entries

[Header

Element]

Body

Element

[Fault

Element]



Interacções previstas no SOAP

Client

Client

Client

Client

Server

Server

Server

Server

one-Way

Mensagem simples

request-response

RPC

Notification

callback

notification-response



Binding do SOAP ao protocolo de Transporte

• O HTTP é um protocolo de pedido-resposta pelo que torna o protocolo de RPC do SOAP muito simples. Para outros protocolos tem de se criar um protocolo de controlo da invocação remota

• O HTTP permite que o servidor não tenha estado

• A confidencialidade da informação pode ser assegurada pelo HTTP/S



Binding do SOAP ao protocolo de Transporte

• O SOAP é independente do transporte e pode ser usado com diferentes protocolos.

• Contudo é necessário dar um contexto que identifique o serviço de destino– O contexto para o servidor perceber qual o serviços invocado pode ser

passado dentro na mensagem SOAP ou na mensagem de transporte– No caso do HTTP a informação de contexto é passada através do URI e do SOAP action

– Se o mecanismo de transporte não tiver possibilidade de ter informação de contexto, por exemplo, usando directamente os sockets as soluções possíveis são:• Por convenção o porto x corresponde ao serviço Y• Usando os headers do SOAP• Usando um protocolo de controlo mínimo para transferir as mensagens do

SOAP

JAM8

Slide 20

JAM8 Introduzir o problema do contextoJose Alves Marques; 22-03-2006



Execução simples em SOAP

• É necessário um URL de destino

• O nome de uma operação

• Os parâmetros. – Os parâmetros são passados por cópia (in e out)

– Não existem referências para os objectos remotos criadas automaticamente como em Corba ou Java.

• Informação contextual, como a informação de segurança



Exemplo

• Servidor que disponibiliza o último preço praticado para um produto

• Função Remota

float GetLastTradePrice(string symbol)



SOAP - Pedido

POST /ExemploHelloWS/endpoint HTTP/1.1Host: www.server.comContent-Type: text/xml; charset="utf-8"Content-Length: 322SOAPAction: ""

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:ns1="http://hello">

<soapenv:Body><ns1:sayHello><ns1:name>friend</ns1:name>

</ns1:sayHello></soapenv:Body>

</soapenv:Envelope>



SOAP - Resposta

HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: 367

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:ns1="http://hello">

<soapenv:Body><ns1:sayHelloResponsens1:sayHelloResponsens1:sayHelloResponsens1:sayHelloResponse>

<ns1:return>Hello friend!</ns1:return></ns1:sayHelloResponse>

</soapenv:Body>

</soapenv:Envelope>



SOAP - Erro

HTTP/1.0 500 Internal Server ErrorContent-Type: text/xml; charset=”utf-8”Content-Length: nnn

<SOAP - ENV: Envelope xmlns:SOAP-ENV=”http//schemas.xmlsoap.org/soap/enve1ope/”SOAP-ENV:encodingStyle=”http//schemas.xmlsoap.org/soap/encoding/”><SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>Client .AuthenticationFailure</faultcode> <faultstring>Failed to authenticate client</faultstring> <faultactor>urn:X-SkatesTown:PartnerGateway</faultactor>

</SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

JAM7

Slide 25

JAM7 validar a distinção para o pacote SOAPJose Alves Marques; 22-03-2006



Physical (Communication Protocol) Message

POST /LookupCentral HTTP/1.1Host: www.lookupcentralserver.comContent-Type: text/xml; charset=“utf-8”Content-Length: nnnSOAPAction: “Directory/LookupPerson”

<SOAP-ENV:Envelopexmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/”SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/”/>

<SOAP-ENV:Header>

<a: AuthorizationLevel>xmls:a=“some-URI”>

</a:AuthorizationLevel>

</SOAP-ENV:Header>

<SOAP-ENV:Body><m:LookupPerson xmlns:m=“Some-URI”>

<FirstName>Big<FirstName><LastName>Boss</LastName>

</m:LookupPerson></SOAP-ENV:body>

</SOAP-ENV:Envelope>

Out-of-message context (target URI)

Out-of-message context (SOAPAction)

Logical SOAP Message

SOAP Headers

In-message context

SOAP Body



SOAPEnvelope

+addHeader(header:SOAPHeader):void+addBodyElement(element:SOAPBodyElement):void+getHeaderByName(namespace:String, localPart:String):SOAPHeader

message Type:StringencodingStyleURI:StringbodyElements:Vectorheaders:Vector

MessageElement

+getValueAsType(type:QName):Object+output(context:SerializationContext):Void

Name:StringPrefix:StringnamespaceURI:StringType:QNameParent:MessageElementElement:SOAPEnvelope

SOAPBodyElement

+SOAPBodyElement(elem:Element)

SOAPHeader

+SOAPHeader(namespace:String, localPart:String+SOAPHeader(elem:Element)

mustUnderstand:booleanactor:String

RPCParam

+RPCParam(name:String, value:Object)

value:Object

name:String

RPCElementmethodName:Stringparams:Vector+RPCElement(namespace:String, methodName:String, args:Object[])

+getParam(name:String):RPCParam

+addParam(param:RPCParam):void



Execução dos Web Services



Apache Axis

• Apache Axis é uma plataforma open source para Web Services

• O Axis engine é o Servidor SOAP que suporta as linguagens Java e C++

• É composto por:– Axis engine – O processador de SOAP

– Handlers – os blocos básicos de parametrização dentro do Axis

– Chains – cadeias de invocação de handlers



Relação Transporte

• O Processador SOAP pode receber mensagens através de vários mecanismos de transporte – Os Transport listeners esperam

mensagens e invocam o Axis engine

– Os Transport listeners são servlets cuja função é invocar o Axis engine com uma mensagem SOAP

– Podem ser adicionados ou modificados listeners para requisitos particulares de transporte



Handlers



Handler Chain

• As chains representam a invocação de handlers

• A WS specific chain invocam handlers que se aplicam a um web service determinado e são definidos no seu contrato WSDL



Servidor

• A Global chain são handlers que são invocados para todos os web services. Um exemplo o log de todas as invocações recebidas

• A Transport chain é especifica do transporte e executa operações que se aplicam sempre a um transporte. Por exemplo cifrar o corpo da mensagem

• O dispatcher faz a invocação da função



Cliente



WSDL - Web Service Definition Language

Definição do contrato do Serviço



WSDL - Web Service Definition Language

• A Interface Description Language dos Web Services• Define o contrato a que o serviço se obriga• Foi submetida para norma ao W3C pela IBM e pela Microsoft em

Setembro 2000.• A definição permite descrever

– Qual o serviço– Que mensagens devem ser enviadas e qual a sua estrutura– Como usar os vários protocolos de transporte– Onde o serviço está localizado, mais precisamente para que rede a

mensagem deve ser enviada

• A documento WSDL é um documento XML com todas as vantagens que dai advém de extensibilidade (namespaces, xml schema, etc.)



ServiceOrchestration

Endpoint

Service

Service

WSFL/

WSEL

WSDL

XML

Description

Interface

Implementation

XLANG

WSDL

XML Schema

Service Description stack



WSDLWeb Services Description Language

• Descreve:– O que o serviço faz

• Operações

– Onde está localizado• Endpoint

– Como invocá-lo

• Existem bindings para:– SOAP 1.1– HTTP GET/POST– MIME

WSDL

Document

[Types]

{Messages}

{Port Types}

{Bindings}

{Services}

WSDL 1.1 Document

Structure



Definições

• Port Type – Descreve a interface abstracta de um Web service. – Atenção porque o termo “port” é usado com um sentido totalmente

diferente dos sockets. Um port de um Web Service é mais parecido com uma interface Java

• message – assinatura das operações descrevendo o nome e os parâmetros da operação

• types – colecção de todos os tipos de dados usados na especificação.

• Estes elementos são reutilizáveis porque definem entidades abstractas e não a concretização de um serviço



portType

<portType name=”PriceCheckPortType”><operation name=”checkPrice”>

<input message=”pc:PriceCheckRequest”/><output message=”pc:PriceCheckResponse”/>

</operation>

</portType>

• Descreve o que o Serviço faz • As mensagens permitem saber a assinatura dos métodos• Normalmente um documento WSDL contem apenas um port type por razões

de reutilização



Mensagens

<! - - Message definitions - -><! - - A PriceCheckRequest is simply an item code (sku) - ->

<message name=”PriceCheckRequest”><part name=”sku” type=”xsd:string”/>

</message>

<! - - A PriceCheckResponse consists of an availability structure, -- >

<! - - defined above.<message name=”PriceCheckResponse”>

<part name=”result” type=”avail:availabilityType”/></message>

• As mensagens podem ser de input, output ou assinalar faltas • podem ser usadas para diferentes operações



Tipos de dados

<types><xsd:schema

targetNamespace=http://www.skatestown.com/ns/availabilityxmlns:xsd=http://www.w3.org/2001/XMLSchema>

<xsd:complexType name=”availabilityType”><wsd:sequence>

<xsd:element name=”sku” type=”xsd:string”/>

<xsd:element name=”price” type=”xsd:double”/></xsd:sequence>

</xsd:complexType></xsd:schema>

</types>

• Tipos utilizados no documento WSDL• Os tipos são declarados num XML schema


Sistemas Distribuídos 2009/108/28/2003 José Alves Marques

Binding

• A função do binding é tornar concreto o serviço definindo a forma como funciona

• Exemplos:– SOAP; HTTP; SMTP– Semântica da invocação – Request response; one-way; solicit response;

notification– Protocolo de transporte – Valor do Soap action– Formatação da mensagem

• Um portType pode ter um mais bindings associados, mas cada documento WSDL normalmente só tem um.



binding

<binding name=”PriceCheckSOAPBinding” type=”pc:PriceCheckPortType”><soap:binding style=”rpc”

transport=http://schemas.xmlsoap.org/soap/http/>

<operation name=”checkPrice”><soap:operation soapAction=” “/><input>

<soap:body use=”encoded”

namespace= http://www.skatestown.com/services/PriceCheck

encodingStyle= http://schemas.xmlsoap.org./soap/encoding/”/>

</input>

<output>

<soap:body use=”encoded”

namespace= http://www.skatestown.com/services/PriceCheck

encodingStyle= http://schemas.xmlsoap.org/soap/encoding//>

</output>

</operation>

</binding>



<!- - Binding definitions - ->

<binding name=“PriceCheckSMTPBinding”

type=“pc:PriceCheckPortType”>

<soap:binding style= “document”Transport= “http://schemas.xmlsoap.org/soap/smtp”/>

<operation name=“checkPrice”>

<input>

<soap:body use=“literal”/>

</ input>

<output>

<soap:body use=“literal”/>

</ output>

</ operation>

</ binding>

Exemplo de binding para SMTP



Port

<! - - Service definition - ->

<service name=”PriceCheckService”><port name=”PriceCheck” binding=”pc:PriceCheckSOAPBinding”>

<soap:address location= http://localhost:8080/axis/services/PriceCheck/>

</port>

</service

<! - - Service definition - - >

<service name=“PriceCheckSMTPService”>

<port name=“PriceCheckSMTP” binding=“PriceCheckSMTPBinding”>

<soap:address location= “mailto:[email protected]”/</ port>

</ service>

• Define o endereço da rede da rede onde o Web service é disponibilizado.• Se existirem vários bindings são definidos vários ports

– exemplo para http ou o endereço de email para SMTP



part type

abstract interfaceportType

(abstract)message

(abstract)operation

concreteimplementation

binding(concrete)message

(concrete)message

service concrete endpoint portMade concrete by

Contains zero or more

WSDL information model



WSDL – exemplo (I)

<?xml version=”1.0”?>

<definitions name=”PriceCheck”

targetNamespace=http://www.skatestown.com/services/PriceCheck

xmlns:pc=http://www.skatestown.com/services/PriceCheck

xmlns:avail=http://www.skatestown.com/ns/availability

xmlns:xsd=http://www.w3.org/2001/XMLSchema

xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/

xmlns=”http://schemas.xmlsoap.org/wsdl/”>

<! - - Type definitions - ->

<types>

<xsd:schema targetNamespace=http://www.skatestown.com/ns/availability

xmlns:xsd=http://www.w3.org/2001/XMLSchema>

<xsd:complexType name=”availabilityType”><wsd:sequence>

<xsd:element name=”sku” type=”xsd:string”/>

<xsd:element name=”price” type=”xsd:double”/>

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

</types>



WSDL – exemplo (II)

<! - - Message definitions - -><! - - A PriceCheckRequest is simply an item code (sku) - ->

<message name=”PriceCheckRequest”><part name=”sku” type=”xsd:string”/>

</message>

<! - - A PriceCheckResponse consists of an availability structure, -- >

<! - - defined above.<message name=”PriceCheckResponse”>

<part name=”result” type=”avail:availabilityType”/></message>

<!- - Port type definitions - ->

<portType name=”PriceCheckPortType”><operation name=”checkPrice”>

<input message=”pc:PriceCheckRequest”/><output message=”pc:PriceCheckResponse”/>

</operation></portType>



WSDL – exemplo (III)<binding name=”PriceCheckSOAPBinding” type=”pc:PriceCheckPortType”>

<soap:binding style=”rpc”transport=http://schemas.xmlsoap.org/soap/http/>

<operation name=”checkPrice”><soap:operation soapAction=” “/>

<input><soap:body use=”encoded”

namespace= http://www.skatestown.com/services/PriceCheckencodingStyle= http://schemas.xmlsoap.org./soap/encoding/”/>

</input>

<output><soap:body use=”encoded”

namespace= http://www.skatestown.com/services/PriceCheckencodingStyle= http://schemas.xmlsoap.org/soap/encoding//>

</output>

</operation></binding>

<! - - Service definition - -><service name=”PriceCheckService”>

<port name=”PriceCheck” binding=”pc:PriceCheckSOAPBinding”><soap:address

location= http://localhost:8080/axis/services/PriceCheck/></port>

</service>

</definitions>



Directory

Inspection

UDDI

ADS/DISCO

UDDI- Discovery stack



Discovery Stack

Find Publish

Bind

ServiceProvider

ServiceRequestor

ServiceRegistry



Universal Description Discovery & Integration (UDDI)

• Definição de um conjunto de serviços que suportam a descrição e a localização de:– Entidades que disponibilizam Web Services (empresas,

organizações)– Os Web Services disponibilizados– As interfaces que devem ser utilizadas para aceder aos Web

Services

• Baseada em standards Web: HTTP, XML, XML Schema, SOAP

• Norma definida por um consórcio alargado: Accenture, Ariba, Commerce One, Fujitsu, HP, i2 Technologies, Intel, IBM, Microsoft, Oracle, SAP, Sun e Verisign

• Versão actual: UDDI Version 3.0, 19 Jul 200



Discovery Stack

• Protocolo de ligação ou binding entre o cliente e o servidor.

• Os fornecedores dos serviços publicam a respectiva interface

• O protocolo de inspecção permite verificar se um dado serviço existe baseado na sua identificação

• O UDDI responde às questões– Onde é que o Web service está localizado?– Qual o processo de negócio que o serviço disponibiliza

• O UDDI permite encontrar o serviço baseado na sua definição – capability lookup



JAX - WS

Integração dos Web Services com o ambiente Java



Stack típico de Interacção

Java API

SOAP message

HTTP packet

Java API

SOAP message

HTTP packet

ProviderRequestorView

Developer

Web service

Wire-level



JAX-WS

• Java API for XML Web Services– Evolução da JAX-RPC (Java API for XML-based RPC)

• Em JAX-WS, uma chamada remota de procedimento é efectuada utilizando o protocolo SOAP (que define a estrutura e regras de representação da informação).

• A API do JAX-WS esconde a complexidade da utilização de SOAP do programador.

• No servidor, o programador especifica os procedimentos remotos definindo uma interface em Java e criando uma classe que implemente esta interface.

• No cliente, o programador cria uma proxy (objecto local que representa o serviço) que é invocado para executar os métodos.

• Um cliente JAX-WS pode aceder a Web services definidos noutras plataformas (devido à utilização de HTTP, SOAP e WSDL).



JAX-WS- Arquitectura

Transport Protocol - HTTP

Message Protocol - SOAP

Dispatch

Web Container - Tomcat

Service EndpointService Client

Stub

JAX-WS API

Tie

JAX-WS API

Client Side JAX-WS

Runtime System

Server Side JAX-WS

Runtime System

WSDL

description

WSDL<->

Java Mapping



JAX-WS - Passos de Execução



JAX-WS

• Duas componentes– Server-side

• Definir o WSDL

• Gerar os ties a partir do WSDL

• Empacotar aplicação

• Instalar (deploy) num servidor aplicacional

– Client-side• Gerar os stubs a partir do WSDL

• Compilar e executar a aplicação



Modelo de programação JAX-WS

• Para criar um Web Service em JAX-WS existem duas abordagens: contract-first ou implementation-first

• Contract-first– Define-se o WSDL– Gera-se um esqueleto do servidor usando a ferramenta wsimport– Implementa-se o código do serviço

• Implementation-first– Define-se a classe Java– Anota-se a classe para dizer que deve gerar um Web Service– O WSDL e os ties são gerados usando a ferramenta wsgenerate

JAM10

Slide 61

JAM10 Exemplo do livroJose Alves Marques; 21-01-2005



Service Endpoint

• A interface implícita na classe Java com a anotação @WebService declara os métodos que um cliente remoto pode invocar no serviço

public String sayHello(String name)

Algumas das regras– Os parâmetros de entrada e de retorno tem de ser suportados pelo JAX-WS

JAM11

Slide 62

JAM11 Exemplo do livroJose Alves Marques; 21-01-2005



Exemplo

A implementação é efectuada na própria classe:

public String sayHello(String name) {return "Hello " + name + "!";

}

• A ferramenta wsgenerate gera classes stub (cliente) e tie (servidor), que interagem com as bibliotecas de run-time.

• O wsgenerate gera também o documento da WSDL que descreve o serviço

• As configurações podem ser detalhadas:– Em anotações do código Java (capacidade disponível desde o Java 5)– Ou em ficheiro de configuração



Cliente

• O cliente pode ter um static proxy criado antes da execução (static stub) que é compilado a partir do WSDL pelo wsimport

• O cliente pode também usar um dynamic proxy uma classe que é criada durante a execução a partir do WSDL



Cliente com Stub

• Um stub nunca é downloaded ou distribuído aos clientes

• O stub implementado em Java só é relevante para o run-time do JAX-WS e não é portável para outros ambientes

• O stub é específico para um protocolo de transporte

• Com um stub o cliente não precisa do WSDL em tempo de execução



Stack Típico de Interacção



Cliente

• Invocação estática

– O cliente pode ter um static proxy criado antes da execução (static stub) que é compilado a partir do WSDL pelo wsimport

• Invocação dinâmica

– Dynamic Invocation Interface – DII. Semelhante à invocação dinâmica do Corba. O cliente em tempo de execução utiliza o WSDL para construir a invocação

• Invocação dinâmica. – O cliente pode também usar um dynamic proxy uma classe que é

criada durante a execução a partir do WSDL

JAM9

Slide 67

JAM9 aula 8Jose Alves Marques; 22-03-2006



Cliente com um static proxy

package soma;import javax.xml.rpc.Stub;public class SomaClient {

public static void main(String[] args) {try {

Stub stub = createProxy();SomaIF soma = (SomaIF)stub;

int res = soma.soma(1, 2);

System.out.println("O resultado e': " + res);} catch (Exception ex) {

ex.printStackTrace();}

}

private static Stub createProxy() {// implementação estática de um proxy

return (Stub)(new EndpointSoma_Impl().getSomaIFPort());}

}



Cliente com DII

public class DIIClient_WSDL{

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

String wsdllocation = http://127.O.O.1:9090/billpayservice/billpayservice.wsdl”;

String namespace = “http://www.flutebank.com/xml”; String serviceName = “Billpayservice”; ServiceFactory factory = ServiceFactory.newlnstanceQ; Service service = (Service) factory.createService (

new URL(wsdllocation),new QName(namespace,serviceName));

QName portName = new QName(namespace,”BillPayPort”); QName operationName = new QName(namespace”getLastPayment”); Call call = service.createCall(portName, operationName);

Object[] params = {“my cable tv provider”}; Object lastpaid (Double)call.invoke(params);System.out.println(”Last payment was + lastpaid);

}

}



Dynamic Proxyimport java.util.Date; import java.net.URL;

// Interface class

import com.flutebank.billpayservice.BillPay;

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

String namespace = “http://www.flutebank.com/xml”;

String wsldport “BillPayPort”; String wsdlservice = “Billpayservice”;

String wsdllocation = “http://127.O.O.1:8080/billpayservice/billpayservice.wsdl”;

URL wsldurl = new URL(wsdllocation); ServiceFactory factory = ServiceFactory.newlnstance();

Service service = factory.createService(wsldurl,

new QName(namespace, wsdlservice)); // make the call to get the stub corresponding to this service and

interface BillPay stub (BillPay) service.getPort(new

QName(namespace,wsldport), BillPay.class); // invoke methods on the service

double lastpaid= stub.getLastPayment(“my cable tv provider”); System.out.println(“Last payment was” + lastpaid);

}

}



JAX-WS Handlers

• Os handlers podem ser usados por exemplo para efectuar logging ou cifrar/decifrar os envelopes SOAP que passam na rede

• Handler– Estende a classe

• javax.xml.ws.handler.Handler

– Métodos relevantes• handleRequest(MessageContext context)• handleResponse(MessageContext context)• handleFault(MessageContext context)

• Handler Chain– Sequência de handlers executados sobre pedidos e respostas



HandlersConfiguração

• Configuração (cliente ou servidor)...

<jws:handler-chains>

<jws:handler-chain>

<jws:handler>

<jws:handler-class>util.LogHandler</jws:handler-class>

</jws:handler>

<jws:handler>

<jws:handler-class>util.CipherHandler</jws:handler-class>

</jws:handler>

</jws:handler-chain>

</jws:handler-chains>

...

• Esta configuração especifica que, para cada mensagem SOAP que é recebida ou enviada pelo Web Service, os handlers são invocados na seguinte ordem:– À saída (outbound): Log, Cipher

– À chegada (inbound): Cipher, Log



Projecto em Sistemas Empresariais Integrados



Windows Communication Foundation

Integração dos Web Services com o ambiente .Net 3.0



Windows Communication Foundation (WCF)

• Unifica de forma consistente o anterior suporte na plataforma .Net a:– Web Services

– Invocação remota de objectos (.Net Remoting)

– Transações distribuídas (MS Transaction Server)

– Message Queues (MSMQ)

• Assegurando execução protegida (managed) desse suporte

• Através de modelo de programação orientado a serviços



(As Muitas) Semelhanças de Base com JAX-WS

• Baseado em SOAP para comunicação entre processos

• API simples, alivia programador da complexidade de SOAP, WSDL, etc.– No servidor, o programador especifica os procedimentos remotos definindo uma interface C# (ou Java, ou outra...) e criando uma classe que a implemente

– No cliente, o programador cria um objecto proxy para utilizar os serviços remotos



Definição dos Serviços: Services e Endpoints

• Service serve múltiplas actions – Cada action associada a um método

no servidor• Cada service associado a múltiplos endpoints– No servidor, o programador expõe os

seus Endpoints – Mensagens enviadas para endpoints

• Endpoint define:– Para onde as mensagens devem ser

enviadas (endereço)– Como as mensagens devem ser

enviadas (Binding)– O que as mensagens devem conter (Contract)



Definição dos Serviços: Contracts

• Service Contracts– Mapeia um serviço remoto a uma interface (e.g. C#)

• Operation Contracts– Mapeia uma (ou mais) acções a cada método na interface

• Message Contracts– Permitem definir cabeçalhos específicos para as mensagens SOAP

using System.ServiceModel;

namespace ServiceLibrary {

[ServiceContract(Namespace="http://example.org/echo/")]public interface IEchoService {

[OperationContract]string Echo(string msg);

}

}



Implementação do Serviço


namespace ServiceLibrary {

[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,ConcurrencyMode=ConcurrencyMode.Multiple)]

public class EchoService : IEchoService {

public string Echo(string msg) {

return msg;

}

...

}}

• Classe que implementa a interface do serviço

Behaviors permitem configurar aspectos do processamento local

Existe também operationBehavior

Uma única instância da classe serve as chamadas remotas

Múltiplas chamadas podem acontecer concorrentemente



Definição dos Serviços: Bindings

• Binding define como o cliente deve enviar mensagens e como o servidor as deve processar

• WCF já inclui largo conjunto de bindings pré-definidos– Mas programador também pode criar novos bindings



Definição de Serviços: Exemplo

using System;


using ServiceLibrary;

class Program {

static void Main(string[] args) {

using (ServiceHost host = new ServiceHost( typeof(EchoService), new Uri("http://localhost:8080/echo")))

{

host.AddServiceEndpoint(typeof(IEchoService), new BasicHttpBinding(), "svc");

host.AddServiceEndpoint(typeof(IEchoService),

new NetTcpBinding(),

"net.tcp://localhost:8081/echo/svc");

host.Open();...

}}}

1. Cria serviço, indicando classe que o implementa e

endereço

2. Cria (múltiplos) endpoints

3. Inicia o serviço



Cliente: Exemplousing System; using System.ServiceModel;

using ServiceLibrary;

class Program {

static void Main(string[] args) { try {

// define service endpoints on client ServiceEndpoint httpEndpoint = new ServiceEndpoint(

ContractDescription.GetContract( typeof(IEchoService)),new BasicHttpBinding(), new EndpointAddress("http://localhost:8080/echo/svc"));

IEchoService svc = null;

// create channel factory based on HTTP endpoint

using (ChannelFactory<IEchoService> httpFactory = new ChannelFactory<IEchoService>(httpEndpoint)) {

// create channel proxy for endpoint svc = httpFactory.CreateChannel();// invoke service operation Console.WriteLine("Invoking HTTP endpoint: {0}",

svc.Echo("Hello, world"));}

...

}

1. Cria endpoint do lado do cliente, especificando contract, binding e endereço do endpoint

do servidor

2. Cria proxy (equivalente a dynamic proxy do JAX-WS)

3. Faz chamada remota



SOAP como evolução dos protocolos nas redes



Uma transformação no desenvolvimento dos protocolos

• Os protocolo tradicionais da aplicação na Internet (IETF et al.):– Um protocolo para cada tipo de aplicação:

• SMTP para email, ftp para transferência de ficheiros, HTTP para acesso web, POP para ler email, NNTP para netnews, …

• Processo de desenvolvimento de protocolos lento• refazer segurança (autenticação) para cad protocolo• Cada novo protocolo tem a sua codificação de texto própria • Semelhanças em vários protocolos: SMTP-style headers

– Content-Type: text/plain; charset="us-ascii"; format=flowed

• Exposição ao parsing � Possibilidade de novos buffer overflows para cada protocolo

application

IP

TCP

application

IP

TCP

SOAPHTTP



A transformação do desenho de protocolos

• Uma aplicação, um protocolo � uma infraestrutura comum para o desenvolvimento• Modelo Antigo:

– RPC para as aplicações proprietárias das empresas– Protocolos dedicados para aplicações comuns na internet

• Muitas aplicações novas– Não há engenheiros de redes suficientes– Evoluir de especialista da rede � especialista da aplicação– Um novo protocolo da IEFT demora em média ~5 anos

• Muitas aplicações (do email ao file access) podiam ser estruturadas como RPC

custom text

protocol

(ftp)

RFC 822 protocol

(SMTP, HTTP, RTSP, SIP, …)

use XML for protocol bodies

(IETF IM & presence)

SOAP and other XML protocols

ASN.1-based

(SNMP, X.400)



Porque podem ter sucesso os Web Services se os RPC falharam (??)

• SOAP = só mais um protocolo de RPC– Muitos precursores: SunRPC, DCE, DCOM, Corba, …– Modelo Cliente Servidor– Todos iam transformar a informática das empresas, integrar os sistemas

legados, …• Porque não o fizeram?• Especulação:

– Não tinha uma interface Web (não eram aplicações a três níveis)– Poucas implementações open-source – O protocolo não era o mesmo entre o cliente PC (Microsoft) e o backend

(IBM, Sun, VMS)– As redes empresariais eram locais, ligações à Internet limitadas

Documents

4-Web services 2010 · estrangulamentos, interblocagem •Sósão bem suportadas as interacções 1-para-1 (ou seja não suporta difusão) •Existem mais níveis de software que