2013 Fumec Oliveirajunior

UNIVERSIDADE FUMEC
FACULDADE DE CINCIAS EMPRESARIAIS FACE

ISMAEL DE SOUZA OLIVEIRA JNIOR

COMPARAO ENTRE FRAMEWORKS JAVA PARA
DESENVOLVIMENTO DE WEB SERVICES:
Axis2 e CXF

Belo Horizonte
2013

ISMAEL DE SOUZA OLIVEIRA JNIOR

COMPARAO ENTRE FRAMEWORKS JAVA PARA
DESENVOLVIMENTO DE WEB SERVICES:
Axis2 e CXF

Monografia apresentada Universidade
FUMEC, no curso de Cincia da Computao,
apresentado disciplina Trabalho de Concluso
de Curso.

Orientador: Prof. Flvio Velloso Laper
Co-Orientador: Prof. Ricardo Terra
Orientador ABNT: Prof. Osvaldo Manoel Corra

Belo Horizonte
2013

AGRADECIMENTOS

Deus, primeiramente, por sempre estar comigo e dar sabedoria e pacincia
necessrias para chegar at aqui.

Aos meus pais, por me darem todo o apoio necessrio para que o sonho de me tornar
bacharel em Cincia da Computao se tornasse realidade.

Lucy, por todo o amor e pacincia demonstrados durante este estudo.

Ao professor Ricardo Terra, por todo o ensinamento passado e pela pacincia e
ateno demonstradas na orientao deste trabalho.

RESUMO

A necessidade de troca de informaes entre empresas com diferentes
ambientes (sistemas operacionais, linguagens de programao, etc.) fazem com que
a utilizao de Web services se apresente como a soluo mais apropriada. No
entanto, como se trata de uma tecnologia independente de linguagem de
programao, existem implementaes para as mais variadas linguagens de
programao. Mais especificamente, a linguagem Java possui diversos frameworks
que auxiliam no desenvolvimento de Web services. Diante disso, este estudo
apresenta dois frameworks largamente utilizados para a linguagem Java: Axis2 e CXF.
Mais importante, este estudo compara esses dois frameworks frente a diversos
aspectos, tais como padres adotados e complexidade de desenvolvimento. Como
resultado, pde-se observar que o framework CXF mais indicado para ser adotado
por fbricas de software principalmente por utilizar padres j consolidados na
comunidade Java e por possuir uma complexidade menor de desenvolvimento.

Palavras-chave: Arquitetura Orientada a Servios, Servios Web, Java, Axis2, CXF.

ABSTRACT

Information exchange is the basis for the communication among
companies. However, companies usually rely on different operating systems,
programming languages, etc. This scenario indicates the use of Web services (WS) as
the most suitable solution. Although WS is a technology-independent solution, there
are implementations for a wide range of programming languages. Specifically, there
are several Java-based frameworks that assist developers to build WS. In view of such
circumstances, this study describes two widely used Java-based frameworks: Axis2
and CXF. As a practical contribution, this study also compares these frameworks w.r.t.
standards, complexity, etc. As a result, we could observe that CXF overcomes Axis2
because the development of CXF-based WS is more intuitive and relies on patterns
already consolidated by the Java community.

Keywords: Service Oriented Architecture, Web services, Java, Axis2, CXF.

LISTA DE FIGURAS

Figura 1 Fluxo de um Web service........................................................................... 11
Figura 2 Componentes da arquitetura do Axis2....................................................... 23
Figura 3 Hierarquias de descrio e contexto do Axis2........................................... 24
Figura 4 Sistema motivador..................................................................................... 28
Figura 5 Estrutura de diretrios do aplicativo Axis2 para containers web............... 29
Figura 6 Componentes da arquitetura do Apache CXF........................................... 36
Figura 7 Estrutura do projeto webservicecxf no Eclipse..................................... 40
Figura 8 Fluxo de uma mensagem no servidor CXF................................................ 42
Figura 9 Fluxo de uma mensagem no consumidor CXF.......................................... 44

LISTA DE SIGLAS

ADB Axis2 Data Binding
API Application Programming Interface
AXIOM Axis2 Object Model
CORBA Common Object Request Broker Architecture
DOM Document Object Model
DTD Document Type Definition
EAI Enterprise Application Integration
ESB Enterprise Service Bus
HTML Hyper Text Markup Language
HTTP Hypertext Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
IDE Integrated Development Environment
IDL Interface Description Language
IIOP Internet Inter-Orb Protocol
JAXB Java Architecture for XML Binding
JAX-RS Java API for RESTful Web Services
JAX-WS Java API for XML-Based Web Services
JBI Java Business Integration
JCP Java Community Process
JMS Java Message Service
JSR Java Specification Request
MEP Message Exchange Pattern
POJO Plain Old Java Object
OMG Object Management Group
RPC Remote Procedure Call
REST Representational State Transfer
SMTP Simple Mail Transfer Protocol
SCA Service-Component Architecture
SEI Service Endpoint Interface
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
SDO Service Data Objects

StAX Streaming API for XML
TCP Transmission Control Protocol
UDDI Universal Description, Discovery and Integration
URI Uniform Resource Identifier
URL Uniform Resource Locator
WSDL Web Services Description Language
WS-BPEL Web Service Business Process Execution Language
W3C World Wide Web Consortium
XML Extensible Markup Language
XMPP Extensible Messaging and Presence Protocol

Sumrio

Introduo ................................................................................................................... 9
1. WEB SERVICES ................................................................................................ 11
1.1. Web services baseados em XML ................................................................. 13
1.1.1. WSDL .................................................................................................... 13
1.1.2. UDDI ...................................................................................................... 15
1.1.3. SOAP ..................................................................................................... 15
1.2. Web services baseados em REST ............................................................... 17
1.3. Especificaes para Web services em Java ................................................ 17
1.3.1. JAX-WS ................................................................................................. 18
1.3.2. JAX-RS .................................................................................................. 19
1.4. Ambiente de desenvolvimento ..................................................................... 19
1.5. Consideraes finais do captulo ................................................................. 19
2. APACHE AXIS2 ................................................................................................. 21
2.1. Viso geral ................................................................................................... 21
2.2. Arquitetura .................................................................................................... 22
2.2.1. Information processing Model ................................................................ 23
2.2.2. XML processing Model .......................................................................... 25
2.2.3. SOAP processing Model ........................................................................ 25
2.2.4. Deployment Model ................................................................................. 26
2.2.5. Client API ............................................................................................... 26
2.2.6. Transports ............................................................................................. 27
2.2.7. Code Generation ................................................................................... 27
2.2.8. Data binding .......................................................................................... 27
2.3. Sistema Motivador........................................................................................ 27
2.4. Implementao do servio ........................................................................... 28
2.5. Implementao do consumidor .................................................................... 31
3. APACHE CXF .................................................................................................... 34
3.1. Viso geral ................................................................................................... 34
3.2. Arquitetura .................................................................................................... 36
3.2.1. Bus ........................................................................................................ 36
3.2.2. Front-end ............................................................................................... 37
3.2.3. Messaging & Interceptors ...................................................................... 37

3.2.4. Data binding .......................................................................................... 37
3.2.5. Service model ........................................................................................ 38
3.2.6. Protocol binding ..................................................................................... 38
3.2.7. Transport ............................................................................................... 38
3.2.8. Modelo de processamento XML ............................................................ 39
3.3. Implementao do Servio ........................................................................... 39
3.4. Implementao do consumidor .................................................................... 42
Concluso ................................................................................................................. 46
REFERNCIAS ......................................................................................................... 51

APNDICE I Implementao do sistema motivador ............................................... 54
APNDICE II Implementao Axis2 ....................................................................... 56
APNDICE III Implementao CXF ....................................................................... 60

9

Introduo

A necessidade de troca de informaes entre empresas com diferentes
ambientes (sistemas operacionais, linguagens de programao, etc.) tem se tornado
cada vez mais evidente. Empresas podem ser compostas por vrias aplicaes que
so customizadas, adquiridas a partir de terceiros, parte de um sistema legado
1
, ou
uma combinao disso, operando em diferentes plataformas de sistemas
operacionais (HOHPE, WOOLF, 2003, p. 31 Traduo nossa). A partir dessa
necessidade, surgiram os primeiros conceitos de integrao de sistemas utilizando
Enterprise Application Integration (EAI), que consiste no processo de integrao de
vrios sistemas de software que foram desenvolvidos de forma independente, usando
tecnologias incompatveis que continuam a ser gerenciados de forma independente
(RICHADSON, 2013 Traduo nossa).
Entre as primeiras solues de EAI podemos destacar duas
implementaes baseadas em Remote Procedure Call (RPC): CORBA e XML-RPC.
RPC consiste de uma tcnica para computao distribuda em sistemas baseados em
cliente-servidor podendo ser considerada uma extenso da tradicional chamada local
de procedimentos, de forma que o procedimento no precisa estar no mesmo
ambiente da aplicao que deseja execut-lo (MARSHALL, 2013). CORBA a sigla
para Common Object Request Broker Architecture, uma arquitetura aberta, definida
pela OMG
2
e independente de fornecedor e infraestrutura, que as aplicaes usam
para trabalhar em conjunto atravs da rede. Apesar de ser uma soluo independente
de linguagem de programao, possui como desvantagem necessitar que todos os
sistemas de software envolvidos sejam baseados em CORBA (CORBA FAQ, 2013).
J o XML-RPC permite utilizar os recurso de RPC atravs da Internet sobre o
protocolo HTTP
3
. No entanto, no recebeu apoio e caiu em desuso.
Atualmente, a soluo mais utilizada para integrao de sistemas se baseia
na Service-Oriented Architecture (SOA), ou Arquitetura Orientada a Servios, que
um conceito de arquitetura corporativo que promove a integrao entre as reas de
negcio e Tecnologia da Informao (TI) por meio de um conjunto de interfaces de

1
Segundo Sommerville (2003), sistemas legados so sistemas antigos que so fundamentais para as
empresas que o utilizam e que sofreram (e ainda sofrem) vrias alteraes ao longo do tempo.
2
Object Management Group (OMG) um consrcio internacional que prov padres para a rea da
Cincia da Computao (OMG, 2013).
3
HTTP definido como o protocolo padro usado para transportar informaes entre servidores e
clientes na Internet (TANENBAUM; WETHERALL, 2011).
10

servios acoplados. No entanto, no correto afirmar que SOA um modelo de
integrao de sistemas, nem mesmo que integrao de sistemas contm SOA.
Podemos determinar que SOA uma estratgia que tem por objetivo criar todos os
ativos de software
4
de uma empresa via metodologia de programao orientada a
servios (KOCH, 2013). De um ponto de vista mais tcnico, notou-se que Web service
possui as caractersticas necessrias para ser considerado a abordagem mais
apropriada para implementar sistemas de software baseados em SOA.
Web service um componente de software que pode ser implementado por
diversas linguagens de programao e tem a capacidade de reutilizar componentes
de aplicao e fazer com que sistemas desenvolvidos em diferentes linguagens de
programao se comuniquem sem requerer que os sistemas envolvidos passem por
larga reestruturaes. Mais importante, pelo fato de ser implementado por diversas
linguagens de programao, atualmente existem uma diversidade de frameworks
5

para as vrias linguagens disponveis no mercado. Diante desse cenrio, o objetivo
desse trabalho descrever dois frameworks feitos para linguagem Java Apache
Axis2 e Apache CXF e, por meio de uma anlise comparativa de aspectos relevantes
tais como complexidade e padres suportados determinar qual framework o mais
apropriado para ser adotado por fbricas de software. Esse estudo, portanto, poder
apoiar pequenas e mdias empresas de desenvolvimento de software na escolha de
qual framework adotar no desenvolvimento de seus projetos.
Esta monografia est organizada como a seguir. O Captulo 1 aborda Web
services, suas principais caractersticas e os padres adotados pela linguagem Java.
O Captulo 2 descreve o projeto e implementao de Web services e consumidores
usando o framework Apache Axis2. Como alternativa ao Axis2, o Captulo 3 descreve
o framework Apache CXF. Por fim, na Concluso, apresentada uma anlise
comparativa no intuito de determinar qual framework o mais indicado a ser adotado
por fbricas de software.

4
Vasconcellos (2013), define ativo de software como todos os ativos que formam o grande inventrio
da rea de TI, aquele que parece mais esquecido ou, relegado a um segundo plano.
5
Fayad e Schmidt (1997) definem framework como um conjunto de classes que colaboram para
realizar uma responsabilidade para um domnio de um subsistema da aplicao.
11

1. WEB SERVICES
Web services so componentes de software, independentes de plataforma
para implementao de servios e oferecem um alto grau de reso e
interoperabilidade. Basicamente, Web services so concebidos com o intuito de
consumir e/ou disponibilizar servios. Para consumir servios, um aplicativo efetua
uma requisio a um Web service e o seu retorno tratado por esse Web service. Por
outro lado, ao disponibilizar um servio, o Web service apenas invocado quando
solicitado. No entanto, Web services podem ser constitudos por vrios servios, cada
um possuindo uma finalidade, fazendo com que esses sejam capazes de consumir e
disponibilizar servios simultaneamente. A Figura 1 ilustra o fluxo de trabalho bsico
de um Web service.

Figura 1: Fluxo de um Web service.
Fonte: JAVAWORLD, 2013. (Adaptado pelo autor)

