Web Services
Equipe:
Cláudia Brito Lyra Nunes da Silva
Clindemberg Mendes Patrício
Luiz Eugênio Fernandes Tenório
Marcelo Faro do Amaral Lemos
Marco Antônio Costa Simões
Paula Geralda Barbosa Coelho
Simith
Tópicos






Web Services
CORBA e Web Services
SOAP & WSDL
UDDI
WSFL
ebXML
Web Services
Integração de Aplicações

O desafio da interoperação entre
ambientes heterogêneos
Integração de Aplicações

Diversidade de componentes


Diversidade de linguagens



EJB, CORBA, DCOM ...
Java, C/C++, C# ...
Firewalls
Falta de padrões para interoperação
Integração de Aplicações

Definindo o formato para troca de
dados
Business-to-Business

Aplicações se conhecem e conversam
entre si
Web Services

Aplicações oferecem serviços que
podem ser acessados dinamicamente
Web Services

Próxima geração de serviços baseados na
internet que utiliza padrões da indústria,
como XML, SOAP, UDDI e ebXML, para
conectar aplicações e provê novos serviços
via Internet


serviços mais robustos e integrados
Nova “onda” de componentes


serviços como componentes reutilizáveis
“blocos” que integrados produzirão novos serviços
Web Services

Definição

Modelo computacional distribuído






fracamente acoplado
utiliza mecanismos de transporte padrão (HTTP e HTTPS)
modelo de programação síncrona e assíncrona
utiliza XML para o transporte de dados
Descrito através de metadados (XML)
Localizável através de pesquisas em diretórios de
serviços
Web Services

Service-oriented


Serviços inteligentes


paradigma de orientação a serviços
coarse grained services
Tecnologia

basicamente é XML sobre HTTP


XML: porque o mercado concorda
HTTP: livre acesso através de firewalls
Web Services


A web “costumava” ter foco em pessoas
A web está se tornando um plataforma
A2A (application-to-application)


B2B é um caso especial
Web Services é a plataforma
computacional distribuída sobre a qual
aplicações A2A serão construídas
Arquitetura Típica de uma
Aplicação Web
Web
Services
Web Services
Enterprise
Legacy
System
Firewall
as
service
Business
Partner
as
service
as
service
Enterprise
Services
Gateway
as
service
as
service
Enterprise
Client
Enterprise
Messaging
System
as
service
as
service
Web/
Application
Server
Workflow/
Business
Processes
Devices
Web Services
Enterprise
Legacy
System
provide
widget
Enterprise
Messaging
System
Service
Provider
Services
Gateway
Workflow/
Business
Processes
Service
Requester
Web
Server
Application
Server
Services
Broker
Enterprise
Legacy
System
Enterprise
Messaging
System
Service
Provider
Service
Requester
Services
Gateway
Workflow/
Business
Processes
Web
Server
Application
Server
need
widget
Web Services pode ser visto
como middleware ?
Tecnologias Web Services

Any technology-service paradigm

Tipicamente





SOAP: transporte de dados (XML/HTTP)
WSDL: descrição dos serviços
UDDI: registro e busca de serviços
ebXML: framework para e-commerce
WSFL: composição de Web Services
SOAP


Simple Object Access Protocol
Modelo de mensagens independente do
protocolo de transporte


Modelo de codificação para tipos do sistema


suporte para HTTP
exemplo: XML para objetos Java, e vice-versa
RPC sobre HTTP
WSDL


Web Services Definition Language
Provê descrição funcional de serviços




IDL description
Protocol and deployment details
idealmente deveria provê todas as
informações necessárias para acessar o
serviço (programaticamente)
Machine-readable description
UDDI



Universal Description, Discovery and
Integration
Coleção de diretórios (peers) que
contém informações sobre negócios e
serviços
Conjunto de especificações baseadas
em padrões para a descrição e pesquisa
de serviços
UDDI
WSFL


Web Services Flow Language
Composição de Web Services



controle do fluxo de mensagens
Construída sobre WSDL
Modelos de utilização

Flow Model


compõe serviços existentes em novos serviços, definindo
o workflow entre os serviços compostos
Global Model

descreve a interação entre serviços sem definir a função
(serviço) composto
Web Services

Papéis




Service provider
Service broker
Service requester
Operations



Publish
Find
Bind
Business Web

Novo tipo de aplicação
Business Web

É um Web Services composto por
outros Web Services
Business Web
Que tipos de aplicações
utilizarão Web Services?
Web Services

Benefícios







