UNIVERSIDADE DE SAO PAULOInstituto de Ciencias Matematicas e de Computacao

ISSN - 0103-2585

WEB SERVICES TUTORIAL

Julio Cezar EstrellaRegina Helena Carlucci Santana

Marcos Jose Santana

No¯ 77

NOTAS DIDATICAS

Sao CarlosFev/2009

Web Services Tutorial

Julio Cezar Estrella, Regina Helena Carlucci Santana, Marcos Jose Santana

Departamento de Sistemas de ComputacaoGrupo de Sistemas Distribuıdos e Programacao Concorrente

Universidade de Sao Paulo - Instituto de Ciencias Matematicas e de Computacao{jcezar, rcs, mjs}@icmc.usp.br

http://www.lasdpc.icmc.usp.br

Resumo O proposito deste documento e prover uma breve introducaoda tecnologia de Web Services, seus protocolos e padroes, bem como des-crever o processo de instalacao e configuracao de um motor de processa-mento de mensagens SOAP denominado Apache Axis2. Web Services euma tecnologia relativamente recente que tem crescido rapidamente nosultimos anos em funcao da heterogeneidade da Web e do surgimento denovas aplicacoes distribuıdas em que o foco e a interoperabilidade.

1 Introducao

O termo Web Services tem sido muito abordado nos ultimos anos. Varias sao asdefinicoes apresentadas pela literatura. Uma definicao amplamente aceita apre-senta Web Services como um componente, ou unidade logica de aplicacao, aces-sıvel atraves de protocolos padroes da Internet, possuindo uma funcionalidadeque pode ser reutilizada sem a preocupacao de como e implementada. Web Ser-vices sao referenciados como a implementacao de uma arquitetura orientada aservicos - SOA - (Service Oriented Architecture) [3].

A W3C define o termo como uma aplicacao identificada por uma URI -(Uniform Resource Identifier), cujas interfaces e ligacoes sao definidas, descritase descobertas utilizando-se uma linguagem padrao como XML - Web Servicesocorrem tipicamente como chamadas SOAP - (Simple Object Access Protocol),protocolo de comunicacao baseado em XML (uma linguagem padronizada, ade-quada para descrever as interfaces dos Web Services, que sao acessıveis por umagrande variedade de plataformas e linguagens de programacao) para a intera-cao de aplicacoes [8]. SOAP e apresentado como um backbone para uma novageracao de aplicacoes de computacao distribuıda, independente de plataforma ede linguagens. Alem disso, as descricoes de interfaces dos Web Services sao ex-pressas usando uma linguagem denominada WSDL - (Web Service DescriptionLanguage) [10].

A pilha conceitual dos Web Services relaciona tres camadas principais: ca-mada fısica (wire layer), camada de descricao (description layer) e camada dedescoberta (discovery layer), mostradas na figura 1.

Para a construcao e utilizacao de Web Services e necessario considerar algu-mas especificacoes e tecnologias:

– Uma maneira de representar dados– Um formato de mensagens comum e extensıvel– Um mecanismo para localizar os servicos presentes em web sites especıficos– Um mecanismo para descobrir os provedores de servicos

Em resumo, um Web Service pode ser definido como um servico de softwarepublicado na Web atraves do protocolo SOAP [5], [6], descrito em uma interfaceWSDL e registrado num repositorio denominado UDDI [2]. Os protocolos acimacitados serao objetos de estudo nas proximas secoes deste documento.

2 XML

XML e o acronimo para eXtensible Markup Language. A informacao armazenadaem um documento XML e estruturada usando elementos e atributos, em que oselementos sao os nomes das tags:

<Element> ... </Element>

Os atributos, por sua vez, sao definidos dentro da tag Element.

<Element attribute= "..."> ... </Element>

Figura 1. Pilha conceitual dos Web Services [1]

2.1 XML Schema

XML Schema e uma maneira de definir a estrutura de documentos XML. Elepode ser utilizado para definir tipos de dados em um modelo de dados. Um docu-mento XML pode ser uma instancia de um XML Schema [11]. Tais documentosXML podem ser validados em oposicao ao Schema para verificar que ele esta emconformidade com o esquema. XML Schema pode ser comparado as definicoesde classes em programacao orientada a objetos. Nao apenas um tipo de dadoem um modelo de dados pode ser expressado em uma linguagem de computadorusando definicoes de classe, mas tambem tipos de dados podem ser expressadosusando XML Schema. Isto permite a troca de tipos de dados entre diferentes lin-guagens de programacao e plataformas. Esta importante caracterıstica do XMLe utilizada intensamente em Web Services.

Um dos usos mais comuns para schemas e verificar que um documento XMLe valido de acordo com um conjunto de regras definidas. Um schema pode serutilizado para validar [11]:

– A estrutura de elementos e atributos– A ordem de elementos– Os valores de dados de atributos e elementos, baseado em intervalos enume-

racoes e padroes de correspondencia– A singularidade dos valores em uma instancia

2.2 Namespaces

XML Namespace e um metodo para evitar conflito entre elementos com o mesmonome. Eles sao definidos por uma recomendacao da W3C chamado Namespacesem XML. Uma instancia XML pode conter elemento ou nomes de atributo demais de um vocabulario XML [14]. Se cada vocabulario possui um namespace,entao a ambiguidade entre elementos ou atributos com mesmo nome pode serresolvida, como mostrado a seguir:

<namespace:Element> ... </namespace:Element>