Mais precisamente, a Figura 1 ilustra um provedor de servios que publica
um documento que descreve os servios disponveis (WSDL) e um cliente que
consulta esse documento para obter detalhes do servio que deseja invocar. O cliente
ao efetuar a requisio desse servio para o provedor utiliza o protocolo SOAP, o
provedor processa essa requisio e envia o resultado para o cliente (utilizando
tambm SOAP).
As duas principais funes dos Web services so: reutilizar componentes
de aplicao e conectar sistemas de software diferentes (W3SCHOOLS, 2013). Essas
funes fazem com que Web service seja a principal tecnologia utilizada para
implementar sistemas de software cuja arquitetura baseada em SOA. No entanto,
12

necessrio entender o que um servio e qual o seu papel dentro de um contexto
SOA. Erl (2009, p. 25) define da seguinte forma:
Os servios existem como programas de software fisicamente
independentes, com caractersticas de design distintas que do
suporte obteno dos objetivos estratgicos associados
computao orientada a servios. Cada servio recebe seu prprio
contexto funcional distinto e possui um conjunto de capacidades
relacionadas a esse contexto. Essas capacidades adequadas para a
invocao por programas externos so comumente expressas via um
contrato de servios pblico.

Outra caracterstica importante dos Web services a sua capacidade de
se compor com outros servios. Essa caracterstica recebe o nome de Composio e
permite que um novo servio seja criado com um nvel ainda maior de abstrao.
Segundo Erl (2009, p. 228), Web services estabelecem um nvel de composio
nativo, fazendo com que esse seja mais um motivo para reforar que Web service a
abordagem mais conveniente para construir SOA. A implementao de Composio
de servios mais conhecida a Orquestrao. Essa implementao consiste em um
Web service que invoca outros servios respeitando uma ordem de execuo que
gerenciada por um controlador central. A tecnologia mais utilizada para implementar
Orquestrao a Web Service Business Process Execution Language (WS-BPEL).
Existem ainda outras duas implementaes de composio de servios:
Coordenao e Coreografia. Coordenao um tipo de composio muito parecido
com a Orquestrao. No entanto, no existe uma ordem para execuo dos servios
que participam desse tipo de composio.
6
J a Coreografia descreve o fluxo entre as
entidades envolvidas nesse tipo de composio, porm, o controle e o cumprimento
desse fluxo de responsabilidade de cada entidade.
7

Ao longo deste captulo sero descritos dois tipos de Web services:
baseados em XML
8
(que o foco deste trabalho) e baseados em REST. Em seguida,
sero abordadas as especificaes de desenvolvimento de Web services para a
linguagem Java JAX-WS e JAX-RS e suas respectivas implementaes de
referncia. Por ltimo, detalhado o ambiente de desenvolvimento utilizado ao longo
desta monografia.

6
O padro que define frameworks para Coordenao um conjunto de especificaes: WS-
BusinessActivity (WS-BA), WS-AtomicTransaction (WS-AT) e WS-Coordination (WS-C).
7
J o padro para a implementao de Coreografia definida pelo W3C e denominado por Web
Service Choreography Description Language (WS-CDL).
8
XML a sigla para Extensible Markup Language. uma tecnologia para criar linguagens de
marcao que descrevem dados de praticamente qualquer tipo de forma estruturada (DEITEL, 2003).
13

1.1. Web services baseados em XML

Esse tipo de Web service utiliza XML para codificar e decodificar dados e
utiliza um protocolo de transporte (geralmente HTTP) para trafegar esses dados.
Atualmente denominado Web service clssico, essa plataforma possui trs
elementos bsicos: WSDL, UDDI e SOAP.

1.1.1. WSDL

Web Services Description Language (WSDL) uma linguagem
padronizada pelo W3C
9
, baseada em XML, que usada para descrever e localizar
Web services. Assim, para descrever um Web service necessrio existir um
documento WSDL, conforme exemplificado a seguir:

1. <message name="getTermRequest">
2. <part name="term" type="xs:string"/>
3. </message>

4. <message name="getTermResponse">
5. <part name="value" type="xs:string"/>
6. </message>

7. <portType name="glossaryTerms">
8. <operation name="getTerm">
9. <input message="getTermRequest"/>
10. <output message="getTermResponse"/>
11. </operation>
12. </portType>

13. <binding type="glossaryTerms" name="b1">
14. <soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
15. <operation>
16. <soap:operation soapAction="http://example.com/getTerm"/>
17. <input><soap:body use="literal"/></input>
18. <output><soap:body use="literal"/></output>
19. </operation>
20. </binding>

O exemplo acima ilustra o documento WSDL de um Web service de
consulta de termos em um glossrio. Nesse documento existem dois elementos
<message> (linhas 1-3 e 4-6) que recebem os nomes de getTermRequest que faz
a requisio de um termo e getTermResponse que faz o retorno referente ao termo
requisitado. O elemento <message> define o nome das mensagens que podero ser

9
World Wide Web Consortium (W3C) um consrcio internacional responsvel por desenvolver
padres Web (W3C, 2013 Traduo nossa).
14

utilizadas no Web service e os atributos e tipos de dados suportados por uma
mensagem.
Outro elemento presente nesse exemplo o <portType> (linhas 7-12)
que o elemento mais importante de um documento WSDL, pois nele que de fato
definido um Web service, isto , as operaes e as mensagens envolvidas. No
exemplo, o elemento <portType> recebe o nome de glossaryTerms e a nica
operao suportada recebe o nome de getTerm (que busca um termo). Essa
operao define uma mensagem para receber uma requisio (input message) e
outra para enviar a resposta (output message). Esse tipo de operao em que
definida uma mensagem para requisio e uma para resposta conhecido como
request-response. Existem ainda outros trs tipos de operaes suportadas pelo
elemento <portType>: one-way, solicit-response e notification. Operaes do tipo
one-way podem apenas receber uma mensagem, mas no retornam uma resposta.
J as operaes do tipo solicit-response so capazes de enviar uma requisio e
aguardar uma resposta. E, por ltimo, as operaes do tipo notification so capazes
de enviar uma mensagem, porm, no aguardam resposta. importante mencionar
que os tipos de operao no so explicitamente descritos no documento WSDL.
O elemento <binding> (linhas 13-20) define o formato da mensagem e o
protocolo utilizado para um Web service. O protocolo mais utilizado para Web services
o protocolo SOAP (detalhado na seo 1.1.3). Esse elemento possui dois atributos:
name e type. O atributo name define o nome da ligao e o atributo type aponta para
o elemento <portType> do documento. O elemento <soap:binding> (linha 14)
possui dois atributos: style e transport. Nesse caso, o atributo style recebeu o
valor document, mas tambm aceita rpc. Esse atributo indica como a ligao entre
o documento WSDL e uma mensagem SOAP traduzida. J o atributo transport
define qual o protocolo de transporte utilizado para transmitir uma mensagem SOAP
e, nesse caso, foi utilizado HTTP. O elemento <operation> (linhas 15-19) define as
operaes expostas pelo elemento <portType>. Cada operao deve possuir uma
ao correspondente que o SOAP deve realizar. Deve-se tambm especificar como a
entrada e a sada de dados sero codificados. Nesse caso, foi utilizado literal (no
qual as mensagens se referem a uma definio de schema concreto), porm,
possvel utilizar encoded (nesse caso as mensagens referem-se a uma definio de
15

schema abstrata e uma mensagem concreta pode ser produzida aplicando uma
codificao especfica).
Em Web services baseados em XML, a concretizao do conceito de
interoperabilidade s possvel graas ao documento WSDL. Por se tratar de um
documento XML, pode ser interpretado por todas as linguagens de programao que
implementam Web services.

1.1.2. UDDI

Universal Description, Discovery and Integration (UDDI) um servio de
diretrio onde empresas podem registrar e procurar Web services baseados em XML.
UDDI um framework independente de plataforma construdo na plataforma Microsoft
.NET, utiliza documento WSDL para descrever as interfaces dos Web services e se
comunica atravs do protocolo SOAP (detalhado na seo seguinte).
Antes da existncia de UDDI, no havia uma forma padronizada para que
uma empresa chegasse at seus clientes e fornecedores com informaes sobre seus
produtos e servios atravs da Internet. Mais importante, tambm no era possvel
integrar sistemas e processos entre empresas diferentes.

1.1.3. SOAP

Simple Object Access Protocol (SOAP) um protocolo de comunicao
baseado em XML utilizado para estabelecer comunicao entre aplicaes atravs do
protocolo HTTP. Como utilizado para acessar um Web service, SOAP
independente de linguagem e plataforma. Alm disso, recomendado pelo W3C. Uma
mensagem SOAP um documento XML que contm os elementos
<soap:Envelope>, <soap:Head>, <soap:Body> e <soap:Fault>.
Basicamente, o elemento <soap:Envelope> identifica o documento XML como uma
mensagem SOAP, <soap:Head> contm informaes de cabealho da mensagem,
<soap:Body> armazena o contedo da mensagem transmitida e <soap:Fault>
armazena as informaes de status e erros. As regras sintticas para uma mensagem
SOAP so:
1. Obrigatoriamente ser codificada utilizando XML;
16

2. Utilizar namespaces
10
padro SOAP Envelope e SOAP Encoding e
3. No conter referncias DTD
11
e instrues de processamento XML
12
.
A seguir, apresentado um exemplo de mensagem SOAP.

1.
POST /InStock HTTP/1.1
2.
Host: www.example.org
3.
Content-Type: application/soap+xml; charset=utf-8
4.
Content-Length: nnn

5.
<?xml version="1.0"?>
6.
<soap:Envelope
7.
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
8.
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

9.
<soap:Body xmlns:m="http://www.example.org/stock">
10.
<m:GetStockPrice>
11.
<m:StockName>IBM</m:StockName>
12.
</m:GetStockPrice>
13.
</soap:Body>

14.
</soap:Envelope>

As linhas 1-4 referem-se ao cabealho de uma requisio de conexo com
o protocolo HTTP. Aps estabelecer a conexo, o cliente pode enviar a mensagem
SOAP utilizando HTTP.
O elemento <soap:Envelope> (linhas 6-14) obrigatrio e utiliza dois
namespaces. Um se refere diretamente a esse elemento e o padro utilizado
definido por uma URI
13
: http://www.w3.org/2001/12/soap-envelope. O
segundo namespace corresponde a codificao SOAP e dos tipos de dados. A URI
padro correspondente a esse namespace : http://www.w3.org/2001/12/
soap-encoding.
O elemento <soap:Body> (linhas 9-13) um elemento obrigatrio em uma
mensagem SOAP. Ele armazena o contedo da mensagem transmitida ao ltimo
endpoint
14
. Deve ser o ltimo endpoint, pois dependendo da arquitetura, uma

10
Namespace utilizado para evitar colises de nomes de tags em um documento XML (DEITEL, 2003.
p. 164-165).
11
Document Type Definition (DTD) define a estrutura de um documento (ou seja, quais elementos,
atributos, etc. so permitidos) (DEITEL, 2003. p. 176). No entanto, foi substitudo pelo XML Schema.
12
Instrues de processamento XML so marcaes especiais que permitem instrues especficas
para a aplicao que est processando um documento XML (PROCESSING INSTRUCTIONS, 2013).
13
Segundo Deitel (2003, p. 165-166), Uniform Resource Identifier (URI) uma srie de caracteres
usados para diferenciar nomes.
14
Endpoint uma associao entre um Web service e um endereo de rede, que comunica com uma
instncia de servio, indicando o local, protocolo e tipos de dados (ENDPOINT REFERENCE, 2013).
17

mensagem SOAP pode trafegar por vrios endpoints. Cada elemento filho de
<soap:Body> pode ter seu prprio namespace.

1.2. Web services baseados em REST

Representational State Transfer (REST) uma arquitetura definida para
sistemas distribudos que teve origem a partir de uma tese de doutorado escrita por
Roy Fielding, um dos principais autores da especificao do protocolo HTTP. Segundo
Fielding (2000), REST um estilo hbrido derivado de vrias arquiteturas baseadas
em rede combinado com restries adicionais que definem uma interface de conector
uniforme.
Essa arquitetura est relacionada a recursos que so identificados por URI.
Um recurso pode ser qualquer tipo de informao, por exemplo: pedido, cliente,
fornecedor, etc. As informaes referentes a esse recurso so as representaes e
so armazenadas em arquivos formatados, tais como HTML
15
, XML ou JSON
16
.
Web services podem ser construdos utilizando os princpios da arquitetura
REST e so conhecidos como RESTful Web services. Web services desenvolvidos
sobre essa abordagem so vistos como recursos e identificados por sua URI. Os Web
services expem um grupo de operaes atravs de uma interface comum para
transferncia de estado entre clientes e recursos e essas operaes utilizam mtodos
HTTP, tais como GET e POST. Os clientes especificam qual representao desejam
declarando um dos mtodos definidos nessa interface usando a URI sobre o protocolo
HTTP (BALANI; HATHI, 2013). Web services baseados em REST so uma alternativa
para os Web services tradicionais (baseados em XML). No entanto, a falta de
padronizao da arquitetura REST impede que essa seja amplamente empregada.

1.3. Especificaes para Web services em Java

Como j mencionado, Web services so componentes de software
padronizados pelo W3C e podem ser desenvolvidos em praticamente qualquer
linguagem de programao. No entanto, cada linguagem possui sua prpria
especificao, ou implementao de referncia a fim de auxiliar os desenvolvedores

15
Segundo a HTML Introduction (2013), HTML a sigla para Hyper Text Markup Language e uma
linguagem usada na criao de pginas web.
16
JSON um formato de texto independente de linguagem de programao baseado em um
subconjunto da linguagem JavaScript utilizado para troca de dados. (JSON, 2013)
18

