TJAVWSER - v4 - (08.11.2010)

Java Web Services
TJAVWSER
Novembro/2010
Apostila desenvolvida especialmente para a Target Informtica Ltda.

Sua cpia ou reproduo expressamente proibida.
Java Web Services
Sumrio
1. Integrao.................................................................................. 1
Objetivos....................................................................................................................................2
Introduo.................................................................................................................................3
Desafios da integrao.........................................................................................................4
Diferentes tipos de integraes.............................................................................................4
Integrao em nvel de dados................................................................................................5
Integrao em nvel de sistema.............................................................................................5
Integrao em nvel de processos de negcio.......................................................................6
Integrao em nvel de apresentao....................................................................................7
Integrao B2B (Business-to-Business)...............................................................................8
Infraestrutura para integraes......................................................................................10
Comunicao......................................................................................................................10
Transformao....................................................................................................................10
Business Intelligence (BI)...................................................................................................10
Transaes...........................................................................................................................11
Segurana............................................................................................................................11
Ciclo de vida.......................................................................................................................11
Nomenclatura......................................................................................................................11
Escalabilidade.....................................................................................................................11
Gerenciamento....................................................................................................................12
Tecnologias para integraes...........................................................................................13
Acesso a banco de dados....................................................................................................13
Message-Oriented Middleware (MOM).............................................................................13
Remote Procedure Call (RPC)............................................................................................14
Object Request Brokers (ORB)..........................................................................................15
Servidores de aplicao......................................................................................................16
Web Services.......................................................................................................................17
Enterprise Service Buses (ESB).........................................................................................18
As empresas hoje em dia..................................................................................................19
Trocando os sistemas existentes....................................................................................20
Exerccios.................................................................................................................................21
2. SOA (Service Oriented Architecture)...........................................23
Objetivos..................................................................................................................................24
Conceitos e princpios de SOA.........................................................................................25
Mudana de paradigma: de aplicaes independentes ao servio......................................26
Orientao a servio............................................................................................................26
Servios baseados em componentes...................................................................................26
A internet simplificando os servios remotos.....................................................................27
Consumindo servios..........................................................................................................27
Vantagens e desvantagens...................................................................................................28
Aplicaes...........................................................................................................................29
Exerccios.................................................................................................................................30
3. Web Services............................................................................33
Objetivos..................................................................................................................................34
Integrao...............................................................................................................................35
T@rgetTrust Treinamento e Tecnologia
Integra
Porque usar web services?................................................................................................36

Arquitetura dos web services...........................................................................................37
Benefcios dos web services.............................................................................................38
Self-Contained....................................................................................................................38
Self-Describing...................................................................................................................38
Modular...............................................................................................................................38
Acessvel atravs da web....................................................................................................38
Linguagem, plataforma e protocolo neutros.......................................................................39
Aberto e baseado em padres.............................................................................................39
Dinmico.............................................................................................................................39
Web Services em Java: Serializao..............................................................................40
Exerccios.................................................................................................................................43
4. Criando Web Services................................................................45
Objetivos..................................................................................................................................46
Necessidades bsicas.........................................................................................................47
IDE (Integrated Development Environment).....................................................................47
soapUI.................................................................................................................................47
Apache Tomcat...................................................................................................................50
Apache OpenEJB................................................................................................................50
JAX-WS.......................................................................................................................................51
Descrio............................................................................................................................51
Necessidades.......................................................................................................................51
Arquitetura..........................................................................................................................51
Construo de um web service...........................................................................................52
Descrio bsica das Annotations mencionadas.................................................................56
Publicando um web service sem Application Server..........................................................57
JAX-WS (via EJB).....................................................................................................................58
Descrio............................................................................................................................58
Necessidades.......................................................................................................................58
Arquitetura..........................................................................................................................59
Apache Axis............................................................................................................................63
Descrio............................................................................................................................63
Necessidades.......................................................................................................................63
Arquitetura..........................................................................................................................63
Codehaus XFire......................................................................................................................66
Descrio............................................................................................................................66
Necessidades.......................................................................................................................66
Arquitetura..........................................................................................................................66
Exerccios.................................................................................................................................70
5. Criando clientes de Web Service.................................................73
Objetivos..................................................................................................................................74
O que so clientes de web services?............................................................................75
WSDL - Web Service Definition Language...................................................................76
Eclipse IDE como cliente de web service....................................................................79
Geradores de cliente automticos.................................................................................82
II
Integra
Fixando conceitos...............................................................................................................82
JAX-WS..............................................................................................................................82
JAX-WS: Consumindo o Servio.......................................................................................85
Apache Axis 1.x: Consumindo o Servio...........................................................................86
Apache Axis 2.x..................................................................................................................87
Apache Axis 2.x: Consumindo o Servio...........................................................................87
Netbeans IDE......................................................................................................................88
Netbeans IDE: Consumindo o Servio...............................................................................90
Exerccios.................................................................................................................................91
Espao para anotaes........................................................................................................92
6. Comunicao via SOAP..............................................................93
Objetivos..................................................................................................................................94
O que SOAP?.......................................................................................................................95
Por que SOAP?........................................................................................................................96
Bloco de estrutura SOAP....................................................................................................97
Exemplo de mensagem SOAP..........................................................................................99
O SOAP Request.................................................................................................................99
O SOAP Response..............................................................................................................99
SAAJ - SOAP with Attachments API for Java..............................................................100
Mensagens........................................................................................................................100
Estrutura do XML.............................................................................................................100
Mensagem sem anexos.....................................................................................................100
Mensagem com anexos.....................................................................................................101
Conexes...........................................................................................................................102
Exemplo completo de chamada....................................................................................104
Dica de construo da chamada SOAP.............................................................................105
Exerccios...............................................................................................................................109
Espao para anotaes......................................................................................................110
7. Segurana com Web Services...................................................111
Objetivos................................................................................................................................112
Introduo..............................................................................................................................113
Segurana em web service.............................................................................................114
Segurana em nvel de transporte.....................................................................................114
Segurana em nvel de XML............................................................................................115
Questes a serem consideradas...................................................................................116
Vantagens da segurana na camada de mensagem............................................117
Especificaes e iniciativas atuais...............................................................................118
Especificaes W3C.........................................................................................................118
Especificaes OASIS......................................................................................................119
Especificaes JCP...........................................................................................................119
Especificaes WS-I.........................................................................................................120
WS-Security...........................................................................................................................121
Exerccios..........................................................................................................................122
Espao para anotaes......................................................................................................123
Apndice 1: Estudos Complementares...........................................125
Diferena entre JAX-RPC e JAX-WS................................................................................126
Diferena entre Document/Literal e RPC/Literal.....................................................127
III
Integra
Referncias Bibliogrficas............................................................129
IV
Integra
1. Integrao
Integrao
Objetivos
Compreender como as integraes de dados e softwares impactam as

empresas.
Conhecer os desafios relacionados s integraes.
Identificar infraestrutura e tecnologia envolvidas nas integraes.
Integrao
Introduo
A crescente necessidade de disponibilidade e acesso s informaes
caracteriza um desafio para o desenvolvimento de aplicaes. Sistemas standalone no conseguem mais atender s necessidades de crescimento das
empresas atualmente. A maioria das companhias ainda tm sistemas legados,
desenvolvidos utilizando diferentes arquiteturas e tecnologias. Muitos destes
sistemas, no foram concebidos para proporcionarem integrao. Seria
extremamente custoso para as empresas reescrever ou trocar todos seus
sistemas da noite para o dia.
Alm disto, empresas precisam, sem sombra de dvida, aderir a novos
sistemas de tempos em tempos. Novas solues, normalmente, so baseadas
em novas e modernas arquiteturas, que acabam diferindo significantemente
daquela utilizada nos sistemas legados. Estas novas aplicaes tambm tm
de se integrar s aplicaes existentes, para formar um conjunto nico e coeso
de dados que podem ser aproveitados entre si.
Hoje, a integrao de aplicaes uma tarefa extremamente difcil, talvez a
mais complicada de ser encarada, no que diz respeito ao desenvolvimento de
aplicaes em uma empresa. Para tentar solucionar estes objetivos de
integrao, muitas metodologias, tcnicas e tecnologias foram desenvolvidas
nos ltimos anos, desde a integrao de aplicaes ponto-a-ponto, quanto ao
gerenciamento de processos de negcio baseado em arquitetura orientada a
servios.
Integrao
Desafios da integrao
A habilidade de instantaneamente acessar informaes vitais que podem estar
armazenadas em uma variedade de diferentes aplicaes pode influenciar o
sucesso de uma empresa. Para as empresas, a facilidade de acesso
informao, de forma que evite numerosas tarefas manuais, ou que envolvam
muitos funcionrios, muito importante. Funcionrios no devem ter de trocar
de sistema em sistema para que consigam realizar seus trabalhos, ou mesmo,
entrar com a mesma informao em diversos sistemas. O ideal seria possuir
sistemas bem integrados, garantindo o suporte aos processos de negcio de
ponta a ponta.
Muitos gestores de TI no esto familiarizados com a complexidade escondida
por trs da integrao de processos. s vezes, at os funcionrios de TI,
arquitetos e desenvolvedores, no compreendem as armadilhas atrs das
integraes. E o mais importante: os gestores podem no compreender
que uma integrao relaciona-se com a empresa como um todo, e no
somente com o departamento de TI.
Integraes devem ser consideradas como as mais importantes prioridades
estratgicas, principalmente porque solues inovadoras demandam
integraes entre diversas reas do negcio, dados da empresa e aplicaes.
Informaes integradas aumentam a vantagem competitiva com o acesso
unificado e eficiente informao. Integraes bem feitas facilitam a busca por
informaes na hora da necessidade por uma tomada de deciso, por exemplo.
Diferentes tipos de integraes

A arquitetura das integraes construda normalmente em camadas. A ideia
por trs disto a de o problema ser quebrado em pedaos menores para que
possam ser resolvidos passo a passo. Atualmente, as integraes podem ser
vistas em diversas camadas.
A seguir, sero comentados os seguintes tipos de integraes:
Integrao
Integrao
Integrao
Integrao
Integrao
em nvel de dados
em nvel de sistema
em nvel de processo de negcio
em nvel de apresentao
B2B (Business-to-Business)
Integrao
Integrao em nvel de dados

A integrao em nvel de dados tem como objetivo a movimentao dos dados
entre sistemas, primando pelo compartilhamento das mesmas informaes.
Geralmente, este o ponto inicial onde as empresas iniciam o trabalho de
integrao.
Data
Data
Server
Server
Data
Data
Data
Server
Server
Integrao em nvel de sistema

O foco principal da integrao em nvel de sistema o compartilhamento de
funcionalidades lgica de negcio; e no apenas integrao em nvel de
dados. Integrao em nvel de sistema comumente conseguida atravs de
APIs (Application Programming Interfaces). Sistemas que expe suas
funcionalidades atravs de APIs permitem o acesso s suas funcionalidades de
uma forma programtica; atravs de suas interfaces.
Integrao
Integrao em nvel de processos de negcio

A integrao em nvel de processos de negcio tem como objetivo expor
atravs de interfaces uma abstrao das funcionalidades dos processos da
empresa. As funcionalidades das aplicaes legadas no so reescritas. Mas
so remodeladas de uma forma a expor estas funcionalidades em uma camada
intermediria, e consequentemente, em uma nova arquitetura.
Finalmente, todas estas peas so agrupadas, geralmente utilizando-se de
tcnicas, metodologias e ferramentas para modelagem de processos de
negcio, como o BPEL (Business Process Execution Language), conforme
mostrado a seguir:
SOA, BPEL e tecnologias relacionadas, provm hoje, novas oportunidades de

integrao entre sistemas de informao. Mais flexveis e adaptveis s
mudanas nos processos de negcio. Desta forma, os sistemas de informaes
tornam-se mais geis, suportando melhor as mudanas nos requisitos,
alinhando-se muito bem s necessidades do negcio.
Tem-se que ter em mente que alcanar bons nveis de integrao dos
processos de negcio, normalmente, necessita de uma reengenharia nestes
processos, o que no resolvido somente em uma implementao. Para isto,
talvez, sejam necessrias vrias camadas de integrao entre as aplicaes
existentes, at que sejam alcanados altos nveis de abstrao.
Integrao em nvel de apresentao

Com frequncia, depois de alcanar uma integrao em nvel de processo de
negcio, vem o prximo passo: a integrao em nvel de apresentao. Como
agora, as aplicaes esto remodeladas e encapsuladas em uma camada
intermediria (chamada de middle tier), onde os servios so expostos em
Integrao
interfaces de alto nvel, torna-se crucial que o usurio tenha uma nica viso
da informao como um todo. Tendo o usurio que ficar trocando de aplicao
em aplicao legada, pode ocorrer que informaes sejam perdidas;
conhecimento seja perdido.
Integrao em nvel de apresentao resulta em um sistema que prov uma
camada nica de visualizao, onde os usurios podem acessar as
funcionalidades dos sistemas de forma integrada. Do ponto de vista da
usabilidade do usurio, ele no toma conhecimento de que funcionalidades de
outras aplicaes esto sendo executadas devido a sua interao. Assim, a
camada de apresentao fica desacoplada e no toma conhecimento dos
detalhes das aplicaes existentes.
Com o desenvolvimento de uma camada de apresentao unificada,
escondem-se as aplicaes legadas, mas suas funcionalidades continuam
sendo executadas. Desta forma, melhora-se a eficincia do usurio final e se
fornece uma maneira de se trocar partes dos sistemas legados no futuro, sem
influenciar outras partes do sistema.
Integrao
Integrao B2B (Business-to-Business)

Hoje, a integrao em nvel de aplicao dentro das companhias no
suficiente. Existem necessidades crescentes de integrao entre empresas,
frequentemente chamadas de integraes business-to-business (B2B) ou ebusiness. E-Business torna-se um novo desafio para os sistemas de
informao. Os requisitos hoje so muito altos e vo alm dos dias em que as
empresas apenas publicavam seus catlogos off-line em suas pginas web. O
que se espera no momento a informao online, atualizada,
eficiente, rpida, confivel e de qualidade.
bvio que como pr-requisito para um e-business ou uma integrao B2B
seja necessrio que a empresa possua um sistema de informao integrado,
possivelmente com seus processos de negcio ajustados. Somente este tipo de
nvel de integrao permite o processamento de demandas instantaneamente.
Clientes, hoje, esperam por respostas imediatas e no ficam satisfeitos com
processamentos batch, ou que a demora na confirmao de um pedido leve
dias para chegar, por exemplo.
Existem exemplos claros de integraes B2B: pesquisa por passagens areas!
H no mercado, hoje, sites especializados em encontrar a passagem area
mais barata em todas as companhias areas que fazem o trecho pesquisado.
Estes sites fornecem seus servios na forma B2B e consomem o servio das
companhias areas no mesmo modelo. Quem pode garantir que este servio
fornecido em ambas as pontas no se utilizam de sistemas legados? Para o
usurio (no caso, ns) esta percepo transparente. Abaixo, vm-se
exemplos destes servios:
ViajaNet http://www.viajanet.com.br
Integrao
Decolar.com http://www.decolar.com
Integrao
Infraestrutura para integraes