baixo acoplamento entre aplicações
evolução independente de aplicações
B2B a baixo custo (reuso)
EAI (Enterprise Application Integration) não
intrusiva
diversidade de componentes não afeta
interoperabilidade
diversidade de linguagens não afeta
interoperabilidade
padronização (futura)dos mecanismos de
interoperação
Web Services em Java
Web Services em Java


Estende HTTP e Servlets/JSP para
suportar “program-to-program” ou
“business-to-business”
(Re)utiliza a infra-estrutura J2EE
WebServices Pack

Empacotamento de todas as tecnologias
necessárias para o desenvolvimento de
web services
WebService
Pack
Tomcat
JAX Pack
Java Server
Faces
JSP TagLibrary
Web Services

Companhias estão anunciando sua estratégia
para Web Services



IBM, Sun, Oracle, HP, ...
duas plataformas devem dominar o mercado: a
plataforma Java e .NET
Novos servidores de aplicação já oferecem
soluções para o desenvolvimento de web
services



WebSphere 4.0 (IBM)
WebLogic 6.1 (BEA)
...
Web Services

Considerações

operações precisam ser restringidas por
mecanismos de segurança negociáveis



Encriptação, autenticação, autorização ...
requer padrões bem definidos e
largamente adotados
performance

Transformação XML <-> 0101010
Web Services

Conclusão

é uma forma nova de utilizar tecnologias e
conceitos já existentes

viabilizada pelo contexto tecnológico e
comercial atual
CORBA e Web Services
CORBA e Web Services
• Características benéficas a integração:
• Web Services:
• Um middleware para middleware
• Pode ser utilizado com um middleware existente (ex.
COM/DCOM, J2EE, CORBA)
• CORBA:
• Uma arquitetura aberta composta de ~42 interfaces
definidas para serviços horizontais e verticais
• Independência de protocolo de aplicação com a
utilização de mapeamentos para GIOP
CORBA e Web Services
• Possíveis cenários de integração:
• Implementando objetos CORBA utilizando
Web Services;
• Implementando Web Services utilizando
objetos CORBA;
• Expondo objetos CORBA como Web
Services;
CORBA e Web Services
• Implementado objetos CORBA usando Web
Services:
CORBA e Web Services
• Implementado Web Services usando objetos
CORBA:
CORBA e Web Services
• Expondo objetos CORBA como Web Services:
CORBA e Web Services
• Comparação entre protocolos de transporte:
GIOP/IIOP
SOAP/HTTP
Codificação das
mensagens
- CDR
- Menor tamanho
(sintaxe binária)
- XML
- Maior legibilidade *
(sintaxe texto)
Complexidade de
empacotamento
- Simples/Média
- Complicado
- Devido ao uso de parsers XML
Suportado na
Internet
- Tráfego não permitido na
maioria dos firewalls
- Utiliza protocolos de
aplicação conhecidos na
Internet (ex. HTTP)
Interoperabilidade
com middlewares
existentes
- Utilizando outros
mapeamentos (ex. DCE CIOP)
- Utilizando bridges (ex. DCOM)
- Mapeamento mais simples
- Ubiquitous industry support
SOAP
SOAP – Simple Object
Access Protocol
• Definição:
É um protocolo que descreve mensagens
trocadas entre processos, chamadas
remotas a métodos e padrões para
transporte via HTTP.
Baseado em XML
Se propõe a desempenhar o mesmo papel
do IIOP (padrão CORBA), ORPC (padrão
DCOM) e JRMP(padrão Java RMI) para
Sistemas Distribuídos na Internet.
Para que mais um
protocolo ?
• SOAP é baseado em texto (XML) enquanto os
demais protocolos (IIOP,JRMP,ORPC) são
binários
 Vantagens: facilidade de depuração e maior
adaptabilidade aos firewalls
 Desvantagem: tamanho da mensagem SOAP é bem