a manter o padro. Para isso, a plataforma Java conta com a colaborao do Java
Community Process (JCP). JCP o mecanismo para o desenvolvimento de
especificaes tcnicas padro da tecnologia Java (JCP, 2013). O JCP utiliza os Java
Specification Requests (JSRs) para descrever as especificaes propostas e
tecnologias que deseja adicionar na plataforma Java. Cada especificao possui
uma identificao nica. Por exemplo, a especificao JAX-WS (detalhada a seguir)
descrita pela JSR 224. Mais especificamente, a linguagem Java possui uma
especificao para Web services baseados em XML e outra para Web services
baseados em REST: Java API for XML-Based Web Services (JAX-WS) e Java API for
RESTful Web Services (JAX-RS).

1.3.1. JAX-WS

JAX-WS uma especificao para desenvolvimento de Web services
baseados em XML e de clientes para consumir servios utilizando linguagem Java.
Sua especificao definida pelo JCP, identificada pela JSR 224 e atualmente
encontra-se na verso 2.x. Originalmente, o nome dessa especificao era JAX-RPC.
Na primeira verso da especificao, uma aplicao Java poderia ser vista como uma
aplicao RPC, porm, em forma de Web service. JAX-WS manteve todas as
caractersticas da verso anterior, mas aumentou significativamente o seu poder de
expresso (KALIN, 2009). A especificao JAX-WS permite criar Web services a partir
de cdigo Java utilizando anotaes
17
apropriadas. Em Web services, essa
abordagem recebe o nome de bottom-up, pois o documento WSDL gerado partir
do cdigo-fonte. JAX-WS utiliza uma srie de anotaes que so derivadas de
algumas especificaes, por exemplo, JSR 181 que define a sintaxe de anotaes
para programao de Web services e JSR 250 que define anotaes utilizadas na
linguagem Java. Para fazer uma ligao entre os tipos de dados existentes em um
documento XML e objetos Java, JAX-WS utiliza uma outra especificao: Java
Architecture for XML Binding (JAXB). JAXB uma especificao que define como
JavaBeans
18
podem ter dados ligados ao XML (JAYASINGHE; AZEEZ, 2011, p. 180
Traduo nossa).

17
Anotaes proveem informaes sobre o cdigo que est sendo escrito ou at mesmo do prprio
programa. Em contraste com comentrios, anotaes so interpretadas por compiladores (TI EXPERT,
2013).
18
JavaBeans, ou simplesmente beans, so componentes de software reutilizveis que podem ser
desenvolvidos para criar aplicaes sofisticadas (JAVABEANS, 2013).
19

A implementao de referncia para JAX-WS desenvolvida como um
projeto open source
19
e parte do projeto GlassFish, um servidor de aplicao
tambm open source para aplicaes Java.

1.3.2. JAX-RS

JAX-RS uma especificao para desenvolvimento de Web services
baseados na arquitetura REST para a linguagem Java. tambm uma especificao
definida pelo JCP na JSR 339 e encontra-se na verso 2.x. Por fim, Jersey a
implementao de referncia para essa especificao.

1.4. Ambiente de desenvolvimento

Como j definido, o objetivo desta monografia comparar dois frameworks
amplamente utilizados para desenvolvimento de Web services utilizando linguagem
Java Axis2 e CXF que sero respectivamente apresentados nos captulos 2 e 3.
Como o foco dado nos Web services baseados em XML, o estudo dos frameworks
regido pela especificao JAX-WS. O ambiente de desenvolvimento utilizado para
programar os Web services e seus consumidores descrito a seguir:
- Java Development Kit (JDK) 7u17: conjunto de ferramentas que
permitem criar sistemas de software na plataforma Java.
- Eclipse Juno (4.2): Integrated Development Environment (IDE) para
desenvolvimento de programas.
- Maven 3.0.4: ferramenta utilizada para gerenciar projetos de
desenvolvimento de sistemas de software, principalmente voltados
plataforma Java.
- Apache Tomcat 7.0.35: container de aplicaes web construdas em
linguagem Java utilizando a especificao Java EE (JSR 316).

1.5. Consideraes finais do captulo

Neste primeiro captulo foram abordados conceitos relacionados a Web
services, componentes de software implementados independentes de linguagem de
programao utilizados para reutilizar componentes de software e/ou integrar

19
Open-source, ou cdigo aberto, uma metodologia de desenvolvimento de software que tem como
premissa a liberao do cdigo-fonte anexo ao programa (OPENSOURCE, 2013 Traduo nossa).
20

sistemas de software distintos. Por possuir tal caracterstica, considerado a
tecnologia mais apropriada para SOA. Outra caracterstica importante dos Web
services a Composio, que capacidade de um Web service se compor com outros
servios. A implementao mais conhecida de Composio de servios a
orquestrao, que consiste em um Web service que invoca outros Web services
respeitando uma ordem de execuo.
Neste captulo tambm foram demonstrados dois tipos de Web services e
seus conceitos bsicos: os baseados em XML (tambm conhecidos como Web
services clssicos) e baseados em REST (conhecidos como RESTful Web services).
Embora cada linguagem de programao possua sua prpria implementao de Web
services, este trabalho foca em implementaes Java. Mais especificamente, o foco
se dar nos frameworks Axis2 e CXF. Ainda mais importante, o estudo avalia apenas
as implementaes de Web services clssicos (baseados em XML) que seguem a
especificao JAX-WS. O principal motivo de no avaliarmos RESTful Web services
se d pelo fato de no serem uma implementao padronizada e tambm por no
serem to empregados pelo mercado quanto os Web services clssicos.
No prximo captulo abordado o Axis2, um dos frameworks utilizado no
desenvolvimento de Web services para a linguagem Java. Seu objetivo consiste
basicamente em demonstrar a arquitetura do Axis2 e implementaes de servios e
consumidores por meio do uso desse framework.

21

2. APACHE AXIS2

Apache Axis2 um framework open-source utilizado no desenvolvimento
de Web services para as linguagens Java e C. Na sua verso para Java, Axis2 suporta
o desenvolvimento de Web services baseados em XML e baseados em REST.
20

Na seo 2.1 demonstrada uma viso geral desse framework, sua
histria, principais caractersticas e ferramentas. Na seo 2.2 apresentada a
arquitetura do Axis2. Na seo 2.3 apresentado o sistema motivador utilizado pelos
dois frameworks abordados nesta monografia que a base para realizar a
comparao entre eles. Na seo 2.4 demonstrado como implementar um Web
service utilizando Apache Axis2 e, por fim, na seo 2.5 demonstrado como
implementar um consumidor utilizando esse framework.

2.1. Viso geral

O Apache Axis2 foi lanado em 2006 sendo considerado a terceira gerao
de frameworks para desenvolvimento de Web services da Apache. Seus antecessores
so Apache SOAP e Apache Axis 1.0. O Axis2 foi criado para atender os novos
padres de Web services, pois no era vivel alterar a arquitetura do Axis 1.0
(JAYASINGHE; AZEEZ, 2011. p. 19).
Axis2 implementa vrios padres de Web services. Essas implementaes
podem ser nativas, como o padro WS-Addressing ou implementadas a partir de
mdulos. Os mdulos so plugins que podem ser estendidos pelo Axis2 e que
implementam padres de Web service, tais como: Apache Sandecha2 que
implementa o padro WS-ReliableMessaging, Apache Kandula2 que implementa os
padres WS-Coordination e WS-AtomicTransaction e Apache Rampart que
implementa o padro WS-Security.
Entre as caractersticas principais do Axis2, destacam-se o seu prprio
modelo de objeto o Axis2 Object Model (AXIOM) e a sua capacidade de implantar
servios em um servidor de aplicao em execuo. Para a implantao em
execuo, basta inserir no diretrio de servios o arquivo com a extenso .class que
representa um Web service e o prprio servidor se encarrega de realizar o deploy e
disponibilizar o servio. A arquitetura do Axis2 bastante flexvel e permite que o

20
No faz parte do escopo do trabalho abordar a implementao para a linguagem C desse framework,
a qual detalhada em: http://axis.apache.org/axis2/c/core/index.html.
22

desenvolvedor inclua extenses para customizar qualquer caracterstica do
framework. Por exemplo, Axis2 oferece suporte a Web services assncronos e MEPs
21

e possui uma clara e simples abstrao da camada de transporte, fazendo com que o
ncleo do Axis2 seja totalmente independente de protocolo de transporte.
Axis2 tambm possui ferramentas de apoio para o desenvolvimento de
servios e/ou consumidores. Code Generation Tool faz parte do ncleo do Axis2 e
um plugin que cria classes Java a partir de um WSDL. Existem tambm outros plugins
para gerenciadores de projeto, como o Maven, e para IDEs, como o Eclipse, conforme
pode ser observados na Tabela 1.

TABELA 1 Ferramentas do Apache Axis2
Tipo de Ferramenta Nomes
Plugins para Maven
Maven2 WSDL2Code, Maven Java2WSDL, Maven2
MAR Plugin, Maven2 AAR Plugin
Plugins para IDE
Code Generator Wizard - IntelliJ IDEA Plug-in, Code
Generator Wizard - Eclipse Plug-in, Service Archive
Wizard - Eclipse Plug-in
Fonte: Apache Axis2 (2013).

2.2. Arquitetura

Conforme pode ser observado na Figura 2, o Axis2 possui uma arquitetura
modular, o que permite que componentes presentes nesse tipo de arquitetura sofram
modificaes sem impactar o ncleo da aplicao. Quando o Axis2 foi projetado, trs
regras fundamentais foram incorporadas sua arquitetura para garantir maior
flexibilidade e tornar o processamento de mensagens SOAP mais robusto: (i) separar
a lgica do estado da aplicao, pois Web services so aplicaes stateless, ou seja,
no armazenam o seu estado anterior; (ii) possuir um modelo de informaes nico,
o que permite ao Axis2 suspender e retomar suas atividades; e (iii) capacidade de
suportar novas especificaes de Web services realizando o mnimo de alteraes
possveis nos mdulos principais da sua arquitetura.

21
Message Exchange Pattern (MEP) um template que estabelece um padro para troca de
mensagens entre duas partes que se comunicam (MEPS, 2013 Traduo nossa).
23

Figura 2: Componentes da arquitetura do Axis2.
Fonte: JAYSINGHE; AZEEZ, 2011, p.28. (Adaptado pelo autor)

Segundo Jayasinghe e Azeez (2011), a arquitetura do Axis2 composta
por componentes principais e secundrios. A Figura 2 ilustra todos os componentes
presentes na arquitetura do Axis2 das quais pode-se citar como principais: Information
processing Model, XML processing Model, SOAP processing Model, Deployment
Model, Client API e Transports. J os seguintes mdulos so considerados
secundrios: Code Generation e Data binding. Esses componentes so detalhados
nas sub-sees seguintes.

2.2.1. Information processing Model

Esse componente define um modelo para manipulao de informaes.
Esse modelo consiste de duas hierarquias: (i) hierarquia de descrio e (ii) hierarquia
de contexto. A hierarquia de descrio representa dados estticos que podem ser, por
exemplo, arquivos de configurao utilizados pelo Axis2. J a hierarquia de contexto
mantm informaes dinmicas sobre objetos que possuem mais de uma instncia.
Ambas as hierarquias criam um modelo que permite a busca de informaes por meio
de mapas chave-valor. Manter esses dados separados prov maior flexibilidade ao
sistema, o que fundamental para um Web service.
A hierarquia de descrio muito importante para garantir outra
caracterstica fundamental para Web services: o desempenho. Dentro do conceito da
hierarquia de descrio, o Axis2 possui uma outra hierarquia que armazena os dados
24

de configurao de uma forma mais organizada, que a hierarquia de objetos.
Segundo Jaysinghe e Azeez (2011), existem trs tipos de arquivos de configurao,
cada um em um nvel, que populam e configuram essa hierarquia: (i) nvel global
(axis2.xml); (ii) nvel de servio (services.xml); e (iii) nvel de mdulo ou
extenso de servio (module.xml). O arquivo axis2.xml contm as configuraes
mnimas para iniciar o Axis2, seja como servidor ou consumidor e pode ser
customizado de acordo com a necessidade. J o arquivo services.xml armazena
informaes necessrias para implantar um Web service. Por fim, o arquivo
module.xml armazena todas as configuraes necessrias para criao de um
mdulo, que pode ser entendido como uma extenso de um servio.
J a hierarquia de contexto s acionada quando o Axis2 recebe alguma
mensagem. Como j definido, essa hierarquia armazena dados dinmicos e em tempo
de execuo. Esses dados so compartilhados entre vrias invocaes ou entre os
manipuladores de uma invocao. Nessa hierarquia, a principal forma de
armazenamento de configuraes a utilizao de Properties. A Figura 3 ilustra o
relacionamento entre as hierarquias de descrio e contexto.

Figura 3: Hierarquias de descrio e contexto do Axis2.
Fonte: Jaysinghe e Azeez (2011).

De acordo com a Figura 3, para cada elemento da hierarquia de descrio
deve existir um contexto associado. Como se trata de uma hierarquia, o elemento de
25

nvel superior responsvel pelos elementos subsequentes, que podem no existir
como podem ser vrios.

2.2.2. XML processing Model

Como j citado na seo 2.1, o Axis2 possui seu prprio mecanismo para
processamento de documentos XML, o AXIOM, que uma implementao de StAX
22

