Resumo Web Services Evolução

Departamento de Engenharia Informática
Departamento de Engenharia Informática
RPC: comparação com Mensagens
Positivo
Negativo
Programação usando uma IDL que é uma linguagem
• Só são bem suportadas as interacções 1-para-1
(ou seja não suporta difusão)
• Funcionamento síncrono
•A semântica exactamente-uma-vez não é possível
sem um suporte transaccional
•A transparência de execução entre um chamada
local e remota é limitada por alguns pormenores na
passagem de parâmetros
•Existem mais níveis de software que implicam
maior overhead na execução
idêntica às linguagens de programação habituais.
A interface do serviço encontra-se claramente
especificada e não é apenas um conjunto de mensagens
Resumo
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
Mecanismo de estabelecimento da ligação entre o
cliente e o servidor é automatizado através do serviço
de nomes e rotinas do run-time de suporte ao RPC
As funções do cliente e do servidor são consistentes, o
sistema garante que ambas são modificadas
coerentemente
As excepções adaptam-se bem ao tratamento de erros
nas invocações remotas
2009
José Alves Marques
2009
José Alves Marques
Departamento de Engenharia Informática
2
Departamento de Engenharia Informática
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.
Web Services
•
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
2009
José Alves Marques
2009
José Alves Marques
1
Departamento de Engenharia Informática
Departamento de Engenharia Informática
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
Permitir utilizar RPC ou MOM (Message Oriented Middleware)
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
– Conseguindo maior facilidade de passar através das firewalls
•
•
•
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
2009
José Alves Marques
Dinâmica do Mercado
•
IBM
•
Microsoft
– O produto principal é o Websphere que inclui o SOAP, WSDL, UDDI
– .NET suporta directamente Web Services mas é muito mais abrangente
– O biztalk suporta web services
•
Sun Microsystems
– O suporte da Sun ao Java faz com que esta plataforma é uma das que
incorpora a tecnologia Java Enterprise e os Web services.
•
Oracle:
•
SAP:
– Oracle 10i Web Service Broker. BPEL server, Oracle BPMS
– SAP XI,
2009
José Alves Marques
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Porque podem ter sucesso os Web Services se os
RPC falharam (??)
Uniform Resource Identifiers (URIs)
• Standard de nomes de recursos na WWW
• Sintaxe: [prefixo]:[sufixo-específico-do-protocolo]
– Exemplos:
urn:isbn:0-486-27557-4
https://www.ist.utl.pt/index.html
mailto:[email protected]
•
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
• Duas funções distintas:
– Identificar univocamente um recurso na internet
• Chamados URNs (Uniform Resource Names)
e/ou
– Localizar um recurso na internet
• Chamados URLs (Uniform Resource Locator)
2009
José Alves Marques
2
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Modelo dos Web Services
Arquitectura dos Web Services
(arquitectura básica)
Find
Client
•
Name & Service
description
Service
Registry
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
•
Interacção
•
Uma especificação da interface
do serviço – WSDL
•
Contratos
Publish
Service
Service
Requestor
Service
Provider
Bind
Páginas amarelas e directório
(endereço, contactos, identificadores,
categorizadores, ...)
Service
description
Request /Response
13
16-03-2011
16-03-2011
14
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Web Services (standards)
Choreography - CDL4WS
Orchestration - BPEL4WS
Business
Processes
Simple Object Access Protocol
SOAP
Management
Transactions
WS-Reliability
WS-Security
Coordination
Quality of
Service
Context
UDDI
Discovery
WSDL
Description
Description
Protocolo de comunicação dos Web
Services
SOAP
Message
XML
HTTP, JMS, SMTP
2009
José Alves Marques
Transport
2009
José Alves Marques
3
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Simple Object Access Protocol - SOAP
Wire stack – Visão dos Web Services
• Objectivo
– Ubiquitous XML distributed computing infrastructure
– Protocolo de comunicação distribuído permitindo o envio de
qualquer tipo de informação entre aplicações
– Define o protocolo de pedido resposta – estrutura das mensagens
e da interacção entre cliente e servidor
– O 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
XML Messaging
XML and
SOAP
Data Encoding
2009
José Alves Marques
HTTP(S),
SMTP, FTP,
sockets.
Network Protocol
2009
José Alves Marques
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Interacções previstas no SOAP
SOAP Simple Object Access Protocol
SOAP 1.1 Message
Structure
•
Define:
– Modelo de empacotamento
SOAP
Envelope
Quality of Service
SOAP
• Características
Manageability
Envelope
Extensions
Security
SOAP Headers
one-Way
• SOAP Envelope
Client
Server
Client
Server
Client
Server
Client
Server
Mensagem simples
Header
Entries
•
Baseado em XML
•
Pode usar vários transportes:
request-response
[Header
Element]
Body
Element
RPC
– HTTP
– SMTP
– ...
Notification
callback
notification-response
[Fault
Element]
2009
José Alves Marques
2009
José Alves Marques
4
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Execução simples em SOAP
• É necessário um URL de destino
• O nome de uma operação
• Os parâmetros.
Binding do SOAP ao protocolo de Transporte
• Informação contextual, como a informação de segurança
• 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
2009
2009
– 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.
José Alves Marques
José Alves Marques
Departamento de Engenharia Informática
SOAP - Pedido
POST /ExemploHelloWS/endpoint HTTP/1.1
Host: www.server.com
Content-Type: text/xml; charset="utf-8"
Content-Length: 322
SOAPAction: ""
Departamento de Engenharia Informática
Binding de
SOAP sobre HTTP
O que há de
específico deste
transporte?
Envelope SOAP
com pedido
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ns1="http://hello">
SOAP - Resposta
HTTP/1.1 200 OK
Content-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:sayHelloResponse
ns1:sayHelloResponse>
ns1:sayHelloResponse
<ns1:return>Hello friend!</ns1:return>
</ns1:sayHelloResponse>
</soapenv:Body>
<soapenv:Body>
<ns1:sayHello>
<ns1:name>friend</ns1:name>
</ns1:sayHello>
</soapenv:Body>
</soapenv:Envelope>
</soapenv:Envelope>
2009
José Alves Marques
2009
José Alves Marques
5
Departamento de Engenharia Informática
Departamento de Engenharia Informática
SOAP - Erro
HTTP/1.0 500 Internal Server Error
Content-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>
2009
José Alves Marques
WSDL - Web Service Definition Language
Definição do contrato do Serviço
2009
José Alves Marques
Departamento de Engenharia Informática
Departamento de Engenharia Informática
WSDL
WSDL - Web Service Definition Language
Web Services Description Language
WSDL 1.1 Document
Structure
• 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
José Alves Marques
{Messages}
{Port Types}
Diferenças vs IDL de RPC?
2009
[Types]
Interface
Concreta
–
–
–
–
WSDL
Document
Interface
Abstracta
• A IDL dos Web Services
• Define o contrato a que o serviço se obriga
2009
{Bindings}
{Services}
José Alves Marques
6
Departamento de Engenharia Informática
Departamento de Engenharia Informática
WSDL information model
part
Definições
type
• Port Type
abstract interface
portType
(abstract)
message
(abstract)
operation
concrete
implementation
binding
(concrete)
message
Made concrete by
(concrete)
message
service
service.
– Descreve a interface abstracta de um Web
– 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
– 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
• types
concrete endpoint port
Contains zero or more
2009
José Alves Marques
2009
José Alves Marques
Departamento de Engenharia Informática
Departamento de Engenharia Informática
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
2009
José Alves Marques
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
2009
José Alves Marques
7
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Tipos de dados
<types>
<xsd:schema
targetNamespace=http://www.skatestown.com/ns/availability
xmlns:xsd=http://www.w3.org/2001/XMLSchema>
<xsd:complexType name=”availabilityType”>
<xsd:sequence>
<xsd:element name=”sku” type=”xsd:string”/>
<xsd:element name=”price” type=”xsd:double”/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</types>
•
•
Binding
•
•
A função do binding é tornar concreto o serviço definindo a forma
como funciona
Exemplos:
–
–
–
–
•
SOAP; HTTP; SMTP
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.
Tipos utilizados no documento WSDL
Os tipos são declarados num XML schema
Diferente do outro conceito de Binding!
2009
José Alves Marques
2009
José Alves Marques
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Exemplo de binding para HTTP
<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>
2009
José Alves Marques
Exemplo de opções no binding
RPC/encoded
document/literal
document/encoded
RPC/literal
2009
José Alves Marques
8
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Exemplo de binding para SMTP
<!- - 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>
2009
José Alves Marques
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
2009
José Alves Marques
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Universal Description Discovery & Integration
(UDDI)
Discovery Stack
• Definição de um conjunto de serviços que suportam a
descrição e a localização de:
Service
Registry
Find
– Entidades que disponibilizam Web Services (empresas,
organizações)
– Os Web Services disponibilizados
– As interfaces que devem ser utilizadas para aceder aos Web
Services
Publish
• Baseada em standards Web: HTTP, XML, XML Schema,
SOAP
Service
Requestor
2009
Bind
José Alves Marques
Service
Provider
2009
José Alves Marques
9
Departamento de Engenharia Informática
Informação representada na UDDI
Departamento de Engenharia Informática
Modelo estrutural da informação
• businessEntity: descreve uma empresa ou organização
que exporta Web Services
• A UDDI permite pesquisar informação muito variada
sobre os Web Services. Ex:
– Procurar Web Services que obedeçam a uma determinada interface
abstracta
– Procurar Web Services que estejam classificados de acordo com
um esquema conhecido de classificação
– Determinar os protocolos de transporte e segurança suportados por
um determinado Web Service
– Procurar Web Services classificados com uma palavra-chave
– A informação encontra-se conceptualmente dividida em:
– Páginas brancas – informação geral de contacto
– Páginas amarelas – Classificação do tipo de serviço e localização
– Páginas verdes – Detalhes sobre a invocação do serviço
• O acesso é via as API definidas mas os operadores também
disponibilizam sites para acesso via web
• businessService: descreve um conjunto de Web Services
exportado por uma businessEntity
• bindingTemplate: descreve a informação técnica
necessária para usar um determinado serviço
• tModel: descreve o “modelo técnico” de uma entidade
reutilizável, como um tipo de Web Service, o binding a um
protocolo usado por um Web Service, etc.
Sistemas Distribuídos
Sistemas Distribuídos
78
Departamento de Engenharia Informática
Taxionomia
Departamento de Engenharia Informática
Arquitectura UDDI - Registries
• Os serviços registados devem ser categorizados em
taxionomias que os permitam pesquisar
• Existem várias taxionomias normalizadas, ex.:
– ISO 3166 – geografias
– D-U-N-S – Data Universal Numbering System – Dun&Bradstreet
– UN/SPSC- produtos e serviços – ONU
• O UDDI permite que todas as entidades sejam
classificadas
• As pesquisas podem usar múltiplas classificações
• Para uso interno das organizações podem ser definidos os
seus esquemas de classificação. Ex.: qualidade de serviço
do fornecedor do web service
Sistemas Distribuídos
79
80
• Um Registry é composto por um ou mais nós
UDDI
• Os nós de um Registry gerem colectivamente um
conjunto bem definido de dados UDDI.
Tipicamente, isto é suportado com replicação entre
os nós do Registry
• A representação física de um Registry é deixada à
escolha das implementações
Sistemas Distribuídos
81
10
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Registry Server privado
• Gere a base de dados com
os registos UDDI
• Modos de acesso
JAX - WS
– Aplicações JAX-R
– Registry Browser
– Xindice
Integração dos Web Services com o
ambiente Java
• Interfaces
– API
– Acesso directo aos registos
Sistemas Distribuídos
82
2009
José Alves Marques
Departamento de Engenharia Informática
Departamento de Engenharia Informática
JAX-WS
JAX-WS- Arquitectura
Web Container (e.g. JBoss)
•
Java API for XML Web Services
•
•
Esconde a complexidade da utilização de SOAP do programador.
No servidor:
– Evolução da JAX-RPC (Java API for XML-based RPC)
Service Client
Stub
– Programador especifica os procedimentos remotos definindo uma
interface em Java e criando uma classe que implemente esta interface
•
Service Endpoint
Stub (Tie)
No cliente:
– Programador cria uma proxy (objecto local que representa o serviço) que é
invocado para executar os métodos.
•
WSDL
description
Um cliente JAX-WS pode aceder a Web services definidos noutras
plataformas (devido à utilização de HTTP, SOAP e WSDL).
Dispatch
JAX-WS API
Client Side JAX-WS
Runtime System
WSDL
<->
Java Mapping
JAX- WS API
Server Side JAX-WS
Runtime System
Message Protocol - SOAP
Transport Protocol – HTTP, etc
2009
José Alves Marques
2009
José Alves Marques
11
Departamento de Engenharia Informática
Departamento de Engenharia Informática
JAX-WS - Passos de Execução
Programação do servidor JAX-WS
• Contract-first (ver lab. 4)
– Define-se o WSDL
– Gera-se um esqueleto do servidor usando a ferramenta wsconsume
– Implementa-se o código do serviço
• Implementation-first (ver lab. 3)
– 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 wsprovide
Vantagens e desvantagens?
2009
José Alves Marques
2009
José Alves Marques
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Quando usar cada abordagem?
Programação do cliente JAX-WS
• Implementation-first
– Gerar os stubs a partir do WSDL (wsconsume)
– Compilar e executar a aplicação
– Oferecer serviços já implementados por web service
– Construir novo web service de raiz sem ter de aprender
a programar WSDL
• Contract-first
– Programador conhecedor de WSDL que pretende ter
elevado controlo sobre o que é especificado no contrato
– Substituir a implementação de um web service existente
por outro mantendo compatibilidade com clientes
– Aderir a contrato definido por terceiros (e.g. protocolo
definido por consórcio de organizações)
2009
José Alves Marques
2009
José Alves Marques
12
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Cliente com dynamic proxy
Cliente: geração dos stubs
• Invocação estática (static proxy)
– Criado antes da execução
– Gerado e compilado a partir do WSDL
– Não é portável para outros ambientes
• Invocação “semi-dinâmica” (dynamic proxy)
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);
– Classe criada durante a execução a partir do WSDL que se obtém
na altura
– Antes da execução, apenas a interface abstracta do serviço é
conhecida (correspondendo a uma interface Java)
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
• Invocação dinâmica (dynamic invocation interface,DII)
– O cliente em tempo de execução utiliza o WSDL para construir a
invocação
– Antes da execução, nem interface abstracta nem concreta do
serviço são conhecidas
2009
double lastpaid= stub.getLastPayment(“my cable tv provider”);
System.out.println(“Last payment was” + lastpaid);
}
}
José Alves Marques
2009
José Alves Marques
Departamento de Engenharia Informática
Departamento de Engenharia Informática
Cliente com invocação dinâmica (DII)
JAX-WS Handlers
•
•
public class DIIClient_WSDL{
Os handlers podem ser usados por exemplo para efectuar logging ou cifrar/decifrar os
envelopes SOAP que passam na rede
Handler
–
Estende a classe
–
Métodos relevantes
• javax.xml.ws.handler.Handler
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”};
• handleRequest(MessageContext context)
• handleResponse(MessageContext context)
• handleFault(MessageContext context)
•
Handler Chain
–
Sequência de handlers executados sobre pedidos e respostas
Object lastpaid = (Double)call.invoke(params);
System.out.println(”Last payment was” + lastpaid);
}
}
2009
José Alves Marques
2009
José Alves Marques
13
Departamento de Engenharia Informática
Handlers
Configuraçã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
2009
José Alves Marques
14