maior que os protocolos binários podendo gerar
perda de performance
• Padrão aberto e independente de plataforma
Arquitetura do SOAP
• Um envelope que descreve o conteúdo
da mensagem e como processá-la
• Um conjunto de regras de
codificação que descrevem como os
tipos de dados definidos na aplicação
são serializados
• Uma convenção para representar
chamadas remotas a métodos
(RPC) e suas respostas
Exemplo de Mensagem
SOAP
<SOAP-ENV:Envelope
xmlns:SOAPENV=“http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsi=“http://www.w3.org/2001/XMLSchemainstance”
xmlns:xsd=“http://www.w3.org/2001/XMLSchema”
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Exemplo: SOAP Body
<SOAP-ENV:Body>
<ns1:sayHelloTo
xmlns:ns1=“Hello”
SOAPENV:encodingStyle=“http://schemas.xmlsoap.org/soa
p/encoding/”>
<name xsi:type=“xsd:string”>Maria</name>
</ns1:sayHelloTo>
<SOAP-ENV:Body>
Implementando um Web
Service SOAP
• A Especificação SOAP restringe-se aos
detalhes da mensagem que é trocada
entre os processos
• Não há qualquer padronização quanto
às API’s para implementar Serviços ou
clientes
• Existem uma série de ferramentas
disponíveis: MS SOAP Toolkit, IBM
WSTK, Apache-SOAP, GLUE, etc
Pré-Requisitos
• O requisito básico é possuir um Servidor
Web com suporte para servlets
• O Serviço pode ser implementado em
diversas linguagens de programação e
de script
• Tomando Java como exemplo, um
serviço é uma classe Java comum sem
qualquer alteração adicional
Exemplo de Serviço
public class HelloServer {
public String sayHelloTo(String nome)
{
return "Ola "+nome+", como vai ?";
}
public String sayHelloTo(Name nome) {
return "Ola "+nome.getName()+", como
vai ?";
}
}
O Cliente
• O mesmo serviço pode ser publicado
utilizando ferramentas de apoio diferentes
sem sofrer qualquer alteração.
• O Cliente, entretanto, pode mudar bastante
entre pacotes diferentes.
• A seguir será exemplificado um cliente para o
serviço anterior usando o Apache-SOAP e
outro utilizando o GLUE.
Cliente Apache-SOAP
Call call = new Call();
call.setTargetObjectURI("urn:Hello");
call.setMethodName("sayHelloTo");
call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC
);
Vector params = new Vector();
params.addElement(new
Parameter("nome",String.class,nome,null));
call.setParams(params);
Cliente Apache-SOAP
Response resp = null;
try { resp = call.invoke(url,""); }
...
Parameter ret = resp.getReturnValue();
Object value = ret.getValue();
System.out.println(value);
Cliente GLUE
IHelloServerService server = HelloServerHelper.bind();
System.out.println(server.sayHelloTo(“Maria”));
• A interface IHelloServerService pode ser gerada com
o utilitário wsdl2java fornecido junto com o pacote;
• O mesmo utilitário gera também a classe
HelloServerHelper.
• O GLUE exige que o Serviço publique a sua interface
WSDL para que o cliente utilize como base
• Se o serviço for publicado utilizando o Servidor Web
do próprio GLUE, este gera o WSDL dinamicamente
Tratamento de Exceções
• A Especificação SOAP prevê que os
métodos remotos retornem Exceções
para os clientes através do rótulo
<Fault>
• Ou seja, qualquer exceção lançada pelo
Serviço será convertida em uma seção
<Fault> no envelope SOAP de resposta
Tratamento de Exceções
• Da mesma forma que a API do cliente não é
padronizada, a forma como as exceções
serão capturadas e tratadas também não é
estabelecida
• No Apache-SOAP, o Fault é extraído do objeto
Response que é retornado
• No GLUE, deve ser capturada uma exceção
WrappedException que contém uma
SOAPException encapsulada contendo as
informações do Fault
WSDL
WSDL – Web Services
Description Language
• Definição:
É a especificação publicada para um
diretório UDDI(Universal Description
Discovery).
Tem uma interface e implementação de
detalhes específicos dos serviços da Web
disponíveis e dos respectivos proprietários
Baseada em XML, descreve a interface,
protocolos, ligações, detalhes de
visualização, tipos de dados e localização
A Dupla SOAP e WSDL
• O SOAP foi criado pela Microsoft/IBM
• O WSDL foi criado para descrever os
contratos(interfaces) dos serviços WEB
invocados através do SOAP
• Estes contratos de serviços indicam à aplicação
que pretende chamar os serviços, quais são as
suas interfaces, incluindo parâmetros de
chamada e retorno
• Resolvem os problemas de interoperabilidade
das plataformas, mas o aspecto dinâmico ainda
não foi inteiramente solucionado
IDL (Interface Definition
Language)
• Definida juntamente com o CORBA 1.1
em 1991
• Descreve as interfaces que são
chamadas pelos clientes e fornecidas
pelas implementações
• O mapeamento IDL foi estabelecido
primeiramente com a utilização da
linguagem C++
IDL X WSDL
Padrão de Mapeamento
SIM
NÃO
Protocolo de Mensagens
IIOP
SOAP
-
UDDI
NÃO
SIM
NÃO
SIM
Registro dos Serviços
Fornece Localização
(URL)
Complexidade de
Programação
Exemplo de IDL
UMA INTERFACE SIMPLES CONTENDO UMA OPERAÇÃO:
Module Exmodule {
structure ExStuct{
short structMember1;
float structMember2;
};
exception ExException{
string excepMember1;
long excepMember2;
};
interface Exinterface {
string ExOp( in long inParam1, out float outParam2, inout Exstruct
inoutParam3)
raises(ExException);
};
}
Mapeamento o Exemplo de
IDL -> WSDL
<?xml version=”1.0” ?>
<wsdl:definitions
name=”ExInterfaceService”
targetNamespace =” http://example.com/Exmodule/ExInterface.wsdl”
xmlns:tns=”http://example.com/ExModule/ExInterface.wsdl”
xmlns:xds=”http://www.w3.org/2000/10/XMLSchema”
xmlns:defs=”http://example.com/ExModule/definitions”
xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap”
xmlns:scoap=” http://schemas.omg.org/scoap/encoding”
xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”
<wsdl:importnamespace = “ http:// schemas.omg.org/scoap/encoding”
location=”http: //localhost/schemas/omg/scoap.xsd “ />
<wsdl:importnamespace = “ http:// example.com/ExModule/chemas”
location=”http: //localhost/schemas/ExModule/ExModule.xsd “ />
<wsdl:message name = “ ExException”
<wsdl:part name=”Exception” type=”defs:ExException” />
</wsdl:message>
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
Mapeamento IDL -> WSDL
<wsdl:message name = “ ExOpInput”
<wsdl:part name=”InParam1” type=”scoap:long” />
<wsdl:part name=”InoutParam3” type=”defs:ExStruct” />
</wsdl:message>
<wsdl:message name = “ ExOpOutput”
<wsdl:part name=”_return” type=”scoap:string” />
<wsdl:part name=”OutParam2” type=”scoap:float” />
<wsdl:part name=”InoutParam3” type=”defs:ExStruct” />
</wsdl:message>
<wsdl:message name = “ InterfaceType”
<wsdl:part name=”RepID” type=”defs:ExInterfaceRepId” />
</wsdl:message>
<wsdl:porttype name = “ ExInterface”
<wsdl:operationname=”ExOp” />
parameterOrder = “inParam1 outParam2 inoutParam3” >
<wsdl:input message=”tns:ExOpInput” />
<wsdl:output message=”tns:ExOpOutput” />
<wsdl:fault message=”tns:ExException” />
</wsdl:operation>
</wsdl:portType>
(11)
(12)
(13)
(14)
(15)
WSDL
UDDI
UDDI
(Universal Description, Discovery and Integration)