e pode ser manipulado como qualquer modelo de objeto. O AXIOM surgiu para
substituir o Document Object Model (DOM), que era utilizado como mecanismo de
processamento de XML no Axis1. A principal desvantagem de utilizao do DOM
que se faz necessrio carregar a mensagem completa em memria antes de iniciar o
processamento. No entanto, a principal vantagem da utilizao do AXIOM que os
objetos so criados apenas quando necessrio (instanciados sob demanda). Isso faz
com que o consumo de memria seja menor, aumentando significativamente o
desempenho.

2.2.3. SOAP processing Model

Esse componente responsvel por receber, enviar e processar
mensagens SOAP. Uma caracterstica da arquitetura do Axis2 que o processamento
de mensagens no ncleo do Axis2 feito exclusivamente atravs do protocolo SOAP,
ou seja, todas as mensagens devem ser convertidas para o formato SOAP antes de
serem processadas. A arquitetura do Axis2 prov dois fluxos para realizar duas aes
bsicas em mensagens SOAP. Essas aes esto representadas na classe
AxisEngine atravs dos mtodos send() e receive(). Os dois fluxos recebem o
nome de Out Pipe e In Pipe respectivamente e a combinao entre esses dois fluxos
dada atravs de MEPs. Esses fluxos trabalham em conjunto com os manipuladores
de mensagens. Os manipuladores atuam como interceptadores sobre parte da
mensagem SOAP que est sendo processada, provendo servios adicionais. Os
fluxos Out Pipe e In Pipe consistem de manipuladores de mensagens que tratam
exclusivamente da sada e entrada de mensagens respectivamente.

22
Streaming API for XML (StAX) uma especificao para linguagem Java identificada pela JSR 173
que prov uma API padro para manipulao de arquivos XML (JAYASINGHE; AZEEZ, 2011. p. 41).
26

2.2.4. Deployment Model

Esse componente prov um mecanismo concreto para configurao do
Axis2 que consiste de trs arquivos j definidos na seo 2.2.1: (i) axis2.xml; (ii)
services.xml; e (iii) module.xml.
Jayasinghe e Azeez (2011) definem que o Axis2 prov um mecanismo de
implantao semelhante quele definido pela especificao Java EE, alm do
conceito de deployer que prov uma maneira de implantao de servios simplificada.
Axis2 oferece ainda suporte aos conceitos de hot deployment e hot update, isto ,
respectivamente a capacidade de implantao e atualizao sem a necessidade de
parar o servio.

2.2.5. Client API

Esse mdulo consiste de uma API para criao de consumidores de Web
services e possui duas classes: (i) ServiceClient e (ii) OperationClient.
ServiceClient utilizada apenas para enviar e receber documentos XML. J
OperationClient utilizada para tarefas avanadas como trabalhar com
cabealhos de mensagens SOAP.
A classe ServiceClient conta com o mtodo sendRobust(), que
possui a funcionalidade de enviar uma requisio para um Web service, mas no
recebe um retorno (apenas uma exceo, caso ocorra algum erro). Apesar do Axis2
ser construdo para suportar qualquer interao entre mensagens, nativamente
suporta apenas dois MEPs: One-way e In-Out. One-way trata o fluxo da mensagem
unidirecional (entrada ou sada), enquanto que o In-Out trata mensagens nos dois
fluxos (entrada e sada). Os demais mtodos da classe ServiceClient so
baseados nesses dois MEPs. O mtodo fireAndForget() baseado no MEP One-
way e apenas envia uma requisio e no se encarrega de receber uma mensagem
de retorno, nem mesmo uma exceo. Os mtodos sendReceive() e
sendReceiveNonBlocking() so baseados no MEP In-Out e so utilizados para
enviar requisies e aguardar o retorno do Web service. O mtodo sendReceive()
o mais utilizado e o mtodo sendReceiveNonBlocking() utilizado apenas para
chamadas assncronas.

27

2.2.6. Transports

Axis2 possui duas construes bsicas para transportes: Transport
Senders e Transport Receivers e que podem ser definidos nas configuraes globais
do Axis2. atravs do Transport Receiver que o AxisEngine recebe as mensagens,
enquanto o Transport Sender responsvel por enviar mensagens. Mais importante,
o ncleo do Axis2 independente do tipo de transporte (sender ou receiver). Por fim,
Axis2 construdo com suporte aos seguintes protocolos de transporte: HTTP,
HTTPS, TCP, SMTP, JMS e XMPP.

2.2.7. Code Generation

Code Generation uma ferramenta disponibilizada pelo Axis2 que tem o
intuito de gerar cdigo-fonte para Web services e consumidores a partir de
documentos WSDL. Essa caracterstica recebe o nome de top-down, o que facilita e
agiliza o desenvolvimento de Web services. Algumas possibilidades de utilizao
dessa ferramenta se d atravs de plugins para o Maven e para IDEs como o Eclipse.

2.2.8. Data binding

No Axis2 o mdulo Data binding o responsvel por fazer o mapeamento
entre objetos Java e tipos de dados XML. Na arquitetura do Axis2 esse mdulo fica
fora do seu ncleo. Isso permite que um servio ou consumidor seja criado utilizando
diferentes frameworks de Data binding, por exemplo: Axis2 Data Binding (ADB),
XMLBeans, JibX e JAXB-RI.

2.3. Sistema Motivador

Com o intuito de demonstrar o funcionamento de um Web service utilizando
os dois frameworks estudados nesta monografia, foi construdo um sistema de
consulta de partidas de futebol. Basicamente, esse sistema recebe os parmetros
necessrios para efetuar uma consulta a uma partida de futebol e o retorno consistir
de dados relevantes da partida consultada, como pode ser observado na Figura 4.

28

Figura 4: Sistema motivador

O sistema motivador recebe como parmetros obrigatrios os nomes dos
dois times envolvidos e a data do jogo (opcionalmente pode ser informado a cidade
onde o jogo ocorreu). Aps realizar uma consulta na base histrica e caso encontre
alguma partida, retornado um objeto Partida. Esse objeto contm os nomes dos
times envolvidos, a data, cidade, placar e motivo da partida e as informaes
adicionais. A entidade Partida est descrita no Apndice I, assim como a classe
EfetuaConsultaPartida que realiza de fato a consulta e de fato independente
do framework de Web service utilizado.

2.4. Implementao do servio

O Axis2 suporta a criao de trs tipos servios: SOAP, RESTful e CORBA.
importante lembrar mais uma vez que o foco desta monografia nos Web services
clssicos, ou seja, baseados em XML utilizando protocolo SOAP. Para execuo dos
Web services necessrio a instalao do aplicativo axis2 para containers de
aplicaes web.
23
Um Web service desenvolvido em Axis2 deve sempre ser
implantado nesse aplicativo. A Figura 5 ilustra a estrutura de diretrio desse aplicativo
utilizando o Tomcat como container web.
Como pode ser visualizado na Figura 5, o aplicativo axis2 deve ser
implantado no diretrio webapps, que o diretrio onde todas as aplicaes
gerenciadas pelo Tomcat so armazenadas. O diretrio axis2-web armazena os
arquivos necessrios para acessar o aplicativo atravs de um navegador web. O
diretrio META-INF, possui o arquivo MANISFEST.MF, necessrio para o deploy deste
aplicativo no Tomcat. O diretrio WEB-INF armazena arquivos necessrios para
realizao de deploy de Web services. Os Web services podem ser publicados nos

23
http://axis.apache.org/axis2/java/core/download.cgi.
29

diretrios pojo ou services, de acordo com a abordagem utilizada para o seu
desenvolvimento (detalhada logo a seguir).

Figura 5: Estrutura de diretrios do aplicativo Axis2 para containers web.
Fonte: Do autor.

O Axis2 suporta quatro abordagens para o desenvolvimento de Web
services clssicos: (i) utilizao de AXIOM, que permite que o servio seja criado
utilizando a especificao StAX, baseando-se no objeto OMElement. Essa
abordagem exige que o arquivo services.xml seja configurado de forma especfica.
Assim, para publicar um Web service utilizando essa abordagem necessrio criar
um arquivo com a extenso .aar e o deploy deve ser realizado no diretrio
services. Para criao do arquivo .aar, pode-se utilizar o plugin axis2-aar-
maven-plugin para o Maven; (ii) utilizao do WSDL2Java, uma ferramenta que
permite criar Web services atravs de um documento WSDL, e possvel, entre outras
personalizaes, especificar o componente Data binding. Para publicar um Web
service atravs desse mtodo tambm necessrio criar um arquivo .aar; (iii)
utilizao de POJO
24
, que permite que a implementao do servio seja feita em uma
nica classe e somente sua verso compilada necessrio para a implantao do
servio (isto , o arquivo .class correspondente). Utilizando essa abordagem, o
deploy deve ser realizado no diretrio pojo do aplicativo Axis2. A utilizao de POJO

24
Plain Old Java Object (POJO) o nome dado quelas classes cuja regra de negcio implementada
em uma nica classe simples (FOWLER, 2013).
30

pode no ser a mais apropriada para criao de Web services, pois, realizar o deploy
de classes que utilizam pacotes, ou algum recurso da orientao a objetos uma
tarefa complexa; e (iv) utilizao de anotaes, que permite criar Web services
baseando-se na especificao JSR 181 (detalhada a seguir).
Em relao a utilizao de anotaes (item iv), o Axis2 oferece duas formas
principais para realizar o deploy de um Web service. A primeira consiste na criao
de um POJO, na qual a classe que representa o servio possui a implementao e as
anotaes necessrias. Porm, as desvantagens de utilizar POJO j foram
mencionadas e as caractersticas do sistema utilizado nesta monografia no permitem
que essa tcnica seja utilizada. A segunda forma semelhante criao de um POJO,
no entanto, utiliza-se o plugin axis2-aar-maven-plugin para criar um arquivo com
a extenso .aar, permitindo que o deploy seja realizado no diretrio services do
aplicativo Axis2. Apesar da utilizao de anotaes, necessrio a existncia do
arquivo services.xml para realizao do deploy do Web service. O cdigo abaixo
demonstra a classe que representa um Web service em Axis2. A implementao do
sistema motivador que de fato a implementao do servio est detalhado no
Apndice I.

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
package br.com.ismael;

import java.util.GregorianCalendar;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import br.com.ismael.EfetuaConsultaPartida;
import br.com.ismael.Partida;

@WebService(serviceName = "ConsultaPartida")
public class ConsultaPartida {

@WebMethod(operationName = "consultaPartida")
public Partida consultaPartida(@WebParam(name = "nomeTime1") String
nomeTime1, @WebParam(name = "nomeTime2") String nomeTime2,
@WebParam(name = "data") GregorianCalendar data,
@WebParam(name = "cidade") String cidade) {
return new EfetuaConsultaPartida().consultaPartida(nomeTime1,
nomeTime2, data, cidade);
}
}

Como pode ser observado no cdigo acima, a anotao @WebService
(linha 10) identifica essa classe como um Web service. A anotao @WebMethod
(linha 13) opcional e utilizada para customizar as operaes de Web service. Essa
31

anotao prov o nome da operao e os elementos de ao que sero utilizados
para customizar o atributo name do elemento operation e o elemento soapAction
no documento WSDL. Outra anotao (embora opcional) @WebParam (linhas 14, 15,
16 e 17) que utilizada para customizar o nome dos atributos da requisio. Caso no
seja utilizado, no documento WSDL so atribudos nomes padres para esses
parmetros.

2.5. Implementao do consumidor

Axis2 possui no seu ncleo uma API para criao de consumidores de Web
services j descrita na seo 2.2.5. Entre as opes j apresentadas demonstrada
a implementao de um consumidor com Axis2 utilizando a classe ServiceClient.
Os cdigos abaixo representam apenas parte da implementao do consumidor, o
cdigo-fonte completo encontra-se disponvel no Apndice II.

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
public OMElement getPartida(String nomeTime1, String nomeTime2,
GregorianCalendar data, String cidade) {

OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace omNs = fac.createOMNamespace("http://ismael.com.br",
"xs");
OMElement operacao = fac.createOMElement("consultaPartida",
omNs);
OMElement time1 = fac.createOMElement("nomeTime1", omNs);
time1.addChild(fac.createOMText(time1, nomeTime1));
operacao.addChild(time1);


OMElement dataPartida = fac.createOMElement("data", omNs);
XMLGregorianCalendar xmlGregorianCalendar = null;
try {
xmlGregorianCalendar = DatatypeFactory.newInstance().
newXMLGregorianCalendar(data);
} catch (DatatypeConfigurationException e) {
e.printStackTrace();
}
dataPartida.addChild(fac.createOMText(dataPartida,
xmlGregorianCalendar.toString()));
operacao.addChild(dataPartida);

OMElement cidadePartida = fac.createOMElement("cidade", omNs);
cidadePartida.addChild(fac.createOMText(cidadePartida, cidade));
operacao.addChild(cidadePartida);

return operacao;
}

32