Para evitar repetir uma declaracao de namespace para cada elemento quelhe pertence, a declaracao de um prefixo pode ser feita em um elemento pai [9].Se, por exemplo, houver dois elementos com o nome ”element” e quisermos usardois namespaces separados para esses, e preciso escrever:

<ParentElement xmlns:ns1="http://meunamespace.com.br/NS1 xmlns:ns1="http://meunamespace.com.br/NS2><ns1:Element> ... </ns1:Element><ns2:Element/>

</ParentElement>

O primeiro Element no exemplo anterior pertence ao namespace,

– http://meunamespace.com.br/NS1,

enquanto o segundo pertence ao namespace,

– http://meunamespace.com.br/NS2.

O uso do endereco http para a declaracao do namespace e apenas uma con-vencao. Qualquer string pode ser utilizada.

3 Web Services

Um Web Service e um sistema de software construıdo para suportar interopera-bilidade na interacao entre maquinas sobre uma rede de computadores [13]. WebServices sao auto-contidos, auto-descritivos, modulares e independentes de pla-taformas e sistemas operacionais. Outros sistemas interagem com o Web Serviceem uma maneira prescrita pelo proprio Web Service, usando mensagens SOAP,normalmente transferida usando o protocolo HTTP. Devido ao alto nıvel de pa-dronizacao que os Web Services requerem, desenvolvedores consideram que sejafacil integra-los e reutiliza-los. Combinado com sua utilizacao generalizada, issoos fazem uma tecnologia adequada para a integracao de servicos. As plataformasde desenvolvimento mais populares e linguagens de programacao de alto nıvelproveem atualmente funcionalidades que tornam facil acessar os Web Services.

3.1 SOAP

SOAP, originalmente definido como (Simple Object Access Protocol) e um proto-colo usado para a troca de documentos XML entre Web Services [12]. SOAP in-troduz alguma estrutura adicional aos documentos XML. Uma mensagem SOAPe um elemento Envelope que consiste de um elemento Header e este por sua vezconsiste de um elemento Body [6].

<Envelope><Header> ... </Header><Body> ... <Body/>

</Envelope>

Esta estrutura permite a separacao de metadados contido no Header do pay-load da mensagem presente no elemento Body. Este metadado pode ser a infor-macao de roteamento, informacao de expiracao ou outra mensagem qualquer.Um motor de processamento SOAP tambem define:

– Um modelo de processamento– Um mecanismo de manipulacao de erros– Um modelo extensıvel– Um mecanismo para representacao de dados– Uma convencao para RPC (Remote Procedure Call)– Um framework para o binding de protocolo

3.2 Motores de processamento SOAP

Um motor de processamento SOAP e um framework utilizado em clientes eprovedores de Web Services, e apresenta como funcoes principais:

– A serializacao de objetos de uma linguagem de programacao em mensagensSOAP

– A deserializacao de mensagens SOAP em objetos em uma linguagem deprogramacao, ou seja, criar tipos de dados apropriados e popula-los com oconteudo da mensagem.

Para atuar como um motor de processamento SOAP, o Axis2 possui carac-terısticas importantes que facilitam a geracao automatica do codigo cliente eservidor do Web Service. Essa geracao automatica pe feita baseado em classesJava ou arquivos WSDL.

3.3 WSDL - Web Services Description Language

A interface de um Web Service e definida usando o formato XML denominadoWSDL. A interface e independente da implementacao do Web Service. Um do-cumento WSDL pode nao necessariamente parecer complexo a primeira vista,mas eles nao sao adequados para aleitura de seres humanos. Enquanto proveemum alto nıvel de flexibilidade em termo de interface para Web Services, os docu-mentos WSDL devem tambem permitir que o mapeamento WSDL-SOAP nao

seja ambıguo. Em outras palavras, a interface do Web Service deve sempre serinterpretada do mesmo modo por clientes que fazem o acesso. A especificacaoformal da WSDL pode ser encontrada em http://www.w3.org/TR/wsdl. Umdocumento WSDL define uma ou mais operacoes e as mensagens que elas rece-bem e retornam. Estas operacoes e mensagens sao primeiro descritas de formaabstrata e entao vinculados a uma ou mais instancias concretas em termos deprotocolo, formato de mensagem e endereco de rede, o que constitui o endpoint.Esta flexibilidade permite a reutilizacao de definicoes abstratas.

Um exemplo de documento WSDL e mostrado abaixo:

<definitions></types><message/><part/></message><portType></operation></portType><binding/><service></port></service></definitions>

Um documento WSDL consiste das seguintes partes:

– types: Declaracao de tipos de dados usando algum sistema de tipo (normal-mente XML Schema). Um XML Schema externo tambem pode ser impor-tado.

– message elements: Definicoes abstratas de o que pode ser comunicado, ouseja, mensagens de entrada e saıda e seus tipos de dados. Tipos de dados saodefinidos em elementos filhos denominados part e podem se referir aos tiposdeclarados nos elementos types descritos acima.

– portType: Um portType contem um ou mais elementos operation. Cadaoperacao especifica de forma abstrata uma acao suportada pelo servico e amensagem que pode ser enviada por/para o servico. O conjunto de operacoesem um PortType e suportado por um ou mais endpoints.

– binding: Um binding define o formato da mensagem e detalhes de protocolospara operacoes e mensagens definidas por um portType, ou seja, o mapea-mento WSDL-SOAP do servico (prevendo que o binding utiliza SOAP). Asregulacoes de formato de dados e codificacoes sao geralmente RPC/enco-ded, RPC/literal ou document/literal. Isto e tambem conhecido comoestilo do Web Service.

