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 legado1, 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 OMG2 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 HTTP3. 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 software4 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 frameworks5

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 XML8 (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 W3C9, 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.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

O exemplo acima ilustra o documento WSDL de um Web service de

consulta de termos em um glossrio. Nesse documento existem dois elementos

(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 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 (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 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 : 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 (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 do documento. O elemento (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 (linhas 15-19) define as

operaes expostas pelo elemento . 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

, , e .

Basicamente, o elemento identifica o documento XML como uma

mensagem SOAP, contm informaes de cabealho da mensagem,

armazena o contedo da mensagem transmitida e

armazena as informaes de status e erros. As regras sintticas para uma mensagem

SOAP so:

1. Obrigatoriamente ser codificada utilizando XML;

16

2. Utilizar namespaces10 padro SOAP Envelope e SOAP Encoding e

3. No conter referncias DTD11 e instrues de processamento XML12.

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. 6.

9.

10. 11. IBM 12. 13.

14.

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 (linhas 6-14) obrigatrio e utiliza dois

namespaces. Um se refere diretamente a esse elemento e o padro utilizado

definido por uma URI13: 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 (linhas 9-13) um elemento obrigatrio em uma

mensagem SOAP. Ele armazena o contedo da mensagem transmitida ao ltimo

endpoint14. 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

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 HTML15, XML ou JSON16.

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

15Segundo a HTML Introduction (2013), HTML a sigla para Hyper Text Markup Language e uma linguagem usada na criao de pginas web. 16JSON 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 anotaes17 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

JavaBeans18 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 source19 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 MEPs21

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 StAX22

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 POJO24, 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 time2 = fac.createOMElement("nomeTime2", omNs);

time2.addChild(fac.createOMText(time2, nomeTime2));

operacao.addChild(time2);

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.

2.6. Consideraes finais do captulo 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 ESB25 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

SCA27 como o Tuscany. CXF suporta tambm Web services implantados como

service engine em containers JBI28, 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 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.

3.5. Consideraes finais do captulo 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 implement

2013_fumec_oliveirajunior

Documents

Transcript of 2013_fumec_oliveirajunior