Como j definido na seo 2.2.2, Axis2 utiliza AXIOM para processamento
de XML, que baseado na especificao StAX. O mtodo getPartida() (linhas 1
e 2) recebe os parmetros necessrios para invocar o servio consultaPartida. A
classe OMElement a base para processamento de XML utilizando StAX. Para
instanciar um OMElement necessrio utilizar o objeto OMFactory (linha 4) e definir
um namespace, por meio do objeto OMNamespace (linhas 5 e 6). A invocao do
mtodo createOMElement() (linhas 7, 9, 13, 17 e 29), como o prprio nome sugere,
cria novos objetos OMElement. Ele recebe como parmetro o nome de cada elemento
a ser procurado no documento WSDL dentro de um namespace especfico. Na linha
7 foi definido o elemento que representa a operao do Web service e os demais
elementos representam parmetros dessa operao. Cada parmetro de operao
especificado pelo parmetro correspondente do mtodo getPartida() (linhas 10,
14, 25 e 30) e adicionado ao elemento que corresponde a operao (linhas 11, 15, 27
e 31). O retorno do mtodo o objeto OMElement que representa a operao. A
seguir demonstrado um trecho de cdigo que utiliza o mtodo descrito acima.

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
EndpointReference endPoint = new EndpointReference(
"http://localhost:8080/axis2/services/ConsultaPartida");
ClienteAxis2 clienteAxis2 = new ClienteAxis2();
String[] dataSeparada = fieldData.getText().split("/");
XMLGregorianCalendar dataGregorian = DatatypeFactory.newInstance().
newXMLGregorianCalendar();
dataGregorian.setDay(new Integer(dataSeparada[0]));
dataGregorian.setMonth(new Integer(dataSeparada[1]));
dataGregorian.setYear(new Integer(dataSeparada[2]));
OMElement informacoesPartida = clienteAxis2.getPartida("Attico-MG",
"Cruzeiro", dataGregorian, null);
Options options = new Options();
options.setTo(endPoint);
options.setTransportInProtocol(Constants.TRANSPORT_HTTP);

ServiceClient cliente = new ServiceClient();
cliente.setOptions(options);
OMElement resposta = cliente.sendReceive(informacoesPartida);

O cdigo acima representa a implementao de fato do consumidor de
servios. Nele, indicado o endpoint que representa a URL do Web service (linha 1).
O mtodo getPartida() (linha 10) invocado para realizar o tratamento necessrio
para invocar o servio utilizando AXIOM. O objeto Options utilizado para definir
uma srie de parmetros que deseja adicionar a um ServiceClient. Nesse caso
foram especificados a URL do Web service (linha 13) e o protocolo de transporte
33

utilizado (linha 14). Por fim, o objeto ServiceClient instanciado (linha 16), recebe
o objeto options (linha 17) e o mtodo sendReceive() invocado (linha 18)
recebendo como parmetro um objeto OMElement e retorna um outro objeto do
mesmo tipo com o retorno do processamento do Web service.


Neste captulo foi abordado o Apache Axis2 que um framework
largamente utilizado para auxiliar no desenvolvimento de Web services baseados em
XML em REST para linguagem Java. Axis2 oferece suporte a vrios padres de Web
services, protocolos de mensagem e transporte atravs de uma arquitetura modular.
Essa arquitetura permite que alteraes sejam feitas e recursos novos sejam
adicionados ao Axis2 sem comprometer o seu ncleo, tornando essa arquitetura
bastante flexvel.
Axis2 tambm define um modelo para manipulao de informaes que
consiste em hierarquias de descrio e de contexto. A hierarquia de descrio
representa os arquivos de configurao do Axis2 e a hierarquia de contexto mantm
informaes dinmicas sobre objetos. Alm disso, Axis2 possui o prprio processador
de documentos XML o AXIOM que baseado na especificao StAX. Outra
caracterstica importante a utilizao de um aplicativo prprio para containers web
para realizao de deploy dos Web services. No intuito de prover uma implementao
de exemplo de servios e consumidores, foi especificado um sistema simples de
consulta de partidas de futebol.
Para implementar servios, notou-se que existem quatro abordagens
principais, sendo a abordagem por POJO menos apropriada, por limitaes tcnicas
desse padro e foi detalhado o desenvolvimento de Web service utilizando anotaes
definidas pela JSR 181. Por ltimo, notou-se que o Axis2 possui uma API no seu
ncleo para criao de consumidores de servio, sendo detalhada a criao desses
por meio da classe ServiceClient.
O prximo captulo aborda o Apache CXF, outro framework largamente
utilizado pelo mercado no desenvolvimento de Web services e consumidores para
Java. O objetivo do captulo 3 consiste em demonstrar a arquitetura desse framework
e como so desenvolvidos Web services e consumidores.

34

3. APACHE CXF

Apache CXF um framework open-source para a linguagem Java
amplamente utilizado pelo mercado que prov suporte na criao e consumo de Web
services utilizando as especificaes JAX-WS e JAX-RS. Ainda oferece suporte a
vrios protocolos de mensagem e transporte. Balani e Hathi (2009, p. 20 Traduo
nossa) afirmam que o CXF desenvolvido com a misso de prover uma infraestrutura
robusta para o desenvolvimento de Web services e facilitar o processo de
desenvolvimento.
Na seo 3.1 apresentado o surgimento desse framework, suas principais
caractersticas e ferramentas. Na seo 3.2 apresentada a arquitetura do CXF. Na
seo 3.3 demonstrado a implementao de um Web service utilizando Apache
CXF. Na seo 3.4 demonstrado como implementar um consumidor utilizando esse
framework e, por fim, na seo 3.5 so feitas as consideraes finais do captulo.

3.1. Viso geral

Apache CXF surgiu a partir de dois projetos: Celtix e XFire e, por isso, o
nome CXF. Celtix um projeto open-source ESB
25
baseado na linguagem Java
desenvolvido pela ObjectWeb, uma empresa que desenvolve solues open-source
de middleware. J o XFire um framework open-source baseado em Java para
desenvolvimento de Web services baseados no protocolo SOAP desenvolvido pela
Codehaus. Durante as verses iniciais de ambos os projetos, foi constatado que havia
muitas caractersticas em comum entre eles e que era possvel transform-los em um
nico projeto. A partir dessa constatao, foi desenvolvido com a ajuda da Apache
Software Foundation, o Apache CXF 2.0. Atualmente encontra-se na verso 2.7.4.
Apache CXF oferece suporte a vrios padres de Web services definidos
por rgos como W3C e OASIS, dos quais podemos destacar: SOAP, WS-I, WSDL,
WS-Addressing, WS-Discovery, WS-Policy, WS-ReliableMessaging, WS-Security,
WS-SecurityPolicy, WS-SecureConverstation, WS-MetadataExcange e parte do
padro WS-Trust. Sua arquitetura foi projetada para ser compatvel com vrios
protocolos de mensagens (por exemplo SOAP, REST/HTTP e XML) e transporte (por
exemplo, HTTP, JMS e TCP), diferentes formatos de arquivos (por exemplo,

25
Enterprise Service Bus (ESB) uma plataforma de integrao que conecta camadas de servios,
permitindo que os consumidores tenham acesso a esses servios (DIKMANS; LUTTIKHUIZEN, 2012).
35

documentos XML e JSON) e ferramentas de associaes de dados entre tipos Java e
XML (por exemplo, JAXB 2.x, Aegis, Apache XMLBeans, Service Data Objects (SDO)
e JiBX). Utiliza APIs que permitem ligaes adicionais ao CXF, fornecendo suporte a
outros formatos de mensagens tais como CORBA/IIOP. Outra caracterstica
importante do CXF a sua integrao com o Spring framework.
26
Essa integrao
permite utilizar arquivos de configurao do Spring framework para que a publicao
de endpoints seja feita de forma mais simples.
Apache CXF conta ainda com vrias ferramentas de apoio para o
desenvolvimento de servios e/ou consumidores. Segundo Apache CXF (2013),
existem ferramentas para gerao de cdigo, gerao de documentos WSDL, adio
de endpoints, gerao de arquivos de suporte e validao de arquivos. A Tabela 2
lista tais ferramentas classificadas de acordo com o seu tipo. Como um exemplo, a
ferramenta WSDL Validation auxilia o desenvolvedor na verificao de arquivos WSDL
criados.

TABELA 2 Ferramentas do Apache CXF
Tipo de Ferramenta Nomes
Gerao de cdigo
WSDL to Java, WSDL to JavaScript e Java to
JavaScript.
Gerao de documento WSDL
Java to WSDL, XSD to WSDL, IDL to WSDL e WSDL
to XML.
Adio de endpoints WSDL to SOAP, WSDL to CORBA e WSDL to service.
Gerao de arquivos de suporte WSDL to IDL.
Validao de arquivos WSDL Validation.
Fonte: Apache CXF (2013).

Web services desenvolvidos com CXF podem ser implantados em
servidores web Tomcat, por exemplo ou em servidores de aplicao robustos que
implementam a especificao Java EE, tais como Websphere, Weblogic, JBoss,
Geronimo e JOnAS. Ainda, podem ser implementados em servidores baseados em
SCA
27
como o Tuscany. CXF suporta tambm Web services implantados como
service engine em containers JBI
28
, como ServiceMix, OpenESB, e Petals.

26
Spring framework um framework de aplicaes em camadas criado para simplificar o
desenvolvimento de sistemas corporativos para a linguagem Java (BALANI; HATHI, 2009).
27
Service-component Architecture (SCA) um grupo de especificaes para o desenvolvimento de
aplicaes baseadas em SOA (SERVICE-COMPONENT ARCHITECTURE, 2013).
28
Java Business Integration (JBI) uma especificao definida pela JSR 208 que define uma
abordagem para implementar SOA utilizando WSDL (JAVA BUSINESS INTEGRATION, 2013).
36

3.2. Arquitetura

A arquitetura do CXF baseada nos componentes Bus, Front-end,
Messaging & Interceptors, Data binding, Service Model, Protocol bindings e Transport.
A Figura 6 ilustra os componentes desta arquitetura.

Figura 6: Componentes da arquitetura do Apache CXF.
Fonte: APACHE CXF (2013).

A Figura 6 mostra uma viso dos mdulos arquiteturais do Apache CXF.
uma arquitetura bem flexvel em que o componente Bus um provedor de recursos e
os demais componentes possuem responsabilidades especficas. As sub-sees
seguintes detalham cada componente dessa arquitetura.

3.2.1. Bus

Bus o componente principal da arquitetura do CXF. Ele um provedor de
recursos compartilhados para a execuo do CXF dos quais podemos destacar
gerenciadores de WSDL e binding factory. Esse componente pode ser configurado
para a incluso de recursos e/ou servios prprios ou modificao dos recursos
padres. Isso possvel devido a tcnicas de injeo de dependncia.
29
A
implementao padro deste componente baseada no Spring framework. A classe
SpringBusFactory responsvel por criar o Bus. Essa classe procura arquivos de
configurao localizados no diretrio META-INF/cxf do projeto e cria os respectivos
contextos de aplicao.

29
Injeo de dependncia uma tcnica que visa remover dependncias desnecessrias entre as
classes e ter um design de software que seja fcil de manter e evoluir (DEVMEDIA, 2013).
37

3.2.2. Front-end

Front-end prov um modelo de programao para interagir com o CXF e
cada implementao separada do restante do CXF. O CXF fornece as APIs de front-
end JAX-WS, JAX-RS, Simple e JavaScript e elas funcionam por meio de
interceptadores que so adicionados aos servios e endpoints.

3.2.3. Messaging & Interceptors

Messaging uma forma de estabelecer comunicao entre sistemas de
software atravs de trocas de mensagens, o que garante baixo acoplamento entre as
aplicaes envolvidas (HAASE, 2013). O CXF possui uma camada de Messaging
genrica composta por Messages, Interceptors e Interceptor chains que so
representados pelas interfaces Message, Interceptor e InterceptorChain,
respectivamente. O Interceptor a unidade fundamental dessa camada e um dos
elementos mais importantes da arquitetura do CXF. Seu objetivo interceptar as
mensagens trocadas entre clientes de Web services e componentes do servidor. No
CXF isso implementado atravs do conceito de Interceptor chains representando
pela classe PhaseInterceptorChain que segundo Balani e Hathi (2009, p. 43)
a funcionalidade principal da execuo do CXF e torna a arquitetura do CXF
bastante flexvel (APACHE CXF, 2013). A interceptao de mensagens pode ser
reconfigurada em qualquer ponto do processamento, provendo ao CXF a capacidade
de pausar e retomar as cadeias de interceptadores.
De um ponto de vista mais tcnico, a interface Interceptor possui o
mtodo handleMessage, que permite atuar sobre as mensagens. Um ponto
importante que os Interceptors so unilaterais e desconhecem qual tipo de
mensagem (requisio, resposta ou falha) esto lidando.

3.2.4. Data binding

Assim como no Axis2, Data binding o responsvel por fazer o
mapeamento entre objetos Java e tipos de dados XML. Os tipos de componentes data
binding que o CXF suporta so: JAXB, Aegis, Apache XMLBeans, SDO e JiBX (em
desenvolvimento). Dentre eles, o JAXB o padro adotado.

38

3.2.5. Service model

Service model a representao de um servio dentro do CXF e
constitudo de dois mdulos: ServiceInfo e o prprio Service. ServiceInfo
contm o modelo do servio baseado no documento WSDL juntamente com suas
operaes, ligaes, endpoints e schema. J o Service contm o ServiceInfo,
informaes sobre data binding, interceptadores e propriedades do servio, entre
outras informaes.

3.2.6. Protocol binding

Protocol binding o componente que define o protocolo de comunicao
utilizado pelos Web services. Bindings definem formas para mapear formatos
concretos e protocolos sobre a camada de transporte. Na arquitetura do CXF, uma
ligao contm duas classes principais: BindingFactory e Binding.
BindingFactory instancia um objeto Binding que contm interceptadores
especficos para realizar a ligao e tambm implementa o mtodo
createMessage() que cria uma implementao de Message especfica para esse
Binding. Atualmente, o CXF suporta os protocolos SOAP 1.1, SOAP 1.2,
REST/HTTP, CORBA e XML nativo.

3.2.7. Transport