– service: Uma colecao de endpoints. Cada endpoint e representado por umelemento port e cada port define um endereco de rede e um nome para umbinding, determinando assim uma instancia de Web Service.

4 Desenvolvimento de Web Services

Nesta secao sera descrito como servicos funcionam sob a visao do provedor deWeb Services, ou seja, o que ocorre quando um Web Service do lado do provedorde servicos recebe uma mensagem SOAP de um Web Service cliente.

Como foi visto na secao anterior, um documento WSDL e usado para descre-ver a interface de um Web Service para os seus clientes. Um cliente nao necessitade qualquer conhecimento sobre o Web Service alem do que ele vai encontrar naWSDL. Do lado do provedor, o Web Service e responsavel por:

1. Deserializar mensagens SOAP que chegam do Web Service cliente2. Implementar um servico3. Serializar objetos resultantes em mensagens SOAP de reposta4. Enviar o resultado de volta ao Web Service cliente.

Uma engine SOAP e responsavel pela implementacao em baixo nıvel dos itens1 e 3 acima descritos. O codigo do servidor (chamado de stub do servidor) interagecom a engine SOAP de acordo com a funcionalidade do Web Service. O stub doservidor pode ser gerado automaticamente. E preciso haver uma correspondenciacompleta entre a interface WSDL e o stub do servidor, uma vez que o stub doservidor e a implementacao do que e descrito na WSDL. O codigo que implementaa logica do Web Service do lado do servidor e conhecido como codigo back-end.O codigo back-end pode conter qualquer coisa, que vai desde um sistema desoftware em larga escala com multiplas interfaces de usuario, ate poucas linhasde implementacao de codigo.

Os requisitos descritos anteriormente podem ser aplicados em um motor deprocessamento de mensagens SOAP como o Apache Axis2, ou qualquer outraplataforma de desenvolvimento de Web Services. Para construir um servico, duasalternativas possıveis sao mostradas a seguir:

1. Gerar o stub do servidor e um documento WSDL do codigo back-end exis-tente

2. Gerar o stub do servidor a partir de um arquivo WSDL e conecta-lo manu-almente com o codigo back-end.

O primeiro metodo e a mais rapida estrategia e requer pouco esforco doprogramador. Entretanto, o arquivo WSDL e o stub presentes no servidor saoprodutos da ferramenta com os quais eles foram gerados. Neste caso, o desenvol-vedor tem pouco controle sobre os detalhes da implementacao. Em alguns casos,o Web Service gerado pode somente ser entendido por clientes usando a mesmaferramenta para deserializacao.

Para permitir que a interface WSDL e o servico suportem rapidamente asnormas envolvidas e as melhores praticas, incluindo WS-I (Web Services Inte-roperability), um controle fino sobre o desenho do servico e primordial. Com aexistencia de ferramentas, desenvolvedores sao forcados a operar em um nıvelmais baixo e ter que desenhar o arquivo WSDL manualmente para asseguraruma boa interoperabilidade. Devido a este fato, a recomendacao e utilizar osegundo metodo na maioria das situacoes.

4.1 Estilos de Ligacao - Binding

Em um documento WSDL, um estilo de ligacao (binding) descreve o mapeamentoSOAP do Web Service, ou seja, como os tipos de dados recebidos e enviados peloWeb Service devem ser traduzidos/encapsulados em um envelope SOAP. Estepasso e caracterizado no binding do documento WSDL e implementado pelaengine SOAP utilizada. Um binding SOAP-WSDL pode ou ser no estilo RPC(Remote Procedure Call) ou no estilo Document. Assim, documentos de entradae saıda podem ser ou literal ou codificado (encoded).

Ha um estilo denominado literal/wrapped que segue algumas convencoesadicionais de como o servico e o documento WSDL devem ser construıdos. Emsuma, isto da origem a cinco diferentes estilos, embora somente quatro sejamutilizados na pratica:

1. RPC/encoded2. RPC/literal3. Document/literal4. Document/literal wrapped

Esta convencao de nomes RPC x Document e talvez infeliz, uma vez quenao ha erro em trabalhar com um Web Service estilo literal com operacoesque se comportem como chamadas remotas de procedimento. O termo RPCsimplesmente se refere a uma convencao indicando como deserializar objetospara SOAP, e nada mais. A recomendacao e usar o estilo Document/literalwrapped na maioria dos casos. Para saber mais sobre outros estilos e como elesse referem, consulte o site:

– http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/.

Este documento abordara somente o estilo Document/literal wrapped.

Estilo Document/literal wrapped

E um caso especial de estilo literal/wrapped. Este estilo define que qualquerdeclaracao de tipos de dados sao descritos usando XML Schema. As mensagensSOAP enviadas de/para um Web Service, seguindo este estilo, podem assim se-rem validadas em relacao a este equema, usando um validador XML. Isto e umacaracterıstica importante e muito util. Assim, cada parte da mensagem usadapara um mensagem de entrada deve se referir a um elemento apresentado nadeclaracao de tipo, que por sua vez possui o mesmo nome da operacao. Isto echamado de wrapper element. Sendo assim, o nome da operacao aparece na men-sagem SOAP de chegada/entrada. Para entender melhor esta abstracao, a seguirsera apresentado um exemplo de um servico com uma operacao denominada ge-tAddNumber. Esta operacao aceita dois numeros e retorna a soma destes comoresposta.

<types><schema<element name="getAddNumber"><complexType><numbers><element name="X" type="xsd:int"/><element name="Y" type="xsd:int"/><numbers/><complexType><element/>