Permite informações sobre negócio e serviços
sejam eletronicamente publicadas e
consultadas. “Register once, published everywhere”
Define como os negócios interagem sobre a
internet e compartilham informações em uma
arquitetura de registro global.
É um framework para integração de Web
Services.
UDDI Project(www.uddi.org) participam a
IBM, Microsoft e Ariba.
UDDI
(continuação)




UDDI é uma especificação global. Toda
empresa espalhada pelo mundo é capaz de
se registrar em um UDDI Business Registry.
Business Registry implementa a especificação
UDDI.
Nos Registries ocorre uma sincronização de
seus conteúdos regularmente.
Permissões de acesso – Somente o usuário
com as credenciais que conferem com as
credenciais usadas para criação dos registros.
Benefícios imediatos de UDDI




A capacidade de negócios rapidamente e
dinamicamente descobrir outros e interagir na
internet.
Agregar valor aos serviços já fornecidos aos
seus clientes.
Potencializar o crescimento do comércio B2B.
Ressalva: A especificação UDDI ainda não foi
submetida a organizações de padronização. A
versão utilizada pelos desenvolvedores é a
1.0(Draft).
UDDI

Informação fornecida a um registro UDDI
consiste de três componentes:

White pages
Informações de contato da empresa.

Yellow pages
Categorização dos serviços pela taxonomia padrão.

Green pages
Informações técnicas sobre o serviço exposto(regras de
negócio, descrição do serviço,...)
UDDI

Define quatro elementos básicos:

businessEntity
Possui as descrições e informações técnicas dos
serviços. Cada businessEntity possui uma única
chave que identifica o negócio/dado (Modela a
informação de negócio).

businessService
Representa os serviços ou processos de negócio
fornecidos pelo businessEntity (Definição de
alto-nível dos serviços).
UDDI
(elementos)

bindingTemplate


Apresenta os dados que descrevem as
características técnicas de uma dada
implementação de serviço(Mapeamento
entre businessService e tModel).
tModel

Modela um tipo de tecnologia ou serviço.
UDDI
(elementos)
Implementações de UDDI

jUDDI(“judy”)