Esse componente define um protocolo de alto nvel para transmisso de
mensagens. Dentro desse conceito, existe o elemento Conduit, que prov a base para
o envio de mensagens de sada. No CXF, a interface que representa o elemento
Conduit possui o mesmo nome e a implementao desse elemento representado
pela classe ConduitInitiator. A interface Conduit possui dois mtodos para
tratamento de mensagens: (i) prepare(message), que inicia o envio da mensagem;
e (ii) close(message), que fecha e descarta todos os recursos utilizados no envio
da mensagem. Atualmente, o CXF suporta os protocolos HTTP, HTTPS, HTTP-Jetty,
HTTP-OSGI, Servlet, local, JMS e In-VM, alm dos protocolos SMTP/POP3, TCP e
Jabber baseados no Apache Camel.

39

3.2.8. Modelo de processamento XML

Embora esse modelo no esteja ilustrado na Figura 6, importante
destacar que o CXF utiliza um padro internacional para processamento de XML, o
Fast Infoset. Trata-se de uma especificao que padroniza a codificao binria para
XML Information Set.
30
Sua principal caracterstica utilizar tcnicas para maximizar
a velocidade de processamento de documentos XML.

3.3. Implementao do Servio

O CXF suporta a implementao de trs tipos principais de servios: SOAP,
RESTful e CORBA. Como j definido anteriormente, o foco deste trabalho nos Web
services clssicos, ou seja, baseados em XML utilizando protocolo SOAP. Existem
quatro abordagens para implementao de servios utilizando o CXF: (i) WSDL2Java,
que um plugin que cria classes e interfaces Java de acordo com um documento
WSDL; (ii) JAX-WS Providers, que permite que os servios sejam criados a nvel de
mensagens, ao contrrio da utilizao do plugin e da abordagem tradicional (que
detalhada a seguir), que so criadas a nvel de operao. Utilizando essa abordagem,
existe apenas uma operao denominada invoke que recebe ou o contedo de uma
mensagem SOAP (SOAP Body) ou uma mensagem completa (SOAP Envelope); (iii)
mdulo presente no CXF que permite a criao de servios utilizando JavaScript
atravs da biblioteca Java Rhino; e (iv) criar classes Java utilizando anotaes
apropriadas, que a maneira mais tradicional de implementar servios utilizando o
CXF e detalhada a seguir.
Na seo 1.4, em que foi descrito o ambiente de desenvolvimento utilizado
nesta monografia, apontou-se o Maven como um dos elementos mais importantes
para agilizar o desenvolvimento dos Web services. Maven um gerenciador de
construo de projetos e possui o conceito de Archetype. Segundo Maven (2013),
Archetype um conjunto de ferramentas para auxiliar na construo de projetos
Maven. Existem Archetypes para vrios tipos de projetos Maven, inclusive para
criao de Web services utilizando o CXF.
31
Os passos para criao de um Web
service utilizando Maven descrito a seguir:

30
XML Information Set uma especificao que prov uma srie de definies que devem ser utilizadas
por outras especificaes que necessitam obter informaes de um documento XML (W3C, 2013).
31
No objetivo deste estudo demonstrar como criar um ambiente Maven. Detalhes de configurao
do ambiente Maven em: http://maven.apache.org/run-maven/index.html.
40

1. Em uma tela de terminal sob o diretrio do workspace efetue uma
busca nos repositrios Maven:
mvn archetype:generate -Dfilter=org.apache.cxf.archetype:
2. Selecione a opo:
org.apache.cxf.archetype:cxf-jaxws-javafirst (Creates a
project for developing a Web service starting from Java
code).
3. Selecione a ltima verso e defina a nomenclatura desejada.

Em seguida, basta importar o projeto no Eclipse. Ao importar o projeto,
possvel visualizar que a base para a criao de um Web service utilizando CXF est
pronta. A Figura 7 ilustra a estrutura do projeto no Eclipse sob a perspectiva Java EE.

Figura 7: Estrutura do projeto webservicecxf no Eclipse.
Fonte: Do autor.

No diretrio main foi criado um Service Endpoint Interface (SEI) chamado
HelloWorld.java. Um SEI definido como uma interface de Web service e
identificada atravs da anotao @WebService que adicionada antes da declarao
da interface. Essa interface deve expor os mtodos que podero ser invocados pelo
consumidor. Foi criado tambm atravs do Archetype a implementao do servio,
que recebeu o nome de HelloWorldImpl.java. Essa classe deve implementar a
41

SEI, ou seja, representa o servio. Essa classe tambm recebe a anotao
@WebService, porm, informado como parmetro o nome completo da interface
que representa o endpoint. Outro arquivo criado foi o beans.xml. Esse arquivo faz
parte do Spring framework e facilita a declarao de endpoints. Para declarar um
endpoint basta informar dentro da tag <jaxws:endpoint> um valor arbitrrio e nico
no campo id, o nome da classe que implementa o servio no campo implementor
e o endereo utilizado para acessar o Web service que deve igual ao nome da SEI e
declarado no campo address. Por ltimo, foi criada uma classe de teste chamada
HelloWorldImplTest.java. Essa classe representa um teste de unidade para o
servio criado.
importante ressaltar que o projeto criado atravs de um Archetype facilita
o desenvolvimento e o torna mais gil, porm apenas um exemplo. Isto , para
publicar o servio desejado devem ser feitas alteraes. O cdigo abaixo demostra a
SEI que publicar o servio implementado pelo sistema motivador desta monografia.
importante notar que seu nome foi alterado para ConsultaPartida.java. A
classe ConsultaPartidaImpl.java e o arquivo de configurao do Spring
framework beans.xml esto detalhados no Apndice III.

1. package br.com.ismael;
2.
3. import java.util.GregorianCalendar;
4. import javax.jws.WebMethod;
5. import javax.jws.WebParam;
6. import javax.jws.WebService;
7. import javax.xml.bind.annotation.XmlElement;
8. import br.com.ismael.Partida;
9.
10. @WebService
11. public interface ConsultaPartida {
12.
13. @WebMethod
14. Partida consultaPartida(@WebParam(name = "nomeTime1")
15. @XmlElement(required = true) String nomeTime1,
16. @WebParam(name = "nomeTime2") @XmlElement(required = true)
17. String nomeTime2, @WebParam(name = "data")
18. @XmlElement(required = true) GregorianCalendar data,
19. @WebParam(name = "cidade") @XmlElement(required = false)
20. String cidade);
21. }

A interface acima representa a descrio do servio a ser disponibilizado.
Essa SEI expe apenas um mtodo e esse recebe como parmetro o nome de dois
times, a data de realizao da partida e o nome de uma cidade e retorna um objeto
42

Partida contendo as informaes completas da partida. As anotaes utilizadas
para a implementao de um Web service com CXF so as mesmas utilizadas na
implementao com Axis2. A diferena a utilizao da anotao @XMLElement
(linhas 15, 16, 18 e 19), que faz parte do conjunto de anotaes definidas pela
especificao JAXB. Essa anotao permite customizar elementos XML e neste caso,
utilizou-se para definir elementos obrigatrios e opcionais da requisio. A Figura 8
ilustra o fluxo de uma mensagem durante o processamento de uma requisio de
acordo com a arquitetura do CXF.

Figura 8: Fluxo de uma mensagem no servidor CXF.
Fonte: APACHE CXF, 2013. (Adaptado pelo autor)

A requisio inicial interceptada pela cadeia de interceptadores que a manipula e a
repassa para a implementao do servio onde de fato processada. Aps essa etapa
o resultado do processamento da requisio (resposta) enviada para os Interceptors
chains que realizam as manipulaes e encaminha para o Conduit, onde a mensagem
preparada para ser enviada para o consumidor.

3.4. Implementao do consumidor

O CXF possui cinco diferentes abordagens para construo de
consumidores de Web services: (i) WSDL2java, que um plugin que cria classes Java
com base em um documento WSDL. Existem trs formas de utilizao desse plugin:
atravs da linha de comando, de um plugin Maven ou atravs da implementao da
API WSDL2Java; (ii) JAX-WS Proxy que um conceito presente na especificao
JAX-WS. Utilizando essa abordagem, necessrio criar instncias de servios
atravs da classe Service presente no pacote javax.ws e invoc-los: (iii) API
43

Dispatch, tambm presente no JAX-WS, a qual permite que servios sejam
invocados dinamicamente sem a necessidade de criar um cliente para isso. Basta criar
uma mensagem, envi-la para o servidor e aguardar o retorno: (iv) front-end Simple,
em que os consumidores so instanciados baseados em servios que so criados a
partir desse tipo de servio. O CXF possui a API ClientProxyFactoryBean. Essa
API cria um cliente do tipo Java Proxy, permitindo utilizar uma interface para se
comunicar com o Web service; e (v) Dynamic clients, a qual permite a criao de
consumidores de Web services em tempo de execuo. O cdigo abaixo demonstra
como criar um consumidor de Web services com CXF utilizando Dynamic clients. O
cdigo-fonte completo da classe abaixo demonstrado no Apndice III.

1.
DynamicClientFactory factory = DynamicClientFactory.newInstance();
2.
// Cria o cliente atravs do endereo do WSDL
3.
Client client = factory. createClient(
4.
"http://localhost:8080/webservicecxf/ConsultaPartida?wsdl");
5.
try {
6.
/*
7.
* Invoca o mtodo atravs do nome e informa os parmetros
8.
* necessrios para a execuo do mesmo
9.
*/
10.
Object[] obj = client.invoke("consultaPartida", "Atltico-MG",
11.
"Cruzeiro", null);
12.
} catch (Exception e1) {
13.

14.
}

O CXF possui a classe DynamicClientFactory (linha 1) que cria
clientes de Web services dinamicamente recebendo a URL do WSDL atravs do
mtodo createClient (linhas 3-4). Esse mtodo retorna um objeto Client (que
tambm faz parte do CXF). O objeto Client possui o mtodo invoke (linha 10) que
recebe o nome da operao e os parmetros necessrios para a execuo do servio.
O retorno um arranjo de java.lang.Object que armazena a resposta enviada
pelo servio e que pode ser manipulado da maneira necessria. A Figura 9 ilustra o
fluxo de envio e recebimento de mensagens em um consumidor de Web services de
acordo com a arquitetura do CXF.

44

Figura 9: Fluxo de uma mensagem no consumidor CXF.
Fonte: APACHE CXF, 2013. (Adaptado pelo autor)

A Figura 9 mostra como o processamento de uma mensagem para ser
enviada (requisio) e para ser recebida (resposta). Para ser enviada, a requisio
criada pelo consumidor, repassada para o Interceptor chain que realiza o tratamento
necessrio na mensagem para que a mesma seja enviada para o Web service atravs
do Conduit. Aps o processamento do Web service a resposta recebida pelo Conduit
que a envia diretamente para o consumidor. No entanto, uma outro Interceptor chain
pode interceptar essa mensagem, fazer algum tratamento e devolver a mensagem
para o consumidor.


Neste captulo foi abordado o Apache CXF. Trata-se de um framework
open-source que surgiu a partir de dois projetos Celtix e XFire. Em suma,
largamente utilizado para auxiliar no desenvolvimento de Web services para
linguagem Java seguindo as especificaes JAX-WS e JAX-RS e oferece suporte a
vrios padres de Web services, protocolos de mensagem e transporte.
Observou-se que a arquitetura do CXF bastante flexvel, principalmente
pelo mdulo Interceptor que responsvel por interceptar e tratar mensagens entre
clientes e servios e tal interceptao pode ser customizada de acordo com a
necessidade do desenvolvedor. Na implementao de servios, observou-se que o
CXF suporta vrias formas para implement-los, sendo a abordagem de criao de
classes Java utilizando anotaes especficas a mais empregada. A utilizao do
Maven torna o desenvolvimento de servios significativamente mais gil, pois o uso
45

de Archetypes gera um projeto de exemplo com classes e arquivos de configurao
pr-definidos, bastando ao desenvolvedor customiz-los de acordo com o servio que
deseja implementar. Por fim, na implementao de consumidores observou-se que o
CXF suporta tambm vrios mtodos e o mtodo demonstrado Dynamic clients
simples e flexvel, pois o seu retorno um arranjo de objetos genricos. Em outras
palavras, qualquer objeto suportado pela linguagem Java.
46

Concluso

A necessidade por troca de informaes em ambientes heterogneos, isto
, ambientes informatizados compostos por sistemas de softwares desenvolvidos em
diferentes linguagens de programao, fazem com que a utilizao de Web services
se apresente como a soluo mais apropriada. Web service consiste de componentes
de software que podem ser implementados em qualquer linguagem de programao
e tem por objetivo reutilizar componentes de software e/ou integrar sistemas de
software distintos. Essa caracterstica torna o Web service a tecnologia mais
apropriada para implementar sistemas de software na arquitetura SOA. Outra
caracterstica importante dos Web services a Composio, que capacidade de um
Web service se compor com outros servios.
Por ser uma tecnologia largamente utilizada pelo mercado para integrao
de sistemas, cada linguagem de programao possui sua prpria implementao de
Web services, o que motivou a criao de diversos frameworks para auxiliar no seu
desenvolvimento. Existem dois tipos de Web services: baseados em XML tambm
conhecidos como Web services clssicos e baseados em REST tambm
conhecidos como RESTful Web services. No entanto, o foco desta monografia se deu
na implementao de Web services baseados em XML utilizando a linguagem Java,
mais especificamente em dois dos frameworks mais utilizados pelo mercado: Axis2 e
CXF. Por outro lado, no foi abordado Web services baseados em REST devido
falta de padronizao e por no serem largamente utilizados quanto os Web services
clssicos.
Os captulos 2 e 3 abordaram respectivamente os frameworks Apache
Axis2 e Apache CXF. Como resultado da avaliao desses frameworks, a Tabela 3
prov uma anlise comparativa atravs de doze aspectos considerados os mais
relevantes. Baseando-se na Tabela 3, definido a seguir uma comparao de cada
aspecto citado entre os frameworks estudados.