<element name="getAddNumberResponse"><complexType><number><element name="numberResult" type="xsd:int"/><number/><complexType><element/><schema

<message name="getAddNumberRequest"/><part name="parameter" element="getAddNumber"/><message/>

<message name="getAddNumberResponse"/><part name="parameter" element="getAddNumberResponse"/>’<message/>

<portType name="XY"/><operation name="getAddNumber"/><input message="getAddNumberRequest"/><outuput message="getAddNumberResponse"/><operation/><portType/>

<binding ... />

Uma mensagem SOAP wrapped para uma requisicao de chegada/entrada deacordo com esta operacao, deve se parecer como:

<soap:envelope><soap:body><getAddNumber><X>1</X><Y>2<Y/><getAddNumber/><soap:body/><soap:envelope/>

Um estilo de Web Service literal/wrapped possui as seguintes caracterısti-cas:

– A mensagem de entrada/chegada na interface WSDL possui uma unica partque se refere a um elemento.

– O element wrapper tem o mesmo nome que o da operacao.– Nao ha qualquer atributo em element wrapper

O estilo apresenta algumas vantagens:

– Nao ha declaracao de tipos para variaveis em mensagens SOAP (oposto aoestilo encoded (codificado)).

– O corpo (body) da mensagem SOAP e definido por um XML Schema e podeser validado de acordo com este schema.

– O metodo name aparece em mensagens SOAP de entrada/chegada.

5 Web Services com Apache Axis2

O Axis2 e a evolucao natural da mais conhecida API - Application Program-ming Interface para Web Services nos dias atuais. Diferentemente do Axis 1.0, oAxis2 apresenta diversas melhorias, principalmente em relacao ao desempenhoe tambem em relacao a modularidade. A arquitetura do Axis2 e separada emcomponentes (modulos), e subdivide-se em componentes do nucleo e componen-tes nao pertencentes ao nucleo. Dentre as principais funcionalidades do Axis2destacam-se:

– Mecanismo de implantacao (deployment) com base na plataformaJava 2 Enterprise Edition (J2EE) - (baseado em arquivo): Recursos,arquivos de configuracao e binarios todos em um unico arquivo que descreveo servico.

– Hot deployment e hot update: Possibilidade de implantar atualizar ser-vicos sem reiniciar o servidor de aplicacao. No caso da atualizacao e reco-mendavel somente o uso em ambientes de teste.

– Presenca de um repositorio (onde se localizam os servicos e mo-dulos): Onde ficam armazenados os servicos que devem ser acessados pelosclientes.

– Mudancas na implantacao de manipuladores (modulos): Como aarquitetura do Axis2 e modular, tudo que nao e necessario estar no nucleo edisponibilizado como modulo. Esses modulos implementam as especificacoesde Web Services (WS-Policy, WS-Reliable, WS-Security).

– Novos descritores de implantacao:• Descritor Global (axis2.xml)• Descritor do Servico (services.xml)• Descritor do Modulo (module.xml)

O arquivo axis2.xml deve apresentar:

– Parametros do servico– Tipo de Transporte do Rementente– Tipo de Transporte do Emissor– Fases– Modulo Global

O arquivo services.xml deve ser caracterizado com as opcoes abaixo:

– Parametros de Nıvel de Servico– Descricao do Servico– Receptores de Mensagem– Operacao necessaria para expor o servico como uma operacao web

– Modulos de Nıvel de Servicos

O arquivo module.xml deve apresentar os seguintes parametros:

– Manipuladores e suas regras de fases– Parametros do modulo– Descricao sobre o modulo– Pontos finais (Endpoints) - No caso de utilizacao de mensagens confiaveis,

este parametro e fundamental

5.1 Componentes

O Axis2 e um motor de processamento de mensagens SOAP bastante modular.Sua divisao e baseada em componentes, como pode ser descrito na figura 2 edestacados a seguir:

Figura 2. Componentes do Axis2 [4]

– Componentes do nucleo:• AXIOM - Axis Object Model : Modelo de Objetos em XML• Modulo de Processamento SOAP : Framework Manipulador• Modelo de Processamento de Informacoes: Contextos e Descricoes

– Outros componentes:• Modelo de Deploy• Transportes• API Cliente• Modelo de Geracao de Codigo

O Axis2 possui um modelo de processamento XML mais adequado que oAxis1, que utilizava DOM - Document Object Model como um mecanismo derepresentacao XML. O DOM apresenta o problema de manter a hierarquia com-pleta dos objetos em memoria. No Axis2, qualquer mensagem que chega e repre-sentada no modelo AXIOM. As diferencas entre o Axis1 e Axis2 e a utilizacaode duas tecnicas: Pull e Push. Na tecnica denominada Pull o invocador tem ocontrole completo sobre o parser e pode perguntar sobre o proximo evento. Natecnica Pull, o parser procede ate atingir o final do documento. Na tecnica Pullo objeto e construıdo sob demanda, isto e, se for necessaria a sua construcao elesera instanciado e chamado.

5.2 Arquitetura de Implantacao - Deployment Architecture

Um mecanismo de implantacao de aplicacoes (deployment) baseada em reposi-torios e outra importante melhoria presente no Axis2. As principais partes destaarquitetura sao evidenciadas na figura 3 e descritas detalhadamente abaixo:

Figura 3. Arquitetura de implantacao do Apache Axis2 [4]

– Escalonador: Componente que informa ao listener para procurar por servi-cos no repositorio Listener : Busca por atualizacoes no repostorio de servicos

– Descritor do Parser: Um componente para processar os servicos e descri-tores de modulos para deploy : O componente central da implantacao (de-ployment) que faz todo o processamento logico

