TJAVWSER - v4 - [08.11.2010]

Java Web Services

TJAVWSERNovembro/2010

Apostila desenvolvida especialmente para a Target Informática Ltda.

Sua cópia ou reprodução é expressamente proibida.

Java Web Services

Sumário

1. Integração...................................................................................1Objetivos....................................................................................................................................2Introdução.................................................................................................................................3Desafios da integração........................................................................................................4

Diferentes tipos de integrações.............................................................................................4Integração em nível de dados................................................................................................5Integração em nível de sistema.............................................................................................5Integração em nível de processos de negócio.......................................................................6Integração em nível de apresentação....................................................................................7Integração B2B (Business-to-Business)...............................................................................8

Infraestrutura para integrações......................................................................................10Comunicação......................................................................................................................10Transformação....................................................................................................................10Business Intelligence (BI)...................................................................................................10Transações..........................................................................................................................11Segurança............................................................................................................................11Ciclo de vida.......................................................................................................................11Nomenclatura......................................................................................................................11Escalabilidade.....................................................................................................................11Gerenciamento....................................................................................................................12

Tecnologias para integrações..........................................................................................13Acesso a banco de dados....................................................................................................13Message-Oriented Middleware (MOM).............................................................................13Remote Procedure Call (RPC)............................................................................................14Object Request Brokers (ORB)..........................................................................................15Servidores de aplicação......................................................................................................16Web Services......................................................................................................................17Enterprise Service Buses (ESB).........................................................................................18

As empresas hoje em dia..................................................................................................19Trocando os sistemas existentes...................................................................................20Exercícios................................................................................................................................21

2. SOA (Service Oriented Architecture)...........................................23Objetivos..................................................................................................................................24Conceitos e princípios de SOA.........................................................................................25

Mudança de paradigma: de aplicações independentes ao serviço......................................26Orientação a serviço............................................................................................................26Serviços baseados em componentes...................................................................................26A internet simplificando os serviços remotos.....................................................................27Consumindo serviços..........................................................................................................27Vantagens e desvantagens..................................................................................................28Aplicações...........................................................................................................................29

Exercícios................................................................................................................................30

3. Web Services.............................................................................33Objetivos..................................................................................................................................34Integração...............................................................................................................................35Porque usar web services?...............................................................................................36

T@rgetTrust Treinamento e Tecnologia I

Integraçã

Arquitetura dos web services..........................................................................................37Benefícios dos web services............................................................................................38

Self-Contained....................................................................................................................38Self-Describing...................................................................................................................38Modular...............................................................................................................................38Acessível através da web....................................................................................................38Linguagem, plataforma e protocolo neutros.......................................................................39Aberto e baseado em padrões.............................................................................................39Dinâmico.............................................................................................................................39

Web Services em Java: Serialização.............................................................................40Exercícios................................................................................................................................43

4. Criando Web Services.................................................................45Objetivos..................................................................................................................................46Necessidades básicas.........................................................................................................47

IDE (Integrated Development Environment).....................................................................47soapUI.................................................................................................................................47Apache Tomcat...................................................................................................................50Apache OpenEJB................................................................................................................50

JAX-WS......................................................................................................................................51Descrição............................................................................................................................51Necessidades.......................................................................................................................51Arquitetura..........................................................................................................................51Construção de um web service...........................................................................................52Descrição básica das Annotations mencionadas.................................................................56Publicando um web service sem Application Server..........................................................57

JAX-WS (via EJB)....................................................................................................................58Descrição............................................................................................................................58Necessidades.......................................................................................................................58Arquitetura..........................................................................................................................59Construção de um web service...........................................................................................60

Apache Axis............................................................................................................................63Descrição............................................................................................................................63Necessidades.......................................................................................................................63Arquitetura..........................................................................................................................63Construção de um web service...........................................................................................64

Codehaus XFire.....................................................................................................................66Descrição............................................................................................................................66Necessidades.......................................................................................................................66Arquitetura..........................................................................................................................66Construção de um web service...........................................................................................68

Exercícios................................................................................................................................70

5. Criando clientes de Web Service.................................................73Objetivos..................................................................................................................................74O que são clientes de web services?............................................................................75WSDL - Web Service Definition Language..................................................................76Eclipse IDE como cliente de web service....................................................................79Geradores de cliente automáticos.................................................................................82

Fixando conceitos...............................................................................................................82

T@rgetTrust Treinamento e Tecnologia II

Integraçã

JAX-WS..............................................................................................................................82JAX-WS: Consumindo o Serviço.......................................................................................85Apache Axis 1.x: Consumindo o Serviço...........................................................................86Apache Axis 2.x..................................................................................................................87Apache Axis 2.x: Consumindo o Serviço...........................................................................87Netbeans IDE......................................................................................................................88Netbeans IDE: Consumindo o Serviço...............................................................................90

Exercícios................................................................................................................................91Espaço para anotações........................................................................................................92

6. Comunicação via SOAP...............................................................93Objetivos..................................................................................................................................94O que é SOAP?.......................................................................................................................95Por que SOAP?.......................................................................................................................96Bloco de estrutura SOAP...................................................................................................97Exemplo de mensagem SOAP.........................................................................................99

O SOAP Request................................................................................................................99O SOAP Response..............................................................................................................99

SAAJ - SOAP with Attachments API for Java..............................................................100Mensagens........................................................................................................................100Estrutura do XML.............................................................................................................100Mensagem sem anexos.....................................................................................................100Mensagem com anexos.....................................................................................................101Conexões...........................................................................................................................102

Exemplo completo de chamada...................................................................................104Dica de construção da chamada SOAP.............................................................................105

Exercícios..............................................................................................................................109Espaço para anotações......................................................................................................110

7. Segurança com Web Services...................................................111Objetivos................................................................................................................................112Introdução.............................................................................................................................113Segurança em web service............................................................................................114

Segurança em nível de transporte.....................................................................................114Segurança em nível de XML............................................................................................115

Questões a serem consideradas..................................................................................116Vantagens da segurança na camada de mensagem...........................................117Especificações e iniciativas atuais...............................................................................118

Especificações W3C.........................................................................................................118Especificações OASIS......................................................................................................119Especificações JCP...........................................................................................................119Especificações WS-I.........................................................................................................120

WS-Security..........................................................................................................................121Exercícios..........................................................................................................................122Espaço para anotações......................................................................................................123

Apêndice 1: Estudos Complementares...........................................125Diferença entre JAX-RPC e JAX-WS..............................................................................126Diferença entre Document/Literal e RPC/Literal....................................................127

T@rgetTrust Treinamento e Tecnologia III

Integraçã

Referências Bibliográficas...............................................................................129

T@rgetTrust Treinamento e Tecnologia IV

Java Web Services

T@rgetTrust Treinamento e Tecnologia 1

Integraçã


Java Web Services

1.1. IntegraçãoIntegração


Integração

Objetivos Compreender como as integrações de dados e softwares impactam as

empresas. Conhecer os desafios relacionados às integrações. Identificar infraestrutura e tecnologia envolvidas nas integrações.


Integração

Introdução

A crescente necessidade de disponibilidade e acesso às informações caracteriza um desafio para o desenvolvimento de aplicações. Sistemas stand-alone não conseguem mais atender às necessidades de crescimento das empresas atualmente. A maioria das companhias ainda têm sistemas legados, desenvolvidos utilizando diferentes arquiteturas e tecnologias. Muitos destes sistemas, não foram concebidos para proporcionarem integração. Seria extremamente custoso para as empresas reescrever ou trocar todos seus sistemas da noite para o dia.

Além disto, empresas precisam, sem sombra de dúvida, aderir a novos sistemas de tempos em tempos. Novas soluções, normalmente, são baseadas em novas e modernas arquiteturas, que acabam diferindo significantemente daquela utilizada nos sistemas legados. Estas novas aplicações também têm de se integrar às aplicações existentes, para formar um conjunto único e coeso de dados que podem ser aproveitados entre si.

Hoje, a integração de aplicações é uma tarefa extremamente difícil, talvez a mais complicada de ser encarada, no que diz respeito ao desenvolvimento de aplicações em uma empresa. Para tentar solucionar estes objetivos de integração, muitas metodologias, técnicas e tecnologias foram desenvolvidas nos últimos anos, desde a integração de aplicações ponto-a-ponto, quanto ao gerenciamento de processos de negócio baseado em arquitetura orientada a serviços.


Integração

Desafios da integração

A habilidade de instantaneamente acessar informações vitais que podem estar armazenadas em uma variedade de diferentes aplicações pode influenciar o sucesso de uma empresa. Para as empresas, a facilidade de acesso à informação, de forma que evite numerosas tarefas manuais, ou que envolvam muitos funcionários, é muito importante. Funcionários não devem ter de trocar de sistema em sistema para que consigam realizar seus trabalhos, ou mesmo, entrar com a mesma informação em diversos sistemas. O ideal seria possuir sistemas bem integrados, garantindo o suporte aos processos de negócio de ponta a ponta.

Muitos gestores de TI não estão familiarizados com a complexidade escondida por trás da integração de processos. Às vezes, até os funcionários de TI, arquitetos e desenvolvedores, não compreendem as armadilhas atrás das integrações. E o mais importante: os gestores podem não compreender que uma integração relaciona-se com a empresa como um todo, e não somente com o departamento de TI.

Integrações devem ser consideradas como as mais importantes prioridades estratégicas, principalmente porque soluções inovadoras demandam integrações entre diversas áreas do negócio, dados da empresa e aplicações. Informações integradas aumentam a vantagem competitiva com o acesso unificado e eficiente à informação. Integrações bem feitas facilitam a busca por informações na hora da necessidade por uma tomada de decisão, por exemplo.

Diferentes tipos de integraçõesA arquitetura das integrações é construída normalmente em camadas. A ideia por trás disto é a de o problema ser quebrado em pedaços menores para que possam ser resolvidos passo a passo. Atualmente, as integrações podem ser vistas em diversas camadas.

A seguir, serão comentados os seguintes tipos de integrações:

Integração em nível de dados Integração em nível de sistema Integração em nível de processo de negócio Integração em nível de apresentação Integração B2B (Business-to-Business)


Integração

Integração em nível de dadosA integração em nível de dados tem como objetivo a movimentação dos dados entre sistemas, primando pelo compartilhamento das mesmas informações. Geralmente, este é o ponto inicial onde as empresas iniciam o trabalho de integração.

Data

Server

Data

Server

Data

Server

Data

Data

Server

Integração em nível de sistemaO foco principal da integração em nível de sistema é o compartilhamento de funcionalidades – lógica de negócio; e não apenas integração em nível de dados. Integração em nível de sistema é comumente conseguida através de APIs (Application Programming Interfaces). Sistemas que expõe suas funcionalidades através de APIs permitem o acesso às suas funcionalidades de uma forma “programática”; através de suas interfaces.


Integração

Integração em nível de processos de negócioA integração em nível de processos de negócio tem como objetivo expor através de interfaces uma abstração das funcionalidades dos processos da empresa. As funcionalidades das aplicações legadas não são reescritas. Mas são remodeladas de uma forma a expor estas funcionalidades em uma camada intermediária, e consequentemente, em uma nova arquitetura.

Finalmente, todas estas peças são agrupadas, geralmente utilizando-se de técnicas, metodologias e ferramentas para modelagem de processos de negócio, como o BPEL (Business Process Execution Language), conforme mostrado a seguir:

SOA, BPEL e tecnologias relacionadas, provêm hoje, novas oportunidades de integração entre sistemas de informação. Mais flexíveis e adaptáveis às mudanças nos processos de negócio. Desta forma, os sistemas de informações tornam-se mais ágeis, suportando melhor as mudanças nos requisitos, alinhando-se muito bem às necessidades do negócio.

Tem-se que ter em mente que alcançar bons níveis de integração dos processos de negócio, normalmente, necessita de uma reengenharia nestes processos, o que não é resolvido somente em uma implementação. Para isto, talvez, sejam necessárias várias camadas de integração entre as aplicações existentes, até que sejam alcançados altos níveis de abstração.