1. Flexibilidade para adicionar novos recursos: O Axis2 possui uma arquitetura
modular que o torna muito interessante, pois algumas implementaes podem
ser feitas fora do seu ncleo e incorporadas ao framework. Durante os estudos
do CXF no foi identificado tal caracterstica. Nesse aspecto, o Axis2 se
mostrou superior ao CXF;

47

TABELA 3 Anlise comparativa entre os frameworks Axis2 e CXF
# Caracterstica Axis2 CXF
1
Flexibilidade para
adicionar novos
recursos
Possui. No possui.
2
Padres WS-*
suportados
WS-Addressing, WS-
ReliableMessaging, WS-
Coordination e WS-
AtomicTransaction e WS-
Security.
WS-I, WS-Addressing, WS-
Discovery, WS-Policy, WS-
ReliableMessaging, WS-
Security, WS-SecurityPolicy,
WS-SecureConverstation, WS-
MetadataExcange e parte do
padro WS-Trust.
3
Padro para
codificao de
documentos XML
AXIOM. Fast Infoset.
4
Protocolos de
comunicao
suportados
SOAP 1.1 e SOAP 1.2.
SOAP 1.1, SOAP 1.2,
REST/HTTP, CORBA e XML
nativo.
5
Protocolos de
transporte suportados
HTTP, HTTPS, TCP, SMTP,
JMS e XMPP.
HTTP, HTTPS, HTTP-Jetty,
HTTP-OSGI, Servlet, local,
JMS e In-VM, alm dos
protocolos SMTP/POP3, TCP
e Jabber baseados no Apache
Camel.
6
Padres Data binding
suportados
ADB, XMLBeans, JaxME,
JibX, JAXB-RI.
JAXB, Aegis, XMLBeans, SDO
e JiBX.
7
Criao de projetos
atravs de
Archetypes (Maven)
Apenas atravs de repositrios
no-oficiais e no utilizam a
especificao JAX-WS.
Suporta.
8
Ferramentas de
apoio
Descritas na Tabela 1 (seo
2.1).
Descritas na Tabela 2 (seo
3.1).
9
Formas de deploy de
Web services
O deploy deve ser feito
sempre no seu prprio
aplicativo para containers web,
utilizando POJO ou arquivo
com extenso prpria (.aar).
O deploy pode ser feito um
vrios tipos de containers web
e servidores de aplicao.
10
Formas de
desenvolvimento de
consumidores
Atravs de uma API prpria
presente na sua arquitetura.
Abordagens baseadas em
JAX-WS.
11
Formas de
depurao de erros
Atravs de testes de unidade
atravs da prpria IDE.
Permite que a depurao seja
feita como qualquer outra
aplicao, atravs de deploy
na prpria IDE.
12
Complexidade
32

Apresenta alta complexidade
para desenvolvimento de
servios e consumidores,
devido ao uso de muitos
arquivos de configurao e
tecnologias proprietrias para
processamento de
documentos XML e deploy de
servios.
Apresenta baixa
complexidade, pois possui
uma arquitetura fcil de ser
interpretada e busca
implementar apenas
especificaes definidas pela
comunidade Java e j
consolidadas.

32
A complexidade entre os dois frameworks foi analisada a partir de um nico programador que possui
trs anos de experincia com a linguagem Java e o autor desta monografia (Nota do autor).
48

2. Padres WS-* suportados: Apesar de no implementar os padres WS-
Coordination e WS-AtomicTransaction, o CXF mais completo, isto , conta
com uma quantidade maior de especificaes implementadas em relao ao
Axis2. Por isso, nesse aspecto o CXF superior ao Axis2;

3. Padro para codificao de documentos XML: O Axis2 conta com seu
prprio mecanismo para processamento de documentos XML o AXIOM que
possui como caracterstica principal garantir alto desempenho. Por outro lado,
o CXF utiliza um padro internacional para essa tarefa: o Fast Infoset. Sua
caracterstica principal tambm garantir um alto desempenho, porm,
utilizando outras tcnicas. Por utilizar um padro internacional, o CXF
superior ao Axis2 tambm nesse aspecto;

4. Protocolos de comunicao suportados: O Axis2 suporta diferentes tipos de
formatos de mensagens, mas, implementa apenas o protocolo de comunicao
SOAP 1.1 e 1.2. Internamente, todas as mensagens so convertidas para o
protocolo SOAP, o que uma limitao da arquitetura. J o CXF suporta, alm
dos mesmos protocolos do Axis2, os protocolos REST/HTTP, CORBA e XML
nativo, fazendo com que nesse aspecto tambm o CXF seja superior ao Axis2;

5. Protocolos de transporte suportados: Nesse aspecto o CXF se mostra
superior ao Axis2, pois implementa um nmero maior de protocolos de
transporte;

6. Padres Data binding suportados: Nesse aspecto, ambos os frameworks
implementam praticamente os mesmos padres de Data binding, com algumas
excees. A principal diferena est no padro que cada um adota. O Axis2
adota como padro seu prprio mecanismo de Data binding o ADB ,
enquanto o CXF implementa o padro JAXB, que o mesmo utilizado pela
especificao JAX-WS. Por utilizar um padro mais empregado, nesse
aspecto, o CXF novamente se mostra superior ao Axis2;

7. Criao de projetos atravs de Archetypes (Maven): O Axis2 no possui um
Archetype nos repositrios oficiais do Maven. Durante os estudos foi
encontrado um repositrio no-oficial, porm, a utilizao destes pode ser um
49

problema, pois depende de quem desenvolve o Archetype atualizar para as
verses mais atuais do framework utilizado. Por outro lado, o CXF possui
Archetypes nos repositrios oficiais do Maven e, portanto, o CXF se mostra
superior ao Axis2;

8. Ferramentas de apoio: O Axis2 conta com uma srie de ferramentas de apoio,
principalmente para IDEs e gerao de cdigo, porm, o CXF apresenta um
nmero maior de ferramentas e, reconhecidamente teis para integrao de
sistemas;

9. Formas de deploy de Web services: O deploy de todos os Web services
desenvolvidos com Axis2 devem ser realizados em um aplicativo especfico do
Axis2. O deploy desse aplicativo, por sua vez, pode ser realizado em qualquer
container web ou servidor de aplicao que suporte a extenso .war. Isso
torna o deploy de Web services bem flexvel, porm, as opes para criao
de Web services no so to flexveis. A opo mais vivel a criao de um
Web service com a extenso .aar e para isso necessrio utilizar um plugin
para o Maven. Por outro lado, o deploy de um Web service construdo com CXF
tambm pode ser feito em vrios tipos de containers web ou servidores de
aplicao, com a vantagem de ser construdo seguindo a especificao JAX-
WS e no ser necessrio um aplicativo extra, ou seja, o deploy pode ser feito
diretamente. Nesse aspecto, mais uma vez, o CXF se mostra superior ao Axis2;

10. Formas de desenvolvimento de consumidores: Durante o desenvolvimento
do consumidor com Axis2, utilizando AXIOM, notou-se que uma tarefa
complexa, principalmente pela necessidade de preencher um objeto
OMElement. J o CXF implementa consumidores de Web services baseados
na especificao JAX-WS e possui opes mais produtivas. Nesse aspecto o
CXF se mostrou tambm superior ao Axis2;

11. Formas de depurao de erros: Durante os estudos do Axis2 a nica forma
encontrada para realizar depurao de erros foi atravs de testes de unidade.
Por outro lado, com o CXF foi possvel configurar um container web diretamente
na IDE e realizar o deploy do Web service e realizar a depurao de erros em
um ambiente real. Logo, o CXF mostrou-se mais uma vez superior ao Axis2;
50

12. Complexidade: Levando em considerao a experincia do autor desta
monografia com desenvolvimento de sistemas Java, pode-se afirmar que
desenvolver Web services e consumidores com Axis2 uma tarefa mais
complexa do que com o CXF devido principalmente a: (i) Axis2 requer trs
arquivos de configurao para efetuar o deploy de um Web service, enquanto
que o CXF requer apenas um arquivo de configurao e as demais informaes
so obtidas atravs de anotaes Java; (ii) no seguir especificaes
consolidadas para processamento de documentos XML e Data binding, como
adotado pelo CXF; e (iii) no possuir uma forma produtiva para depurao.

Em concluso, o uso mais amplo do Axis2 se deve ao fato de ser um
framework legado e, portanto, j ser adotado nas fbricas de software h mais tempo.
No entanto, a avaliao comparativa dos frameworks permite concluir que o CXF tem
diversas vantagens sobre o Axis2 tais como implementao de um diversidade
maior de especificaes WS-*, seguir especificaes j consolidadas, possuir suporte
do Maven para criao de Web services atravs de Archetypes, possuir uma grande
quantidade de ferramentas de apoio e tambm pelo fato do processo de
desenvolvimento e implantao de Web services ser relativamente fcil e, portanto,
deveria ser o padro atualmente adotado por fbricas de software.
51

REFERNCIAS

APACHE AXIS2. Disponvel em: <http://axis.apache.org/axis2/java/core/>. Acesso
em: 11 maio 2013.

APACHE CXF. Disponvel em: <http://cxf.apache.org>. Acesso em: 27 abr. 2013.

API. Disponvel em: <http://www.webopedia.com/TERM/A/API.html>. Acesso em: 16
mar. 2013.

CORBA FAQ. OMG. Disponvel em: <http://www.omg.org/gettingstarted/
corbafaq.htm>. Acesso em: 02 jun. 2013.

BALANI, Naveen; HATHI, Rajeev. Apache CXF Web Service Development.
Birmingham: Packt Publishing, 2009.

DEITEL, Harvey M. Xml: como programar. Traduo de Luiz Augusto Salgado e
Edson Furmankiewicz. Porto Alegre: Bookman, 2003.

DEVMEDIA. Padro de Injeo de Dependncia. Disponvel em: <http://www.
devmedia.com.br/padrao-de-injecao-de-dependencia/18506>. Acesso em: 04 maio
2013.

DIKMANS, Lonneke; LUTTIKHUIZEN, Ronald van. SOA Made Simple. Birmingham:
Packt Publishing, 2012.

ENDPOINT REFERENCE. W3C. Disponvel em: <http://www.w3.org/Submission/ws-
addressing/#_Toc77464317>. Acesso em: 17 abr. 2013.

ERL, Thomas. SOA: princpios de design de servios. Traduo de Carlos
Schafranski e Edson Furmankiewicz. So Paulo: Pearson, 2009.

FAYAD, M. E.; SCHMIDT, D. C. Object-oriented Application frameworks.
Communications of the ACM. New York, p. 32-38, out. 1997.

FIELDING, T. Roy. Architectural Styles and the Design of Network-based
Software Architectures. Disponvel em: <http://www.ics.uci.edu/~fielding/pubs/
dissertation/top.htm>. Acesso em: 15 mar. 2013.

FOWLER, Martin. Disponvel em: <http://www.martinfowler.com>. Acesso em: 30
maio 2013.

HAASE, Kim. Java Message Service API Tutorial.
Disponvel em: <http://docs.oracle.com/javaee/1.3/jms/tutorial/jms_tutorial-
1_3_1.pdf>. Acesso em: 27 maio 2013.

HOHPE Gregor; WOOLF Bobby. Enterprise Integration Patterns: Designing,
Building, and Deploying Messaging Solutions, [S.I], Addison-Wesley Professional,
2003.

52

HTML INTRODUCTION. W3SCHOOLS. Disponvel em: <http://w3schools.com/html/
html_intro.asp>. Acesso em: 01 abr. 2013.

JAVA BEANS. ORACLE. Disponvel em: <http://docs.oracle.com/javase/tutorial/
javabeans/>. Acesso em: 23 abr. 2013.

JAVA BUSINESS INTEGRATION. SearchSOA. Disponvel em:
<http://searchsoa.techtarget.com/definition/Java-Business-Integration>. Acesso em:
30 abr. 2013.

JAVAWORLD. XFire: The easy and simple way to develop Web services
Disponvel em: <http://www.javaworld.com/javaworld/jw-05-2006/jw-0501-
xfire.html>. Acesso em: 19 abr. 2013.

JAYASINGHE, Deepal; AZEEZ, Afkham. Apache Axis2 Web Services.
Birmingham: 2. ed. Packt Publishing, 2011.

JCP. Disponvel em: <http://www.jcp.org>. Acesso em: 17 abr. 2013.

KALIN, Martin. Java Web Services: Up and Running. OReilly Media, 2009.

KOCH, Christopher. ABC da SOA. Disponvel em: <http://cio.uol.com.br/tecnologia
/2006/07/17/idgnoticia.2006-07-17.3732358054/>. Acesso em: 14 mar. 2013.

MARSHALL, Dave. Remote Procedure Calls. Disponvel em: <http://www.cs.cf.ac.
uk/Dave/C/node33.html>. Acesso em: 13 mar. 2013.

MAVEN. Disponvel em: <http://maven.apache.org>. Acesso em: 05 maio 2013.

MEPS. W3C. Disponvel em: <http://www.w3.org/2002/ws/cg/2/07/meps.html>.
Acesso em: 28 maio 2013.

OMG. Disponvel em: <http://www.omg.org/gettingstarted/gettingstartedindex.htm>.
Acesso em: 02 jun. 2013.