– Nucleo do Axis2: O Axis2 e independente da implantacao e vice-versa– Repositorio: Um diretorio no sistema de arquivos que armazena os servicos

implantados (deployed)

5.3 Ciclo de vida de um servico no Apache Axis2

Com a utilizacao do Axis2 e possıvel construir servicos que se comunicam atravesde trocas de mensagens no formato XML, utilizando como protocolo de trans-porte o HTTP. A figura 4 ilustra de modo simplificado como e um ciclo de vidade um servico.

Figura 4. Fluxo de dados entre cliente e provedor de um Web Service[7]

O Axis2 executa as seguintes tarefas:

– Cria mensagens SOAP– Recebe e processa mensagens SOAP– Cria um Web Service a partir de uma classe Java– Cria classes de implementacao para o servidor e o cliente, usando a WSDL– Recupera facilmente a WSDL para um servico– Envia e recebe mensagens SOAP com anexos– Cria ou utiliza servicos que tiram a vantagem dos padroes WS-Security, WS-

ReliableMessaging, WS-Addressing, WS-Coordination e WS-Atomic Tran-saction

Assumindo-se que o Axis2 execute tanto no cliente quanto no provedor deservicos, a interacao entre cliente e provedor deve seguir algumas fases:

– O cliente (emissor) envia uma mensagem SOAP– O manipulador do Axis2 realiza acoes necessarias de acordo com o que foi

definido pelo usuario– O modulo responsavel pelo transporte envia a mensagem– Do lado do receptor (provedor) a deteccao da mensagem e feita pelo modulo

responsavel por este finalidade– O responsavel pelo trasporte (transport listener) passa a mensagem para um

dos manipuladores do receptor (provedor)– Uma vez processada, a mensagem e entregue a aplicacao

Figura 5. Axis2 e manipulacao de mensagens [4]

A manipulacao das mensagens SOAP pelo Axis2 e mostrada na figura 5 aseguir:

O Axis2 permite quebrar as acoes na transmissao de mensagens em variasfases. Essas fases sao definidas como:

– Fases Pre-Definidas• Pre-Despacho• Despacho• Processamento de Mensagens

– Fases definidas pelo usuario: As fases pre-definidas sao invocadas inde-pendente do servico especificado. As fases definidas pelo usuario sao invoca-das quando o despachante encontrar uma operacao. Cada fase possui umacolecao de manipuladores. O Axis2 permite controlar quais manipuladoresestarao em quais fases e a ordem em que tais manipuladores sao executa-dos dentro de cada fase. O mais interessante e que pode ser adicionada umanova fase juntamente com seus respectivos manipuladores. Entenda-se pormanipuladores os modulos componentes do Axis2 [4]. Exemplos:• WS-Security• WS-Reliability

5.4 Outras caracterısticas do Axis2

Depois de apresentado as funcionalidades do Axis2 bem como sua divisao emcomponentes e modulos, sao mostrados nesta secao outras caracterısticas impor-tantes do Axis2. Como mencionado anteriormente, o Axis2 e um processador demensagens SOAP. Sendo assim, e preciso destacar que:

– Ele nao conhece WSDL– Tambem nao conhece nenhum esquema de transporte e databinding. Essas

funcionalidades sao feitas atraves de manipuladores/modulos– Suporta invocacao de mensagens assıncronas– Suporta 8 padroes de troca de mensagens definidas na WSDL 2.0– Apresenta o conceito de Fluxo (Colecao de Fases = Colecao Logica de Ma-

nipuladores)

Quanto a invocacao de um Web Service por parte de um cliente, o Axis2apresenta suporte a dois tipos de invocacao:

– Invocacao Nao-Bloqueante (Assıncrona): Neste caso, o cliente invocao servico sem bloquear a aplicacao

– Invocacao Bloqueante (Sıncrona): O cliente bloqueia a aplicacao ate quea resposta seja recebida

A invocacao pode ocorrer de dois modos:

– One-Way: Em geral utilizado juntamente com o protocolo SMTP– Two-Way: E utilizado com o protocolo HTTP

Para a invocacao de clientes Web Services, o Axis2 apresenta uma API sub-divida em duas classes:

– ServiceClient: Para usuarios que querem somente enviar e receber mensa-gens XML e nao se preocupam com atividades mais complexas como ma-nipular cabecalhos SOAP. Esta API possui alguns metodos para realizar ainvocacao de Web Services.• sendRobust: Envia mensagem XML e nao se preocupa com a resposta• fireAndForget: Envia mensagem XML e nao se preocupa com a res-

posta ou excecao.• sendReceive: Invoca um Web Service que tem um valor de retorno.

E o mais comum e pode ser usado para invocar o padrao de troca demensagem do tipo in-out

• sendReceiveNonBlocking: Para invocar um Web Service de modonao-bloqueante. Pode ser utilizado quando o Web Service tem um valorde retorno.

– OperationClient: Para usuarios que querem manipular cabecalhos SOAPe outras tarefas avancadas. A API Operation Client e indicada a usuariosavancados. Ao contrario da API Service Client em que o usuario nao precisaconhecer detalhes para invocar um Web Service, utilizar a API OperationClient requer a sequencua dos passos abaixo:1. Criar um Web Service cliente2. Criar um Operation Client usando o Service Client3. Criar um envelope SOAP4. Criar o contexto da Mensagem5. Adicionar envelope SOAP para o contexto da mensagem6. Adicionar o contexto da mensagem para o Operation Client7. Invocar o Operation Client8. Se houver uma resposta, obtenha como resposta o contexto da mensagem