Integração em nível de apresentaçãoCom frequência, depois de alcançar uma integração em nível de processo de negócio, vem o próximo passo: a integração em nível de apresentação. Como agora, as aplicações estão remodeladas e encapsuladas em uma camada intermediária (chamada de middle tier), onde os serviços são expostos em T@rgetTrust Treinamento e Tecnologia 6

Integração

interfaces de alto nível, torna-se crucial que o usuário tenha uma única visão da informação como um todo. Tendo o usuário que ficar trocando de aplicação em aplicação legada, pode ocorrer que informações sejam perdidas; conhecimento seja perdido.

Integração em nível de apresentação resulta em um sistema que provê uma camada única de visualização, onde os usuários podem acessar as funcionalidades dos sistemas de forma integrada. Do ponto de vista da usabilidade do usuário, ele não toma conhecimento de que funcionalidades de outras aplicações estão sendo executadas devido a sua interação. Assim, a camada de apresentação fica desacoplada e não toma conhecimento dos detalhes das aplicações existentes.

Com o desenvolvimento de uma camada de apresentação unificada, escondem-se as aplicações legadas, mas suas funcionalidades continuam sendo executadas. Desta forma, melhora-se a eficiência do usuário final e se fornece uma maneira de se trocar partes dos sistemas legados no futuro, sem influenciar outras partes do sistema.


Integração

Integração B2B (Business-to-Business)Hoje, a integração em nível de aplicação dentro das companhias não é suficiente. Existem necessidades crescentes de integração entre empresas, frequentemente chamadas de integrações business-to-business (B2B) ou e-business. E-Business torna-se um novo desafio para os sistemas de informação. Os requisitos hoje são muito altos e vão além dos dias em que as empresas apenas publicavam seus catálogos off-line em suas páginas web. O que se espera no momento é a informação online, atualizada, eficiente, rápida, confiável e de qualidade.

É óbvio que como pré-requisito para um e-business ou uma integração B2B seja necessário que a empresa possua um sistema de informação integrado, possivelmente com seus processos de negócio ajustados. Somente este tipo de nível de integração permite o processamento de demandas instantaneamente. Clientes, hoje, esperam por respostas imediatas e não ficam satisfeitos com processamentos batch, ou que a demora na confirmação de um pedido leve dias para chegar, por exemplo.

Existem exemplos claros de integrações B2B: pesquisa por passagens aéreas! Há no mercado, hoje, sites especializados em encontrar a passagem aérea mais barata em todas as companhias aéreas que fazem o trecho pesquisado. Estes sites fornecem seus serviços na forma B2B e consomem o serviço das companhias aéreas no mesmo modelo. Quem pode garantir que este serviço fornecido em ambas as pontas não se utilizam de sistemas legados? Para o usuário (no caso, nós) esta percepção é transparente. Abaixo, vêm-se exemplos destes serviços:

ViajaNet – http://www.viajanet.com.br


Integração

Decolar.com – http://www.decolar.com


Integração

Infraestrutura para integrações

A seguir, serão apresentadas informações básicas sobre as infraestruturas necessárias para integração dos serviços.

ComunicaçãoA principal responsabilidade dos serviços de comunicação é prover a abstração dos detalhes da comunicação. Ela fornece uma transparência para acesso remoto aos sistemas e unifica a visibilidade destes. Ela garante que os desenvolvedores não tenham a preocupação de lidar com a comunicação de baixo nível.

Diferentes tipos de middlewares fornecem diferentes camadas de serviços. As mais comumente utilizadas são as tecnologias de acesso aos bancos de dados, como o JDBC (Java Database Connectivity), que fornece uma camada de abstração para acesso a diferentes bancos de dados.

TransformaçãoTransformação das estruturas de dados, suas representações e tecnologias sempre foram muito importantes. No passado, pequenos programas que liam uma informação da origem e a transformavam em outro formato no destino, geralmente, resolviam os problemas relacionados às integrações (ex. mainframe para baixa plataforma). Com o advento de linguagens de marcação, como o XML (Extensible Markup Language), que acabou se tornando a linguagem padrão para troca de informações, as transformações alcançaram um novo nível de maturidade.

Business Intelligence (BI)A camada de BI é responsável por apresentar uma interface de alto nível para acessar as informações de negócio em outras aplicações e usuários. A camada de BI apresenta os dados aos usuários em um formulário compreensível. Com o crescimento do e-commerce, a camada de BI também é responsável pela integração B2B.

Hoje, a camada de BI é suportada por diversas camadas de apresentação, mais comumente encontradas em forma de portais. Portais personalizados garantem a entrega de valor de dados e conteúdo personalizados aos funcionários, parceiros de negócio e clientes.


Integração

TransaçõesA integração da infraestrutura deve proporcionar que as operações que envolvam o negócio ocorram de forma transacional. Entretanto, devem ser possíveis chamadas a diversas operações em diferentes sistemas. Deve suportar o modelo de atomicidade ACID (atomicity, consistency, isolation, durability).

Em outras palavras, a aderência ao modelo transacional deve garantir que qualquer operação executada em uma ou mais aplicações (que causem a mudança de estado ou permanente mudança nos dados - persistência) ocorram com garantia de consistência.

SegurançaA infraestrutura de integração deve fornecer maneiras de restringir o acesso ao sistema. Esta deve preocupar-se também, com a encriptação do canal de comunicação, autenticação, autorização e auditoria.

Ciclo de vidaA infraestrutura de integração deveria prover formas de controlar o ciclo de vida de todas as aplicações envolvidas. Deveria permitir que aplicações existentes pudessem ser trocadas uma a uma, ou até mesmo em partes, sem que houvesse influência em qualquer parte do todo.

NomenclaturaA unificação da nomenclatura dos serviços vai garantir a transparência na localização da implementação e garantirá a troca futura de um recurso por outro, se necessário. Web services são grandes exemplos de serviços que devem ser expostos com cuidado em sua nomenclatura.

EscalabilidadeA infraestrutura de integração deve ser montada pensando-se em escalabilidade. Deve acessar as informações de forma a prover o acesso concorrente às aplicações. Deve incorporar soluções que garantam acesso suficiente à demanda esperada, e onde possa ser possível expandi-la conforme demanda.

A infraestrutura de integração, no entanto, não pode ser responsabilizada por más arquiteturas da aplicação.


Integração

GerenciamentoDeve-se haver formas de gerenciar a infraestrutura de integração. A camada de gerenciamento deve prover métodos e ferramentas para que os serviços sejam gerenciados. Deveria prover também uma forma simples de configuração e gerenciamento das versões. O gerenciamento remoto garantiria à gerência de infraestrutura de que esta seja administrada off-site.


Integração

Tecnologias para integrações

Normalmente, integrações de infraestrutura requerem diferentes formas e tecnologias de implementação. Até porque tem-se um mistura muito grande de tecnologias envolvidas relacionadas ao negócio. Quando se tem esta mistura, deve-se focar em interoperabilidade.

Interoperabilidade entre tecnologias será crucial e será utilizada para implementar a integração da infraestrutura. Alcançá-la poderá ser difícil mesmo baseando-se em padrões abertos. Tecnologias utilizadas nas integrações são comumente oferecidas em forma de middlewares.

Middleware é um software executado entre a camada do sistema operacional e a camada da aplicação. Ele conecta duas ou mais aplicações, proporcionando assim conectividade e interoperabilidade entre elas. Middleware adiciona uma camada de abstração na arquitetura do sistema e assim reduz consideravelmente a complexidade. Por outro lado, cada middleware introduz uma certa sobrecarga na comunicação do sistema, que pode influenciar na performance, estabilidade, escalabilidade e outros fatores relacionados à eficiência geral.

A seguir serão apresentadas algumas das tecnologias mais comuns de middleware.

Acesso a banco de dadosAs tecnologias de acesso ao banco de dados fornecem o acesso através de uma camada de abstração, a qual nos permite modificar o SGBD (Sistema Gerenciador de Banco de Dados) sem modificar o código fonte. Em outras palavras, elas permitem usar o mesmo (ou quase o mesmo) código para acessar diferentes bancos de dados. As mais conhecidas são 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 aplicações. Ela permite a comunicação entre aplicações através de uma plataforma distribuída e heterogênea. Ela reduz a complexidade porque esconde os detalhes da comunicação, da plataforma e os protocolos envolvidos. Geralmente, as funcionalidades MOM são acessadas através de API (Application Programming Interface).

Ela fornece uma comunicação assíncrona e usa fila de mensagens para processar as informações. As aplicações podem desta forma, trocar


Integração

mensagens sem a preocupação com os detalhes da aplicação, arquiteturas e a plataforma envolvida.

O básico da arquitetura pode ser visto no diagrama a seguir:

Um exemplo de plataforma que fornece este tipo de interface de comunicação é o JMS (Java Messaging Service).

Remote Procedure Call (RPC)RPC também se utiliza de infraestrutura cliente/servidor. Criada para garantir e aumentar a interoperabilidade das aplicações através de plataformas heterogêneas. Como o MOM, ela permite a comunicação entre software em diferentes plataformas e esconde quase todos os detalhes da comunicação. RPC é baseado em conceitos procedurais; sua primeira implementação data a década de 80.


Integração

A diferença principal entre o MOM e o RPC é a maneira como a comunicação é feita. Enquanto o MOM suporta comunicação assíncrona, o RPC é síncrono. O diagrama a seguir mostra duas aplicações comunicando-se através de RPC:

Object Request Brokers (ORB)São tecnologias de middleware que gerenciam e suportam a comunicação entre objetos ou componentes. Facilitam a comunicação entre objetos distribuídos sem a preocupação com os detalhes da arquitetura da comunicação. Fornecem transparência na localização, linguagem de programação, protocolo e sistema operacional.

São comunicações baseadas em interfaces. A comunicação é geralmente síncrona, mas pode também ser feita assincronamente. A seguir pode-se identificar um diagrama com este conceito:


Integração

Existem três principais padrões de ORB:

OMG CORBA ORB Java RMI e RMI-IIOP Microsoft COM/DCOM/COM+/.NET Remoting/WCF

Servidores de aplicaçãoServidores de aplicação gerenciam todas ou a grande maioria das interações entre a camada de cliente e a camada de persistência. Eles fornecem uma coleção de serviços middleware, junto com o conceito de gerenciamento do ambiente onde os componentes de regra de negócio são implantados (deploy): o container.

Na grande maioria dos servidores de aplicação, pode-se encontrar suporte aos web services, ORB, MOM, gerenciamento de transação, segurança, balanceamento de carga e gerenciamento de recursos. Abaixo seguem alguns dos servidores de aplicação de mercado:

Oracle Weblogic Server Red Hat JBoss IBM WebSphere Application Server Oracle Glassfish Application Server


Integração

Web ServicesWeb services são o que há de mais novo em questão de tecnologia distribuída. Eles fornecem a fundamentação tecnológica para que seja alcançada a interoperabilidade entre aplicações usando diferentes plataformas, sistemas operacionais e linguagens de programação. Do ponto de vista de tecnologia, web services são os próximos passos na evolução das arquiteturas distribuídas. São similares aos seus predecessores, mas também diferem deles em diversos aspectos.

Web services são as primeiras tecnologias distribuídas a serem suportadas pela grande maioria de fornecedores. E além disto, foi a primeira tecnologia que preencheu todos os requisitos do universo de promessas de interoperabilidade existentes. As especificações fundamentais são que os web services são baseados em SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) e UDDI (Universal Description, Discovery and Integration). SOAP, WSDL e UDDI são baseados em XML, fazendo com que o protocolo da mensagem do web service seja possível de ser lido pelo ser humano.

Da perspectiva de arquitetura, web services introduzem diversas mudanças importantes se comparada com as arquiteturas anteriores.

Operações em web services são baseadas na troca de mensagens XML. Elas são coleções de entradas, saídas e mensagens de erro. As combinações de mensagens definem o tipo de operação.