A seguir, sero apresentadas informaes bsicas sobre as infraestruturas
necessrias para integrao dos servios.
Comunicao
A principal responsabilidade dos servios de comunicao prover a abstrao
dos detalhes da comunicao. Ela fornece uma transparncia para acesso
remoto aos sistemas e unifica a visibilidade destes. Ela garante que os
desenvolvedores no tenham a preocupao de lidar com a comunicao de
baixo nvel.
Diferentes tipos de middlewares fornecem diferentes camadas de servios. As
mais comumente utilizadas so as tecnologias de acesso aos bancos de dados,
como o JDBC (Java Database Connectivity), que fornece uma camada de
abstrao para acesso a diferentes bancos de dados.
Transformao
Transformao das estruturas de dados, suas representaes e tecnologias
sempre foram muito importantes. No passado, pequenos programas que liam
uma informao da origem e a transformavam em outro formato no destino,
geralmente, resolviam os problemas relacionados s integraes (ex.
mainframe para baixa plataforma). Com o advento de linguagens de
marcao, como o XML (Extensible Markup Language), que acabou se
tornando a linguagem padro para troca de informaes, as transformaes
alcanaram um novo nvel de maturidade.
Business Intelligence (BI)

A camada de BI responsvel por apresentar uma interface de alto nvel para
acessar as informaes de negcio em outras aplicaes e usurios. A camada
de BI apresenta os dados aos usurios em um formulrio compreensvel. Com
o crescimento do e-commerce, a camada de BI tambm responsvel pela
integrao B2B.
Hoje, a camada de BI suportada por diversas camadas de apresentao,
mais comumente encontradas em forma de portais. Portais personalizados
garantem a entrega de valor de dados e contedo personalizados aos
funcionrios, parceiros de negcio e clientes.
Integrao
Transaes
A integrao da infraestrutura deve proporcionar que as operaes que
envolvam o negcio ocorram de forma transacional. Entretanto, devem ser
possveis chamadas a diversas operaes em diferentes sistemas. Deve
suportar o modelo de atomicidade ACID (atomicity, consistency, isolation,
durability).
Em outras palavras, a aderncia ao modelo transacional deve garantir que
qualquer operao executada em uma ou mais aplicaes (que causem a
mudana de estado ou permanente mudana nos dados - persistncia)
ocorram com garantia de consistncia.
Segurana
A infraestrutura de integrao deve fornecer maneiras de restringir o acesso
ao sistema. Esta deve preocupar-se tambm, com a encriptao do canal de
comunicao, autenticao, autorizao e auditoria.
Ciclo de vida
A infraestrutura de integrao deveria prover formas de controlar o ciclo de
vida de todas as aplicaes envolvidas. Deveria permitir que aplicaes
existentes pudessem ser trocadas uma a uma, ou at mesmo em partes, sem
que houvesse influncia em qualquer parte do todo.
Nomenclatura
A unificao da nomenclatura dos servios vai garantir a transparncia na
localizao da implementao e garantir a troca futura de um recurso por
outro, se necessrio. Web services so grandes exemplos de servios que
devem ser expostos com cuidado em sua nomenclatura.
Escalabilidade
A infraestrutura de integrao deve ser montada pensando-se em
escalabilidade. Deve acessar as informaes de forma a prover o acesso
concorrente s aplicaes. Deve incorporar solues que garantam acesso
suficiente demanda esperada, e onde possa ser possvel expandi-la conforme
demanda.
A infraestrutura de integrao, no entanto, no pode ser responsabilizada por
ms arquiteturas da aplicao.
Integrao
Gerenciamento
Deve-se haver formas de gerenciar a infraestrutura de integrao. A camada
de gerenciamento deve prover mtodos e ferramentas para que os servios
sejam gerenciados. Deveria prover tambm uma forma simples de
configurao e gerenciamento das verses. O gerenciamento remoto garantiria
gerncia de infraestrutura de que esta seja administrada off-site.
Integrao
Tecnologias para integraes

Normalmente, integraes de infraestrutura requerem diferentes formas e
tecnologias de implementao. At porque tem-se um mistura muito grande
de tecnologias envolvidas relacionadas ao negcio. Quando se tem esta
mistura, deve-se focar em interoperabilidade.
Interoperabilidade entre tecnologias ser crucial e ser utilizada para
implementar a integrao da infraestrutura. Alcan-la poder ser difcil
mesmo baseando-se em padres abertos. Tecnologias utilizadas nas
integraes so comumente oferecidas em forma de middlewares.
Middleware um software executado entre a camada do sistema operacional e
a camada da aplicao. Ele conecta duas ou mais aplicaes, proporcionando
assim conectividade e interoperabilidade entre elas. Middleware adiciona uma
camada de abstrao na arquitetura do sistema e assim reduz
consideravelmente a complexidade. Por outro lado, cada middleware introduz
uma certa sobrecarga na comunicao do sistema, que pode influenciar na
performance, estabilidade, escalabilidade e outros fatores relacionados
eficincia geral.
A seguir sero apresentadas algumas das tecnologias mais comuns de
middleware.
Acesso a banco de dados

As tecnologias de acesso ao banco de dados fornecem o acesso atravs de
uma camada de abstrao, a qual nos permite modificar o SGBD (Sistema
Gerenciador de Banco de Dados) sem modificar o cdigo fonte. Em outras
palavras, elas permitem usar o mesmo (ou quase o mesmo) cdigo para
acessar diferentes bancos de dados. As mais conhecidas so o JDBC e o JDO
(Java Data Objects) na plataforma Java, e o ODBC (Open Database
Connectivity) e ADO.NET (Active Data Objects) na plataforma Microsoft.
Message-Oriented Middleware (MOM)

Message-oriented middleware uma infraestrutura cliente/servidor que
permite e aumenta a interoperabilidade, flexibilidade e portabilidade das
aplicaes. Ela permite a comunicao entre aplicaes atravs de uma
plataforma distribuda e heterognea. Ela reduz a complexidade porque
esconde os detalhes da comunicao, da plataforma e os protocolos
envolvidos. Geralmente, as funcionalidades MOM so acessadas atravs de API
(Application Programming Interface).
Ela fornece uma comunicao assncrona e usa fila de mensagens para
processar as informaes. As aplicaes podem desta forma, trocar
Integrao
mensagens sem a preocupao com os detalhes da aplicao, arquiteturas e a

plataforma envolvida.
O bsico da arquitetura pode ser visto no diagrama a seguir:
Um exemplo de plataforma que fornece este tipo de interface de comunicao

o JMS (Java Messaging Service).
Remote Procedure Call (RPC)

RPC tambm se utiliza de infraestrutura cliente/servidor. Criada para garantir e
aumentar a interoperabilidade das aplicaes atravs de plataformas
heterogneas. Como o MOM, ela permite a comunicao entre software em
diferentes plataformas e esconde quase todos os detalhes da comunicao.
RPC baseado em conceitos procedurais; sua primeira implementao data a
dcada de 80.
Integrao
A diferena principal entre o MOM e o RPC a maneira como a comunicao

feita. Enquanto o MOM suporta comunicao assncrona, o RPC sncrono. O
diagrama a seguir mostra duas aplicaes comunicando-se atravs de RPC:
Object Request Brokers (ORB)

So tecnologias de middleware que gerenciam e suportam a comunicao
entre objetos ou componentes. Facilitam a comunicao entre objetos
distribudos sem a preocupao com os detalhes da arquitetura da
comunicao. Fornecem transparncia na localizao, linguagem de
programao, protocolo e sistema operacional.
So comunicaes baseadas em interfaces. A comunicao geralmente
sncrona, mas pode tambm ser feita assincronamente. A seguir pode-se
identificar um diagrama com este conceito:
Integrao
Existem trs principais padres de ORB:
OMG CORBA ORB

Java RMI e RMI-IIOP
Microsoft COM/DCOM/COM+/.NET Remoting/WCF
Servidores de aplicao
Servidores de aplicao gerenciam todas ou a grande maioria das interaes
entre a camada de cliente e a camada de persistncia. Eles fornecem uma
coleo de servios middleware, junto com o conceito de gerenciamento do
ambiente onde os componentes de regra de negcio so implantados (deploy):
o container.
Na grande maioria dos servidores de aplicao, pode-se encontrar suporte aos
web services, ORB, MOM, gerenciamento de transao, segurana,
balanceamento de carga e gerenciamento de recursos. Abaixo seguem alguns
dos servidores de aplicao de mercado:
Oracle Weblogic Server

Red Hat JBoss
IBM WebSphere Application Server
Oracle Glassfish Application Server
Integrao
Web Services
Web services so o que h de mais novo em questo de tecnologia distribuda.
Eles fornecem a fundamentao tecnolgica para que seja alcanada a
interoperabilidade entre aplicaes usando diferentes plataformas, sistemas
operacionais e linguagens de programao. Do ponto de vista de tecnologia,
web services so os prximos passos na evoluo das arquiteturas
distribudas. So similares aos seus predecessores, mas tambm diferem deles
em diversos aspectos.
Web services so as primeiras tecnologias distribudas a serem suportadas
pela grande maioria de fornecedores. E alm disto, foi a primeira tecnologia
que preencheu todos os requisitos do universo de promessas de
interoperabilidade existentes. As especificaes fundamentais so que os web
services so baseados em SOAP (Simple Object Access Protocol), WSDL (Web
Services Description Language) e UDDI (Universal Description, Discovery and
Integration). SOAP, WSDL e UDDI so baseados em XML, fazendo com que o
protocolo da mensagem do web service seja possvel de ser lido pelo ser
humano.
Da perspectiva de arquitetura, web services introduzem diversas mudanas
importantes se comparada com as arquiteturas anteriores.
Operaes em web services so baseadas na troca de mensagens XML. Elas
so colees de entradas, sadas e mensagens de erro. As combinaes de
mensagens definem o tipo de operao.
Web services fornecem suporte a comunicao sncrona e assncrona. Eles
utilizam padres dos protocolos da internet, como o HTTP (Hyper Transfer
Protocol) e MIME (Multipurpose Internet Mail Extensions). Sendo assim,
comunicaes atravs da internet e de firewalls costumam ser menos
problemticas.
Existem tambm, desvantagens no uso dos web services. Uma delas a
performance, a qual no se compara a uma arquitetura distribuda que se
utiliza de protocolos de comunicao binrios. Alm de no oferecer QoS
(Quality of Service). Web services sero o foco de estudo desta apostila.
Na seguinte URL, pode-se conferir todo o embasamento tcnico relacionado
arquitetura dos web services, segundo a W3C (o consrcio World Wide Web
uma comunidade internacional que desenvolve padres com o objetivo de
garantir o crescimento da web): http://www.w3.org/TR/ws-arch/.
Integrao
Enterprise Service Buses (ESB)

ESB so softwares de infraestrutura que agem como uma camada
intermediria de middleware que aumentam as possibilidades que
normalmente web services no conseguem proporcionar, como integrao
entre web services e outras tecnologias de middleware, dependncia de alto
nvel, robustez e segurana, gerenciamento e controle dos servios e das suas
comunicaes.
Um ESB simplifica a integrao e o reuso de servios. Ele facilita a
possibilidade de conectar servios implementados em diferentes tecnologias,
como EJB (Enterprise Java Beans), sistema de mensagens, componentes
CORBA e aplicaes legadas, de uma forma simples. Um ESB pode agir como
um mediador entre diferentes, as vezes incompatveis, protocolos e produtos
de middleware. Ele permite log, balanceamento de carga, tuning, deploy
distribudo, configurao on-the-fly etc.
Integrao
As empresas hoje em dia

Raramente em empresas que esto formadas h poucos anos encontram-se
sistemas de informao integrados. Mas, pode-se encontrar um ambiente
totalmente heterogneo, como por exemplo:
Sistemas desenvolvidos dentro da empresa

Sistemas customizados, mas desenvolvidos por terceiros
Sistemas comerciais e ERP (Enterprise Resource Planning)
Estes sistemas, geralmente, foram desenvolvidos em diferentes plataformas,

usando diferentes tecnologias e linguagens de programao. Com isto, temos
o seguinte:
Combinao de sistemas monolticos, cliente/servidor e multicamadas

Mistura de solues procedurais, orientada a objetos e baseada em
componentes
Mistura de linguagens de programao
Diferentes tipos de banco de dados
Diferentes solues de middleware
Diferentes solues de segurana
Diferentes formas de compartilhamento de dados
Integrao
Trocando os sistemas existentes

Melhorar a funcionalidade dos sistemas de informao possvel de diversas
formas. O mais bvio a troca deste sistema antigo por uma nova soluo. Se,
em princpio, esta parece ser uma soluo atrativa, existem diversos detalhes
que demonstram que fazer uma troca de sistema nem sempre uma boa
soluo para todos os casos. Desenvolver e implantar novos softwares da noite
para o dia impossvel; migrao de sistemas crticos podem significar custos
significativamente altos.
As empresas hoje em dia so muito complexas, onde at mesmo os sistemas
ERP no conseguem cobrir todas as suas necessidades. Existem pesquisas que
informam que os sistemas ERP atendem entre 30% e 40% das informaes
necessrias. Esta uma das razes principais que os maiores fornecedores de
sistemas ERP, como SAP e Oracle, adicionaram interfaces para fornecer
integrao aos seus produtos.
Esta troca dos sistemas por novas solues acabam quase sempre
necessitando de um gasto superior aquele planejado no incio do projeto; at
mesmo nos cenrios mais pessimistas. Muito depende das empresas e de o
quanto de seus processos de negcio esto mapeados e documentados.
claro que trocar os sistemas existentes nem sempre a melhor e a proposta
mais vivel. Muito dinheiro e tempo foi gasto para que elas chegassem ao nvel
de maturidade que esto atualmente; isto, sem contar o conhecimento
incorporado a estes sistemas. No decorrer desta apostila, percebe-se como a
arquitetura SOA (Service Oriented Architecture, como ser mostrado a seguir)
pode contribuir para responder a estes desafios.
Integrao
Exerccios
1. Para voc quais so os desafios das integraes hoje em dia? Cite exemplos.
2. Comente o porqu dos web services serem umas das mais importantes
tecnologias para integraes.
3. Como so as empresas hoje em dia, com relao aos seus softwares?
Integrao
Espao para anotaes
2. SOA (Service Oriented

Architecture)
Soa (Service Oriented Architeture)
Objetivos
Compreender o novo paradigma arquitetural.
Entender suas vantagens e desvantagens.
Conceitos e princpios de SOA

Algumas definies de SOA:
SOA uma forma de encarar os ativos de TI como componentes de

servio. Onde funes em um sistema so expostos como servios
stand-alone, que podem ser acessados separadamente, beneficiando
seus consumidores.
Service Oriented Architecture (SOA) uma infraestrutura de software
que proporciona uma conexo gil aos processos de negcio, atravs de
um baixo acoplamento e de web services.
SOA estratgia de arquitetura de TI voltada para solues de negcio
(e de infraestrutura) baseada no conceito de orientao a servios.
A SOA (Service Oriented Architecture), Arquitetura Orientada a Servios, possui

diversas definies, mas pode ser entendida como um paradigma arquitetural
que viabiliza a criao de servios de negcio com baixo acoplamento e
interoperveis entre si, os quais podem ser facilmente compartilhados dentro e
fora das organizaes.
Esse paradigma j reconhecido como a principal maneira de arquiteturar e
organizar as reas de TI das empresas. Portanto, as empresas que no se
adequarem a este tipo de arquitetura, ficaro completamente obsoletas e sem
poder de reao frente s novas demandas de negcio na atual economia
mundial.
Mudana de paradigma: de aplicaes