para o Operation Client.

6 Instalacao e Configuracao do Ambiente de Programacaocom Axis2

Esta secao tem como objetivo conduzir um usuario iniciante ao processo deconfiguracao de um ambiente para a programacao de Web Services com Axis2,Java, Tomcat e Ant.

6.1 Donwload dos Fontes

Crie um diretorio chamado sources. Faca o download dos pacotes abaixo, e oscopie para o diretorio criado:

– axis2-1.3-bin.zip

• http://mirror.pop-sc.rnp.br/mirror/apache/ws/axis2/1 3/axis2-1.3-bin.zip– apache-tomcat-6.0.18.zip

• http://ftp.unicamp.br/pub/apache/tomcat/tomcat-6/v6.0.18/bin/apache-tomcat-6.0.18.zip

– apache-ant-1.7.0-bin.zip

• http://linorg.usp.br/apache/ant/binaries/apache-ant-1.7.0-bin.zip– jdk1.6.0 06

• http://java.sun.com

6.2 Descompactacao dos Fontes

Descompacte cada um dos arquivos (no caso do JDK, execute o binario que aca-bou de fazer o download e quando o script de instalacao perguntar em qual dire-torio deseja instalar a JVM - Java Virtual Machine, escolha /home/<nome-usuario>/environment/ ) e mova-os para o diretorio:

/home/<nome-usuario>/environment/

Depois de descompactados, parte da estrutura do diretorio /home/<nome-usuario>/environment/ deve ficar como mostrado a seguir:

– apache-ant-1.7.0– apache-tomcat-6.0.18– axis2-1.3– axis2.war

6.3 Configuracao do Classpath

E necessario, antes de iniciar a criacao de Web Services, setar algumas variaveisde ambiente. Em distribuicoes Linux isso pode ser feita de varios modos:

– No bashrc do usuario– No arquivo /etc/bash.bashrc

– No arquivo /etc/profile

Neste documento optaremos por anexar as informacoes das variaveis de am-biente no arquivo /home/<nome-usuario>/.bashrc. Para isso, edite estearquivo, e ao final acrescente as informacoes contidas na listagem 1:

Listagem 1 Arquivo .bashrc#Variavies de ambiente do JAVAJAVA_HOME=/home/<nome-usuario>/environment/jdk1.6.0_06JDK_HOME=/home/<nome-usuario>/environment/jdk1.6.0_06/binPATH=$JAVA_HOME/bin:$JDK_HOME:$PATHMAN_PATH=$MANPATH:$JAVA_HOME/man

#Variaveis de ambiente do CATALINACATALINA_HOME=/home/<nome-usuario>/environment/apache-tomcat-6.0.18

#Variaveis de ambiente do ANTANT_HOME=/home/<nome-usuario>/environment/apache-ant-1.7.0PATH=$ANT_HOME/bin:$PATH