Web services fornecem suporte a comunicação síncrona e assíncrona. Eles utilizam padrões dos protocolos da internet, como o HTTP (Hyper Transfer Protocol) e MIME (Multipurpose Internet Mail Extensions). Sendo assim, comunicações através da internet e de firewalls costumam ser menos problemáticas.

Existem também, desvantagens no uso dos web services. Uma delas é a performance, a qual não se compara a uma arquitetura distribuída que se utiliza de protocolos de comunicação binários. Além de não oferecer QoS (Quality of Service). Web services serão o foco de estudo desta apostila.

Na seguinte URL, pode-se conferir todo o embasamento técnico relacionado à arquitetura dos web services, segundo a W3C (o consórcio World Wide Web é uma comunidade internacional que desenvolve padrões com o objetivo de garantir o crescimento da web): http://www.w3.org/TR/ws-arch/.


Integração

Enterprise Service Buses (ESB)ESB são softwares de infraestrutura que agem como uma camada intermediária de middleware que aumentam as possibilidades que normalmente web services não conseguem proporcionar, como integração entre web services e outras tecnologias de middleware, dependência de alto nível, robustez e segurança, gerenciamento e controle dos serviços e das suas comunicações.

Um ESB simplifica a integração e o reuso de serviços. Ele facilita a possibilidade de conectar serviços implementados em diferentes tecnologias, como EJB (Enterprise Java Beans), sistema de mensagens, componentes CORBA e aplicações legadas, de uma forma simples. Um ESB pode agir como um mediador entre diferentes, as vezes incompatíveis, protocolos e produtos de middleware. Ele permite log, balanceamento de carga, tuning, deploy distribuído, configuração on-the-fly etc.


Integração

As empresas hoje em dia

Raramente em empresas que estão formadas há poucos anos encontram-se sistemas de informação integrados. Mas, pode-se encontrar um ambiente totalmente heterogêneo, 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 programação. Com isto, temos o seguinte:

Combinação de sistemas monolíticos, cliente/servidor e multicamadas Mistura de soluções procedurais, orientada a objetos e baseada em

componentes Mistura de linguagens de programação Diferentes tipos de banco de dados Diferentes soluções de middleware Diferentes soluções de segurança Diferentes formas de compartilhamento de dados


Integração

Trocando os sistemas existentes

Melhorar a funcionalidade dos sistemas de informação é possível de diversas formas. O mais óbvio é a troca deste sistema antigo por uma nova solução. Se, em princípio, esta parece ser uma solução atrativa, existem diversos detalhes que demonstram que fazer uma troca de sistema nem sempre é uma boa solução para todos os casos. Desenvolver e implantar novos softwares da noite para o dia é impossível; migração de sistemas críticos podem significar custos significativamente altos.

As empresas hoje em dia são muito complexas, onde até mesmo os sistemas ERP não conseguem cobrir todas as suas necessidades. Existem pesquisas que informam que os sistemas ERP atendem entre 30% e 40% das informações necessárias. Esta é uma das razões principais que os maiores fornecedores de sistemas ERP, como SAP e Oracle, adicionaram interfaces para fornecer integração aos seus produtos.

Esta troca dos sistemas por novas soluções acabam quase sempre necessitando de um gasto superior aquele planejado no início do projeto; até mesmo nos cenários mais pessimistas. Muito depende das empresas e de o quanto de seus processos de negócio estão mapeados e documentados.

É claro que trocar os sistemas existentes nem sempre é a melhor e a proposta mais viável. Muito dinheiro e tempo foi gasto para que elas chegassem ao nível de maturidade que estão 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.


Integração

Exercícios

1. Para você quais são os desafios das integrações hoje em dia? Cite exemplos.

2. Comente o porquê dos web services serem umas das mais importantes tecnologias para integrações.

3. Como são as empresas hoje em dia, com relação aos seus softwares?


Integração

Espaço para anotações


Java Web Services

2.2. SOA (Service OrientedSOA (Service Oriented Architecture)Architecture)


Soa (Service Oriented Architeture)

Objetivos Compreender o novo paradigma arquitetural. Entender suas vantagens e desvantagens.



Conceitos e princípios de SOA

Algumas definições de SOA:

SOA é uma forma de encarar os ativos de TI como componentes de serviço. Onde funções em um sistema são expostos como serviços stand-alone, que podem ser acessados separadamente, beneficiando seus consumidores.

Service Oriented Architecture (SOA) é uma infraestrutura de software que proporciona uma conexão ágil aos processos de negócio, através de um baixo acoplamento e de web services.

SOA é estratégia de arquitetura de TI voltada para soluções de negócio (e de infraestrutura) baseada no conceito de orientação a serviços.

A SOA (Service Oriented Architecture), Arquitetura Orientada a Serviços, possui diversas definições, mas pode ser entendida como um paradigma arquitetural que viabiliza a criação de serviços de negócio com baixo acoplamento e interoperáveis entre si, os quais podem ser facilmente compartilhados dentro e fora das organizações.

Esse paradigma já é reconhecido como a principal maneira de arquiteturar e organizar as áreas de TI das empresas. Portanto, as empresas que não se adequarem a este tipo de arquitetura, ficarão completamente obsoletas e sem poder de reação frente às novas demandas de negócio na atual economia mundial.



Mudança de paradigma: de aplicações independentes ao serviço

O uso de camadas de serviço na mudança de paradigma das arquiteturas das aplicações em uma empresa fica evidente na abordagem SOA. O valor agregado destas integrações combinado com o ganho da conexão entre várias aplicações vem acelerando este processo de mudança. A necessidade de incorporar o acesso a múltiplos serviços de forma genérica nas empresas é afetada pela camada de infraestrutura, para proporcionar SOA.

Para qualquer solução dada, podemos ter duas, três ou N camadas de infraestrutura. Estas camadas continuarão nas aplicações individuais sendo construídas, isto é, qualquer nova aplicação deverá ter esta preocupação. Para estas, e para as aplicações legadas, existirão camadas de serviço bem definidas. Prover esta infraestrutura está se tornando a maior prioridade da maioria das empresas de TI e por seus CIOs.

Orientação a serviço

Orientação a serviço contém grande importância nas funcionalidades de interface com o negócio. A noção de importância destas interfaces não é de toda nova. Toda aplicação bem elaborada contém módulos de negócio bem estruturados, e cada módulo em cada aplicação terá métodos/operações bem elaborados. Hoje, nas mais variadas plataformas (ex. JAVA EE, CORBA e .NET) existem design patterns, como o Façade, que fornecem estas funcionalidades e garantem um desenvolvimento coeso.

Serviços baseados em componentes

Conceitualmente, serviços baseados em componentes é o cerne do SOA. Orientação a objetos e componentes distribuídos são conceitos bem estabelecidos hoje em dia. Orientação a objetos é uma ótima abordagem para construção de sistemas extensíveis com a complexidade de vários módulos abstraídos e “escondidos”. Componentes distribuídos são uma extensão simples do mecanismo de RPC, o que não é só uma invocação de método, mas um objeto acessado remotamente.



A internet simplificando os serviços remotos

A internet trouxe uma mudança significante para a infraestrutura de TI em diversas áreas. Ela acelerou o crescimento do SOA, fazendo com que fosse facilitado o acesso remoto a serviços através de onipresença da internet e do HTTP. XML, que é uma generalização do HTML, vagarosamente caminhou para um formato aceito de intercâmbio 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 serviço. A requisição é composta de um documento XML (pela especificação do SOAP), e enviada através do HTTP a um endereço web.

Consequentemente, o acesso a qualquer tipo de solução transformou-se em algo simples e independente da tecnologia e infraestrutura que está em uso no lado da aplicação. Uma vez que os serviços estejam prontos e disponíveis, qualquer necessidade de acesso a eles, serão feitos da mesma forma, não se importando com as tecnologias envolvidas.

Consumindo serviços

Uma vez que os serviços estejam disponíveis através da plataforma SOA, o que pode ser feito com eles? Consumir os serviços através de uma aplicação cliente.

Consumir significa usar o serviço – invocar o serviço de outra aplicação como parte da lógica normal deste programa. Digamos numa aplicação de ERP, onde os detalhes de um cliente sejam necessários, pode-se fazer uma chamada ao serviço que fornece essas informações (ex. CRM), e este retornará com os detalhes solicitados.



Vantagens e desvantagens

A arquitetura SOA possui diversas vantagens que contribuem decisivamente para a integração de processos de negócio, conforme a seguir:

Reutilização 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 módulos prontos, a equipe de desenvolvimento pode ser concentrar em outras tarefas do sistema. É mais rápido se conectar a um web service do que criar toda rotina necessária para o sistema.

Maior Agilidade: o fato de não precisar recriar nada, e qualquer alteração no código ter destino certo. Com a certeza de que não existe código duplicado no sistema, a agilidade na manutenção é uma realidade.

Interoperabilidade: consiste em trocar informações 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 estratégia que não é exclusiva dos web services, as escalabilidade horizontal e vertical (adicionar servidores e aumentar a capacidade destes).

Mas também possui desvantagens, listadas a seguir:

Performance: na maioria das vezes a performance é afetada em SOA, apesar de existirem soluções para melhorar a performance pressupõem-se que se esteja usando computação distribuída. Então seus acessos ao web service precisam transitar pela rede, o que pode gerar um problema, pois a latência das redes não são determinísticas, em sistemas de tempo real isso pode ser crucial. O uso de web services também pode exigir o uso de stubs ou skeletons para que haja uma interoperabilidade, isso naturalmente gera algum overhead. Se for trabalhar com XML ao invés de arquivos binários ainda existe o tempo de processamento do arquivo e a validação DTD ou schema do XML.

Segurança: como os dados trafegam pela rede, eles podem ser interceptados, e arquivos textos serão facilmente interpretados. Esse problema pode ser resolvido com alguma chave de identificação, o que irá gerar um tempo de processamento maior também pelo fato de precisar validar o cliente.

Robustez: serviços que dependem da rede podem falhar, com perdas de conexão, mensagens perdidas ou entregues fora de ordem.

Disponibilidade: o tempo em que o servidor fica disponível, se ele for desligado ou a energia cair, ou se for reiniciado. É preciso ter uma solução de infraestrutura que permita a replicação e o balanceamento de carga, por exemplo.

Testes: testar um sistema SOA pode se tornar uma tarefa árdua. Reproduzir problemas em ambiente de testes é difícil. Os arquivos de



logs podem não estar acessíveis, ou o serviço externo não estar disponível. Muitos erros acontecem por criar XML inválidos, é preciso compreender muito bem de XML para resolver problemas de estrutura dos documentos.

Usabilidade: algumas rotinas são por natureza demoradas, por manipularem grandes quantidades de dados e terem muitas regras de negócio. Como web services não funcionam como threads, fica complicado fornecer feedbacks do processo ou cancelar a solicitação.

Este tópico não visa explorar a fundo todas as possibilidades dos serviços SOA e web services, mas tem apenas um apanhado geral sobre algumas vantagens e desvantagens da sua utilização.

Aplicações

Integração de sistemas:

Em quase todas as organizações possuímos cenários complexos, em ambientes completamente heterogêneos, com dezenas de aplicações desenvolvidas para desempenhar papéis distintos. Um grande problema que o SOA se propõe a resolver é facilitar a integração desses componentes da organização. Seguindo os preceitos desse novo paradigma arquitetural, facilmente conseguiríamos integrar os sistemas sem ter quer fazer modificações internas, apenas disponibilizando-os como serviços.

Reutilização de sistemas legados através de chamadas remotas:

No desenvolvimento de novas soluções, quase sempre nos deparamos com sistemas antigos que não podem deixar de ser utilizados, nem mantidos, são os chamados sistemas legados. Esses sistemas também podem possuir uma série de implementações prontas para o novo sistema a ser construído e devem ser reaproveitadas. Com a implementação do SOA é possível disponibilizar maneiras de acessar os sistemas legados através de chamadas remotas.