independentes ao servio
O uso de camadas de servio na mudana de paradigma das arquiteturas das
aplicaes em uma empresa fica evidente na abordagem SOA. O valor
agregado destas integraes combinado com o ganho da conexo entre vrias
aplicaes vem acelerando este processo de mudana. A necessidade de
incorporar o acesso a mltiplos servios de forma genrica nas empresas
afetada pela camada de infraestrutura, para proporcionar SOA.
Para qualquer soluo dada, podemos ter duas, trs ou N camadas de
infraestrutura. Estas camadas continuaro nas aplicaes individuais sendo
construdas, isto , qualquer nova aplicao dever ter esta preocupao. Para
estas, e para as aplicaes legadas, existiro camadas de servio bem
definidas. Prover esta infraestrutura est se tornando a maior prioridade da
maioria das empresas de TI e por seus CIOs.
Orientao a servio
Orientao a servio contm grande importncia nas funcionalidades de
interface com o negcio. A noo de importncia destas interfaces no de
toda nova. Toda aplicao bem elaborada contm mdulos de negcio bem
estruturados, e cada mdulo em cada aplicao ter mtodos/operaes bem
elaborados. Hoje, nas mais variadas plataformas (ex. JAVA EE, CORBA e .NET)
existem design patterns, como o Faade, que fornecem estas funcionalidades
e garantem um desenvolvimento coeso.
Servios baseados em componentes

Conceitualmente, servios baseados em componentes o cerne do SOA.
Orientao a objetos e componentes distribudos so conceitos bem
estabelecidos hoje em dia. Orientao a objetos uma tima abordagem para
construo de sistemas extensveis com a complexidade de vrios mdulos
abstrados e escondidos. Componentes distribudos so uma extenso
simples do mecanismo de RPC, o que no s uma invocao de mtodo, mas
um objeto acessado remotamente.
A internet simplificando os servios remotos

A internet trouxe uma mudana significante para a infraestrutura de TI em
diversas reas. Ela acelerou o crescimento do SOA, fazendo com que fosse
facilitado o acesso remoto a servios atravs de onipresena da internet e do
HTTP. XML, que uma generalizao do HTML, vagarosamente caminhou para
um formato aceito de intercmbio de dados.
O poder da internet e do XML fornecem um mecanismo simples para
descrever, invocar e executar chamadas RPC na forma de web services. Um
simples documento XML descreve o servio. A requisio composta de um
documento XML (pela especificao do SOAP), e enviada atravs do HTTP a um
endereo web.
Consequentemente, o acesso a qualquer tipo de soluo transformou-se em
algo simples e independente da tecnologia e infraestrutura que est em uso no
lado da aplicao. Uma vez que os servios estejam prontos e disponveis,
qualquer necessidade de acesso a eles, sero feitos da mesma forma, no se
importando com as tecnologias envolvidas.
Consumindo servios
Uma vez que os servios estejam disponveis atravs da plataforma SOA, o que
pode ser feito com eles? Consumir os servios atravs de uma aplicao
cliente.
Consumir significa usar o servio invocar o servio de outra aplicao
como parte da lgica normal deste programa. Digamos numa aplicao de
ERP, onde os detalhes de um cliente sejam necessrios, pode-se fazer uma
chamada ao servio que fornece essas informaes (ex. CRM), e este retornar
com os detalhes solicitados.
Vantagens e desvantagens
A arquitetura SOA possui diversas vantagens que contribuem decisivamente
para a integrao de processos de negcio, conforme a seguir:
Reutilizao de Software: algumas rotinas complexas que precisam

ser utilizadas por mais de um sistema da sua empresa, pode ser
vantagem criar um web service.
Aumento de Produtividade: com mdulos prontos, a equipe de
desenvolvimento pode ser concentrar em outras tarefas do sistema.
mais rpido se conectar a um web service do que criar toda rotina
necessria para o sistema.
Maior Agilidade: o fato de no precisar recriar nada, e qualquer
alterao no cdigo ter destino certo. Com a certeza de que no existe
cdigo duplicado no sistema, a agilidade na manuteno uma
realidade.
Interoperabilidade: consiste em trocar informaes entre sistemas
escritos em linguagens distintas. Um web service em Java pode se
comunicar com um sistema em PHP ou .NET de forma transparente.
Escalabilidade: uma forma de melhorar a performance, usar uma
estratgia que no exclusiva dos web services, as escalabilidade
horizontal e vertical (adicionar servidores e aumentar a capacidade
destes).
Mas tambm possui desvantagens, listadas a seguir:
Performance: na maioria das vezes a performance afetada em SOA,

apesar de existirem solues para melhorar a performance pressupemse que se esteja usando computao distribuda. Ento seus acessos ao
web service precisam transitar pela rede, o que pode gerar um
problema, pois a latncia das redes no so determinsticas, em
sistemas de tempo real isso pode ser crucial. O uso de web services
tambm pode exigir o uso de stubs ou skeletons para que haja uma
interoperabilidade, isso naturalmente gera algum overhead. Se for
trabalhar com XML ao invs de arquivos binrios ainda existe o tempo de
processamento do arquivo e a validao DTD ou schema do XML.
Segurana: como os dados trafegam pela rede, eles podem ser
interceptados, e arquivos textos sero facilmente interpretados. Esse
problema pode ser resolvido com alguma chave de identificao, o que
ir gerar um tempo de processamento maior tambm pelo fato de
precisar validar o cliente.
Robustez: servios que dependem da rede podem falhar, com perdas
de conexo, mensagens perdidas ou entregues fora de ordem.
Disponibilidade: o tempo em que o servidor fica disponvel, se ele for
desligado ou a energia cair, ou se for reiniciado. preciso ter uma
soluo de infraestrutura que permita a replicao e o balanceamento de
carga, por exemplo.
Testes: testar um sistema SOA pode se tornar uma tarefa rdua.

Reproduzir problemas em ambiente de testes difcil. Os arquivos de
logs podem no estar acessveis, ou o servio externo no estar
disponvel. Muitos erros acontecem por criar XML invlidos, preciso
compreender muito bem de XML para resolver problemas de estrutura
dos documentos.
Usabilidade: algumas rotinas so por natureza demoradas, por
manipularem grandes quantidades de dados e terem muitas regras de
negcio. Como web services no funcionam como threads, fica
complicado fornecer feedbacks do processo ou cancelar a solicitao.
Este tpico no visa explorar a fundo todas as possibilidades dos servios SOA
e web services, mas tem apenas um apanhado geral sobre algumas vantagens
e desvantagens da sua utilizao.
Aplicaes
Integrao de sistemas:
Em quase todas as organizaes possumos cenrios complexos, em
ambientes completamente heterogneos, com dezenas de aplicaes
desenvolvidas para desempenhar papis distintos. Um grande problema que o
SOA se prope a resolver facilitar a integrao desses componentes da
organizao. Seguindo os preceitos desse novo paradigma arquitetural,
facilmente conseguiramos integrar os sistemas sem ter quer fazer
modificaes internas, apenas disponibilizando-os como servios.
Reutilizao de sistemas legados atravs de chamadas remotas:
No desenvolvimento de novas solues, quase sempre nos deparamos com
sistemas antigos que no podem deixar de ser utilizados, nem mantidos, so
os chamados sistemas legados. Esses sistemas tambm podem possuir uma
srie de implementaes prontas para o novo sistema a ser construdo e
devem ser reaproveitadas. Com a implementao do SOA possvel
disponibilizar maneiras de acessar os sistemas legados atravs de chamadas
remotas.
Disponibilizao de informaes corporativas a usurios ou sistemas que
extrapolam as fronteiras corporativas:
B2B (business-to-business); negcios entre empresas, envolvendo produtos,
servios ou parcerias. Este termo mais usado em relao aos sites que
promovem este tipo de comrcio, oferecendo toda a praticidade e
infraestrutura necessria, cobrando em troca uma mensalidade ou comisso
sobre as transaes.
Exerccios
1. Explique com suas palavras o conceito de SOA.
2. Cite vantagens e desvantagens do paradigma SOA.
3. Voc entende SOA como algo que pode ajudar a sua empresa? De que
forma?
Espao para anotaes
3. Web Services
SOA (Service Oriented Architecture)
Objetivos
Compreender os conceitos associados aos web services.
Identificar as vantagens e desvantagens no uso dos web services.
Conhecer a arquitetura de um web service.
Integrao
A tecnologia de web services tem um papel importante na aplicao dos
conceitos de SOA. Esta tecnologia baseada em padres abertos, como:
XML
SOAP
WSDL
UDDI
O uso de padres abertos proporciona a interoperabilidade entre diferentes

fornecedores de solues. As solues existentes podem ser encapsuladas
como web services e novos servios podem ser desenvolvidos sem a
necessidade de se conhecer quem o consumidor. O utilizador pode consumir
qualquer web service no importando a plataforma a qual ele est rodando.
Isto fornece uma integrao just-in-time de aplicaes e permite ao negcio
estabelecer novas parcerias com muita agilidade. Desta forma, a tecnologia de
web services a melhora candidata para criao de SOA.
Porque usar web services?

Nos primrdios da Internet, era comum que aplicaes de negcio utilizassem
protocolos como SMTP e FTP para realizarem transaes. Isto permitia que
houvesse uma interligao entre as empresas, mas ela no era muito eficiente.
Foi somente com a padronizao de formatos e da adoo do protocolo HTTP
que a web se tornou muito mais do que um conjunto de sites para se tornar o
mais diversificado e poderoso sistema de informao do mundo.
Os web services so a ltima tecnologia para a construo de aplicaes
distribudas pela Internet. O conceito fundamental simples web services
permitem que sejam feitas chamadas remotas (Remote Procedure Calls RPC)
contra um objeto na Internet ou em uma Intranet. Esta no a primeira
tecnologia a permitir esse tipo de servio, mas ela se diferencia por usar XML
na comunicao, escondendo a implementao em ambas as pontas
(cliente/servidor), o que a torna independente de plataforma. a integrao
ideal para um ambiente to diversificado quanto a Internet, na qual se
conectam computadores pessoais e servidores que possuem um nmero
enorme de diferentes plataformas.
Com o uso de web services, possvel obter um conjunto de informaes
publicadas remotamente em um servidor atravs de uma chamada de mtodo
que independe da linguagem utilizada. Desta maneira, um servidor que
disponibiliza informaes em tempo real sobre condies climticas em
qualquer parte do mundo e que tenha sido implementado na plataforma .NET
da Microsoft pode receber uma consulta de uma pequena aplicao cliente
desenvolvida em Java. Mtodos que realizam funes complexas e objetos
inteiros contendo uma vasta quantidade de informaes passam a estar
disponveis na Internet para serem acessados por qualquer aplicao.
Todos esses recursos possibilitam uma melhor integrao entre sistemas,
inclusive os sistemas legados, aspecto esse que tem se tornado uma das
maiores preocupaes no mundo corporativo.
Web services a tecnologia ideal para comunicao entre sistemas. A
comunicao entre os servios padronizada possibilitando a independncia
de plataforma e de linguagem de programao. Por exemplo, um sistema de
reserva de passagens areas feito em Java e rodando em um servidor Linux
pode acessar, com transparncia, um servio de reserva de hotel feito em .NET
rodando em um servidor Microsoft.
Arquitetura dos web services

A arquitetura de web services mostrada em forma de diagrama a seguir:
O provedor de servios cria o servio e o publica em um registro UDDI para

que os consumidores possam descobri-los. Um consumidor pergunta ao
registro e obtm uma referncia a interface do servio. Depois da interface
obtida, o consumidor cria a interface de programa do servio. O utilizador
ento consome o servio usando protocolo padro SOAP. A chamada
direcionada atravs de um servidor web protegido por firewalls. Esta uma
forma de invocar-se um servio.
Benefcios dos web services

A abordagem de construir seus web services SOA oferecem diversos benefcios
como listados a seguir:
Self-Contained
Web services so self-contained (independentes) no sentido deles no
requisitarem que qualquer componente seja instalado no lado do cliente. No
servidor, precisa-se meramente de um componente capaz de fornecer
Servlets, um container EJB ou o runtime .NET. Quando um servio instalado e
fica pronto para o uso, o cliente pode consumi-lo sem a necessidade da
instalao de softwares em sua mquina.
Self-Describing
Web services so self-describing (auto-descritivos). Uma interface para um
servio publicada atravs de um documento WSDL. Um documento WSDL
define o formato da troca de mensagem e os tipos de dados usados. Para
consumir o servio, o cliente necessita conhecer apenas sobre o
formato e contedo da chamada e da resposta da mensagem.
Modular
Web services fornecem diversas abstraes nos componentes de tecnologias
existentes baseados em J2EE, CORBA, DCOM, entre outros. Usando essa
diversidade de tecnologias, os componentes so criados. O web service
compe estes componentes para oferecer o servio ao cliente. A interface aos
componentes no exposta aos clientes. Isto resulta em um desenvolvimento
modular de software, resultando na criao de uma viso mais abstrata do
servio de negcio.
Acessvel atravs da web

Web services so publicados, localizados e invocados atravs da web usando
protocolos padres. A descrio do servio publicada usando WSDL; o servio
localizado com um help no registro UDDI e invocado via SOAP. Todos estes
protocolos so baseados na web.
Linguagem, plataforma e protocolo neutros

Como os web services so baseados em padres abertos de XML, so neutros;
o cliente escrito em qualquer linguagem pode acessar um web service escrito
em outra linguagem. Isto , um web service criado em Java pode ser
consumido por um cliente em PHP.
Aberto e baseado em padres

A tecnologia de web services baseada em padres abertos, fazendo com que
sejam interoperveis entre si. Estes padres sero descritos durante o
desenvolvimento do contedo desta apostila.
Dinmico
Web services podem ser descobertos e consumidos em tempo de execuo,
sem a necessidade de um tempo de compilao. Na maioria das tecnologias, o
cliente precisa apenas conhecer o componente de interface.
Web Services em Java: Serializao

Este tpico demonstra alguns aspectos importantes e que compe a
arquitetura e a construo do conhecimento relacionado criao dos web
services em Java.
Serializao o processo de transformar uma instncia de uma classe Java em
um elemento XML. O processo inverso, transformar um elemento XML em
instncia Java chamado de desserializao.
A serializao o componente mais importante de qualquer plataforma para

Java. No exemplo visto na figura anterior, ilustra-se o problema da serializao
resolvido. Ela traduz os parmetros das instncias das suas respectivas classes
em instncias do schema XML, chamado de mapeamento de tipos (type
mappings) ilustrado no diagrama a seguir.
Para garantir esta traduo, o motor (engine) da serializao necessita de um