OPENSOURCE. Disponvel em: <http://opensource.org/osd>. Acesso em: 23 abr.
2013.

PROCESSING INSTRUCTIONS. W3C. Disponvel em: <http://www.w3.org/TR/REC-
xml/#sec-pi>. Acesso em: 17 abr. 2013.

RICHARDSON, Michael. Concept: Enterprise Application Integration. Disponvel em:
<http://www.michael-richardson.com/rup_classic/modernize.legacy_evol/guidances/
concepts/enterprise_application_integration_3CEC2399.html>. Acesso em: 11 mar.
2013.

SERVICE-COMPONENT ARCHITECTURE. SearchSOA. Disponvel em:
<http://searchsoa.techtarget.com/definition/service-component-architecture>. Acesso
em: 30 abr. 2013.

53

SOMMERVILLE, Ian. Engenharia de Software. Traduo de Maurcio de Andrade.
6. ed. So Paulo: Pearson, 2003.

TANENBAUM, Andrew S.; WETHERALL, David. Redes de Computadores.
Traduo de Daniel Vieira. 5. ed. So Paulo: Pearson, 2011.

TI EXPERT. Annotations. Disponvel em: <http://www.tiexpert.net/programacao/
java/annotations.php>. Acesso em: 23 abr. 2013.

W3C. Disponvel em: <http://www.w3.org>. Acesso em: 17 abr. 2013.

W3SCHOOLS. Disponvel em: <http://www.w3schools.com>. Acesso em: 01 abr.
2013.

54

APNDICE I Implementao do sistema motivador

Este apndice apresenta o cdigo fonte de duas classes relevantes na
implementao do sistema motivador: (i) Partida, que a classe responsvel por
armazenar as informaes relevantes de uma partida;

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.


/**
* Classe que representa uma partida de futebol.
* @author Ismael
*/
public class Partida {

private String time1;
private String time2;
private String resultado;
private String cidade;
private String motivo;
private String informacoesAdicionais;
private GregorianCalendar data;

public Partida(String time1, String time2, String resultado,
GregorianCalendar data, String cidade, String motivo,
String informacoesAdicionais) {
this.time1 = time1;
this.time2 = time2;
this.data = data;
this.resultado = resultado;
this.cidade = cidade;
this.motivo = motivo;
this.informacoesAdicionais = informacoesAdicionais;
}

public Partida() {
}

/*
* Mtodos acessores para todos os atributos privados da classe.
*/
@Override
public String toString() {
return this.getTime1() + " x " + this.getTime2() + ": " +
this.getResultado() + " - " + this.getCidade() + " - "
+ this.getMotivo() + " - " + this.getInformacoesAdicionais();
}

public GregorianCalendar getData() {
return data;
}

public void setData(GregorianCalendar data) {
this.data = data;
}
}
55

e (ii) EfetuaConsultaPartida, que a classe que de fato efetua a consulta na
base de dados. Por motivos de simplicidade, o cdigo de consulta a um SGBD no foi
includo e, portanto, um objeto Partida com valores pr-fixados sempre retornado.

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.


/**
* Classe que consulta o resultado de um jogo.
* @author Ismael
*/
public class EfetuaConsultaPartida {

/**
* Atravs do nome dos times envolvidos e da cidade onde foi
* realizado o confronto (opcional), retorna os dados
* relevantes da partida, como resultado, motivo e informaes
* adicionais.
*
* @param nomeTime1
* @param nomeTime2
* @param data
* @param cidade
* @return Objeto {@link Partida} contendo as principais
* informaes da partida requisitada.
*/
public Partida consultaPartida(String time1, String time2,
return new Partida(time1, time2, "2x1", data, cidade, "Amistoso",
"Foi um jogo muito truncado, com muitas faltas e expulses");
}

}

56

APNDICE II Implementao Axis2

Este apndice apresenta a classe ClienteAxis2, que representa a
implementao de um consumidor de servios com Axis2.

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.

import java.awt.BorderLayout;
import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.Iterator;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JOptionPane;
import javax.swing.JPanel;
import javax.swing.JTextField;
import javax.xml.datatype.DatatypeFactory;
import javax.xml.datatype.XMLGregorianCalendar;
import org.apache.axiom.om.OMAbstractFactory;
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.OMFactory;
import org.apache.axiom.om.OMNamespace;
import org.apache.axis2.Constants;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.Options;
import org.apache.axis2.client.ServiceClient;

/**
* Classe que representa um consumidor de web services feito com
* Axis2.
* @author Ismael
*/
public class ClienteAxis2 {

private JFrame frame;
private JPanel panel;
private JPanel panelTimes;
private JPanel panelResultado;
private JLabel labelTime1;
private JLabel labelData;
private JTextField fieldTime1;
private JTextField fieldData;
private JLabel labelCidade;
private JTextField fieldCidade;
private JButton consultar;
private JButton cancelar;

public ClienteAxis2() {
this.frame = new JFrame("Consulta de partidas de futebol");
this.panel = new JPanel();
this.panelTimes = new JPanel();
this.panelResultado = new JPanel();
this.labelTime1 = new JLabel("Informe o time 1: ");
this.fieldTime1 = new JTextField(30);
57

54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
this.labelData = new JLabel("Informe a data da Partida: ");
this.fieldData = new JTextField(10);
this.labelCidade = new JLabel("Cidade (opcional): ");
this.fieldCidade = new JTextField(30);
this.consultar = new JButton("Consultar Partida");
this.cancelar = new JButton("Cancelar");
}

public void exibeInterfaceGrafica() {
panel.setLayout(new BorderLayout());
panelTimes.setLayout(new GridLayout(5, 2));
panelTimes.add(labelTime1);
panelTimes.add(fieldTime1);
panelTimes.add(labelData);
panelTimes.add(fieldData);
panelTimes.add(labelCidade);
panelTimes.add(fieldCidade);
consultar.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent e) {
try {
EndpointReference endPoint = new EndpointReference(
"http://localhost:8080/axis2/services/ConsultaPartida");
ClienteAxis2 clienteAxis2 = new ClienteAxis2();
XMLGregorianCalendar dataGregorian = DatatypeFactory.
newInstance().newXMLGregorianCalendar();
OMElement informacoesPartida = clienteAxis2.getPartida(
"Attico-MG", "Cruzeiro", dataGregorian, null);
Options options = new Options();
options.setTo(endPoint);
options.setTransportInProtocol(Constants.TRANSPORT_HTTP);

ServiceClient cliente = new ServiceClient();
cliente.setOptions(options);
OMElement resposta =
cliente.sendReceive(informacoesPartida);
Iterator<?> i = resposta.getChildElements();
while (i.hasNext()) {
Object object = i.next();
StringBuffer buffer = new StringBuffer();
buffer.append("Time 1: " + ((Partida)object).getTime1());
buffer.append("\n");
buffer.append("Time 2: " + ((Partida)object).getTime2());
buffer.append("Data: " + ((Partida) object).getData());
buffer.append("Resultado: " + ((Partida)object)
.getResultado());
buffer.append("Cidade: ");
if (((Partida) object).getCidade() != null) {
buffer.append(((Partida) object).getCidade());
}
58

115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
buffer.append("Motivo: " + ((Partida)object)
.getMotivo());
buffer.append("Informaes Adicionais: " + ((Partida)
object).getInformacoesAdicionais());
JOptionPane.showMessageDialog(null, buffer.toString(),
"RESULTADO DA CONSULTA",
JOptionPane.INFORMATION_MESSAGE);
}
e2.printStackTrace();
}
}
});
panelTimes.add(consultar);
cancelar.addActionListener(new ActionListener() {

System.exit(0);

}
});
panelTimes.add(cancelar);
panel.add(panelTimes, BorderLayout.NORTH);
panel.add(panelResultado, BorderLayout.SOUTH);
frame.add(panel);
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}

public OMElement getPartida(String nomeTime1, String nomeTime2,
XMLGregorianCalendar data, String cidade) {
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace omNs = fac.createOMNamespace("http://ismael.com.br",
"xs");

OMElement operacao = fac.createOMElement("consultaPartida",
omNs);

OMElement dataPartida = fac.createOMElement("data", omNs);
dataPartida.addChild(fac.createOMText(dataPartida,
data.toXMLFormat()));
operacao.addChild(dataPartida);
OMElement cidadePartida = fac.createOMElement("cidade", omNs);
cidadePartida.addChild(fac.createOMText(cidadePartida, cidade));
operacao.addChild(cidadePartida);

return operacao;
}

public static void main(String[] args) {

59

176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
ClienteAxis2 cliente = new ClienteAxis2();
cliente.exibeInterfaceGrafica();

}

/*
*/

}

60

APNDICE III Implementao CXF

Este apndice apresenta o cdigo fonte de duas classes e um documento
XML que representa um arquivo de configurao: (i) ConsultaPartidaImpl,
representa a implementao de um Web service com CXF;

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

import javax.jws.WebService;
import br.com.ismael.Partida;

@WebService(endpointInterface = "br.com.ismael.ConsultaPartida")
public class ConsultaPartidaImpl implements ConsultaPartida {

@Override
public Partida consultaPartida(String nomeTime1, String nomeTime2,
return new EfetuaConsultaPartida().consultaPartida(nomeTime1,
nomeTime2, data, cidade);
}

}

(ii) ClienteCXF, que representa um consumidor de servios com CXF;

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.

import java.awt.BorderLayout;
import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JOptionPane;
import javax.swing.JPanel;
import javax.swing.JTextField;
import javax.xml.datatype.DatatypeFactory;
import javax.xml.datatype.XMLGregorianCalendar;
import org.apache.cxf.endpoint.Client;
import org.apache.cxf.endpoint.dynamic.DynamicClientFactory;

/**
* Classe que invoca um mtodo de um web service de forma dinmica
* atravs de um WSDL previamente publicado.
* @author Ismael
*/
public class ClienteCXF {

private JFrame frame;
private JPanel panel;
private JPanel panelTimes;
private JPanel panelResultado;
61

29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
private JLabel labelData;
private JTextField fieldData;
private JLabel labelCidade;
private JTextField fieldCidade;
private JButton consultar;
private JButton cancelar;

public ClienteCXF() {
this.frame = new JFrame("Consulta de partidas de futebol");
this.panel = new JPanel();
this.panelTimes = new JPanel();
this.panelResultado = new JPanel();
this.labelData = new JLabel("Informe a data da Partida: ");
this.fieldData = new JTextField(10);
this.labelCidade = new JLabel("Cidade (opcional): ");
this.fieldCidade = new JTextField(30);
this.consultar = new JButton("Consultar Partida");
this.cancelar = new JButton("Cancelar");
}

public void exibeInterfaceGrafica() {
panel.setLayout(new BorderLayout());
panelTimes.setLayout(new GridLayout(5, 2));
panelTimes.add(labelData);
panelTimes.add(fieldData);
panelTimes.add(labelCidade);
panelTimes.add(fieldCidade);
consultar.addActionListener(new ActionListener() {

@Override
DynamicClientFactory factory = DynamicClientFactory.
newInstance();
// Cria o cliente atravs do endereo do WSDL
Client client = factory.createClient(
"http://localhost:8080/webservicecxf/ConsultaPartida?wsdl");
try {
/*
* Invoca o servio atravs do nome da operao e
* informa os parmetros necessrios para a execuo do
* mesmo
*/
XMLGregorianCalendar dataGregorian = DatatypeFactory.
newInstance().newXMLGregorianCalendar();
Object[] obj = client.invoke("consultaPartida",
62

90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
fieldTime1.getText(), fieldTime2.getText(),
dataGregorian, fieldCidade.getText());
for (Object object : obj) {
StringBuffer buffer = new StringBuffer();
buffer.append("Time 1: " + ((Partida)
object).getTime1());
buffer.append("Time 2: " + ((Partida)
object).getTime2());
buffer.append("Data: " + ((Partida) object).getData());
buffer.append("Resultado: " + ((Partida)
object).getResultado());
buffer.append("Cidade: ");
if (((Partida) object).getCidade() != null) {
buffer.append(((Partida) object).getCidade());
}
buffer.append("Motivo: " + ((Partida)
object).getMotivo());
buffer.append("Informaes Adicionais: " + ((Partida)
object).getInformacoesAdicionais());
JOptionPane.showMessageDialog(null, buffer.toString(),
"RESULTADO DA CONSULTA",
JOptionPane.INFORMATION_MESSAGE);
}
e1.printStackTrace();
}
}
});
panelTimes.add(consultar);
cancelar.addActionListener(new ActionListener() {

@Override
System.exit(0);

}
});
panelTimes.add(cancelar);
panel.add(panelTimes, BorderLayout.NORTH);
panel.add(panelResultado, BorderLayout.SOUTH);
frame.add(panel);
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}

public static void main(String[] args) {

ClienteCXF cliente = new ClienteCXF();
cliente.exibeInterfaceGrafica();

}

/*
63

151.
152.
153.
154.
*/

}

e (iii) beans.xml, que representa o arquivo de configurao baseado no Spring
framework, necessrio para publicao de um Web service com CXF.

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jaxws="http://cxf.apache.org/jaxws"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd">

<import resource="classpath:META-INF/cxf/cxf.xml" />

<jaxws:endpoint id="consultaJogo" implementor=
"br.com.ismael.ConsultaPartidaImpl" address="/ConsultaPartida" />

</beans>

2013 Fumec Oliveirajunior

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2013 Fumec Oliveirajunior

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDADE FUMEC

FACULDADE DE CINCIAS EMPRESARIAIS FACE

Вам также может понравиться