AXIS2_CLASSPATH="."for i in ‘ls $AXIS2_HOME/lib/*.jar‘; doAXIS2_CLASSPATH=$AXIS2_CLASSPATH:$idone

CLASSPATH=.:$JDK_HOME:$JAVA_HOME/lib/tools.jar:$ANT_HOME:$AXIS2_HOME:$AXIS2_BIN:$AXIS2_CLASSPATH

export JDK_HOME JAVA_HOME PATH CLASSPATH MAN_PATH AXIS2_HOMEAXIS2_LIB AXIS2_BIN CATALINA_HOME

Listagem 2 Comando para a inicializacao do Tomcatroot@tucunare:~# /home/<nome-usuario>/environment/apache-tomcat-6.0.18/bin/startup.sh

Using CATALINA_BASE: /home/<nome-usuario>/environment/apache-tomcat-6.0.18Using CATALINA_HOME: /home/<nome-usuario>/environment/apache-tomcat-6.0.18Using CATALINA_TMPDIR: /home/<nome-usuario>/environment/apache-tomcat-6.0.18/tempUsing JRE_HOME: /home/<nome-usuario>/environment/jdk1.6.0_06

6.4 Teste das Configuracoes

Para o Ant, faca o teste a seguir:

root@tucunare:~# ant

Buildfile: build.xml does not exist!Build failed

Para o Tomcat, inicie-o com o comando o comando da listagem 2. O resultadodo comando e mostrado na mesma listagem.

Abra o navegador Firefox e digite:

http://localhost:8080

Se aparecer uma mensagem de boas-vindas e sinal de que o Tomcat foi confi-gurado corretamente. Antes de iniciar o teste do Axis2, e preciso copiar o arquivoaxis2-war para o diretorio webapps do Tomcat. Proceda de acordo com as ins-trucoes a seguir:

cd /home/<nome-usuario>/environment/cp axis2.war /home/<nome-usuario>/environment/apache-tomcat-6.0.18/webapps

Para confirmar o funcionamento do Axis2 abra o navegador Firefox e digite:

http://localhost:8080/axis2

Se aparecer uma mensagem de boas-vindas e sinal de que o Axis2 foi confi-gurado corretamente.

7 Exemplo de Aplicacao com o Apache Axis2

Este tutorial tem como objetivo criar uma aplicacao simples de web servicesutilizando o Axis2, a terceira geracao da implementacao de web services. Assume-se que todas as configuracoes foram efetuadas de acordo com a secao: Instalacao eConfiguracao do Ambiente de Programacao com Axis2 e que ao executar o clientedo web service voce tambem tenha o Axis2 instalado e configurado corretamente.

7.1 Primeira Etapa

A primeira etapa deste tutorial deve envolver primeiramente a criacao de umservico, na forma de uma classe java que sera acessada por um cliente do servico.Em seguida deve ser descrito como este servico deve ser acessado e qual o tipode transporte que cada operacao do servico deve suportar.

Criar o Servico :Antes de criar o servico que ficara disponıvel para o acessode um cliente web, vamos criar a estrutura de diretorios que deve ser usada nomomento de empacotar o servicos.

Crie um estrutura de diretorios de acordo com a listagem 3:

Listagem 3 Estrutura inicial do diretorio meuservicoservicos|--> meuservico

|--> META-INF

Crie um arquivo com o nome de MeuServico.java dentro do diretorio ( servicos) e adicione o codigo correpondente a listagem 4:

Descrever o arquivo services.xml :Depois de escrito o servico, e precisodescreve-lo para que o Axis2 saiba como manipula-lo. Crie um arquivo deno-minado services.xml dentro do diretorio META-INF (descrito anteriormente) eadicione o conteudo abaixo:

No arquivo services.xml sao descritos:

Listagem 4 Classe java correspondente ao servico implementadopublic class MeuServico {

public String ecoa(String valor) {return valor;

}}

Listagem 5 Arquivos services.xml<service>

<parameter name="ServiceClass"locked="false">MeuServico</parameter>

<operation name="ecoa"><messageReceiver

class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/></operation>

</service>

– O nome do servico;– O nome da operacao do servico, que sera exposta para acesso por um cliente

do web services;– O tipo de receptor de mensagem;

Compilar o Servico :Entre no diretorio servicos e compile o arquivo MeuSer-vico.java.

javac MeuServico.java -d meuservico

Um arquivo denominado MeuServico.class deve ser gerado como produto dacompilacao no diretorio meuservico.

7.2 Segunda Etapa

A segunda etapa envolve o empacotamento do servico e o deploy em um reposi-torio de servicos.

Empacotar o Servico :Antes de empacotar o servico, certifique-se de que aestrutura de diretorios seja como a mostrada a listagem 6:

Entre no diretorio meuservico:

cd servicos/meuservico

Faca o empacotamento:

jar -cvf MeuServico.aar

Apos o empacotamento a estrutura de diretorio deve ficar como mostra alistagem 7:

Listagem 6 Estrutura do diretorio servicos<service>servicos||--> MeuServico.java|---> meuservico

||--> MeuServico.class|---> META-INF

|--> services.xml

Listagem 7 Estrutura do diretorio servicos atualizadaservicos||--> MeuServico.java|---> meuservico

||--> MeuServico.class||--> MeuServico.aar|---> META-INF

|--> services.xml

Fazer o Deploy (Implantacao) em um Servidor de Aplicacao ou Con-tainer de Servlets : Neste momento e preciso copiar o pacote MeuServico.aarpara o diretorio services do Tomcat. Proceda de acordo com os passos abaixo:

1. cd servicos/meuservico2. cp MeuServico.aar /usr/local/apache-tomcat-6.0.14/webapps/axis2/WEB-

INF/services/

Verificar o Resultado do Deploy :Abra o browser e digite:

http://localhost:8080/axis2/services/listServices

Voce deve obter como resultado o nome do servico que acabou de ser implan-tado. A WSDL do servico e descrita na figura 6:

7.3 Terceira Etapa

A terceira etapa envolve a criacao dos stubs do servicos a partir da WSDL geradaanteriormente e tambem um cliente que deve fazer o acesso ao servico atravesdo stubs.

Figura 6. WSDL do servico

Gerar os Stubs do Servico A geracao dos stubs deve ser feita de acordo como comando abaixo:

1. cd servicos/meuservico2. /usr/local/axis2/bin/wsdl2java.sh -uri http://localhost:8080/axis2/services/MeuServico?wsdl

-o cliente

onde:

– -uri <caminho> identifica o caminho para a WSDL do servico;– -o <diretorio> identifica o diretorio onde sera armazenado os stubs do cli-

ente.

A partir deste momento a estrutura do diretorio meuservico deve ficar comomostra a listagem 8

Foram gerados os seguintes diretorios e arquivos:

– cliente– src– build.xml

E a partir dos stubs gerados que o cliente do servico pode fazer a ligacaocomo servico.

Listagem 8 Estrutura do diretorio meuservicoservicos||--> MeuServico.java|---> meuservico

||--> MeuServico.class|--> MeuServico.aar||--> cliente| |---> build.xml| || |---> src| |---> org| |---> apache| |---> ws| |---> axis2| |---> MeuServicoCallbackHandler.java| |---> MeuServicoStub.java||---> META-INF

|--> services.xml

Criar o Cliente do Servico :Com os stubs criados, agora e o momento deescrever uma aplicacao cliente que acessa o servico implementado. Assim, crieum arquivo com o nome de Cliente.java e acrescente o codigo da listagem 10:

Listagem 9 Cliente.java - Codigo correspondente ao cliente do servicopackage org.apache.ws.axis2;

import org.apache.ws.axis2.MeuServicoStub.EcoaResponse;

public class Cliente {

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

MeuServicoStub stub = new MeuServicoStub();

//Cria a requisic~ao para o servicoMeuServicoStub.Ecoa request;request = new MeuServicoStub.Ecoa();request.setParam0("Meu primeiro web service com Axis2");

//Invoca o servicoEcoaResponse response;response = stub.ecoa(request);

System.out.println("Resposta : " + response.get_return());}

}

Verifique como ficou a estrutura do diretorio meuservico na listagem 10,depois da criacao do arquivo Cliente.java 1:

Listagem 10 Cliente.java - Codigo correspondente ao cliente do servicoservicos||--> MeuServico.java|---> meuservico

||--> MeuServico.class|--> MeuServico.java|--> MeuServico.aar||--> cliente| |---> build.xml| || |---> src| |---> org| |---> apache| |---> ws| |---> axis2| |---> MeuServicoCallbackHandler.java| |---> MeuServicoStub.java| |---> Cliente.java||---> META-INF

|--> services.xml

Compilar e Executar o Cliente do Servico Na opcao escolhida para estetutorial, a compilacao do cliente deve ser feita sem o auxılio do ant. Compile oarquivo Cliente.java de acordo com os passos abaixo:

1. cd servicos/meuservico/cliente/src2. javac org/apache/ws/axis2/Cliente.java -d ../../cliente

A estrutura de diretorios depois da geracao do cliente pode ser verificada nalistagem 11.

Finalmente chegamos ao final deste tutorial, onde agora e possıvel chamar ocliente do web service e visualizar o resutado. Primeiramente entre no diretorioem que se encontra a classe compilada do cliente:

cd /servicos/meuservico/cliente

Depois, proceda com a execucao do codigo do cliente, cujo resultado e mos-trado a seguir:

java org.apache.ws.axis2.Cliente

1 O local de criacao do arquivo Cliente.java e uma decisao do programador. A decisaode criar no mesmo diretorio contendo todos os arquivos .java, e tentar facilitar oentendimento do processo de criacao de web services.

Listagem 11 Estrutura de diretorios depois da geracao das classes do clientedo servicoservicos||--> MeuServico.java|---> meuservico

||--> MeuServico.class|--> MeuServico.aar||--> cliente| |---> build.xml| || |---> src| | |---> org| | |---> apache| | |---> ws| | |---> axis2| | |---> MeuServicoCallbackHandler.java| | |---> MeuServicoStub.java| | |---> Cliente.java| || |---> org| |---> apache| |---> ws| |---> axis2| |---> Cliente.class| |---> MeuServicoStub.class| |---> MeuServicoStub$Ecoa$Factory.class| |---> MeuServicoStub$EcoaResponse$Factory.class| |---> MeuServicoCallbackHandler.class| |---> MeuServicoStub$Ecoa$1.class| |---> MeuServicoStub$EcoaResponse$1.class| |---> MeuServicoStub$ExtensionMapper.class| |---> MeuServicoStub$1.class| |---> MeuServicoStub$Ecoa.class| |---> MeuServicoStub$EcoaResponse.class||---> META-INF

|--> services.xml

A resposta obtida depois da execucao do cliente e mostrada abaixo:

Meu primeiro web service com Axis2

Referencias

1. C. Brooks. A discussion of xml based middleware for web services, 2002. Dis-ponivel em: http://www.cs.usask.ca/ cab938/papers/898finalpaper.doc - Ultimoacesso: Jan/2009.

2. D. Ehnebuske, D. Rogers, and C. V. Riegen. Uddi version 2.0 data structurereference, 2001. Disponivel em: http://www.uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm - Ultimo acesso: Jan/2009.

3. A. Erradi and P. Maheshwari. A broker-based approach for improving web servi-ces reliability. In Proceedings of IEEE International Conference on Web Services(ICWS-05). IEEE CS Press, 2005.

4. A. S. Foundation. Apache axis2, 2009. Disponivel em: http://ws.apache.org/axis2- Ultimo acesso: Jan/2009.

5. M. Gudgin, M. Hadley, J. Moreau, and H. Nielsen. Soap version 1.2 part 1:Adjuncts, 2007. Disponivel em: http://www.w3.org/TR/2007/REC-soap12-part2-20070427/ - Ultimo acesso: Jan/2009.

6. M. Gudgin, M. Hadley, J. Moreau, and H. Nielsen. Soap version 1.2 part 1: Messa-ging framework, 2007. Disponivel em: http://www.w3.org/TR/2007/REC-soap12-part1-20070427 - Ultimo acesso: Jan/2009.

7. K. Pani. Securing web services using soap extensions, 2004. Disponivelem: http://www.codeproject.com/KB/webservices/Securing web services.aspx -Ultimo acesso: Jan/2009.

8. M. P. Papazoglou. Service-oriented computing: Concepts, characteristics and direc-tions. In Proceedings of the Fourth International Conference on Web InformationSystems Engineering (WISE-03). IEEE CS Press, 2003.

9. W. School. Xml tutorial, 2009. Disponivel em: http://www.w3schools.com/xml/- Ultimo acesso: Jan/2009.

10. J. P. Thomas, M. Thomas, and G. Ghinea. Modeling of web services flow. In IEEEInternational Conference on E-Commerce, Newport Beach, California, USA, June24 - 27, 2003, pages 391–398, 2003.

11. P. Walmsley. Definitive XML Schema. Prentice Hall PTR, Upper Saddle River,NJ, USA, 2001.

12. Wikipedia. Soap - simple object access protocol, 2009. Disponivel em:http://en.wikipedia.org/wiki/SOAP - Ultimo acesso: Jan/2009.

13. Wikipedia. Web services, 2009. Disponivel em:http://en.wikipedia.org/wiki/Web service - Ultimo acesso: Jan/2009.

14. Wikipedia. Xml namespace, 2009. Disponivel em:http://en.wikipedia.org/wiki/XML Namespace - Ultimo acesso: Jan/2009.