conjunto de estratgias de mapeamento que dizem como cada tipo de
mapeamento deve ser implementado; em outras palavras, como serializar as
instncias das classes Java em instncias dos componentes do schema XML.
Diferentes plataformas de web services fornecem diferentes mecanismos e
estratgias de mapeamento que constroem o contexto de serializao. Em
muitos casos, diversos mtodos so utilizados. Alguns destes mecanismos so:
Vinculao Padro: Os mapeamentos so predefinidos por um vnculo
padro de classes Java no schema XML. Cada classe Java tem uma nica
representao no schema XML. Este mecanismo descrito pelas seguintes
especificaes: JAXB e JAX-WS.
Anotao do Cdigo-Fonte: JWS usa esta abordagem para fornecer a
customizao da vinculao padro. Anotar o cdigo-fonte de uma classe Java
modifica o mapeamento no schema XML, e tambm, como a descrio do
WSDL moldado. Esta a forma mais simples e utilizada atualmente.
Algoritmo: Os mapeamentos so embutidos em algoritmos executados por
um sistema de serializao. JAX-RPC e Axis utilizam este mtodo.
Baseado em Regras: Os mapeamentos so especificados como regras que

podem ser criadas e editadas independente do sistema de serializao. As
regras so interpretadas pelo sistema de serializao. SOA-J usa este mtodo
de mapeamento.
Cada uma destas abordagens tm vantagens e desvantagens. O JWS
introduziu as anotaes no cdigo-fonte como um mecanismo de facilitar aos
programadores a especificar como o Java dever ser representado na
descrio do WSDL.
A serializao, como processo fundamental dos web services, gera uma grande
carga na sua execuo, o que pode ser apontada como uma desvantagem ao
uso dos web services. Nos trfegos de grandes quantidades de informao via
web services facilmente identificado o elevado tempo de resposta das
informaes.
Exerccios
1. Como voc v os web services auxiliando nos processos de integrao na
empresa em que trabalha?
2. Cite 03 benefcios no uso dos web services.
3. Voc v alguma desvantagem no uso dos web services? Qual?
4. Por que os web services podem ser teis na integrao de software legado?
Explique.
Espao para anotaes
4. Criando Web Services
Web Services
Objetivos
Compreender as necessidades bsicas para criao dos web services.
Identificar o formato de publicao de web services.
Conhecer o desenvolvimento dos web services em diferentes APIs.
Web Services
Necessidades bsicas
A seguir so consideradas as ferramentas e APIs necessrias para o
desenvolvimento de web services e para execuo dos exerccios propostos
pela apostila. Lembrete: nem todos os arquivos JAR (que compe as APIs) so
utilizados pelo projeto que estar em estudo.
IDE (Integrated Development Environment)