Disponibilização de informações corporativas a usuários ou sistemas que extrapolam as fronteiras corporativas:

B2B (business-to-business); negócios entre empresas, envolvendo produtos, serviços ou parcerias. Este termo é mais usado em relação aos sites que promovem este tipo de comércio, oferecendo toda a praticidade e infraestrutura necessária, cobrando em troca uma mensalidade ou comissão sobre as transações.



Exercícios

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?


Java Web Services

3.3. Web ServicesWeb 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.



Integração

A tecnologia de web services tem um papel importante na aplicação dos conceitos de SOA. Esta tecnologia é baseada em padrões abertos, como:

XML SOAP WSDL UDDI

O uso de padrões abertos proporciona a interoperabilidade entre diferentes fornecedores de soluções. As soluções existentes podem ser encapsuladas como web services e novos serviços podem ser desenvolvidos sem a necessidade de se conhecer quem é o consumidor. O utilizador pode consumir qualquer web service não importando a plataforma a qual ele está rodando. Isto fornece uma integração just-in-time de aplicações e permite ao negócio estabelecer novas parcerias com muita agilidade. Desta forma, a tecnologia de web services é a melhora candidata para criação de SOA.



Porque usar web services?

Nos primórdios da Internet, era comum que aplicações de negócio utilizassem protocolos como SMTP e FTP para realizarem transações. Isto permitia que houvesse uma interligação entre as empresas, mas ela não era muito eficiente. Foi somente com a padronização de formatos e da adoção 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 informação do mundo.

Os web services são a última tecnologia para a construção de aplicações distribuídas 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 não é a primeira tecnologia a permitir esse tipo de serviço, mas ela se diferencia por usar XML na comunicação, escondendo a implementação em ambas as pontas (cliente/servidor), o que a torna independente de plataforma. É a integração ideal para um ambiente tão diversificado quanto a Internet, na qual se conectam computadores pessoais e servidores que possuem um número enorme de diferentes plataformas.

Com o uso de web services, é possível obter um conjunto de informações publicadas remotamente em um servidor através de uma chamada de método que independe da linguagem utilizada. Desta maneira, um servidor que disponibiliza informações em tempo real sobre condições climáticas em qualquer parte do mundo e que tenha sido implementado na plataforma .NET da Microsoft pode receber uma consulta de uma pequena aplicação cliente desenvolvida em Java. Métodos que realizam funções complexas e objetos inteiros contendo uma vasta quantidade de informações passam a estar disponíveis na Internet para serem acessados por qualquer aplicação.

Todos esses recursos possibilitam uma melhor integração entre sistemas, inclusive os sistemas legados, aspecto esse que tem se tornado uma das maiores preocupações no mundo corporativo.

Web services é a tecnologia ideal para comunicação entre sistemas. A comunicação entre os serviços é padronizada possibilitando a independência de plataforma e de linguagem de programação. Por exemplo, um sistema de reserva de passagens aéreas feito em Java e rodando em um servidor Linux pode acessar, com transparência, um serviço 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 serviços cria o serviço e o publica em um registro UDDI para que os consumidores possam descobri-los. Um consumidor “pergunta” ao registro e obtém uma referência a interface do serviço. Depois da interface obtida, o consumidor cria a interface de programa do serviço. O utilizador então consome o serviço usando protocolo padrão SOAP. A chamada é direcionada através de um servidor web protegido por firewalls. Esta é uma forma de invocar-se um serviço.



Benefícios dos web services

A abordagem de construir seus web services SOA oferecem diversos benefícios como listados a seguir:

Self-Contained

Web services são self-contained (independentes) no sentido deles não 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 serviço é instalado e fica pronto para o uso, o cliente pode consumi-lo sem a necessidade da instalação de softwares em sua máquina.

Self-Describing

Web services são self-describing (auto-descritivos). Uma interface para um serviço é publicada através de um documento WSDL. Um documento WSDL define o formato da troca de mensagem e os tipos de dados usados. Para consumir o serviço, o cliente necessita conhecer apenas sobre o formato e conteúdo da chamada e da resposta da mensagem.

Modular

Web services fornecem diversas abstrações nos componentes de tecnologias existentes baseados em J2EE, CORBA, DCOM, entre outros. Usando essa diversidade de tecnologias, os componentes são criados. O web service compõe estes componentes para oferecer o serviço ao cliente. A interface aos componentes não é exposta aos clientes. Isto resulta em um desenvolvimento modular de software, resultando na criação de uma visão mais abstrata do serviço de negócio.

Acessível através da web

Web services são publicados, localizados e invocados através da web usando protocolos padrões. A descrição do serviço é publicada usando WSDL; o serviço é localizado com um help no registro UDDI e é invocado via SOAP. Todos estes protocolos são baseados na web.

Linguagem, plataforma e protocolo neutros

Como os web services são baseados em padrões abertos de XML, são 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 padrões

A tecnologia de web services é baseada em padrões abertos, fazendo com que sejam interoperáveis entre si. Estes padrões serão descritos durante o desenvolvimento do conteúdo desta apostila.

Dinâmico

Web services podem ser descobertos e consumidos em tempo de execução, sem a necessidade de um tempo de compilação. Na maioria das tecnologias, o cliente precisa apenas conhecer o componente de interface.



Web Services em Java: Serialização

Este tópico demonstra alguns aspectos importantes e que compõe a arquitetura e a construção do conhecimento relacionado à criação dos web services em Java.

Serialização é o processo de transformar uma instância de uma classe Java em um elemento XML. O processo inverso, transformar um elemento XML em instância Java é chamado de desserialização.

A serialização é o componente mais importante de qualquer plataforma para Java. No exemplo visto na figura anterior, ilustra-se o problema da serialização resolvido. Ela traduz os parâmetros das instâncias das suas respectivas classes em instâncias do schema XML, chamado de mapeamento de tipos (type mappings) – ilustrado no diagrama a seguir.



Para garantir esta tradução, o motor (engine) da serialização necessita de um conjunto de estratégias de mapeamento que dizem como cada tipo de mapeamento deve ser implementado; em outras palavras, como serializar as instâncias das classes Java em instâncias dos componentes do schema XML.

Diferentes plataformas de web services fornecem diferentes mecanismos e estratégias de mapeamento que constroem o contexto de serialização. Em muitos casos, diversos métodos são utilizados. Alguns destes mecanismos são:

Vinculação Padrão: Os mapeamentos são predefinidos por um vínculo padrão de classes Java no schema XML. Cada classe Java tem uma única representação no schema XML. Este mecanismo é descrito pelas seguintes especificações: JAXB e JAX-WS.

Anotação do Código-Fonte: JWS usa esta abordagem para fornecer a customização da vinculação padrão. Anotar o código-fonte de uma classe Java modifica o mapeamento no schema XML, e também, como a descrição do WSDL é moldado. Esta é a forma mais simples e utilizada atualmente.

Algoritmo: Os mapeamentos são embutidos em algoritmos executados por um sistema de serialização. JAX-RPC e Axis utilizam este método.



Baseado em Regras: Os mapeamentos são especificados como regras que podem ser criadas e editadas independente do sistema de serialização. As regras são interpretadas pelo sistema de serialização. SOA-J usa este método de mapeamento.

Cada uma destas abordagens têm vantagens e desvantagens. O JWS introduziu as anotações no código-fonte como um mecanismo de facilitar aos programadores a especificar como o Java deverá ser representado na descrição do WSDL.

A serialização, como processo fundamental dos web services, gera uma grande carga na sua execução, o que pode ser apontada como uma desvantagem ao uso dos web services. Nos tráfegos de grandes quantidades de informação via web services é facilmente identificado o elevado tempo de resposta das informações.



Exercícios

1. Como você vê os web services auxiliando nos processos de integração na empresa em que trabalha?

2. Cite 03 benefícios 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 integração de software legado? Explique.


Java Web Services

4.4. Criando Web ServicesCriando Web Services


Web Services

Objetivos Compreender as necessidades básicas para criação dos web services. Identificar o formato de publicação de web services. Conhecer o desenvolvimento dos web services em diferentes API’s.


Web Services

Necessidades básicas

A seguir são consideradas as ferramentas e API’s necessárias para o desenvolvimento de web services e para execução dos exercícios propostos pela apostila. Lembrete: nem todos os arquivos JAR (que compõe as API’s) são utilizados pelo projeto que estará em estudo.

IDE (Integrated Development Environment)

Hoje existem diversas IDE’s utilizadas no desenvolvimento do Java. Muitas delas facilitam muito a criação de web services, tanto na criação e publicação do serviço quanto na criação de clientes de acesso.

Trabalharemos nesta apostila com duas das IDE’s 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 mínimo de experiência na sua utilização. E ambas são freeware, isto é, tem seu uso e distribuição gratuito.

soapUI