Desenvolvida pela Bowstreet.
Foi uma das primeiras implementações de
UDDI.
Uddi4J


Desenvolvida pela IBM.
Está presente IBM WSTK 2.1(Web Service
Toolkit).
WSFL
WSFL

Web Service Flow Language

Definição


Modelo de fluxo
Modelo global
Processo Negócio
Modelo de Fluxo
<flowModel name="bookTickets" serviceProviderType="airlineFlow">
<flowSource name="ticketFlowSource">
<output name="processInstanceData"
message="tio:receivedTicketOrder"/>
</flowSource>
<serviceProvider name="agent" type="agentType"/>
<serviceProvider name="traveler" type="travelerType"/>
<activity name="reserveSeats">
<input name="reserveSeatsInput" message="tio:receivedTicketOrder"/>
<output name="reserveSeatsOutput" message="tio:reservation"/>
<performedBy serviceProvider="local"/>
<implement>
<internal>
<!-- .. call to credit card service .. -->
</internal>
</implement>
</activity>
Modelo Global
<globalModel name="bookTripNTickets" serviceproviderType="agentType">
<serviceProvider name="travelAgent"
serviceProviderType="tio:agentType">
<export>
<source portType="tio:tripHandler" operation="sendItinerary"/>
<target portType="tio:tripNTicketHandler"
operation="sendItinerary"/>
</export>
<export>
<source portType="tio:tripHandler" operation="receiveTripOrder"/>
<target portType="tio:tripNTicketHandler"
operation="receiveTripOrder"/>
</export>
<locator type="static" service="abc:agent"/>
<locator type="uddi" bindTime="startup" selectionPolicy="first">
<uddi-api:find_service businessKey="uuid_key"
generic="1.0" xmlns:uddi-api="urn:uddi-org:api">
</uddi-api:find_service>
</locator>
</serviceProvider>
ebXML
ebXML
• Definição:
Conjunto de especificações que juntas possibilitam
um framework para comércio eletrônico.
• Objetivo:
Prover uma infraestrutura aberta baseada em
XML, possibilitando a prática global do comércio
eletrônico de uma forma consistente, segura e
interoperável por todas as partes.
ebXML
• A que se propõe:
Criar padrões para definir:
 Transações comuns de negócios
 Formatos comuns de troca de dados
 Um mecanismo que possibilite descrever o perfil das
companhias
 Um mecanismo que permita organizações descobrirem
outras companhias e ter acesso ao seu perfil
ebXML
 Um mecanismo que permita duas organizações
estabelecerem acordos (contratos) antes de iniciarem as
transações
 Um mecanismo de transporte comum para a troca de
mensagens entre as organizações
 Um framework seguro e confiável
ebXML
Componentes
• ebXML Registry and Repository
 Meio de compartilhar informação entre
empresas
Registry: Serviço similar ao UDDI
Repository: Armazena informações de como a
empresa trabalha: processos,
documentos e perfis de negócio
ebXML
Componentes
• CPP (Collaboration Protocol Profile)
 Descreve o Web service (nome do serviço,
parâmetros requeridos, forma de acessá-lo)
 Permite a empresa descrever o seu perfil
• CPA (Collaborative Partner Agreement)
 Acordo estabelecido entre duas organizções
 Baseado no CPP de ambas
 Adminstra as transações entre elas
ebXML
Componentes
• ebXML Messaging Service
 Qualquer transporte pode ser usado
 Qualquer tipo de informação pode ser roteada
ebXML
(Visão geral de um sistema ebXML)
• Fase de implementação
Durante essa fase a organização deve:
 Solicitar as especificações ebXML e entendê-las
 Implementar um sistema ebXML
 Publicar seu perfil (CPP) de negócio no repositório
ebXML, permitindo que outras organizações o acesse.
ebXML
(Visão geral de um sistema ebXML)
• Fase de implementação
ebXML
(Visão geral de um sistema ebXML)
• Fase de negociação
Durante essa fase a organização deve:
 Recuperar do repositório ebXML o perfil de uma
organização com a qual ela pretende realizar negócios
 Verificar se a organização provê os serviços que ela
deseja
 Enviar a organização um contrato (CPA)
ebXML
(Visão geral de um sistema ebXML)
• Fase de negociação
ebXML
(Visão geral de um sistema ebXML)
• Fase de transação
Depois que as duas organizações estiverem de
acordo com o CPA as transações podem ser
efetuadas. Essas transações consistem em
mensagens ebXML, que são enviadas através do
serviço de mensagens do padrão ebXML.
ebXML
(Visão geral de um sistema ebXML)
• Fase de transação
ebXML
(Visão geral de um sistema ebXML)