Hoje existem diversas IDEs utilizadas no desenvolvimento do Java. Muitas
delas facilitam muito a criao de web services, tanto na criao e publicao
do servio quanto na criao de clientes de acesso.
Trabalharemos nesta apostila com duas das IDEs mais conhecidas no mercado
de
Java:
o
Eclipse
(http://www.eclipse.org/)
e
o
Netbeans
(http://www.netbeans.org/). Com certeza, todo o desenvolvedor Java j teve
um mnimo de experincia na sua utilizao. E ambas so freeware, isto , tem
seu uso e distribuio gratuito.
soapUI
soapUI (http://www.soapui.org/) uma ferramenta de cdigo aberto escrita em
Java cuja principal funo consumir e testar web services. considerada a
ferramenta lder neste segmento, com mais de 2 milhes de downloads, a
mais utilizada para testes SOA no mundo.
Este software requer um detalhamento maior, visto que para que os exerccios
desta apostila sejam bem testados e compreendidos, faz-se necessrio
entender o funcionamento da ferramenta soapUI. Ela ser a responsvel por
fazer as chamadas de REQUEST e RESPONSE a um web service. Permitindo
assim, que sejam feitas requisies sem o uso de uma API cliente de web
service.
A seguir, tm-se as telas bsicas de configurao para criao de chamadas a
um servio deste software:
Web Services
Tela inicial do software
Adicionando um servio - WSDL
Resultado esperado; servio e suas operaes
Web Services
Fazendo chamada a uma operao (SOAP)
Analisando resposta chamada realizada (SOAP)
Web Services
Apache Tomcat
O Apache Tomcat (http://tomcat.apache.org/) uma implementao de
software de cdigo aberto para as tecnologias de Java Servlet e JavaServer
Pages. Est em produo hoje em larga escala, em aplicaes web de misso
crtica em uma grande diversidade de indstrias e organizaes.
Apache OpenEJB
Apache OpenEJB (http://openejb.apache.org/) uma implementao freeware,
embarcada e leve do EJB 3.0, que pode ser utilizada com um servidor
standalone ou integrada a um Tomcat, JUnit, TestNG, Eclipse, IntelliJ, Maven,
Ant e qualquer IDE ou aplicao. OpenEJB est includo no Apache Geronimo,
IBM WebSphere Application Server CE, e no Apple's WebObjects.
Web Services
JAX-WS
Descrio
O Java API for XML Web Services (https://jax-ws.dev.java.net/) uma API Java
para criao de web services. Faz parte da plataforma do Java EE da Sun
Microsystems. Como as outras APIs do Java EE, JAX-WS usa anotaes,
introduzidas no Java SE 5, para simplificar o desenvolvimento e o deploy dos
clientes de web service e endpoints.
Necessidades
API do JAX-WS contendo os seguintes arquivos JAR:
activation.jar
jaxws-rt.jar
FastInfoset.jar
jaxws-tools.jar
gmbal-api-only.jar
jsr173_api.jar
http.jar
jsr181-api.jar
jaxb-api.jar
jsr250-api.jar
jaxb-impl.jar
management-api.jar
jaxb-xjc.jar
mimepull.jar
jaxws-api.jar
policy.jar
resolver.jar
saaj-api.jar
saaj-impl.jar
stax-ex.jar
streambuffer.jar
woodstox.jar
Arquitetura
Segue a estrutura dos arquivos bsicos necessrios e a sua descrio:
Web Services
Mensagem.java e OlaMundo.java
Classes Java que contm as regras de negcio do web service.
web.xml
Configurao do mapeamento do servlet WSServlet para a URL do servio.
sun-jaxws.xml
Mapeamento dos endpoints, suas URLs e classe Java de implementao.
build.xml
XML Apache Ant responsvel pelo deploy da aplicao.
Construo de um web service

Utilizaremos para a API JAX-WS, um web service chamado OlaMundo e outro
Mensagem. O primeiro servir apenas para concatenar a string Ol, ao
nome do aluno. E o segundo, adicionar a uma fila, mensagens enviadas pelos
alunos. Estas mensagens de teste, podero ser conferidas atravs da pgina
index.jsp disponvel no projeto. Para este exemplo, ser utilizada a IDE Eclipse
e o instrutor fornecer o projeto a ser importado ws-jaxws-tomcat.
OlaMundo.java
@WebService
public class OlaMundo {
@WebMethod
public String ola(String nome) {
return "Ol, " + nome;
}
Web Services
Mensagem.java
@WebService
public class Mensagem {
private static ArrayList<Properties> lista;
public Mensagem() {
lista = new ArrayList<Properties>();
}
@WebMethod
public void adicionaMensagem(@WebParam(name = "remetente") String
remetente, @WebParam(name = "mensagem") String mensagem) {
Properties prop = new Properties();
prop.setProperty("DATA", new SimpleDateFormat("dd/MM/yyyy
HH:mm:ss").format(new Date()));
prop.setProperty("REMETENTE", remetente);
prop.setProperty("MENSAGEM", mensagem);
lista.add(prop);
}
@WebMethod(exclude = true)
public static ArrayList<Properties> getListaMensagens() {
return lista;
}
Web Services
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5"
xmlns:xsi="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<listener>
<listenerclass>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listenerclass>
</listener>
<servlet>
<servlet-name>MinhaMensagem</servlet-name>
<servletclass>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MinhaMensagem</servlet-name>
<url-pattern>/mensagem</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>MeuOlaMundo</servlet-name>
<servletclass>com.sun.xml.ws.transport.http.servlet.WSServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MeuOlaMundo</servlet-name>
<url-pattern>/hello</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
</web-app>
sun-jaxws.xml
<endpoints xmlns='http://java.sun.com/xml/ns/jax-ws/ri/runtime' version='2.0'>
<endpoint
name='Hello'
implementation='com.tt.webservice.OlaMundo'
url-pattern='/hello'
/>
<endpoint
name='Mensagem'
implementation='com.tt.webservice.Mensagem'
url-pattern='/mensagem'
/>
</endpoints>
Web Services
index.jsp
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@page import="com.tt.webservice.Mensagem"%>
<%@page import="java.util.Properties"%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Pgina de Mensagens</title>
<meta http-equiv="refresh" content="5" />
</head>
<body>
<%
for(Properties prop : Mensagem.getListaMensagens()) {
out.println(prop.get("DATA") + " - " + prop.get("REMETENTE") + " - " +
prop.get("MENSAGEM"));
out.println("<br />");
}
%>
</body>
</html>
Para verificarmos se os servios esto disponveis para serem consumidos,
podemos
acessar
o
contexto
criado
ws-jaxws-tomcat
(ex.
http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl) e identificar se a
pgina carrega sem erro. Se abrir corretamente, todos os servios foram
publicados e esto prontos para serem consumidos.
Para testarmos o funcionamento dos web services e o resultado das
mensagens, utilizaremos os seguintes endereos de WSDL (esta sigla ser
discutida em um tpico prprio no decorrer desta apostila):
Web Services
Para que possamos testar as chamadas ao web service, utilizaremos a

ferramenta soapUI, comentada em tpico anterior. O resultado esperado, ao
se utilizar a operao adicionaMensagem (encontrada no servio
Mensagem) demonstrado na figura abaixo:
Descrio bsica das Annotations mencionadas

@WebService: Marca uma classe Java como implementao de Web Service.
Utilizada na anotao em nvel de classe.
@WebMethod: Customiza um mtodo como sendo exposto como uma
operao no Web Service. O mtodo associado deve ser pblico e seus
parmetros retornando algum valor, e suas excees devem seguir as regras
definidas na JAX-RPC 1.1, seo 5. Utilizada na anotao em nvel de mtodo.
Parmetros importantes desta anotao:
operationName: Define o nome da operao que ser utilizada pelo

executor
exclude: Marca um mtodo como no exposto como uma operao no
web service.
@WebParam: Customiza o mapeamento de um parmetro individual a uma

mensagem Web Service e a um elemento XML. Utilizada na anotao em nvel
de parmetro de mtodo.
Parmetros importantes desta anotao:
name: Define o nome do parmetro que ser utilizado pelo executor
Para uma descrio detalhada destas annotations, acesse:

http://download.oracle.com/javase/6/docs/api/javax/jws/package-summary.html
Publicando um web service sem Application Server

A partir da verso 6 do Java, ficou disponvel a possibilidade de publicarmos
um web service, sem a necessidade de um web container (ex. Apache Tomcat)
ou de um application server. Isto, dependendo da necessidade e da
Web Services
funcionalidade necessria, pode fazer com que um web service possa ser
publicado com classes localizadas em uma pen drive, por exemplo.
Maximizando assim as possibilidades relacionadas ao uso de web services.
Para este exemplo, ser utilizada a IDE Eclipse e o instrutor fornecer o projeto
a ser importado ws-jaxws-noserv.
OlaMundo.java
@WebService
@WebMethod
}
Servico.java
public class Servico {
public static void main(String[] args) {
Endpoint.publish("http://localhost:8080/hello", new OlaMundo());
}
}
Isto
,
a
classe
Servico
publicar
um
endpoint
na
URL
http://localhost:8080/hello com as operaes expostas na classe de servio
OlaMundo. A operao ola, ter a simples funcionalidade de concatenar a
string Ol, ao parmetro fornecido; como os outros exemplos vistos. Com
apenas duas classes e uma linha de cdigo, publica-se um web
service e o torna disponvel para aceitar chamadas.
Web Services
JAX-WS (via EJB)

Descrio
O Java API for XML Web Services (https://jax-ws.dev.java.net/) uma API Java
para criao de web services, conforme j descrito no tpico anterior. Veremos
como utiliz-la atravs da publicao de um EJB com os web services
fornecidos por ele. Esta uma forma muito interessante de uso de web
services, pois, podem ser aproveitadas todas as funcionalidades da estrutura
do EJB, e us-las a favor da publicao dos web services necessrios.
Necessidades
API JAX-WS (via EJB) contendo os seguintes arquivos JAR:
activeio-core-3.0.0-incubator.jar
log4j-1.2.12.jar
mysql-connector-javaactivemq-core-4.1.1.jar
3.1.11.jar
activemq-ra-4.1.1.jar
neethi-2.0.4.jar
backport-util-concurrent-2.1.jar
openejb-api-3.1.2.jar
bcprov-jdk15-140.jar
openejb-client-3.1.2.jar
commons-cli-1.1.jar
openejb-loader-3.1.2.jar
commons-collections-3.2.jar
xbean-finder-shaded-3.6.jar
commons-dbcp-all-1.3xbean-asm-shaded-3.6.jar
r699049.jar
commons-lang-2.1.jar
openejb-core-3.1.2.jar
opensaml-1.1.jar
quartz-1.5.2.jar
saaj-impl-1.3.jar
serializer-2.7.1.jar
serp-1.13.1.jar
slf4j-api-1.3.1.jar
slf4j-jdk14-1.3.1.jar
stax-api-1.0.1.jar
swizzle-stream1.0.1.jar
wsdl4j-1.6.1.jar
wss4j-1.5.4.jar
wstx-asl-3.2.0.jar
xbean-naming-3.6.jar
xbean-reflect-3.6.jar
commons-logging-1.1.jar
openejb-cxf-3.1.2.jar
commons-pool-1.3.jar
openejb-ejbd-3.1.2.jar
cxf-bundle-2.0.9.jar
openejb-hsql-3.1.2.jar
ejb31-api-experimental-3.1.2.jar
openejb-http-3.1.2.jar
geronimo-connector-2.1.jar
openejb-javaagent-3.1.2.jar
geronimo-javamail_1.4_mailopenejb-jee-3.1.2.jar
xml-resolver-1.2.jar
1.2.jar
geronimo-transaction-2.1.jar
openejb-multicast-3.1.2.jar
XmlSchema-1.4.2.jar
howl-1.0.1-1.jar
openejb-server-3.1.2.jar
xmlsec-1.4.0.jar
hsqldb-1.8.0.7.jar
openejb-telnet-3.1.2.jar
jaxb-impl-2.0.5.jar
javaee-api-5.0-2.jar
openejb-webservices-3.1.2.jar
openjpa-1.2.1.jar
Web Services
Arquitetura
Calculadora.java e OlaMundo.java
CalculadoraIF.java e OlaMundoIF.java
Interfaces Java que contm o contrato a ser exposto s chamadas via EJB
(interface remota e local) e as quais as classes acima devero implementar.
TesteEJB.java
Classe de teste para efetuar uma chamada via EJB aos mtodos das classes.
openejb-jar.xml
Configurao das classes que devem ser expostas via EJB.
persistence.xml
Configurao dos datasources de conexo com banco de dados.
build.xml
Web Services

Utilizaremos para a API JAX-WS (via EJB), um web service chamado OlaMundo
e outro Calculadora. O primeiro servir apenas para concatenar a string Ol,
ao nome do aluno. E o segundo, funcionar como uma calculadora com suas
funes bsicas: adio, subtrao, multiplicao, diviso e raiz quadrada.
Para este exemplo, ser utilizada a IDE Eclipse e o instrutor fornecer o projeto
a ser importado ws-ejb.
Calculadora.java
@Stateless
@WebService
public class Calculadora implements CalculadoraIF {
private static final Logger logger = Logger.getLogger(Calculadora.class);
@WebMethod
public Double adicao(@WebParam(name = "x") Double x, @WebParam(name =
"y") Double y) {
logger.info("Mtodo Adio");
return x + y;
}
@WebMethod
public Double subtracao(@WebParam(name = "x") Double x, @WebParam(name =
"y") Double y) {
logger.info("Mtodo Subtrao");
return x - y;
}
@WebMethod
public Double multiplicacao(@WebParam(name = "x") Double x,
@WebParam(name = "y") Double y) {
logger.info("Mtodo Multiplicao");
return x * y;
}
@WebMethod
public Double divisao(@WebParam(name = "x") Double x, @WebParam(name =
"y") Double y) {
logger.info("Mtodo Diviso");
return x / y;
}
@WebMethod
public Double raizQuadrada(@WebParam(name = "x") Double x) {
logger.info("Mtodo Raiz Quadrada");
return Math.sqrt(x);
}
}
Web Services
OlaMundo.java
@Stateless
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
@WebService
public class OlaMundo implements OlaMundoIF {
@WebMethod
public String ola(@WebParam(name = "nome") String nome) {
}
}
CalculadoraIF.java
public interface CalculadoraIF {
Double adicao(@WebParam(name = "x") Double x, @WebParam(name = "y")
Double y);
Double subtracao(@WebParam(name = "x") Double x, @WebParam(name = "y")
Double y);
Double multiplicacao(@WebParam(name = "x") Double x, @WebParam(name =
"y") Double y);
Double divisao(@WebParam(name = "x") Double x, @WebParam(name = "y")
Double y);
Double raizQuadrada(@WebParam(name = "x") Double x);
}
OlaMundoIF.java
@Local
@Remote
public interface OlaMundoIF {
String ola(@WebParam(name = "nome") String nome);
}
TesteEJB.java
public class TesteEJB {
Hashtable<String, String> ht = new Hashtable<String, String>();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"org.openejb.client.LocalInitialContextFactory");
ht.put(Context.PROVIDER_URL, "t3://localhost:4201");
OlaMundoIF olaMundo = (OlaMundoIF)
ServiceLocator.getEJB3("OlaMundo", ht);
System.out.println(olaMundo.ola("Joao da Silva"));
}
Web Services
persistence.xml
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<!-<persistence-unit name="EXEMPLO_OPENEJB">
<jta-data-source>TESTE</jta-data-source>
<class>com.exemplo.openejb.Usuario</class>
</persistence-unit>
-->
</persistence>
openejb-jar.xml
<openejb-jar>
<ejb-deployment ejb-name="OlaMundo">
<jndi name="OlaMundo" />
</ejb-deployment>
</openejb-jar>
Para que seja manipulado o deploy e undeploy do EJB no OpenEJB, assim como
o start e stop do servio, necessrio conhecer seus comandos bsicos,
conforme a seguir:
openejb-3.1.2\bin\openejb.bat start Inicializa o OpenEJB, publicando
todos os EJBs.
openejb-3.1.2\bin\openejb.bat stop Pra o OpenEJB.
openejb-3.1.2\bin\openejb.bat deploy [pacote_ejb.jar] Faz o deploy dos
EJBs no OpenEJB, tornando-os ativos.
openejb-3.1.2\bin\openejb.bat
undeploy
[c:\caminho\completo\pacote_ejb.jar] Faz o undeploy dos EJBs no
OpenEJB, tornando-os inativos.
Para testarmos o funcionamento dos web services utilizaremos a ferramenta
soapUI apontando para os seguintes WSDL: http://localhost:4204/OlaMundo?
wsdl e http://localhost:4204/Calculadora?wsdl.
E para testarmos a chamada via EJB, executaremos o mtodo esttico main,
da classe TesteEJB.
Web Services
Apache Axis
Descrio
Apache Axis (http://ws.apache.org/axis/) uma implementao do protocolo
SOAP. Ele isola o desenvolvedor dos detalhes de lidar com o SOAP e o WSDL.
um framework de cdigo aberto, baseado na linguagem Java e no padro XML,
utilizado para construo de web services no padro SOAP.
Necessidades
O deploy das classes do web service podem ser feitas diretamente no contexto
padro do Apache Axis. Isto , no pacote do Apache Axis API, vem um contexto
pronto, com a funcionalidade de expor as classes anotadas com @WebService.
A imagem a seguir demonstra o contedo do contexto do Apache Axis (axis).
Arquitetura
Web Services
OlaMundo.java
build.xml

Utilizaremos para o Apache Axis API, um web service chamado OlaMundo,
que servir apenas para concatenar a string Ol, ao nome do aluno,
conforme o exemplo anterior. Para este exemplo, ser utilizada a IDE Eclipse e
o instrutor fornecer o projeto a ser importado ws-axis.
Uma caracterstica interessante no uso do contexto padro do Apache Axis, a
facilidade na publicao de web services. No exemplo da classe OlaMundo,
bastaria renomearmos o cdigo-fonte .java para .jws, e copi-lo para o
contexto do Axis. Isto faria com que o Axis compilasse a classe em tempo de
execuo, e disponibilizasse o web service automaticamente.
@WebService
@WebMethod
}
}
Para verificarmos se o servio est disponvel para ser consumido, podemos
acessar
o
contexto
do
Apache
Axis
criado
axis
(ex.
http://localhost:8080/axis/) - e identificar se a pgina carrega sem erro. Se abrir
corretamente (conforme imagem a seguir), o contexto do axis est no ar.
Web Services
Aps isto, podemos acessar a URL http://localhost:8080/axis/OlaMundo.jws,

onde ser apresentada a seguinte tela (informando que foi identificado um
web service naquele endereo, em ingls):
O teste da execuo da operao ola no web service OlaMundo pode ser feito
via
ferramenta
soapUI,
apontando
para
o
seguinte
WSDL:
http://localhost:8080/axis/OlaMundo.jws?wsdl.
Web Services
Codehaus XFire
Descrio
Codehaus XFire (http://xfire.codehaus.org/) um framework SOAP para
linguagem Java. Codehaus XFire simplifica o desenvolvimento orientado a
servios atravs da facilidade do uso da sua API.
Necessidades
API do Codehaus XFire contendo os seguintes arquivos JAR:
activeio-core-3.0.0-incubator.jar
activemq-core-4.1.1.jar
activemq-ra-4.1.1.jar
backport-util-concurrent-2.1.jar
bcprov-jdk15-140.jar
commons-cli-1.1.jar
commons-collections-3.2.jar
geronimo-transaction-2.1.jar
howl-1.0.1-1.jar
hsqldb-1.8.0.7.jar
javaee-api-5.0-2.jar
jaxb-impl-2.0.5.jar
log4j-1.2.12.jar
mysql-connector-java3.1.11.jar
commons-dbcp-all-1.3r699049.jar
neethi-2.0.4.jar
commons-lang-2.1.jar
openejb-api-3.1.2.jar
commons-logging-1.1.jar
commons-pool-1.3.jar
cxf-bundle-2.0.9.jar
ejb31-api-experimental-3.1.2.jar
geronimo-connector-2.1.jar
geronimo-javamail_1.4_mail1.2.jar
slf4j-api-1.3.1.jar
slf4j-jdk14-1.3.1.jar
stax-api-1.0.1.jar
xml-resolver-1.2.jar
openejb-client-3.1.2.jar
openejb-loader-3.1.2.jar
xbean-finder-shaded-3.6.jar
xbean-asm-shaded-3.6.jar
openejb-core-3.1.2.jar
openejb-ejbd-3.1.2.j
openejb-hsql-3.1.2.j
openejb-http-3.1.2.j
openejb-javaagent-3.1.
openejb-jee-3.1.2.ja
openejb-multicast-3.1.
openejb-server-3.1.2.
openejb-telnet-3.1.2.
openejb-webservice
3.1.2.jar
openjpa-1.2.1.jar
opensaml-1.1.jar
quartz-1.5.2.jar
saaj-impl-1.3.jar
serializer-2.7.1.jar
openejb-cxf-3.1.2.jar
serp-1.13.1.jar
swizzle-stream-1.0.1.jar
wsdl4j-1.6.1.jar
wss4j-1.5.4.jar
XmlSchema-1.4.2.jar
wstx-asl-3.2.0.jar
xbean-naming-3.6.ja
xbean-reflect-3.6.ja
xmlsec-1.4.0.jar
Arquitetura
Web Services
OlaMundo.java
OlaMundoIF.java
Interfaces Java que contm o contrato a ser exposto s chamadas via web
service e as quais as classes acima devero implementar.
services.xml
Arquivo de configurao contendo o mapeamento das classes e interfaces
responsveis pela publicao dos web services.
web.xml
Configurao do mapeamento do servlet XFireConfigurableServlet para a URL
do servio.
build.xml
index.jsp
Pgina de teste para conferncia da publicao do contexto utilizando o XFire.
Na maioria dos problemas de publicao dos servios via XFire, o contexto web
no fica disponvel em caso de erro. Da, uma simples pgina de teste.
Web Services

Utilizaremos para a API Codehaus XFire, um web service chamado OlaMundo.
Este servir apenas para concatenar a string Ol, ao nome do aluno. Para
este exemplo, ser utilizada a IDE Eclipse e o instrutor fornecer o projeto a
ser importado ws-xfire.
OlaMundo.java
public class OlaMundo implements OlaMundoIF {
}
}
OlaMundoIF.java
public interface OlaMundoIF {
String ola(String nome);
}
services.xml
<beans xmlns="http://xfire.codehaus.org/config/1.0">
<service>
<name>OlaMundo</name>
<namespace>OlaMundo</namespace>
<serviceClass>com.tt.webservice.OlaMundoIF</serviceClass>
<implementationClass>com.tt.webservice.OlaMundo</implementationClass>
</service>
</beans>
web.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<servlet>
<servlet-name>XFireServlet</servlet-name>
<servletclass>org.codehaus.xfire.transport.http.XFireConfigurableServlet</servletclass>
</servlet>
<servlet-mapping>
<url-pattern>/servlet/XFireServlet/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<url-pattern>/services/*</url-pattern>
</servlet-mapping>
Web Services
</web-app>
index.jsp
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Insert title here</title>
</head>
<body>
Pgina ok!
</body>
</html>
Para verificarmos quais servios esto disponveis para serem consumidos,

podemos acessar o contexto do Codehaus XFire criado ws-xfire (ex.
http://localhost:8080/ws-xfire/services) conforme imagem a seguir. Nele
sero listados os servios e o link para o WSDL que levar a criao da
chamada s operaes (ex. http://localhost:8080/ws-xfire/services/OlaMundo?
wsdl).
Atravs do WSDL informado anteriormente, a operao ola pode ser

executada atravs da ferramenta soapUI, o que resultar na concatenao da
string Ol, ao parmetro fornecido.
Web Services
Exerccios
1. Escolha uma implementao utilizada por este tpico e crie um web service
com as seguintes operaes:
a) informa data (dd/mm/yyyy, do tipo String) e retorna o dia da semana
referente data
b) informa username e password (do tipo String), e retorna true se
ambos forem iguais a admin e lana uma exceo RuntimeException
caso o logon falhe
c) informa salrio (do tipo Double), e calcula e retorna o valor
correspondente do INSS, conforme tabela a seguir:
Salrio
at R$ 1.040,22
de R$ 1.040,23 a R$ 1.733,70
de R$ 1.733,71 at R$ 3.467,40
Acima de R$ 3.467,40
Desconto
8%
9%
11%
o desconto de R$ 381,41.
2. Teste todas as operaes que voc criou utilizando a ferramenta soapUI.
Web Services
Espao para anotaes
Web Services
5. Criando clientes de Web

Service
Criando Web Services
Objetivos
Compreender que so os clientes de web service.
Conhecer as possibilidades de uso do WSDL.
Identificar as formas de criao automticas de clientes de web service.
O que so clientes de web services?

Web services leva os clientes web a um nvel elevado de maturidade.
Desenvolvedores podem construir melhores clientes, muito mais poderosos, os
quais interagem com web services proporcionando uma experincia
riqussima. Neste ambiente, os desenvolvedores do cliente no precisam ter
controle sobre o lado do servidor de uma aplicao, e mesmo assim eles ainda
podem escrever poderosos aplicativos.
Os clientes podem aproveitar os web services para obter uma ampla variedade
de funes ou servios. Para um cliente, um web service uma caixa preta: o
cliente no precisa conhecer como o servio implementado ou mesmo quem
o presta. O cliente em primeiro lugar se preocupa com a funcionalidade do
servio fornecido pelos web services. Vrios clientes rodando em diferentes
tipos de plataformas podem acessar esses web services normalmente.
Uma das razes principais para implementao de web services alcanar a
interoperabilidade. Os clientes podem acessar web services, independente da
plataforma ou do sistema operacional em que o servio foi construdo. A
implementao completamente independente do servio.
Em resumo, um cliente para web services nada mais do que um
componente que sabe conversar atravs de protocolo SOAP por um
canal HTTP.
Isto , as chamadas de request e response do protocolo HTTP carregam o SOAP
fazendo todo o mecanismo do web service funcionar. Logo, nada mais que
qualquer comunicao que consiga fazer um POST via HTTP para um endereo
de servio de web service e que consiga ler seu resultado.
WSDL - Web Service Definition Language

De que forma um cliente de um web service sabe qual formato dos mtodos a
serem chamados, quais parmetros a serem passados? Como os clientes
sabem como processar uma requisio?
Para solucionar estes tipos de perguntas que foi criado um documento, que
utiliza uma linguagem chamada WSDL. Web Service Description Language
uma linguagem baseada em XML, utilizada para descrever um web service.
Um web service deve, portanto, definir todas as suas interfaces, operaes,
esquemas de codificao, entre outros neste documento.
Um documento WSDL define um XML Schema para descrever um web service.
To logo o cliente tenha acesso descrio do servio a ser utilizado, a
implementao do web service pode ser feita em qualquer linguagem de
programao. Normalmente so utilizadas linguagens construdas para
interao com a web, como por exemplo os Java Servlets, Java Server Pages,
ASP.NET ou mesmo o PHP.
Basicamente, quando o cliente deseja enviar uma mensagem para um

determinado web service, ele obtm a descrio do servio (atravs da
localizao do respectivo documento WSDL; sua URL), e em seguida constri a
mensagem, passando os tipos de dados corretos (parmetros, etc) de acordo
com a definio encontrada no documento. Em seguida, a mensagem
enviada para o endereo onde o servio est localizado novamente sua URL,
a fim de que possa ser processada. O web service, quando recebe esta
mensagem faz a sua validao conforme as informaes contidas no
documento WSDL. A partir de ento, o servio remoto sabe como tratar a
mensagem, sabe como process-la (request) e como montar a resposta ao
cliente (response).
Partindo-se ento desta introduo sobre o WSDL, podemos prever que
possvel, a partir da sua descrio, reconhecer como fazer uma chamada s
operaes do servio, logo, possvel automatizar a criao de clientes para
web services.
Um software que seja capaz de interpretar a descrio do WSDL e transformlo em cdigo-fonte capaz de gerar clientes automaticamente. E isto que
iremos ver no decorrer desta apostila.
As APIs que implementam os web services, tratando agora dos servios, so
as responsveis por transformar a semntica aplicada s classes expostas e/ou
mapeadas em uma descrio WSDL.
A maioria das APIs que expe web services fornecem tambm uma forma de
visualizarmos o XML do WSDL. Geralmente, seu acesso se d atravs da URL
do servio acrescida de ?wsdl, conforme exemplo abaixo:
http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl
Observao: o navegador Chrome, do Google, no exibe XML. Logo, no

mostraria o contedo do WSDL.
Eclipse IDE como cliente de web service

Como vimos, a ferramenta soapUI facilita os testes relacionados s execues
de operaes nos web services. Fazendo com que se tenha a certeza do
funcionamento do servio. O Eclipse IDE tambm tem uma funcionalidade
similar, que pouco conhecida dos desenvolvedores.
Nas figuras a seguir, ser demonstrada a sua utilizao para o exemplo de
chamada ao web service que foi implementado pelo projeto ws-jaxwstomcat.
Passo 1: Mude a perspectiva do Eclipse IDE para Java EE
Passo 2: Acesse o cone Launch the Web Service Explorer (ltimo a direita)
Passo 3: Acesse o cone WSDL Page (penltimo a direita)
Passo 4: Acesse o link WSDL Main, entre com a URL de apontamento para o
WSDL a ser testado e clique em Go
Passo 5: Escolha a operao a ser testada (no caso, adicionaMensagem)
Passo 6: Atravs dos links Add, adicionar os contedos aos parmetros

solicitados (no caso, remetente e mensagem) e clicar em Go
Ento, ser executada a operao desejada, e os resultados (XML SOAP de

resposta) sero mostrados na aba Status, logo abaixo a tela de execuo.
Geradores de cliente automticos

Fixando conceitos
Como o WSDL serve como um descritor dos web services, suas operaes,
seus parmetros e os tipos de dados que devero ser utilizados, fica mais fcil
a gerao de classes pelos geradores automticos de clientes. Estes
interpretam o descritor e geram as classes de forma semntica, contendo por
exemplo, mtodos com o mesmo nome das operaes encontradas nas
operaes do web service.
Resumindo: os clientes criam uma representao em forma de classes das
chamadas aos web services, abstraindo todo o trfego do XML e as chamadas
de HTTP.
Todos os exemplos de criao utilizados a seguir na apostila, faro uso do web
service exposto atravs do projeto ws-jaxws-tomcat.
JAX-WS
J embutido na JDK do Java 6, o gerador automtico de cliente fica em um
arquivo chamado wsimport.exe localizado na pasta bin de instalao da JDK.
Este arquivo no tem interface grfica para sua execuo, isto , costuma ser
utilizado atravs do Prompt do MS-DOS, mas existem ferramentas que o
utilizam para criao de clientes, o executando em background exemplo do
soapUI, conforme figura a seguir.
Uma vantagem no uso deste mtodo que ele nativo da verso 6 do Java,
no precisando de outras dependncias JAR.
Para criarmos o cliente, partimos do princpio que a pasta bin mencionada
anteriormente est no PATH do sistema operacional. Devem-se ser executados
os seguintes passos:
Passo 1: Acessar o Prompt do MS-DOS
Passo 2: Acessar pasta de cdigos-fonte do projeto que receber as classes

criadas;
geralmente
[nome
do
projeto]/src
(ex.
d:\meusprojetos\TesteCliente\src)
Passo 3: Executar o comando de criao das classes cliente
wsimport -keep -p com.tt.meucliente http://localhost:8080/ws-jaxwstomcat/mensagem?wsdl
Onde,
-keep: mantm os arquivos-fonte gerados (se no utilizada este parmetro, o
cliente criado apenas com os cdigos-fonte j compilados; bytecodes)
-p com.tt.meucliente: package onde as classes sero criadas
http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl:
descritor WSDL
URL
do
Passo 4: Conferir os arquivos criados, conforme refresh no projeto do Eclipse,

a seguir na imagem:
JAX-WS: Consumindo o Servio

No quadro abaixo, apresentado um cdigo-fonte que faz uso destas classes
para executar a operao adicionaMensagem.
public class TesteWebservice {
Mensagem ws = new MensagemService().getMensagemPort();
ws.adicionaMensagem("Joo da Silva", "Envio de mensagem via
Netbeans IDE");
}
}

Apache Axis 1.x
A gerao automtica de um cliente utilizando o Apache Axis 1.x feita

atravs da sua API. Para exemplificar, podemos seguir os seguintes passos:
Passo 1: Acessar ao Prompt do MS-DOS
Passo 2: Acessar a pasta lib da API do Apache Axis 1.x (possivelmente axis1_4\lib)
java -classpath .;axis.jar;commons-logging-1.0.4.jar;jaxrpc.jar;log4j1.2.8.jar;saaj.jar;wsdl4j-1.5.1.jar;commons-discovery-0.2.jar;axisant.jar org.apache.axis.wsdl.WSDL2Java -p com.tt.meucliente
http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl
Onde,
-classpath: Aponta para os arquivos JAR necessrios para criao do cliente
org.apache.axis.wsdl.WSDL2Java: Classe do Apache Axis 1.x responsvel
pela criao do cliente
http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl:
descritor WSDL
URL
do
Passo 4: Copiar a pasta com os arquivos criados para o src do projeto no

Eclipse, o que ir gerar a package com as classes do cliente
Apache Axis 1.x: Consumindo o Servio

para executar a operao adicionaMensagem. Notamos que este diferente
do criado via wsimport.
public static void main(String[] args) throws Exception {
Mensagem ws = new MensagemServiceLocator().getMensagemPort();
Netbeans IDE");
}
}
Apache Axis 2.x

A gerao automtica de um cliente utilizando o Apache Axis 2.x feita
atravs da sua API, mas utilizando-se de de um arquivo bat. Para exemplificar,
podemos seguir os seguintes passos:
Passo 1: Acessar ao Prompt do MS-DOS
Passo 2: Acessar a pasta bin da API do Apache Axis 2.x (possivelmente axis21.5.1\bin)
wsdl2java.bat -u -p com.tt.meucliente uri http://localhost:8080/wsjaxws-tomcat/mensagem?wsdl
Onde,
-u: Desacopla da classe de stub as classes necessrias para a representao
das operaes e parmetros do web service; se no informado, todas as
classes tornam-se inner classes da stub.
uri http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl:
descritor WSDL
URL do
Passo 4: Copiar a pasta com os arquivos criados para o src do projeto no

Eclipse, o que ir gerar a package com as classes do cliente
Apache Axis 2.x: Consumindo o Servio

para executar a operao adicionaMensagem. Notamos que este diferente
do criado via wsimport e muito diferente daquele criado na verso 1.x do
prprio Axis.
public static void main(String[] args) throws Exception {
AdicionaMensagemE mensagem = new AdicionaMensagemE();
AdicionaMensagem param = new AdicionaMensagem();
param.setRemetente("Joo da Silva");
param.setMensagem("Envio de mensagem via Netbeans IDE");
mensagem.setAdicionaMensagem(param);
}
}
new MensagemServiceStub().adicionaMensagem(mensagem);
Netbeans IDE
O Netbeans IDE possui a funcionalidade de criao de cliente de web service
nativamente. Atravs das figuras a seguir, ser demonstrada a criao de um
cliente.
Passo 1: Adicione ao seu projeto um novo arquivo do tipo Web Service Client
Passo 2: Adicione o apontamento para a URL do WSDL e escolha o pacote

onde as classes cliente sero armazenadas
Estando o servio no ar, o Netbeans ir criar uma estrutura similar a

apresentada a seguir:
Onde podemos identificar as classes para acesso aos servios e operaes do

web service.
Netbeans IDE: Consumindo o Servio

para executar a operao adicionaMensagem.
Mensagem ws = new MensagemService().getMensagemPort();
Netbeans IDE");
}
}
Podemos identificar que o cdigo-fonte do cliente utilizado para consumir o

servio pelo Netbeans o mesmo do criado pelo comando wsimport. Ambos
utilizam-se da mesma engine de criao.
Exerccios
1. Crie um cliente para o web service solicitado no exerccio do tpico anterior.
Seria interessante tambm, que voc criasse uma interface web (JSP) para
envio e recebimento dos dados do servio. Assim, ficar clara a comunicao e
o mecanismo necessrio entre o cliente e a interface com o servio.
Espao para anotaes
6. Comunicao via SOAP
Criando clientes de Web Service
Objetivos
Conhecer o conceito do protocolo SOAP.
Identificar a estrutura do protocolo.
Compreender quando esta abordagem deve ser utilizada.
O que SOAP?
SOAP um protocolo simples baseado em XML para permitir que aplicaes
troquem informaes atravs do protocolo HTTP. Ou mais simplesmente: SOAP
um protocolo para acessar um web service.
Algumas consideraes importantes:
SOAP
SOAP
SOAP
SOAP
SOAP
SOAP
SOAP
SOAP
SOAP
SOAP
SOAP
significa Simple Object Access Protocol

um protocolo de comunicao
para comunicao entre aplicaes
um formato para envio de mensagens
comunica-se via Internet
independente de plataforma
independente de linguagem
baseado em XML
simples e extensvel
permite contornar firewalls
uma recomendao da W3C
Por que SOAP?

importante para o desenvolvimento de aplicaes permitir a comunicao
via Internet entre os programas.
Os aplicativos de hoje comunicam-se usando chamadas de procedimento
remoto (RPC) entre os objetos como DCOM e CORBA, mas HTTP no foi
projetado para isso. RPC representa um problema de compatibilidade e
segurana; firewalls e servidores proxy normalmente bloqueiam este tipo de
trfego.
A melhor maneira de se comunicar entre as aplicaes atravs de HTTP,
como o HTTP suportado por todos os navegadores de internet e servidores.
SOAP foi criado com este propsito.
SOAP prov uma forma de comunicao entre aplicaes rodando em
diferentes sistemas operacionais, com diferentes tecnologias e linguagens de
programao.
Bloco de estrutura SOAP

Uma mensagem SOAP um documento habitual em XML contendo os
seguintes elementos:
Um elemento envelope que identifica o documento XML como um SOAP

Um elemento de cabealho opcional que contm informaes de
chamadas e repostas
Um elemento de falha opcional que prove informao sobre erros que
ocorrem quando do processamento da mensagem
Estrutura de uma mensagem SOAP:

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soapencoding">
<soap:Header>
...
...
...
</soap:Header>
<soap:Body>
...
...
<soap:Fault>
...
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
Onde,
SOAP envelope
O SOAP <Envelope> o elemento raiz em cada mensagem SOAP, e contm
dois elementos filhos, um <Header> opcional e um <Body> obrigatrio.
SOAP header
O SOAP <Header> um sub-elemento opcional do envelope SOAP, e usado
para repassar informaes relacionadas aplicao que devem ser
processadas pelos ns do SOAP ao longo do caminho da mensagem.
SOAP body
O SOAP <Body> um sub-elemento obrigatrio do envelope SOAP, que
contm informaes necessrias para o destinatrio final da mensagem.
O elemento <Body> e seus elementos filhos associados so usados para troca

de informaes entre o remetente SOAP inicial e o receptor SOAP final. SOAP
define um elemento filho para o <Body>: o elemento <Fault> utilizado para
reportar erros. Outros elementos no <Body> so definidos pelo web service
que us-los.
SOAP fault
O SOAP <Fault> um sub-elemento do corpo SOAP, utilizado para reportar
erros.
Se ocorrer um erro em um web service, uma mensagem de erro retornada
para o cliente. A estrutura bsica da mensagem de falha definida nas
especificaes SOAP. Cada mensagem de erro pode incluir um XML que
descreve a condio de erro especfica. Por exemplo, se um erro anormal
ocorrer na aplicao de um web service, uma mensagem de erro retornado
para o cliente relatando o problema.
Exemplo de mensagem SOAP

No exemplo abaixo, um pedido GetStockPrice enviado para um servidor. O
pedido tem um parmetro StockName e um parmetro de Price, que sero
devolvidos na resposta. O namespace para a funo definido em
http://www.example.org/stock.
O SOAP Request
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<soap:Envelope
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
O SOAP Response
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<soap:Envelope
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>
SAAJ - SOAP with Attachments API for Java

O pacote JAX-WS fornece uma API para trabalharmos com mensagens SOAP,
independentemente de o fluxo de mensagens ser atravs ou no de um web
service. O SAAJ nos permite trocar mensagens XML na plataforma Java.
Simplificando as chamadas de mtodos poderemos ler e escrever mensagens
SOAP baseadas em XML, e poderemos mand-las ou receb-las atravs da
Internet.
Apresentaremos agora uma viso de alto-nvel sobre como o SAAJ trabalha e
explicaremos alguns conceitos gerais.
Mensagens
As mensagens transitadas pelo SAAJ seguem os padres do SOA, que
descrevem o formato das mensagens e especificam tudo o que obrigatrio,
opcional e no permitido.
Estrutura do XML
Um documento XML tem uma estrutura hierrquica feita por elementos e subelementos de vrios nveis. Um elemento tambm referenciado como n. O
SAAJ tem a interface Node, que a base para todas as classes e interfaces que
representam os elementos em uma mensagem SOAP.
Mensagem sem anexos

A figura a seguir mostra uma viso superficial da estrutura de uma mensagem
SOAP sem anexos. Com exceo do SOAP header, todas as partes listadas so
obrigatrias nas mensagens SOAP.
Todos os elementos da figura (SOAPMessage, SOAPPart, SOAPHeader,

SAOPBody) tm suas respectivas classes ou interfaces no SAAJ. Quando
criamos um objeto do tipo SOAPMessage, ele ter automaticamente todas as
partes obrigatrias e opcionais de uma mensagem SOAP representadas como
atributos.
O elemento SOAPHeader pode ter um ou mais headers, contendo dados sobre
a mensagem, como por exemplo, informaes sobre envio e recebimento de
partes da mensagem. O objeto SOAPBody, que obrigatrio sempre, contm o
contedo da mensagem. Se existir um objeto SOAPFault, que representa um
possvel erro, ele deve estar inserido dentro de um objeto SOAPBody.
Mensagem com anexos

Uma mensagem SOAP pode conter um ou mais anexos no SOAPPart, que por
sua vez deve conter apenas um contedo XML, portanto, se qualquer contedo
da mensagem no est em formato de XML, deve ser um anexo. A figura a
seguir mostra o contedo de uma mensagem SOAP com anexos.
O SAAJ contm a classe AttachmentPart para representar o anexo na

mensagem SOAP. A classe SOAPMessage possui automaticamente o objeto
SOAPPart e seus sub-elementos requeridos, mas como os objetos
AttachmentPart so opcionais, deveremos cri-los e adicion-los manualmente.
Se uma mensagem SOAP tiver um ou mais anexos, os objetos AttachmentPart,
que representa cada anexo, dever conter um cabealho MIME que indica que
tipo de dato o anexo contm. Ele deve ter tambm cabealhos MIME adicionais
para identific-lo ou contendo uma referncia de sua localizao. Esses
cabealhos so opcionais, mas podem ser teis quando trabalhamos com
muitos anexos. Quando temos anexos em um objeto SOAPMessage, seu objeto
SOAPPart pode ou no ter contedo.
Conexes
Todas as mensagens so enviadas ou recebidas atravs de uma conexo. Com
o SAAJ, a conexo representada pelo objeto SOAPConnection, que vai do
remetente at o destinatrio. Esse tipo de conexo chamada point-to-point
(ponto-a-ponto), o popular P2P, utilizado em centenas de programas e muito
difundido atualmente na internet. Mensagens enviadas utilizando o SAAJ so
chamadas request-response. Elas so enviadas atravs da chamada ao
mtodo call de um objeto SOAPConnection, que envia uma mensagem
(request) e fica bloqueado at receber a resposta (response).
O trecho de cdigo abaixo cria um objeto SOAPConnection e, depois de criar e

popular a mensagem, o usa para envi-la. Depois da chamada do mtodo call
que envia a requisio o retorno do mtodo a mensagem SOAP de resposta.
SOAPConnection connection = null;
try {
SOAPConnectionFactory soapConnectionFactory =
SOAPConnectionFactory.newInstance();
connection = soapConnectionFactory.createConnection();
} catch (UnsupportedOperationException e1) {
throw new RuntimeException("Operao no suportada", e1);
} catch (SOAPException e1) {
throw new RuntimeException("Erro geral", e1);
}
// cria uma mensagem de request
SOAPMessage response = connection.call(message, service);
Note que o Segundo argumento a ser passado para o mtodo call pode ser
uma String ou um objeto URL, que identifica para onde a mensagem ser
enviada.
Exemplo completo de chamada

Para exemplificar as chamadas utilizando o SOAP, precisaremos que o projeto
ws-ejb esteja disponvel, isto , seu deploy tenha sido realizado. Para
identificarmos se o servio Calculadora est no ar, publicado atravs do
OpenEJB, podemos acessar a seguinte URL http://localhost:4204/Calculadora?
wsdl.
No cdigo-fonte a seguir, faremos uma chamada ao servio descrito no
pargrafo anterior, na sua operao raizQuadrada. A chamada ocorrer
diretamente na console do Eclipse IDE, e ser possvel identificarmos o XML de
request e de response, assim como, o resultado do clculo.
public class TesteComunicacao {
private
private
private
private
String
String
String
String
address = "http://localhost:4204/Calculadora";
targetNamespace = "http://webservice.tt.com/";
requestMethodName = "raizQuadrada";
testParameter = "4.0";
public void sendMessage() throws Exception {

// Criando a mensagem
SOAPMessage message = getRequestMessage();
// Criando a factory de conexo
// Obtendo a conexo da factory
SOAPConnection connection =
soapConnectionFactory.createConnection();
// Enviando a mensagem
SOAPMessage response = connection.call(message, address);
System.out.println("\n\nEnviado (request): " + testParameter + ",
Recebido (response): " + processaResponse(response));
connection.close();
}
"m");
private SOAPMessage getRequestMessage() throws Exception {

// Criando a factory
MessageFactory factory = MessageFactory.newInstance();
// Criando a mensagem a partir da factory
SOAPMessage message = factory.createMessage();
// Pegando o SOAPPart
SOAPPart part = message.getSOAPPart();
// Pegando o SOAPEnvelope
SOAPEnvelope envelope = part.getEnvelope();
// Pegando o SOAPHeader
SOAPHeader soapHeader = envelope.getHeader();
// Pegando o SOAPBody
SOAPBody body = envelope.getBody();
// Eliminando o header
soapHeader.detachNode();
// Criando o contedo
QName bodyName = new QName(targetNamespace, requestMethodName,
SOAPBodyElement bodyElement = body.addBodyElement(bodyName);
SOAPElement symbol = bodyElement.addChildElement("x"); // parmetro

symbol.addTextNode(testParameter);
System.out.println("######### REQUEST ##########");
message.writeTo(System.out);
return message;
@SuppressWarnings("unchecked")
private String processaResponse(SOAPMessage response) throws Exception {
StringBuffer result = new StringBuffer();
System.out.println("\n######## RESPONSE ##########");
response.writeTo(System.out);
SOAPBody body = response.getSOAPBody();
Iterator<SOAPElement> elementIterator = body.getChildElements();
while (elementIterator.hasNext()) {
SOAPElement element = elementIterator.next();
// Contedo
result.append(element.getTextContent());
}
return result.toString();
}
public static void main(String args[]) throws Exception {
new TesteComunicacao().sendMessage();
}
}
A seguir, a sada esperada na console do Eclipse IDE:

######### REQUEST ##########
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<m:raizQuadrada xmlns:m="http://webservice.tt.com/">
<x>4.0</x>
</m:raizQuadrada>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
######## RESPONSE ##########
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns1:raizQuadradaResponse xmlns:ns1="http://webservice.tt.com/">
<return>2.0</return>
</ns1:raizQuadradaResponse>
</soap:Body>
</soap:Envelope>
Enviado (request): 4.0, Recebido (response): 2.0
Dica de construo da chamada SOAP

As chamadas a um servio diretamente atravs da construo do cdigo-fonte,
isto , sem o uso de um cliente de web service, pode parecer a primeira vista
um desafio. Mas com estudo podem-se identificar os casos em que melhor
utilizarmos esta forma de acesso ao servio.
Muitas vezes, clientes automticos de gerao de clientes para web services,

no so satisfatrios no cdigo gerado. E as vezes, no conseguem interpretar
o WSDL para gerar as classes corretamente. a que entra a facilidade de
construirmos uma chamada direto atravs do cdigo-fonte, utilizando o SOAP.
Uma dica importante para identificar como a chamada e a leitura da resposta
ao web service deve ser construda utilizarmos a ferramenta soapUI como
auxiliar neste processo. Como vimos at aqui, esta ferramenta interpreta como
deve ocorrer a chamada de request para a operao no web service
configurado, e a partir desta identificao, ela permite que faamos testes com
preenchimento de parmetros necessrios operao. Dito isto, podemos
descobrir como o soapUI monta o XML SOAP de request e nos prepararmos
para leitura do XML SOAP de response.
Vamos a um exemplo, utilizando o servio Calculadora e a operao
raizQuadrada, como visto no tpico anterior:
Podemos identificar perfeitamente que ser executada a operao chamada

raizQuadrada, e que o parmetro x est preenchido com o inteiro 9. Podemos
identificar tambm, um pouco deslocado no XML o namespace
xmlns:web="http://webservice.tt.com/".
Ao executarmos a operao, o resultado esperado, isto , o XML SOAP
response mostrado na figura a seguir:
Identificamos no XML o retorno do valor 3.0, que nada mais que a

raizQuadrada do parmetro x=9, informado na chamada request.
Logo, se precisssemos criar um cliente para chamada a este servio, onde
fosse necessrio ler o retorno, poderamos fazer o seguinte:
MessageFactory factory = MessageFactory.newInstance();

SOAPMessage message = factory.createMessage();
SOAPPart soapPart = message.getSOAPPart();
SOAPEnvelope envelope = soapPart.getEnvelope();
envelope.addNamespaceDeclaration("web", "http://webservice.tt.com/");
SOAPBody body = envelope.getBody();
SOAPBodyElement attrib1 =
body.addBodyElement(envelope.createName("raizQuadrada", "web", ""));
SOAPElement attrib2 = attrib1.addChildElement("x");
attrib2.addTextNode("9");
message.saveChanges();
System.out.println("REQUEST:");
message.writeTo(System.out);
System.out.println();
SOAPConnection connection = soapConnectionFactory.createConnection();
SOAPMessage response = connection.call(message,
"http://localhost:4204/Calculadora");
System.out.println("RESPONSE:");
ByteArrayOutputStream saida = new ByteArrayOutputStream();
response.writeTo(System.out);
response.writeTo(saida);
System.out.println();
connection.close();
String XML = saida.toString();
try {
ByteArrayInputStream b = new ByteArrayInputStream(XML.getBytes("UTF-8"));

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new BufferedInputStream(b));
String tagName = "return";

NodeList n1 = doc.getElementsByTagName(tagName);
if (n1.getLength() == 0) {
throw new RuntimeException("Nenhum resultado encontrado para
TagName=" + tagName);
}
Node node = n1.item(0);
String resultado = node.getTextContent();
System.out.println("RESULTADO DO CLCULO: " + resultado);
} catch (Exception e) {
throw new RuntimeException(e);
}
Exerccios
1. Qual a linguagem de marcao utilizada pelo protocolo SOAP? Qual a
vantagem desta utilizao?
2. Quais os elementos da estrutura de uma mensagem SOAP?
3. Qual o benefcio no uso do protocolo SOAP para questes relacionadas s
redes (ex. firewall)?
4. Com suas palavras, explique o que o SOAP Request e o SOAP Response.
Co-relacione com os conceitos do protocolo HTTP.
5. Crie uma chamada operao de clculo de INSS sem o uso de criao
automtica de m cliente para o web service. Utilize para isto chamadas SOAP.
Espao para anotaes
7. Segurana com Web

Services
Comunicao via SOAP
Objetivos
Conhecer aspectos de segurana relacionados com web services.
Compreender as alternativas e especificaes atuais.
Comunicao via SOAP
Introduo
No momento, a arquitetura orientada a servios encontra-se no radar de
muitos gerentes de TI, e um nmero maior de empresas passam a dedicar
cada vez mais recursos ao SOA. Se a SOA a arquitetura, os web services so
os blocos de construo. Desta forma, web services esto em destaque no
mundo da computao distribuda como uma tecnologia que resolve os
problemas de interoperabilidade dos sistemas. Porm, por possuir uma
infraestrutura pblica oferece, tambm, uma maior preocupao relacionada
segurana.
Este tpico pretende demonstrar o funcionamento de web services seguros
utilizando a tecnologia Java abordando conceitos da arquitetura orientada a
servios. Para tornar um web service seguro voc deve criptografar a
comunicao, e existem duas maneiras de se fazer isso: garantir a segurana
ao nvel de transporte e em nvel de XML.
Comunicao via SOAP
Segurana em web service

Os mecanismos de segurana dos web services ainda esto sendo discutidos.
O SOAP, por exemplo, no define um mecanismo para autenticao de uma
mensagem antes do seu processamento. Como soluo implementada a
segurana nos canais de transmisso usados para trocar as mensagens SOAP,
utilizando o HTTP com o SSL (Secure Socket Layer) ou as VPNs (Virtual Private
Networks). Tambm esto sendo desenvolvidos alguns mecanismos para
manter a segurana na camada de mensagens como a assinatura digital em
XML, a criptografia em XML e a SAML (Security Assertion Markup Language)
que uma linguagem comum para compartilhamento de servios de
segurana.
Um fator importante que deve ser considerado para a utilizao dos web
services que eles normalmente so transportados sobre o HTTP na porta 80 e
com isso passam facilmente pelo firewall situado entre a rede interna de uma
empresa e a Internet. O firewall monitora todo o trfego de fora para dentro, e
bloqueia aquilo que no esteja autorizado, mas a porta 80 usualmente
deixada com pouca proteo. Enquanto a CORBA e a Java RMI so utilizadas
em outras portas e tm o seu acesso dificultado, os web services tm a
vantagem de passar livremente pelo firewall, mas isto tambm pode se
configurar em uma desvantagem se o web service no implementar nenhuma
funcionalidade de segurana.
Os web services simplificaram as comunicaes, mas tambm alteraram
algumas medidas de segurana existentes. Ento, o desafio agora definir um
modelo de segurana que demonstre como os dados podem ser transportados
atravs da aplicao e da rede de acordo com os requisitos especificados pelo
negcio sem expor os dados a um risco inadequado.
Segurana em nvel de transporte

Segurana em nvel de transporte significa proteger o protocolo de rede que o
web service utiliza para se comunicar. O Secure Sockets Layer (SSL) um
protocolo padro para criptografar comunicaes sobre TCP/IP. Neste modelo,
um cliente abre um socket seguro para um web service e ento o utiliza para
trocar mensagens SOAP via HTTPS. A implementao de SSL garante
segurana criptografando todo o trfego de rede sobre o socket.
Comunicao via SOAP
Segurana em nvel de XML

Por sua vez, segurana em nvel de XML envolve a criptografia e
descriptografia de documentos XML. O World Wide Web Consortium (W3C), o
qual mantm o padro XML, tem criado grupos de trabalhos para definir
padres para segurana em XML, incluindo assinaturas digitais, criptografia e
gerenciamento de chaves para XML. O padro mais utilizado para
implementao de segurana em web services o WS-Security.
Comunicao via SOAP
Questes a serem consideradas

Segurana fcil de se implementar utilizando a tecnologia Java EE, e oferece
um bom nvel de controle de acesso as funcionalidades da aplicao e seus
dados. Entretanto, o que inerente segurana aplicada na camada de
aplicao, propriedades de segurana no so transferveis a outras aplicaes
rodando em outros ambientes e somente protegem os dados enquanto eles
residem no ambiente da aplicao. No contexto de uma aplicao tradicional,
isso no necessariamente um problema, mas quando aplicado ao contexto
de web services, os mecanismos de segurana do Java EE provm apenas uma
soluo parcial.
As caractersticas de um web service fazem sua segurana precisar de algo
diferente do que a aplicada a outras aplicaes so as seguintes:
Perda de acoplamento entre o provedor e o consumidor do servio

Uso de mensagens XML e metadata
Foco em prover interoperabilidade
Independncia de linguagem e plataforma
Variedade de protocolos de transporte que podem ser usados
Possibilidade de passagem por vrios hosts entre o provedor e o cliente
Algumas caractersticas dos web services os tornam especialmente vulnerveis

a ataques de segurana. So algumas delas:
Operaes so feitas atravs da internet utilizando protocolos amigveis

a firewalls
A comunicao iniciada pelos clientes que no tem nenhuma relao
com o provedor
A mensagem no formato texto
Alm disso, a natureza dos web services distribudos, suas interaes e

dependncias podero exigir uma maneira padro de propagar identidade e
confiana entre a aplicao e seus domnios.
Existem vrios aspectos bem definidos de segurana de aplicao, que quando
bem utilizados, ajudam a minimizar os riscos. Entre eles esto autenticao,
autorizao, integridade e confidencialidade, entre outros.
Comunicao via SOAP
Vantagens da segurana na camada de

mensagem
Antes de entrarmos na questo da segurana de mensagem, importante
entender porque a segurana na camada de transporte no sempre
suficiente para prover a segurana necessria a um web service. A segurana
na camada de transporte provida por mecanismos de transporte utilizados
para transmitir a informao entre clientes e provedores de servio, assim a
segurana nessa camada baseia-se no transporte seguro via HTTP (HTTPS)
utilizando Secure Sockets Layer (SSL). Segurana no transporte um
mecanismo de segurana ponto a ponto que pode ser utilizado para
autenticao, integridade da mensagem e confidencialidade. Quando rodando
em uma sesso protegida por SSL, provedor e cliente podem autenticar um ao
outro e negociar um algortimo e chaves para criptografia da mensagem antes
de sua transmisso.
A segurana vai desde o momento em que a mensagem deixa o cliente at
sua chegada no servidor, ou vice-versa, at mesmo entre intermedirios. O
problema que no h mais proteo uma vez chegada no destino. Uma
soluo criptografar a mensagem antes de envi-la.
Na segurana da camada de mensagem, a informao de segurana
trafegada dentro da mensagem SOAP ou em um anexo da mensagem.
As vantagens da segurana na camada de mensagem so:
A segurana permanece na mensagem de uma ponta a outra mesmo

passando por vrios intermedirios
Pode ser aplicada em diferentes partes da mensagem, inclusive seus
anexos
Pode ser utilizada em conjunto com diferentes intermedirios atravs de
vrios hosts
independente do ambiente da aplicao e do protocolo de transporte
A desvantagem em se utilizar esse tipo de segurana a relativa

complexidade de implementao e o tempo de processamento que se perde
ao aplic-la.
Comunicao via SOAP
Especificaes e iniciativas atuais

As organizaes listadas a seguir trabalham em especificaes de segurana
para web services, orientaes e ferramentas:
World Wide Web Consortium (W3C)

Organization for Advancement of Structured Information Standards
(OASIS)
Web Services Interoperability Organization (WS-I)
Java Community Process (JCP)
Basicamente, JCP, W3C e OASIS desenvolvem especificaes relacionadas

segurana em web services. WS-I cria padres que indicam o que implementar
de vrias especificaes e prove uma direo sobre como implementar as
especificaes.
Especificaes W3C
O papel da W3C, de acordo com seu site em http://www.w3.org/ liderar a web
ao seu total potencial desenvolvendo protocolos e diretrizes que tero
resultado a longo prazo. W3C desempenha seu papel, atravs da criao de
padres web e orientaes.
O W3C trabalha sobre as seguintes especificaes relacionadas aos web
services e segurana:
XML Encryption (XML-Enc): Essa especificao prove os requisitos

para a sintaxe e o processamento de XML para criptografia digital,
incluindo partes de documentos XML e mensagens de protocolos.
XML Digital Signature (XML-Sig): Especifica uma sintaxe de
compilao para XML representando uma assinatura de recursos web,
partes de mensagens de protocolos e procedimentos para computao e
verificao dessas assinaturas.
XML Key Management Specification (XKMS): Especifica protocolos
para distribuio e registro de chaves pblicas, adequado para o uso em
conjunto com as recomendaes da W3C para XML-Signature e XMLEncryption.
Comunicao via SOAP
Especificaes OASIS
De acordo com seu site em http://www.oasis-open.org/, o OASIS impulsiona o
desenvolvimento e a convergncia, bem como a adoo de normas para ebusiness.
O OASIS trabalha sobre as seguintes especificaes relacionadas segurana
em web services:
Web Services Security (WSS): Segurana em mensagens SOAP. Essa

especificao descreve acessrios para promover integridade,
confidencialidade e autenticao nas mensagens, acolhendo uma grande
variedade de tecnologias e modelos de segurana e criptografia. Esta
especificao tambm define um mecanismo para associar tokens de
segurana com contedos de mensagens, assim como codificar tokens
binrios de segurana, bem como incluir chaves criptografadas ocultas
na mensagem.
Security Assertion Markup Language (SAML): Essa especificao
define um mecanismo baseado em XML para segurana em transaes
de e-commerce business-to-business (B2B) e business-to-consumer
(B2C). SAML define um framework para troca de informao de
autenticao e autorizao baseado em XML. SAML utiliza um protocolo
de XML codificado para requisio e resposta e especifica regras para o
uso de padres de transporte de mensagens. SAML prov
interoperabilidade entre sistemas de segurana distintos e pode ser
aplicado para facilitar trs casos de uso: login simples, transaes
distribudas e servios de autorizao.
eXtensible Access Control Markup Language (XACML): Essa
especificao define uma linguagem comum para expressar poltica de
segurana e uma estrutura extensvel de schema e namespace para
expressar polticas de autorizao em XML. Uma linguagem comum para
especificao de poltica segurana permite que a empresa gerencie os
esforos de todos os seus elementos em todos os seus sistemas de
informaes.
Especificaes JCP
O JCP responsvel pelo desenvolvimento na tecnologia Java. Primeiramente o
JCP guia o desenvolvimento e a aprovao de especificaes tcnicas da
tecnologia Java. Est trabalhando atualmente nas seguintes especificaes:
JSR 104 - XML Trust Service APIs: Define uma srie de padres de
APIs e um protocolo para um servio confivel. Um dos objetivos-chave
do design do protocolo minimizar a complexidade de aplicaes
utilizando XML Signature. Se tornando um cliente de um servio
confivel, a aplicao livrada da complexidade para estabelecer
relaes de confiana, o que pode ser baseado em uma diferente
especificao, assim como X509, PKIX, SPKI ou PGP.
Comunicao via SOAP
JSR 105 - XML Digital Signature APIs: Define uma srie de padres
de APIs para servios de criptografia de XML. A criptografia pode ser
utilizada para criptografar documentos XML, bem como fragmentos
binrios contidos em um documento XML.
JSR 155 - Web Services Security Assertions: Prov um conjunto de
APIs e padres de implementao para segurana (integridade e
confidencialidade) em comunicaes entre web services baseado na
especificao SAML da OASIS.
JSR 183 - Web Services Message Security APIs: Define um conjunto
padro de APIs para segurana de mensagens em web services. O
objetivo desta JSR tornar aplicaes aptas a fazer trocas seguras de
mensagens SOAP.
JSR 196 - Java Authentication Service Provider Interface for
Containers: A especificao prope uma interface padro provedora de
servios com mecanismos de autenticao e integrao com containers.
Provedores integrados atravs dessa interface sero utilizados para
estabelecer as identidades de autenticao usadas no controle de acesso
dos containers, incluindo aquelas utilizadas pelo container em
invocaes de componentes em outros containers.
Especificaes WS-I
WS-I uma organizao aberta, feita com o propsito de promover a
interoperabilidade de web services atravs de diferentes plataformas, sistemas
operacionais e linguagens de programao. Especificamente, o WS-I cria,
promove e d suporte a protocolos genricos para a troca de mensagens entre
web services. O WS-I cria profiles, que recomendam o que e como usar vrias
especificaes criadas por W3C, OASIS e JCP. WS-I trabalha nos seguintes
profiles relacionados segurana em web services:
Basic Security Profile (BSP): Fornece informaes sobre o uso de WSSecurity e os formatos de token UserName e X.509.
REL Token Profile: o profile de interoperabilidade para o token de
segurana Rights Expression Language (REL) que utilizado com WSSecurity.
SAML Token Profile: o profile de interoperabilidade para o token de
segurana Security Assertion Markup Language (SAML) que utilizado
com WS-Security.
Security Challenges, Threats, and Countermeasures: Indica
desafios potenciais em segurana em web services e identifica as
tecnologias candidatas a vencer esses desafios.
Comunicao via SOAP
WS-Security
Em abril de 2002, a Microsoft Corporation, a IBM Corporation e a VeriSign Inc.
se uniram e publicaram um conjunto de novas especificaes de segurana
denominadas WS-Security, com o objetivo de que as empresas pudessem criar
e construir aplicaes de web services com ampla interoperabilidade.
As especificaes do WS-Security, propostas pela IBM e Microsoft, so
fundamentais para a concretizao de um planejamento amplo de recursos
que possam atender crescente necessidade de oferecer suporte mais seguro
para construo de web services. O documento "A Segurana no mundo dos
Web services", de autoria da Microsoft e da IBM, explica as novas
especificaes de segurana para web services que essas empresas
pretendem desenvolver em conjunto com alguns de seus principais clientes,
parceiros de mercado e entidades responsveis pela padronizao.
O WS-Security suporta, integra e unifica vrios modelos, mecanismos e
tecnologias de segurana em uso no mercado, permitindo que vrios sistemas
possam interoperar em plataformas e linguagens neutras.
As novas especificaes de segurana definem um conjunto de padres para
extenses SOAP ou para cabealhos de mensagens, utilizados para oferecer
maior integridade e confidencialidade s aplicaes de web services. O WSSecurity oferece os mecanismos padro de segurana necessrios para
realizar o intercmbio seguro de mensagens certificadas em um ambiente de
web services.
O documento citado acima define alguns recursos adicionais de segurana de
web services que se enquadram no modelo estabelecido pelas especificaes
WS-Security, entre eles:
WS-Policy, WS-Trust e WS-Privacy: O WS-Policy define como os

recursos e restries das normas de segurana podero ser expressos; o
WS-Trust ir descrever um modelo para que se obtenha um
relacionamento de confiana, tanto direto, quanto por meio de agentes
(incluindo terceiros e intermedirios); o WS-Privacy determinar de que
forma os web services sero adotados e implementados.
WS-Secure Conversation, WS-Federation e WS-Authorization: O
WS-Secure Conversation explica como autenticar e gerenciar a troca de
mensagens, incluindo especificaes para o contexto de segurana
desse intercmbio e a derivao de chaves de sesso; o WS-Federation
gerencia os vrios tipos de relacionamento em ambientes heterogneos
associados, incluindo o suporte identidade dessas partes associadas; a
WS-Authorization define como os web services administraro os dados e
as normas de autorizao.
Comunicao via SOAP
Exerccios
1. Cite as principais caractersticas que tornam um web service vulnervel.
2. Explique os nveis de segurana em web services.
3. Quais os pontos devem ser considerados quando falamos em segurana em
web services?
Comunicao via SOAP
Espao para anotaes
Comunicao via SOAP
Apndice 1:
Estudos Complementares
125
Segurana com Web Services
Diferena entre JAX-RPC e JAX-WS

Nos links a seguir, a IBM explica todos os detalhes que diferenciam as duas
formas de implementao de web services comuns do Java: o Java API for XMLBased RPC e o Java API for XML Web Services:
JAX-RPC vs. JAX-WS, Parte 1:

http://www.ibm.com/developerworks/webservices/library/ws-tipjaxwsrpc.html
http://www.ibm.com/developerworks/webservices/library/ws-tipjaxwsrpc2.html
http://www.ibm.com/developerworks/webservices/library/ws-tipjaxwsrpc3/
Diferena entre Document/Literal e RPC/Literal

Existem dois modelos de programao populares para web services hoje: RPC
e messaging. A especificao WSDL 1.1 define necessariamente dois estilos
mensagem SOAP Message, RPC e Document, que supostamente correspondem
a dois modelos de programao.
Aqui esto dois exemplos de mensagens SOAP: document/literal e RPC/literal.
Note que ambos os exemplos necessitam (mas no so obrigados a) conter um
elemento chamado Example com um filho chamado cust. No entanto, os
namespaces de Example e cust so diferentes nos dois exemplos, como
mostrado a seguir:
Document/Literal
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Example xmlns="http://example.org/soapformat">
<cust>
<Customer>
<Name>John Doe</Name>
<Id>ABC-1234</Id>
</Customer>
<Customer>
<Name>Jane Doe</Name>
<Id>XYZ-1234</Id>
</Customer>
</cust>
</Example>
</soap:Body>
</soap:Envelope>
RPC/Literal
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<x:Example xmlns:x="http://example.org/soapformat/Example">
<cust>
<t:Customer xmlns:t="http://example.org/soapformat">
<t:Name>John Doe</t:Name>
<t:Id>ABC-1234</t:Id>
</t:Customer>
<t:Customer>
<t:Name>Jane Doe</t:Name>
<t:Id>XYZ-1234</t:Id>
</t:Customer>
</cust>
</x:Example>
</soap:Body>
</soap:Envelope>
Maiores informaes so encontradas em http://msdn.microsoft.com/enus/library/ms996466.aspx.
Referncias Bibliogrficas
129
Apndice 1:
Estudos Complementares
BRYDON, S., MURRAY, G., RAMACHANDRAN, V., SINGH, I., STEARNS, B.,
VIOLLEAU, T. Designing Web Services with the J2EETM 1.4 Platform:
JAX-RPC, SOAP, and XML Technologies. Addison-Wesley, 2004
HANSEN, Mark D. SOA Using Java Web Services. New Jersey: Prentice Hall,
2007.
IBM. What is SOAP? Disponvel em: http://tinyurl.com/29yky4g. Acesso em 3
de nov. 2010.
JENNINGS, Frank. JURIC, Matjaz B. LOGANATHAN, Ramesh. SARANG,
Poornachandra. SOA Approach to Integration: XML, Web services,
ESB, and BPEL in real-world SOA projects. Birmingham: Packt
Publishing Ltd., 2007.
KEITH, Mike. SCHINCARIOL, Merrick. Pro EJB 3: Java Persistence API.
Berkeley: Apress, 2006.
KOCH, Christopher. ABC da SOA. Disponvel em: http://tinyurl.com/cnujvq.
Acesso em: 18 de ago. 2010.
PEREIRA, Michael Luiz. Web Services Seguros em Java. 2008. 64.
Monografia Ps-graduao em Desenvolvimento Orientado a Objetos Java
Centro Universitrio de Maring. Maring, 2008.

TJAVWSER - v4 - (08.11.2010)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TJAVWSER - v4 - (08.11.2010)

Uploaded by

Copyright:

Available Formats

Java Web Services

Apostila desenvolvida especialmente para a Target Informtica Ltda.

Java Web Services

Porque usar web services?................................................................................................36

T@rgetTrust Treinamento e Tecnologia

T@rgetTrust Treinamento e Tecnologia

Compreender como as integraes de dados e softwares impactam as

Conhecer os desafios relacionados s integraes.

Identificar infraestrutura e tecnologia envolvidas nas integraes.

Diferentes tipos de integraes

Integrao em nvel de dados

Integrao em nvel de sistema

Integrao em nvel de processos de negcio

SOA, BPEL e tecnologias relacionadas, provm hoje, novas oportunidades de

Integrao em nvel de apresentao

Integrao B2B (Business-to-Business)

Infraestrutura para integraes

Business Intelligence (BI)

Tecnologias para integraes

Acesso a banco de dados

Message-Oriented Middleware (MOM)

mensagens sem a preocupao com os detalhes da aplicao, arquiteturas e a

Um exemplo de plataforma que fornece este tipo de interface de comunicao

Remote Procedure Call (RPC)

A diferena principal entre o MOM e o RPC a maneira como a comunicao

Object Request Brokers (ORB)

Existem trs principais padres de ORB:

OMG CORBA ORB

Oracle Weblogic Server

Enterprise Service Buses (ESB)

As empresas hoje em dia

Sistemas desenvolvidos dentro da empresa

Estes sistemas, geralmente, foram desenvolvidos em diferentes plataformas,

Combinao de sistemas monolticos, cliente/servidor e multicamadas

Trocando os sistemas existentes

Espao para anotaes

2. SOA (Service Oriented

Soa (Service Oriented Architeture)

Compreender o novo paradigma arquitetural.

Entender suas vantagens e desvantagens.

Soa (Service Oriented Architeture)

Conceitos e princpios de SOA

SOA uma forma de encarar os ativos de TI como componentes de

A SOA (Service Oriented Architecture), Arquitetura Orientada a Servios, possui

Soa (Service Oriented Architeture)

Mudana de paradigma: de aplicaes

Servios baseados em componentes

Soa (Service Oriented Architeture)

A internet simplificando os servios remotos

Soa (Service Oriented Architeture)

Reutilizao de Software: algumas rotinas complexas que precisam

Mas tambm possui desvantagens, listadas a seguir:

Performance: na maioria das vezes a performance afetada em SOA,

Soa (Service Oriented Architeture)

Testes: testar um sistema SOA pode se tornar uma tarefa rdua.

Soa (Service Oriented Architeture)

Soa (Service Oriented Architeture)

Espao para anotaes

Soa (Service Oriented Architeture)

SOA (Service Oriented Architecture)

Compreender os conceitos associados aos web services.

Identificar as vantagens e desvantagens no uso dos web services.

Conhecer a arquitetura de um web service.