soapUI (http://www.soapui.org/) é uma ferramenta de código aberto escrita em Java cuja principal função é consumir e testar web services. É considerada a ferramenta líder neste segmento, com mais de 2 milhões de downloads, é a mais utilizada para testes SOA no mundo.

Este software requer um detalhamento maior, visto que para que os exercícios desta apostila sejam bem testados e compreendidos, faz-se necessário entender o funcionamento da ferramenta soapUI. Ela será a responsável por fazer as chamadas de REQUEST e RESPONSE a um web service. Permitindo assim, que sejam feitas requisições sem o uso de uma API cliente de web service.

A seguir, têm-se as telas básicas de configuração para criação de chamadas a um serviço deste software:


Web Services

Tela inicial do software

Adicionando um serviço - WSDL

Resultado esperado; serviço e suas operações


Web Services

Fazendo chamada a uma operação (SOAP)

Analisando resposta à chamada realizada (SOAP)


Web Services

Apache Tomcat

O Apache Tomcat (http://tomcat.apache.org/) é uma implementação de software de código aberto para as tecnologias de Java Servlet e JavaServer Pages. Está em produção hoje em larga escala, em aplicações web de missão crítica em uma grande diversidade de indústrias e organizações.

Apache OpenEJB

Apache OpenEJB (http://openejb.apache.org/) é uma implementação 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 aplicação. OpenEJB está incluído no Apache Geronimo, IBM WebSphere Application Server CE, e no Apple's WebObjects.


Web Services

JAX-WS

Descrição

O Java API for XML Web Services (https://jax-ws.dev.java.net/) é uma API Java para criação de web services. Faz parte da plataforma do Java EE da Sun Microsystems. Como as outras API’s do Java EE, JAX-WS usa anotações, 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 resolver.jarFastInfoset.jar jaxws-tools.jar saaj-api.jar

gmbal-api-only.jar jsr173_api.jar saaj-impl.jarhttp.jar jsr181-api.jar stax-ex.jar

jaxb-api.jar jsr250-api.jar streambuffer.jarjaxb-impl.jar management-api.jar woodstox.jarjaxb-xjc.jar mimepull.jar

jaxws-api.jar policy.jar

Arquitetura

Segue a estrutura dos arquivos básicos necessários e a sua descrição:


Web Services

Mensagem.java e OlaMundo.java

Classes Java que contém as regras de negócio do web service.

web.xml

Configuração do mapeamento do servlet WSServlet para a URL do serviço.

sun-jaxws.xml

Mapeamento dos endpoints, suas URL’s e classe Java de implementação.

build.xml

XML Apache Ant responsável pelo deploy da aplicação.

Construção 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, poderão ser conferidas através da página index.jsp disponível no projeto. Para este exemplo, será utilizada a IDE Eclipse e o instrutor fornecerá o projeto a ser importado – ws-jaxws-tomcat.

OlaMundo.java@WebServicepublic class OlaMundo {

@WebMethodpublic String ola(String nome) {

return "Olá, " + nome;}

}


Web Services

Mensagem.java@WebServicepublic class Mensagem {

private static ArrayList<Properties> lista;

public Mensagem() {lista = new ArrayList<Properties>();

}

@WebMethodpublic 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/javaeehttp://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

<listener><listener-

class>com.sun.xml.ws.transport.http.servlet.WSServletContextListener</listener-class>

</listener>

<servlet><servlet-name>MinhaMensagem</servlet-name><servlet-

class>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><servlet-

class>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<?xml version="1.0" encoding="UTF-8"?><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>Página 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 serviços estão disponíveis para serem consumidos, podemos acessar o contexto criado ws-jaxws-tomcat (ex. http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl) e identificar se a página carrega sem erro. Se abrir corretamente, todos os serviços foram publicados e estão prontos para serem consumidos.

Para testarmos o funcionamento dos web services e o resultado das mensagens, utilizaremos os seguintes endereços de WSDL (esta sigla será discutida em um tópico próprio no decorrer desta apostila):


Web Services

Para que possamos testar as chamadas ao web service, utilizaremos a ferramenta soapUI, comentada em tópico anterior. O resultado esperado, ao se utilizar a operação adicionaMensagem (encontrada no serviço Mensagem) é demonstrado na figura abaixo:

Descrição básica das Annotations mencionadas

@WebService: Marca uma classe Java como implementação de Web Service. Utilizada na anotação em nível de classe.

@WebMethod: Customiza um método como sendo exposto como uma operação no Web Service. O método associado deve ser público e seus parâmetros retornando algum valor, e suas exceções devem seguir as regras definidas na JAX-RPC 1.1, seção 5. Utilizada na anotação em nível de método.

Parâmetros importantes desta anotação:

operationName: Define o nome da operação que será utilizada pelo executor

exclude: Marca um método como não exposto como uma operação no web service.

@WebParam: Customiza o mapeamento de um parâmetro individual a uma mensagem Web Service e a um elemento XML. Utilizada na anotação em nível de parâmetro de método.

Parâmetros importantes desta anotação:

name: Define o nome do parâmetro que será utilizado pelo executor

Para uma descrição 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 versão 6 do Java, ficou disponível a possibilidade de publicarmos um web service, sem a necessidade de um web container (ex. Apache Tomcat) T@rgetTrust Treinamento e Tecnologia 56

Web Services

ou de um application server. Isto, dependendo da necessidade e da funcionalidade necessária, 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@WebServicepublic class OlaMundo {



}

Servico.javapublic 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 operações expostas na classe de serviço OlaMundo. A operação ola, terá a simples funcionalidade de concatenar a string “Olá, “ ao parâmetro fornecido; como os outros exemplos vistos. Com apenas duas classes e uma linha de código, publica-se um web service e o torna disponível para aceitar chamadas.


Web Services

JAX-WS (via EJB)

Descrição

O Java API for XML Web Services (https://jax-ws.dev.java.net/) é uma API Java para criação de web services, conforme já descrito no tópico anterior. Veremos como utilizá-la através da publicação 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 publicação dos web services necessários.

Necessidades

API JAX-WS (via EJB) contendo os seguintes arquivos JAR:activeio-core-3.0.0-incubator.jar log4j-1.2.12.jar opensaml-1.1.jar

activemq-core-4.1.1.jar mysql-connector-java-3.1.11.jar quartz-1.5.2.jar

activemq-ra-4.1.1.jar neethi-2.0.4.jar saaj-impl-1.3.jarbackport-util-concurrent-2.1.jar openejb-api-3.1.2.jar serializer-2.7.1.jar

bcprov-jdk15-140.jar openejb-client-3.1.2.jar serp-1.13.1.jarcommons-cli-1.1.jar openejb-loader-3.1.2.jar slf4j-api-1.3.1.jar

commons-collections-3.2.jar xbean-finder-shaded-3.6.jar slf4j-jdk14-1.3.1.jarcommons-dbcp-all-1.3-

r699049.jar xbean-asm-shaded-3.6.jar stax-api-1.0.1.jar

commons-lang-2.1.jar openejb-core-3.1.2.jar swizzle-stream-1.0.1.jar

commons-logging-1.1.jar openejb-cxf-3.1.2.jar wsdl4j-1.6.1.jarcommons-pool-1.3.jar openejb-ejbd-3.1.2.jar wss4j-1.5.4.jarcxf-bundle-2.0.9.jar openejb-hsql-3.1.2.jar wstx-asl-3.2.0.jar

ejb31-api-experimental-3.1.2.jar openejb-http-3.1.2.jar xbean-naming-3.6.jar

geronimo-connector-2.1.jar openejb-javaagent-3.1.2.jar xbean-reflect-3.6.jargeronimo-javamail_1.4_mail-

1.2.jar openejb-jee-3.1.2.jar xml-resolver-1.2.jargeronimo-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.jarhsqldb-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 contém o “contrato” a ser exposto às chamadas via EJB (interface remota e local) e as quais as classes acima deverão implementar.

TesteEJB.java

Classe de teste para efetuar uma chamada via EJB aos métodos das classes.

openejb-jar.xml

Configuração das classes que devem ser expostas via EJB.

persistence.xml

Configuração dos datasources de conexão 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 funções básicas: adição, subtração, multiplicação, divisão 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@WebServicepublic class Calculadora implements CalculadoraIF {

private static final Logger logger = Logger.getLogger(Calculadora.class);

@WebMethodpublic Double adicao(@WebParam(name = "x") Double x, @WebParam(name =

"y") Double y) {logger.info("Método Adição");return x + y;

}

@WebMethodpublic Double subtracao(@WebParam(name = "x") Double x, @WebParam(name =

"y") Double y) {logger.info("Método Subtração");return x - y;

}

@WebMethodpublic Double multiplicacao(@WebParam(name = "x") Double x,

@WebParam(name = "y") Double y) {logger.info("Método Multiplicação");return x * y;

}

@WebMethodpublic Double divisao(@WebParam(name = "x") Double x, @WebParam(name =

"y") Double y) {logger.info("Método Divisão");return x / y;

}

@WebMethodpublic Double raizQuadrada(@WebParam(name = "x") Double x) {

logger.info("Método Raiz Quadrada");return Math.sqrt(x);

}

}


Web Services

OlaMundo.java@Stateless@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)@WebServicepublic class OlaMundo implements OlaMundoIF {

@WebMethodpublic String ola(@WebParam(name = "nome") String nome) {


}

CalculadoraIF.javapublic 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@Remotepublic interface OlaMundoIF {

String ola(@WebParam(name = "nome") String nome);

}

TesteEJB.javapublic class TesteEJB {

public static void main(String[] args) {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<?xml version="1.0" encoding="UTF-8"?><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>

openejb-jar.xml<?xml version="1.0" encoding="UTF-8"?><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 serviço, é necessário conhecer seus comandos básicos, conforme a seguir:

openejb-3.1.2\bin\openejb.bat start – Inicializa o OpenEJB, publicando todos os EJB’s.

openejb-3.1.2\bin\openejb.bat stop – Pára o OpenEJB.

openejb-3.1.2\bin\openejb.bat deploy [pacote_ejb.jar] – Faz o deploy dos EJB’s no OpenEJB, tornando-os ativos.

openejb-3.1.2\bin\openejb.bat undeploy [c:\caminho\completo\pacote_ejb.jar] – Faz o undeploy dos EJB’s 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 método estático main, da classe TesteEJB.

Web Services

Apache Axis

Descrição

Apache Axis (http://ws.apache.org/axis/) é uma implementação do protocolo SOAP. Ele isola o desenvolvedor dos detalhes de lidar com o SOAP e o WSDL. É um framework de código aberto, baseado na linguagem Java e no padrão XML, utilizado para construção de web services no padrão SOAP.

Necessidades

O deploy das classes do web service podem ser feitas diretamente no contexto padrão 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 conteúdo 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 característica interessante no uso do contexto padrão do Apache Axis, é a facilidade na publicação de web services. No exemplo da classe OlaMundo, bastaria renomearmos o código-fonte .java para .jws, e copiá-lo para o contexto do Axis. Isto faria com que o Axis compilasse a classe em tempo de execução, e disponibilizasse o web service automaticamente.@WebServicepublic class OlaMundo {



}

Para verificarmos se o serviço está disponível para ser consumido, podemos acessar o contexto do Apache Axis criado - axis (ex. http://localhost:8080/axis/) - e identificar se a página carrega sem erro. Se abrir corretamente (conforme imagem a seguir), o contexto do axis está no ar.


Web Services

Após 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 endereço, em inglês):

O teste da execução da operação 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

Descrição

Codehaus XFire (http://xfire.codehaus.org/) é um framework SOAP para linguagem Java. Codehaus XFire simplifica o desenvolvimento orientado a serviços através da facilidade do uso da sua API.

Necessidades

API do Codehaus XFire contendo os seguintes arquivos JAR:

activeio-core-3.0.0-incubator.jar

geronimo-transaction-2.1.jar openejb-ejbd-3.1.2.jar

activemq-core-4.1.1.jar howl-1.0.1-1.jar openejb-hsql-3.1.2.jaractivemq-ra-4.1.1.jar hsqldb-1.8.0.7.jar openejb-http-3.1.2.jar

backport-util-concurrent-2.1.jar javaee-api-5.0-2.jar openejb-javaagent-

3.1.2.jarbcprov-jdk15-140.jar jaxb-impl-2.0.5.jar openejb-jee-3.1.2.jarcommons-cli-1.1.jar log4j-1.2.12.jar openejb-multicast-

3.1.2.jarcommons-collections-

3.2.jarmysql-connector-java-

3.1.11.jaropenejb-server-

3.1.2.jarcommons-dbcp-all-1.3-

r699049.jar neethi-2.0.4.jar openejb-telnet-3.1.2.jar

commons-lang-2.1.jar openejb-api-3.1.2.jar openejb-webservices-3.1.2.jar

commons-logging-1.1.jar openejb-client-3.1.2.jar openjpa-1.2.1.jarcommons-pool-1.3.jar openejb-loader-3.1.2.jar opensaml-1.1.jarcxf-bundle-2.0.9.jar xbean-finder-shaded-

3.6.jar quartz-1.5.2.jarejb31-api-experimental-

3.1.2.jarxbean-asm-shaded-

3.6.jar saaj-impl-1.3.jargeronimo-connector-2.1.jar openejb-core-3.1.2.jar serializer-2.7.1.jar

geronimo-javamail_1.4_mail-1.2.jar openejb-cxf-3.1.2.jar serp-1.13.1.jar

slf4j-api-1.3.1.jar swizzle-stream-1.0.1.jar wstx-asl-3.2.0.jarslf4j-jdk14-1.3.1.jar wsdl4j-1.6.1.jar xbean-naming-3.6.jarstax-api-1.0.1.jar wss4j-1.5.4.jar xbean-reflect-3.6.jar

xml-resolver-1.2.jar XmlSchema-1.4.2.jar xmlsec-1.4.0.jar

Arquitetura

Segue a estrutura dos arquivos básicos necessários e a sua descrição:T@rgetTrust Treinamento e Tecnologia 66

Web Services

OlaMundo.java


OlaMundoIF.java

Interfaces Java que contém o “contrato” a ser exposto às chamadas via web service e as quais as classes acima deverão implementar.

services.xml

Arquivo de configuração contendo o mapeamento das classes e interfaces responsáveis pela publicação dos web services.

web.xml

Configuração do mapeamento do servlet XFireConfigurableServlet para a URL do serviço.

build.xml


index.jsp

Página de teste para conferência da publicação do contexto utilizando o XFire. Na maioria dos problemas de publicação dos serviços via XFire, o contexto web não fica disponível em caso de erro. Daí, uma simples página 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.javapublic class OlaMundo implements OlaMundoIF {

public String ola(String nome) {return "Olá, " + nome;

}

}

OlaMundoIF.javapublic 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><servlet-

class>org.codehaus.xfire.transport.http.XFireConfigurableServlet</servlet-class>

</servlet>

<servlet-mapping><servlet-name>XFireServlet</servlet-name><url-pattern>/servlet/XFireServlet/*</url-pattern>

</servlet-mapping>

<servlet-mapping><servlet-name>XFireServlet</servlet-name><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>

Página ok!</body>

</html>

Para verificarmos quais serviços estão disponíveis 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 serão listados os serviços e o link para o WSDL que levará a criação da chamada às operações (ex. http://localhost:8080/ws-xfire/services/OlaMundo?wsdl).

Através do WSDL informado anteriormente, a operação ola pode ser executada através da ferramenta soapUI, o que resultará na concatenação da string “Olá, “ ao parâmetro fornecido.


Web Services

Exercícios

1. Escolha uma implementação utilizada por este tópico e crie um web service com as seguintes operações:

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 lança uma exceção RuntimeException caso o logon falhe

c) informa salário (do tipo Double), e calcula e retorna o valor correspondente do INSS, conforme tabela a seguir:

Salário Descontoaté R$ 1.040,22 8%

de R$ 1.040,23 a R$ 1.733,70 9%de R$ 1.733,71 até R$ 3.467,40 11%

Acima de R$ 3.467,40 o desconto é de R$ 381,41.

2. Teste todas as operações que você criou utilizando a ferramenta soapUI.


Web Services



Java Web Services

5.5. Criando clientes de WebCriando clientes de Web ServiceService


Criando Web Services

Objetivos Compreender que são os clientes de web service. Conhecer as possibilidades de uso do WSDL. Identificar as formas de criação automáticas de clientes de web service.



O que são clientes de web services?

Web services leva os clientes web a um nível elevado de maturidade. Desenvolvedores podem construir melhores clientes, muito mais poderosos, os quais interagem com web services proporcionando uma experiência riquíssima. Neste ambiente, os desenvolvedores do cliente não precisam ter controle sobre o lado do servidor de uma aplicação, e mesmo assim eles ainda podem escrever poderosos aplicativos.

Os clientes podem aproveitar os web services para obter uma ampla variedade de funções ou serviços. Para um cliente, um web service é uma caixa preta: o cliente não precisa conhecer como o serviço é implementado ou mesmo quem o presta. O cliente em primeiro lugar se preocupa com a funcionalidade do serviço fornecido pelos web services. Vários clientes rodando em diferentes tipos de plataformas podem acessar esses web services normalmente.

Uma das razões principais para implementação de web services é alcançar a interoperabilidade. Os clientes podem acessar web services, independente da plataforma ou do sistema operacional em que o serviço foi construído. A implementação é completamente independente do serviço.

Em resumo, um cliente para web services nada mais é do que um componente que “sabe conversar” através 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 comunicação que consiga fazer um POST via HTTP para um endereço de serviço 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 métodos a serem chamados, quais parâmetros a serem passados? Como os clientes sabem como processar uma requisição?

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, operações, esquemas de codificação, entre outros neste documento.

Um documento WSDL define um XML Schema para descrever um web service.

Tão logo o cliente tenha acesso à descrição do serviço a ser utilizado, a implementação do web service pode ser feita em qualquer linguagem de programação. Normalmente são utilizadas linguagens construídas para interação 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 obtém a descrição do serviço (através da localização do respectivo documento WSDL; sua URL), e em seguida constrói a mensagem, passando os tipos de dados corretos (parâmetros, etc) de acordo com a definição encontrada no documento. Em seguida, a mensagem é enviada para o endereço onde o serviço está localizado – novamente sua URL, a fim de que possa ser processada. O web service, quando recebe esta mensagem faz a sua validação conforme as informações contidas no documento WSDL. A partir de então, o serviço remoto sabe como tratar a mensagem, sabe como processá-la (request) e como montar a resposta ao cliente (response).

Partindo-se então desta introdução sobre o WSDL, podemos prever que é possível, a partir da sua descrição, reconhecer como fazer uma chamada às operações do serviço, logo, é possível automatizar a criação de clientes para web services.

Um software que seja capaz de interpretar a descrição do WSDL e transformá-lo em código-fonte é capaz de gerar clientes automaticamente. E é isto que iremos ver no decorrer desta apostila.

As API’s que implementam os web services, tratando agora dos serviços, são as responsáveis por transformar a semântica aplicada às classes expostas e/ou mapeadas em uma descrição WSDL.

A maioria das API’s que expõe web services fornecem também uma forma de visualizarmos o XML do WSDL. Geralmente, seu acesso se dá através da URL do serviço acrescida de ?wsdl, conforme exemplo abaixo:



http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl

Observação: o navegador Chrome, do Google, não exibe XML. Logo, não mostraria o conteúdo do WSDL.



Eclipse IDE como cliente de web service

Como vimos, a ferramenta soapUI facilita os testes relacionados às execuções de operações nos web services. Fazendo com que se tenha a certeza do funcionamento do serviço. O Eclipse IDE também tem uma funcionalidade similar, que é pouco conhecida dos desenvolvedores.

Nas figuras a seguir, será demonstrada a sua utilização para o exemplo de chamada ao web service que foi implementado pelo projeto ws-jaxws-tomcat.

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 (penúltimo 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 operação a ser testada (no caso, adicionaMensagem)



Passo 6: Através dos links Add, adicionar os conteúdos aos parâmetros solicitados (no caso, remetente e mensagem) e clicar em Go

Então, será executada a operação desejada, e os resultados (XML SOAP de resposta) serão mostrados na aba Status, logo abaixo a tela de execução.



Geradores de cliente automáticos

Fixando conceitosComo o WSDL serve como um descritor dos web services, suas operações, seus parâmetros e os tipos de dados que deverão ser utilizados, fica mais fácil a geração de classes pelos geradores automáticos de clientes. Estes interpretam o descritor e geram as classes de forma semântica, contendo por exemplo, métodos com o mesmo nome das operações encontradas nas operações do web service.

Resumindo: os clientes criam uma representação em forma de classes das chamadas aos web services, abstraindo todo o tráfego do XML e as chamadas de HTTP.

Todos os exemplos de criação utilizados a seguir na apostila, farão uso do web service exposto através do projeto ws-jaxws-tomcat.

JAX-WSJá embutido na JDK do Java 6, o gerador automático de cliente fica em um arquivo chamado wsimport.exe localizado na pasta bin de instalação da JDK. Este arquivo não tem interface gráfica para sua execução, isto é, costuma ser utilizado através do Prompt do MS-DOS, mas existem ferramentas que o utilizam para criação de clientes, o executando em background – exemplo do soapUI, conforme figura a seguir.



Uma vantagem no uso deste método é que ele é nativo da versão 6 do Java, não precisando de outras dependências JAR.

Para criarmos o cliente, partimos do princípio 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 códigos-fonte do projeto que receberá as classes criadas; geralmente [nome do projeto]/src (ex. d:\meusprojetos\TesteCliente\src)

Passo 3: Executar o comando de criação das classes cliente

wsimport -keep -p com.tt.meucliente http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl



Onde,

-keep: mantém os arquivos-fonte gerados (se não utilizada este parâmetro, o cliente é criado apenas com os códigos-fonte já compilados; bytecodes)

-p com.tt.meucliente: package onde as classes serão criadas

http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl: URL do descritor WSDL



Passo 4: Conferir os arquivos criados, conforme refresh no projeto do Eclipse, a seguir na imagem:

JAX-WS: Consumindo o ServiçoNo quadro abaixo, é apresentado um código-fonte que faz uso destas classes para executar a operação adicionaMensagem.

public class TesteWebservice {public static void main(String[] args) {

Mensagem ws = new MensagemService().getMensagemPort();ws.adicionaMensagem("João da Silva", "Envio de mensagem via

Netbeans IDE");}

}



Apache Axis 1.x

A geração automática de um cliente utilizando o Apache Axis 1.x é feita através 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 axis-1_4\lib)


java -classpath .;axis.jar;commons-logging-1.0.4.jar;jaxrpc.jar;log4j-1.2.8.jar;saaj.jar;wsdl4j-1.5.1.jar;commons-discovery-0.2.jar;axis-ant.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 necessários para criação do cliente

org.apache.axis.wsdl.WSDL2Java: Classe do Apache Axis 1.x responsável pela criação do cliente


http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl: URL do descritor WSDL

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 ServiçoNo quadro abaixo, é apresentado um código-fonte que faz uso destas classes para executar a operação adicionaMensagem. Notamos que este é diferente do criado via wsimport.

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

Mensagem ws = new MensagemServiceLocator().getMensagemPort();ws.adicionaMensagem("João da Silva", "Envio de mensagem via

Netbeans IDE");}

}



Apache Axis 2.x

A geração automática de um cliente utilizando o Apache Axis 2.x é feita através 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 axis2-1.5.1\bin)


wsdl2java.bat -u -p com.tt.meucliente –uri http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl

Onde,

-u: Desacopla da classe de stub as classes necessárias para a representação das operações e parâmetros do web service; se não informado, todas as classes tornam-se inner classes da stub.


–uri http://localhost:8080/ws-jaxws-tomcat/mensagem?wsdl: URL do descritor WSDL

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 ServiçoNo quadro abaixo, é apresentado um código-fonte que faz uso destas classes para executar a operação adicionaMensagem. Notamos que este é diferente do criado via wsimport e muito diferente daquele criado na versão 1.x do próprio Axis.public class TesteWebservice {

public static void main(String[] args) throws Exception {AdicionaMensagemE mensagem = new AdicionaMensagemE();

AdicionaMensagem param = new AdicionaMensagem();param.setRemetente("João da Silva");param.setMensagem("Envio de mensagem via Netbeans IDE");

mensagem.setAdicionaMensagem(param);

new MensagemServiceStub().adicionaMensagem(mensagem);}

}



Netbeans IDEO Netbeans IDE possui a funcionalidade de criação de cliente de web service nativamente. Através das figuras a seguir, será demonstrada a criação 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 serão armazenadas

Estando o serviço no ar, o Netbeans irá criar uma estrutura similar a apresentada a seguir:

Onde podemos identificar as classes para acesso aos serviços e operações do web service.



Netbeans IDE: Consumindo o ServiçoNo quadro abaixo, é apresentado um código-fonte que faz uso destas classes para executar a operação adicionaMensagem.

public class TesteWebservice {public static void main(String[] args) {

Mensagem ws = new MensagemService().getMensagemPort();ws.adicionaMensagem("João da Silva", "Envio de mensagem via

Netbeans IDE");}

}

Podemos identificar que o código-fonte do cliente utilizado para consumir o serviço pelo Netbeans é o mesmo do criado pelo comando wsimport. Ambos utilizam-se da mesma engine de criação.



Exercícios

1. Crie um cliente para o web service solicitado no exercício do tópico anterior. Seria interessante também, que você criasse uma interface web (JSP) para envio e recebimento dos dados do serviço. Assim, ficará clara a comunicação e o mecanismo necessário entre o cliente e a interface com o serviço.


Java Web Services

6.6. Comunicação via SOAPComunicação 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 aplicações troquem informações através do protocolo HTTP. Ou mais simplesmente: SOAP é um protocolo para acessar um web service.

Algumas considerações importantes:

SOAP significa Simple Object Access Protocol SOAP é um protocolo de comunicação SOAP é para comunicação entre aplicações SOAP é um formato para envio de mensagens SOAP comunica-se via Internet SOAP é independente de plataforma SOAP é independente de linguagem SOAP é baseado em XML SOAP é simples e extensível SOAP permite contornar firewalls SOAP é uma recomendação da W3C



Por que SOAP?

É importante para o desenvolvimento de aplicações permitir a comunicação 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 não foi projetado para isso. RPC representa um problema de compatibilidade e segurança; firewalls e servidores proxy normalmente bloqueiam este tipo de tráfego.

A melhor maneira de se comunicar entre as aplicações é através de HTTP, como o HTTP é suportado por todos os navegadores de internet e servidores. SOAP foi criado com este propósito.

SOAP provê uma forma de comunicação entre aplicações rodando em diferentes sistemas operacionais, com diferentes tecnologias e linguagens de programação.



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 cabeçalho opcional que contém informações de

chamadas e repostas Um elemento de falha opcional que prove informação 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/soap-encoding">

<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 contém dois elementos filhos, um <Header> opcional e um <Body> obrigatório.

SOAP header

O SOAP <Header> é um sub-elemento opcional do envelope SOAP, e é usado para repassar informações relacionadas à aplicação que devem ser processadas pelos nós do SOAP ao longo do caminho da mensagem.

SOAP body

O SOAP <Body> é um sub-elemento obrigatório do envelope SOAP, que contém informações necessárias para o destinatário final da mensagem.



O elemento <Body> e seus elementos filhos associados são usados para troca de informações 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> são 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 básica da mensagem de falha é definida nas especificações SOAP. Cada mensagem de erro pode incluir um XML que descreve a condição de erro específica. Por exemplo, se um erro anormal ocorrer na aplicação 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 parâmetro StockName e um parâmetro de Price, que serão devolvidos na resposta. O namespace para a função é definido em http://www.example.org/stock.

O SOAP RequestPOST /InStock HTTP/1.1Host: www.example.orgContent-Type: application/soap+xml; charset=utf-8Content-Length: nnn

<?xml version="1.0"?><soap:Envelopexmlns:soap="http://www.w3.org/2001/12/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 ResponseHTTP/1.1 200 OKContent-Type: application/soap+xml; charset=utf-8Content-Length: nnn

<?xml version="1.0"?><soap:Envelopexmlns:soap="http://www.w3.org/2001/12/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>


http://www.example.org/stock


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 através ou não de um web service. O SAAJ nos permite trocar mensagens XML na plataforma Java. Simplificando as chamadas de métodos poderemos ler e escrever mensagens SOAP baseadas em XML, e poderemos mandá-las ou recebê-las através da Internet.

Apresentaremos agora uma visão de alto-nível sobre como o SAAJ trabalha e explicaremos alguns conceitos gerais.

MensagensAs mensagens transitadas pelo SAAJ seguem os padrões do SOA, que descrevem o formato das mensagens e especificam tudo o que é obrigatório, opcional e não permitido.

Estrutura do XMLUm documento XML tem uma estrutura hierárquica feita por elementos e sub-elementos de vários níveis. Um elemento é também 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 anexosA figura a seguir mostra uma visão superficial da estrutura de uma mensagem SOAP sem anexos. Com exceção do SOAP header, todas as partes listadas são obrigatórias nas mensagens SOAP.



Todos os elementos da figura (SOAPMessage, SOAPPart, SOAPHeader, SAOPBody) têm suas respectivas classes ou interfaces no SAAJ. Quando criamos um objeto do tipo SOAPMessage, ele terá automaticamente todas as partes obrigatórias 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, informações sobre envio e recebimento de partes da mensagem. O objeto SOAPBody, que é obrigatório sempre, contém o conteúdo da mensagem. Se existir um objeto SOAPFault, que representa um possível erro, ele deve estar inserido dentro de um objeto SOAPBody.

Mensagem com anexosUma mensagem SOAP pode conter um ou mais anexos no SOAPPart, que por sua vez deve conter apenas um conteúdo XML, portanto, se qualquer conteúdo da mensagem não está em formato de XML, deve ser um anexo. A figura a seguir mostra o conteúdo de uma mensagem SOAP com anexos.



O SAAJ contém 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 são 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 cabeçalho MIME que indica que tipo de dato o anexo contém. Ele deve ter também cabeçalhos MIME adicionais para identificá-lo ou contendo uma referência de sua localização. Esses cabeçalhos são opcionais, mas podem ser úteis quando trabalhamos com muitos anexos. Quando temos anexos em um objeto SOAPMessage, seu objeto SOAPPart pode ou não ter conteúdo.

ConexõesTodas as mensagens são enviadas ou recebidas através de uma conexão. Com o SAAJ, a conexão é representada pelo objeto SOAPConnection, que vai do remetente até o destinatário. Esse tipo de conexão é 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 são chamadas request-response. Elas são enviadas através da chamada ao método call de um objeto SOAPConnection, que envia uma mensagem (request) e fica bloqueado até receber a resposta (response).



O trecho de código abaixo cria um objeto SOAPConnection e, depois de criar e popular a mensagem, o usa para enviá-la. Depois da chamada do método call que envia a requisição o retorno do método é a mensagem SOAP de resposta.

SOAPConnection connection = null;try {

SOAPConnectionFactory soapConnectionFactory = SOAPConnectionFactory.newInstance();

connection = soapConnectionFactory.createConnection();} catch (UnsupportedOperationException e1) {

throw new RuntimeException("Operação não 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 método 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 disponível, isto é, seu deploy tenha sido realizado. Para identificarmos se o serviço Calculadora está no ar, publicado através do OpenEJB, podemos acessar a seguinte URL http://localhost:4204/Calculadora?wsdl.

No código-fonte a seguir, faremos uma chamada ao serviço descrito no parágrafo anterior, na sua operação raizQuadrada. A chamada ocorrerá diretamente na console do Eclipse IDE, e será possível identificarmos o XML de request e de response, assim como, o resultado do cálculo.

public class TesteComunicacao {

private String address = "http://localhost:4204/Calculadora";private String targetNamespace = "http://webservice.tt.com/";private String requestMethodName = "raizQuadrada";private String testParameter = "4.0";

public void sendMessage() throws Exception {// Criando a mensagemSOAPMessage message = getRequestMessage();// Criando a factory de conexãoSOAPConnectionFactory soapConnectionFactory =

SOAPConnectionFactory.newInstance();// Obtendo a conexão da factorySOAPConnection connection =

soapConnectionFactory.createConnection();// Enviando a mensagemSOAPMessage response = connection.call(message, address);System.out.println("\n\nEnviado (request): " + testParameter + ",

Recebido (response): " + processaResponse(response));connection.close();

}

private SOAPMessage getRequestMessage() throws Exception {// Criando a factoryMessageFactory factory = MessageFactory.newInstance();// Criando a mensagem a partir da factorySOAPMessage message = factory.createMessage();// Pegando o SOAPPartSOAPPart part = message.getSOAPPart();// Pegando o SOAPEnvelopeSOAPEnvelope envelope = part.getEnvelope();// Pegando o SOAPHeaderSOAPHeader soapHeader = envelope.getHeader();// Pegando o SOAPBodySOAPBody body = envelope.getBody();// Eliminando o headersoapHeader.detachNode();// Criando o conteúdoQName bodyName = new QName(targetNamespace, requestMethodName,

"m");SOAPBodyElement bodyElement = body.addBodyElement(bodyName);



SOAPElement symbol = bodyElement.addChildElement("x"); // parâmetrosymbol.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();// Conteúdoresult.append(element.getTextContent());

}return result.toString();

}

public static void main(String args[]) throws Exception {new TesteComunicacao().sendMessage();

}

}

A seguir, a saída 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 construção da chamada SOAPAs chamadas a um serviço diretamente através da construção do código-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 serviço.



Muitas vezes, clientes automáticos de geração de clientes para web services, não são satisfatórios no código gerado. E as vezes, não conseguem interpretar o WSDL para gerar as classes corretamente. É aí que entra a facilidade de construirmos uma chamada direto através do código-fonte, utilizando o SOAP.

Uma dica importante para identificar como a chamada e a leitura da resposta ao web service deve ser construída é utilizarmos a ferramenta soapUI como auxiliar neste processo. Como vimos até aqui, esta ferramenta interpreta como deve ocorrer a chamada de request para a operação no web service configurado, e a partir desta identificação, ela permite que façamos testes com preenchimento de parâmetros necessários à operação. 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 serviço Calculadora e a operação raizQuadrada, como visto no tópico anterior:

Podemos identificar perfeitamente que será executada a operação chamada raizQuadrada, e que o parâmetro x está preenchido com o inteiro 9. Podemos identificar também, um pouco deslocado no XML o namespace xmlns:web="http://webservice.tt.com/".

Ao executarmos a operação, 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 parâmetro x=9, informado na chamada request.

Logo, se precisássemos criar um cliente para chamada a este serviço, onde fosse necessário ler o retorno, poderíamos 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();

SOAPConnectionFactory soapConnectionFactory = SOAPConnectionFactory.newInstance();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 CÁLCULO: " + resultado);} catch (Exception e) {

throw new RuntimeException(e);}



Exercícios

1. Qual a linguagem de marcação utilizada pelo protocolo SOAP? Qual é a vantagem desta utilização?

2. Quais os elementos da estrutura de uma mensagem SOAP?

3. Qual o benefício no uso do protocolo SOAP para questões 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 à operação de cálculo de INSS sem o uso de criação automática de m cliente para o web service. Utilize para isto chamadas SOAP.


Java Web Services

7.7. Segurança com WebSegurança com Web ServicesServices


Comunicação via SOAP

Objetivos Conhecer aspectos de segurança relacionados com web services. Compreender as alternativas e especificações atuais.



Introdução

No momento, a arquitetura orientada a serviços encontra-se no radar de muitos gerentes de TI, e um número maior de empresas passam a dedicar cada vez mais recursos ao SOA. Se a SOA é a arquitetura, os web services são os blocos de construção. Desta forma, web services estão em destaque no mundo da computação distribuída como uma tecnologia que resolve os problemas de interoperabilidade dos sistemas. Porém, por possuir uma infraestrutura pública oferece, também, uma maior preocupação relacionada à segurança.

Este tópico pretende demonstrar o funcionamento de web services seguros utilizando a tecnologia Java abordando conceitos da arquitetura orientada a serviços. Para tornar um web service seguro você deve criptografar a comunicação, e existem duas maneiras de se fazer isso: garantir a segurança ao nível de transporte e em nível de XML.



Segurança em web service

Os mecanismos de segurança dos web services ainda estão sendo discutidos. O SOAP, por exemplo, não define um mecanismo para autenticação de uma mensagem antes do seu processamento. Como solução é implementada a segurança nos canais de transmissão usados para trocar as mensagens SOAP, utilizando o HTTP com o SSL (Secure Socket Layer) ou as VPNs (Virtual Private Networks). Também estão sendo desenvolvidos alguns mecanismos para manter a segurança 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 serviços de segurança.

Um fator importante que deve ser considerado para a utilização dos web services é que eles normalmente são 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 tráfego de fora para dentro, e bloqueia aquilo que não esteja autorizado, mas a porta 80 usualmente é deixada com pouca proteção. Enquanto a CORBA e a Java RMI são utilizadas em outras portas e têm o seu acesso dificultado, os web services têm a vantagem de passar livremente pelo firewall, mas isto também pode se configurar em uma desvantagem se o web service não implementar nenhuma funcionalidade de segurança.

Os web services simplificaram as comunicações, mas também alteraram algumas medidas de segurança existentes. Então, o desafio agora é definir um modelo de segurança que demonstre como os dados podem ser transportados através da aplicação e da rede de acordo com os requisitos especificados pelo negócio sem expor os dados a um risco inadequado.

Segurança em nível de transporteSegurança em nível de transporte significa proteger o protocolo de rede que o web service utiliza para se comunicar. O Secure Sockets Layer (SSL) é um protocolo padrão para criptografar comunicações sobre TCP/IP. Neste modelo, um cliente abre um socket seguro para um web service e então o utiliza para trocar mensagens SOAP via HTTPS. A implementação de SSL garante segurança criptografando todo o tráfego de rede sobre o socket.



Segurança em nível de XMLPor sua vez, segurança em nível de XML envolve a criptografia e descriptografia de documentos XML. O World Wide Web Consortium (W3C), o qual mantém o padrão XML, tem criado grupos de trabalhos para definir padrões para segurança em XML, incluindo assinaturas digitais, criptografia e gerenciamento de chaves para XML. O padrão mais utilizado para implementação de segurança em web services é o WS-Security.



Questões a serem consideradas

Segurança é fácil de se implementar utilizando a tecnologia Java EE, e oferece um bom nível de controle de acesso as funcionalidades da aplicação e seus dados. Entretanto, o que é inerente à segurança aplicada na camada de aplicação, propriedades de segurança não são transferíveis a outras aplicações rodando em outros ambientes e somente protegem os dados enquanto eles residem no ambiente da aplicação. No contexto de uma aplicação tradicional, isso não é necessariamente um problema, mas quando aplicado ao contexto de web services, os mecanismos de segurança do Java EE provém apenas uma solução parcial.

As características de um web service fazem sua segurança precisar de algo diferente do que a aplicada a outras aplicações são as seguintes:

Perda de acoplamento entre o provedor e o consumidor do serviço Uso de mensagens XML e metadata Foco em prover interoperabilidade Independência de linguagem e plataforma Variedade de protocolos de transporte que podem ser usados Possibilidade de passagem por vários hosts entre o provedor e o cliente

Algumas características dos web services os tornam especialmente vulneráveis a ataques de segurança. São algumas delas:

Operações são feitas através da internet utilizando protocolos amigáveis a firewalls

A comunicação é iniciada pelos clientes que não tem nenhuma relação com o provedor

A mensagem é no formato texto

Além disso, a natureza dos web services distribuídos, suas interações e dependências poderão exigir uma maneira padrão de propagar identidade e confiança entre a aplicação e seus domínios.

Existem vários aspectos bem definidos de segurança de aplicação, que quando bem utilizados, ajudam a minimizar os riscos. Entre eles estão autenticação, autorização, integridade e confidencialidade, entre outros.



Vantagens da segurança na camada de mensagem

Antes de entrarmos na questão da segurança de mensagem, é importante entender porque a segurança na camada de transporte não é sempre suficiente para prover a segurança necessária a um web service. A segurança na camada de transporte é provida por mecanismos de transporte utilizados para transmitir a informação entre clientes e provedores de serviço, assim a segurança nessa camada baseia-se no transporte seguro via HTTP (HTTPS) utilizando Secure Sockets Layer (SSL). Segurança no transporte é um mecanismo de segurança ponto a ponto que pode ser utilizado para autenticação, integridade da mensagem e confidencialidade. Quando rodando em uma sessão protegida por SSL, provedor e cliente podem autenticar um ao outro e negociar um algorítimo e chaves para criptografia da mensagem antes de sua transmissão.

A segurança vai desde o momento em que a mensagem deixa o cliente até sua chegada no servidor, ou vice-versa, até mesmo entre intermediários. O problema é que não há mais proteção uma vez chegada no destino. Uma solução é criptografar a mensagem antes de enviá-la.

Na segurança da camada de mensagem, a informação de segurança é trafegada dentro da mensagem SOAP ou em um anexo da mensagem.

As vantagens da segurança na camada de mensagem são:

A segurança permanece na mensagem de uma ponta a outra mesmo passando por vários intermediários

Pode ser aplicada em diferentes partes da mensagem, inclusive seus anexos

Pode ser utilizada em conjunto com diferentes intermediários através de vários hosts

É independente do ambiente da aplicação e do protocolo de transporte

A desvantagem em se utilizar esse tipo de segurança é a relativa complexidade de implementação e o tempo de processamento que se perde ao aplicá-la.



Especificações e iniciativas atuais

As organizações listadas a seguir trabalham em especificações de segurança para web services, orientações 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 especificações relacionadas à segurança em web services. WS-I cria padrões que indicam o que implementar de várias especificações e prove uma direção sobre como implementar as especificações.

Especificações 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 terão resultado a longo prazo. W3C desempenha seu papel, através da criação de padrões web e orientações.

O W3C trabalha sobre as seguintes especificações relacionadas aos web services e segurança:

XML Encryption (XML-Enc): Essa especificação 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 compilação para XML representando uma assinatura de recursos web, partes de mensagens de protocolos e procedimentos para computação e verificação dessas assinaturas.

XML Key Management Specification (XKMS): Especifica protocolos para distribuição e registro de chaves públicas, adequado para o uso em conjunto com as recomendações da W3C para XML-Signature e XML-Encryption.



Especificações OASIS De acordo com seu site em http://www.oasis-open.org/, o OASIS impulsiona o desenvolvimento e a convergência, bem como a adoção de normas para e-business.

O OASIS trabalha sobre as seguintes especificações relacionadas à segurança em web services:

Web Services Security (WSS): Segurança em mensagens SOAP. Essa especificação descreve acessórios para promover integridade, confidencialidade e autenticação nas mensagens, acolhendo uma grande variedade de tecnologias e modelos de segurança e criptografia. Esta especificação também define um mecanismo para associar tokens de segurança com conteúdos de mensagens, assim como codificar tokens binários de segurança, bem como incluir chaves criptografadas ocultas na mensagem.

Security Assertion Markup Language (SAML): Essa especificação define um mecanismo baseado em XML para segurança em transações de e-commerce business-to-business (B2B) e business-to-consumer (B2C). SAML define um framework para troca de informação de autenticação e autorização baseado em XML. SAML utiliza um protocolo de XML codificado para requisição e resposta e especifica regras para o uso de padrões de transporte de mensagens. SAML provê interoperabilidade entre sistemas de segurança distintos e pode ser aplicado para facilitar três casos de uso: login simples, transações distribuídas e serviços de autorização.

eXtensible Access Control Markup Language (XACML): Essa especificação define uma linguagem comum para expressar política de segurança e uma estrutura extensível de schema e namespace para expressar políticas de autorização em XML. Uma linguagem comum para especificação de política segurança permite que a empresa gerencie os esforços de todos os seus elementos em todos os seus sistemas de informações.

Especificações JCP O JCP é responsável pelo desenvolvimento na tecnologia Java. Primeiramente o JCP guia o desenvolvimento e a aprovação de especificações técnicas da tecnologia Java. Está trabalhando atualmente nas seguintes especificações:

JSR 104 - XML Trust Service APIs: Define uma série de padrões de APIs e um protocolo para um serviço confiável. Um dos objetivos-chave do design do protocolo é minimizar a complexidade de aplicações utilizando XML Signature. Se tornando um cliente de um serviço confiável, a aplicação é livrada da complexidade para estabelecer relações de confiança, o que pode ser baseado em uma diferente especificação, assim como X509, PKIX, SPKI ou PGP.



JSR 105 - XML Digital Signature APIs: Define uma série de padrões de APIs para serviços de criptografia de XML. A criptografia pode ser utilizada para criptografar documentos XML, bem como fragmentos binários contidos em um documento XML.

JSR 155 - Web Services Security Assertions: Provê um conjunto de APIs e padrões de implementação para segurança (integridade e confidencialidade) em comunicações entre web services baseado na especificação SAML da OASIS.

JSR 183 - Web Services Message Security APIs: Define um conjunto padrão de APIs para segurança de mensagens em web services. O objetivo desta JSR é tornar aplicações aptas a fazer trocas seguras de mensagens SOAP.

JSR 196 - Java Authentication Service Provider Interface for Containers: A especificação propõe uma interface padrão provedora de serviços com mecanismos de autenticação e integração com containers. Provedores integrados através dessa interface serão utilizados para estabelecer as identidades de autenticação usadas no controle de acesso dos containers, incluindo aquelas utilizadas pelo container em invocações de componentes em outros containers.

Especificações WS-I WS-I é uma organização aberta, feita com o propósito de promover a interoperabilidade de web services através de diferentes plataformas, sistemas operacionais e linguagens de programação. Especificamente, o WS-I cria, promove e dá suporte a protocolos genéricos para a troca de mensagens entre web services. O WS-I cria profiles, que recomendam o que e como usar várias especificações criadas por W3C, OASIS e JCP. WS-I trabalha nos seguintes profiles relacionados à segurança em web services:

Basic Security Profile (BSP): Fornece informações sobre o uso de WS-Security e os formatos de token UserName e X.509.

REL Token Profile: É o profile de interoperabilidade para o token de segurança Rights Expression Language (REL) que é utilizado com WS-Security.

SAML Token Profile: É o profile de interoperabilidade para o token de segurança Security Assertion Markup Language (SAML) que é utilizado com WS-Security.

Security Challenges, Threats, and Countermeasures: Indica desafios potenciais em segurança em web services e identifica as tecnologias candidatas a vencer esses desafios.



WS-Security

Em abril de 2002, a Microsoft Corporation, a IBM Corporation e a VeriSign Inc. se uniram e publicaram um conjunto de novas especificações de segurança denominadas WS-Security, com o objetivo de que as empresas pudessem criar e construir aplicações de web services com ampla interoperabilidade.

As especificações do WS-Security, propostas pela IBM e Microsoft, são fundamentais para a concretização de um planejamento amplo de recursos que possam atender à crescente necessidade de oferecer suporte mais seguro para construção de web services. O documento "A Segurança no mundo dos Web services", de autoria da Microsoft e da IBM, explica as novas especificações de segurança para web services que essas empresas pretendem desenvolver em conjunto com alguns de seus principais clientes, parceiros de mercado e entidades responsáveis pela padronização.

O WS-Security suporta, integra e unifica vários modelos, mecanismos e tecnologias de segurança em uso no mercado, permitindo que vários sistemas possam interoperar em plataformas e linguagens neutras.

As novas especificações de segurança definem um conjunto de padrões para extensões SOAP ou para cabeçalhos de mensagens, utilizados para oferecer maior integridade e confidencialidade às aplicações de web services. O WS-Security oferece os mecanismos padrão de segurança necessários para realizar o intercâmbio seguro de mensagens certificadas em um ambiente de web services.

O documento citado acima define alguns recursos adicionais de segurança de web services que se enquadram no modelo estabelecido pelas especificações WS-Security, entre eles:

WS-Policy, WS-Trust e WS-Privacy: O WS-Policy define como os recursos e restrições das normas de segurança poderão ser expressos; o WS-Trust irá descrever um modelo para que se obtenha um relacionamento de confiança, tanto direto, quanto por meio de agentes (incluindo terceiros e intermediários); o WS-Privacy determinará de que forma os web services serão 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 especificações para o contexto de segurança desse intercâmbio e a derivação de chaves de sessão; o WS-Federation gerencia os vários tipos de relacionamento em ambientes heterogêneos associados, incluindo o suporte à identidade dessas partes associadas; a WS-Authorization define como os web services administrarão os dados e as normas de autorização.



Exercícios

1. Cite as principais características que tornam um web service vulnerável.

2. Explique os níveis de segurança em web services.

3. Quais os pontos devem ser considerados quando falamos em segurança em web services?


Java Web Services

Apêndice 1:Apêndice 1:Estudos ComplementaresEstudos Complementares


Segurança com Web Services

Diferença entre JAX-RPC e JAX-WS

Nos links a seguir, a IBM explica todos os detalhes que diferenciam as duas formas de implementação de web services comuns do Java: o Java API for XML-Based RPC e o Java API for XML Web Services:

JAX-RPC vs. JAX-WS, Parte 1: http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc.html

JAX-RPC vs. JAX-WS, Parte 2: http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc2.html

JAX-RPC vs. JAX-WS, Parte 3: http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc3/





Diferença entre Document/Literal e RPC/LiteralExistem dois modelos de programação populares para web services hoje: RPC e messaging. A especificação WSDL 1.1 define necessariamente dois estilos mensagem SOAP Message, RPC e Document, que supostamente correspondem a dois modelos de programação.

Aqui estão dois exemplos de mensagens SOAP: document/literal e RPC/literal. Note que ambos os exemplos necessitam (mas não são obrigados a) conter um elemento chamado Example com um filho chamado cust. No entanto, os namespaces de Example e cust são 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 informações são encontradas em http://msdn.microsoft.com/en-us/library/ms996466.aspx.


Java Web Services

Referências BibliográficasReferências Bibliográficas


Apêndice 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? Disponível 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. Disponível em: http://tinyurl.com/cnujvq. Acesso em: 18 de ago. 2010.

PEREIRA, Michael Luiz. Web Services Seguros em Java. 2008. 64. Monografia Pós-graduação em Desenvolvimento Orientado a Objetos Java – Centro Universitário de Maringá. Maringá, 2008.


http://tinyurl.com/29yky4g

TJAVWSER - v4 - [08.11.2010]

Documents

Transcript of TJAVWSER - v4 - [08.11.2010]