Estudo comparativo das API s JAX-RPC e JAXM na construção de Web Services

Transcrição

1 Estudo comparativo das API s JAX-RPC e JAXM na construção de Web Services Danielle Corrêa Ribeiro 1, Elizabeth Mª Martinho da Silva 1, Francisco A. S. Júnior 1, Thatiane de Oliveira Rosa 1, Madianita Bogo 1 1 Curso de Sistemas de Informação Centro Universitário Luterano de Palmas (CEUL/ULBRA) Teotônio Segurado 1501 SUL Palmas TO Brasil {danielle, elizabeth, franciscojr, mbogo, thatiane}@ulbra-to.br Resumo. Este artigo apresenta um breve estudo sobre a tecnologia Web Service, relatando seu conceito, suas características e vantagens; e sobre o pacote desenvolvido pela empresa Sun para aplicações Web Services JWSDP, apresentando as API s JAX-RPC e JAXM, por ser o objetivo deste trabalho um posterior comparativo entre essas API s. 1. Introdução Quando surgem novas tecnologias Java, estas são desenvolvidas com o intuito de inovar a programação visando à facilidade e promover eficiência. Em 12 de novembro de 2001, a empresa Sun, com a aprovação da Comunidade Java JCP lançou os pacotes JAXs, formando o JWSDP (Java Web Services Developer Packet), com o intuito de aprimorar a implementação em Web Services com a utilização do SOAP Simple Object Access Protocol (LACERDA, 2005). Dentre estes pacotes, pode-se encontrar o JAX-RPC, uma aplicação que utiliza o RMI sobre SOAP/HTTP e, por possuir um alto nível de abstração, possibilita que o cliente obtenha uma interface para comunicação com o serviço dinamicamente, em tempo de execução. Outro pacote encontrado é o JAXM, desenvolvido com o intuito de prover um protocolo SOAP através de uma API Java permitindo, de uma forma padronizada, a emissão de mensagens originadas do XML pela Internet sobre uma plataforma Java. Esse pacote já fez parte do JWSDP, mas atualmente é independente do mesmo. A utilização do Web Serices vem crescendo bastante por ser um conjunto de tecnologias com elevado potencial, eficaz em termos de custos e poderoso, o qual promete integração de computação distribuída interoperável. Dentre as várias tecnologias que oferecem recursos para a implementação de Web Services, pode-se destacar o pacote JWSDP, que oferece um conjunto de soluções para construir aplicações distribuídas utilizando documentos XML e está disponível gratuitamente através da Internet. A API JAX-RPC, encontrada neste pacote, é utilizada para a comunicação entre cliente e servidor, com a troca de mensagens SOAP. Existe uma outra API, a JAXM, que, como dito anteriormente, fazia parte do JWSDP, que possui algumas características JAX- RPC, mas não usa a idéia dos mecanismos de RPC. Existem poucos estudos referentes a

2 API JAXM, principalmente no que diz respeito à relação com o JAX-RPC e quais são as situações mais apropriadas para usar cada uma das API s. Assim, a realização de um estudo aprofundado das duas API s, no que diz respeito ao funcionamento básico, recursos oferecidos e principais características, para fazer um paralelo entre as mesmas é de grande relevância, pois auxiliará os desenvolvedores na definição de qual é a API mais apropriada, no momento do planejamento dos Web Services, suas diferenças, vantagens e desvantagens. 2. Web Services Com o desenvolvimento tecnológico, houve um crescimento no número de pessoas que acessam a Internet surgindo, então, a necessidade das mesmas trocarem informações entre aplicações disponíveis na Web, o que contribuiu para o surgimento de aplicações baseadas em Web Services. Web Services são aplicações implementadas estaticamente ou dinamicamente, através de tecnologias da Internet, que formam um conjunto de especificações de interface independentes do mecanismo de transporte, da arquitetura de hardware ou sistema operacional (BASIURA, 2003), baseado nos cinco padrões definidos pela W3C: UDDI Universal Description Discovery and Integration: consiste em um protocolo padrão, criado pela indústria de desenvolvimento de software, que possibilita a publicação e busca de informações sobre Web Services (UDDI, 2002). É composto por um conjunto de registros baseados na Internet, fornecendo informações sobre negócios ou entidades ou quem desejar obter informações sobre serviços Web publicados. WSDL Web Service Description Language: é uma linguagem de marcação, a qual descreve um Web Service, informando qual o serviço que ele oferece, como é realizada a sua comunicação e onde localizá-lo. Disponibiliza um mecanismo estruturado para detalhar as operações que pode executar, o formato das mensagens que processa, os protocolos que suporta e o ponto de acesso de uma instância de um Web Service. SOAP Simple Object Access Protocol: consiste em um protocolo responsável pela invocação de aplicações remotas através de RPC ou trocas de mensagens em ambientes desprendidos de plataforma e linguagem de programação, sendo, portanto, um padrão freqüentemente aceito na utilização de Web Services, garantindo a interoperabilidade e intercomunicação entre sistemas distintos, através da utilização de uma linguagem XML e mecanismo de transporte HTTP padrões, com a grande vantagem de ser desprovido de restrições de algum tipo de implementação para os pontos de acesso. XML Extensible Markup Language: é um padrão que possibilita descrever, armazenar, intercambiar e manipular dados estruturados (XML, 2003). É considerado uma linguagem de marcação de dados, o qual facilita declarações

3 precisas de conteúdo e resultados, possibilitando a geração de novas aplicações de manipulação e visualização de dados via Web. HTTP Hyper Text Transfer Protocol: é um protocolo que possibilita que servidores Web e browsers troquem dados pela Web, utilizando confiáveis conexões TCP através da porta 80. Figura 1. Modelo genérico de um Web Services modificado de (CBDI Web Services Roadmap, 2005). Na figura 1 é possível observar o modelo genérico do funcionamento de Web Services, no qual o provedor publica um serviço na Web através de um registro UDDI, sendo pesquisado por um consumidor, que possui um vínculo com o provedor, possibilitando, assim, total acessibilidade aos serviços Web registrados no UDDI. Desta forma, BASIURA (2003) afirma que o ciclo de vida de um Web Service é composto por 6 itens: 1. criação do Web Service; 2. divulgação do Web Service em um registro UDDI; 3. localização do Web Service; 4. obtenção da descrição do Web Service através da WSDL a partir do acesso do consumidor do Web Service em um provedor Web Service; 5. criação do Proxy e do cliente; 6. chamada do Web Service através do SOAP. Pode-se encontrar, ainda, várias outras tecnologias que possibilitam o desenvolvimento de Web Services, como Asp.Net, que oferece vários recursos avançados, mas que necessita de um investimento para ser utilizado; e o pacote JWSDP, uma plataforma gratuita, tornando, assim, sua utilização mais acessível.

4 3. JWSDP O pacote desenvolvido pela Sun Microsytems, conhecido como JWSDP Java Web Services Developer Pack oferece um conjunto de recursos para a construção de Web Services. Neste pacote estão concentradas as principais tecnologias para processamento de documentos XML, sendo essenciais para criação de Web Services. O JWSDP disponibiliza um grupo de API s e várias ferramentas para a elaboração dos artefatos imprescindíveis tanto para o desenvolvimento quanto para a publicação de serviços. Estas API s se dividem em dois conjuntos: Baseadas no processamento de documentos XML: são API s que trabalham ao lado do cliente e do servidor, manipulando documentos XML. São elas: o JAXP Java API for XML Processing: permite a interpretação de documentos XML a partir da utilização do modelo DOM (Document Object Model) ou SAX (Simple API for XML Parsing), sendo utilizada para interpretar, criar e alterar mensagens. o JAXB Java Architeture for XML Binding: possibilita a criação de classes utilizando XML Schemas, suprindo a necessidade de codificação de classes para a manipulação de XML. Esta API mapeia as classes Java e documentos XML, permitindo a geração de JavaBeans a partir de esquema XML possibilitando a serialização de objetos para XML e vice e versa. o SAAJ SOAP with Attachments API for Java: composta por um conjunto de API s para a manipulação de envelopes SOAP, permite a comunicação baseada em eventos e em RPC. Baseadas na comunicação: são API s que realizam a comunicação entre o cliente e o servidor. São elas: o JAX-RPC Java API for XML-based RPC: é considerada a principal API para o desenvolvimento de Web Services, por permitir a geração de infra-estrutura similar ao Java RMI (Remote Metod Invocation) facilitando a utilização de Web Services no modelo RPC. o JAXR Java API for XML Registries: oferece uma forma padrão de acessar registros de negócio e informações compartilhadas. No próximo tópico será feita uma maior análise sobre a API JAX-RPC, para um posterior comparativo com a API JAXM JAX-RPC Como mencionado anteriormente, a API JAX-RPC se encarrega em auxiliar o desenvolvimento de Web Services, tendo como base o modelo de comunicação RPC, que permite a elaboração da infra-estrutura de comunicação entre as aplicações cliente e servidor. Semelhante ao RMI, o JAX-RPC possui um desenvolvimento simples e

5 baseado em geração de código de forma automática, não precisando ser manipulado, ou seja, não há a necessidade do desenvolvedor se preocupar com detalhes de comunicação, diferenciando-se por enviar mensagens SOAP sobre o HTTP (JWSDP, 2004). Ao implementar um Web Service utilizando a API JAX-RPC toda a complexidade da comunicação é transparente para o programador devido ao fato desta API fornecer mecanismos que realizam todas as ações necessárias para a troca de informações entre as aplicações. Para desenvolver uma aplicação utilizando a API JAX-RPC é necessário, no lado do servidor, implementar os métodos necessários em uma classe Servidor e uma interface Java em que estarão especificados os métodos que serão utilizados pelo Web Service. Ainda no lado do servidor, será necessário utilizar algumas ferramentas como a wsdeploy, que é responsável por compilar e gerar os skeletons e produzir automaticamente o arquivo WSDL. Já no lado do cliente a ferramenta utilizada é o wscompile que gera os stubs, que representam o serviço remoto. Desse lado é implementado um programa que chama os métodos com um objeto local stub. Os stubs e skeletons são classes de baixo nível responsáveis pela a comunicação entre o cliente e o servidor e como essas classes são criadas na compilação dos programas, a implementação da comunicação se torna totalmente transparente para o desenvolvedor. A figura 2 apresenta a arquitetura da API JAX-RPC, ilustrando o processo de comunicação entre o cliente e o servidor. Figura 2. Arquitetura da API JAX-RPC modificada de (IST, 2004). De forma geral, a comunicação entre o cliente e o serviço é realizada da seguinte forma: o cliente descobre um determinado Web Service. Através do stub, que se comunica através do SOAP sobre HTTP, realiza a solicitação de um serviço ao skeleton, que passará o pedido para a aplicação servidora e depois que receber a reposta retorna para o stub. A principal vantagem de utilizar a API JAX-RPC é que esta possui total independência de plataforma devido à linguagem de programação Java, o que possibilita que a aplicação cliente acesse um Web Services que não tenha sido implementado na

6 plataforma Java e vice-versa. Isto se torna possível pelo fato desta API basear-se em padrões que são definidos pela W3C HTTP, SOAP e XML JAXM A API JAXM Java API for XML Messaging assim como JAX-RPC é utilizada para implementar sistemas cliente/servidor e permite a transmissão de documentos XML pela Internet baseados em SOAP, porém não segue o modelo RPC, o que significa que o desenvolvedor deve implementar a forma como a transmissão será realizada, fazendo a manipulação direta das mensagens XML. Segundo alguns autores, a API JAXM pode ainda ser definida como um conjunto de API s que possibilitam a manipulação de envelopes SOAP, sendo estes transportados através de protocolos como HTTP, SMTP entre outros. Para melhor compreensão do conceito da API JAXM, pode-se dividir esta tecnologia em quatro elementos funcionais: A mensagem; O remetente da mensagem; O receptor da mensagem; A troca da mensagem. A figura 3 apresenta os quatro elementos funcionais do JAXM. Figura 3. Elementos Funcionais modificado de (CEDRO, 2005). Existem determinadas situações em que é preferível utilizar o JAXM, pois a possibilidade de adaptar aplicações é maior, considerando que esta não possui uma solução pronta e transparente. Existem duas formas de enviar mensagens utilizando a API JAXM usando messaging provider e standalone message, mensagens enviadas ponto a ponto (MENÉNDEZ, 2002). Mensagens que não fazem uso do messaging provider forçam o cliente JAXM a enviar o documento XML diretamente para o Web Services o qual implementa solicitações request/response, que consiste em uma mensagem síncrona, ou seja, são realizados na mesma operação o envio e o recebimento da mensagem. A utilização do messaging provider permite que mensagens assíncronas sejam enviadas. O transporte dessas mensagens acontece da seguinte forma: o messaging provider executa o encaminhamento para o destino, caso aconteça algum problema na entrega, reenvia-a. Outra atividade executada pelo messaging provider é o envio de mensagens para messaging providers intermediários antes que esta chegue ao seu destino final.

7 A figura 4 apresenta a arquitetura da API JAXM, ilustrando o envio e recebimento de mensagens. Figura 4. Arquitetura da API JAXM (SUN, 2005). A API JAXM pode ser utilizada com os protocolos do messaging de um nível superior, tais como o serviço de mensagem do ebxml negócio eletrônico XML, incrementando a funcionalidade do protocolo no alto do SOAP. 4. Comparativo entre as API s JAX-RPC e JAXM A seção anterior apresentou uma breve descrição sobre as API s JAX-RPC e JAXM, em que foram abordados conceitos, características e arquiteturas. Com isso, pôde-se perceber que estas possuem a mesma finalidade, ou seja, o envio de mensagens XML utilizando o protocolo SOAP, porém em certos domínios a utilização de JAX-RPC torna-se mais viável do que a utilização da JAXM, e vice-versa. Portanto, pode-se enfim, realizar um breve comparativo entre estas API s: 1. O API JAX-RPC, é recomendada para ambientes que trocam mensagens de forma síncrona, ou seja, o envio e o recebimento de mensagens são realizados na mesma operação, pois, por ser um mecanismo RPC, a criação da mensagem e as rotinas para comunicação são feitas automaticamente. Já o JAXM, é recomendado para ambiente que trocam mensagens de forma assíncrona, onde a aplicação não fica bloqueada aguardando uma resposta e que não precise ser retornada imediatamente, ou nem enviada. 2. O JAX-RPC implementa a linguagem WSDL, pois esta gera automaticamente a descrição dos serviços disponibilizados, possibilitando que o cliente acesse métodos de forma remota, enquanto o JAXM não faz uso desta linguagem, por utilizar dois tipos de conexão: ponto-a-ponto e de um provedor de mensagens. 3. Enquanto a API JAX-RPC trata de esconder a implementação das mensagens SOAP com RMI, tornando-a transparente, a JAXM trabalha de forma direta com a estrutura dos documentos XML utilizados na comunicação entre Web Services.

8 4. A implementação realizada na API JAX-RPC é de alto nível, diferenciando da JAXM por esta apresentar uma implementação de baixo nível, pois nesta as mensagens SOAP devem ser manipuladas pelo desenvolvedor. 5. Pelo fato da implementação na API JAX-RPC ser de alto nível, esta se torna mais simples e sua análise mais conceitual. Por outro lado, pelo fato da implementação na API JAXM ser de baixo nível, esta se torna relativamente mais complexa, sendo sua análise mais detalhada. 6. As mensagens na JAX-RPC são estruturadas para um único destinatário, pois segue o modelo requisição resposta. Já na JAXM suas mensagens possuem uma estrutura para um ou vários destinatários, pois as mensagens podem ser mandadas de forma assíncrona. 7. Na API JAX-RPC, as aplicações cliente e servidor devem estar ativas no momento da comunicação, e se por alguma razão o serviço não estiver disponível no momento em que o cliente realiza o pedido, a conexão com o servidor não poderá ser criada, enquanto na API JAXM é oferecido um serviço de entrega de confiança sem que exista a necessidade da aplicação cliente se preocupar com a forma com que a confiabilidade é fornecida e permite ainda a distribuição de mensagens SOAP entre aplicações que não estejam diretamente conectadas. 8. Na maioria das aplicações pode-se usar tanto a API JAX-RPC quanto a JAXM. Mas deve-se considerar que a aplicação da API JAX-RPC é mais bem utilizada em sistemas locais ou sistemas Web. Por ora, a API JAXM é sugerida para a comunicação business to business B2B, por ser comum situações em que não é necessário processamento imediato de resposta enviadas e que a mensagem tenha que ser enviada para vários destinatários. A tabela 1 apresenta o paralelo entre as API s JAX-RPC e JAXM. JAX-RPC Mensagens Síncronas. Implementa WSDL. JAXM Mensagens síncronas e assíncronas. Não usa WSDL. Mensagem SOAP transparente. Permite manipulação da mensagem SOAP. Implementação alto nível. Estruturação de uma mensagem para somente um destinatário. Sem resposta de erro. Implementação mais simples. Indicada para sistemas Web ou sistemas locais. Implementação baixo nível. Estruturação de uma mensagem para mais de um destinatário. Mensagem confiável, como garantia de entrega. Implementação relativamente complexa. Indicada para comunicação business to business (B2B).

9 5. Conclusões Este trabalho foi realizado com o intuito de promover um comparativo entre as API s JAX-RPC Java API for XML-based RPC, encontrada no pacote JWSDP e JAXM Java API for XML Messaging. Para isso, foi necessária a compreensão de assuntos como: Web Services, o pacote JWSDP e suas API s, realizando um maior estudo sobre uma delas JAX-RPC, a API JAXM, e o conhecimento de desenvolvimento de aplicações em Java. De acordo com os estudos apresentados neste trabalho, pôde-se perceber que com a utilização da tecnologia Web Service não há a necessidade em preocupar-se com a compatibilidade de plataformas, pois esta segue os padrões definidos pela W3C. Com relação ao comparativo realizado entre as API s JAX-RPC e JAXM, pôde-se observar algumas diferenças, tais como: a questão do sincronismo de suas mensagens, de transparência, nível de implementação, estruturação das mensagens, confiabilidade quanto ao transporte de mensagens e sobre a questão da performance em determinados ambientes. De forma geral, a escolha da utilização da API JAX-RPC é sugerida para criação de aplicações SOAP-RPC utilizando o padrão WSDL. Enquanto para a utilização da API JAXM como um provedor de mensagem, juntamente com SAAJ, é sugerida quando há necessidade da manipulação da mensagem. Assim, de acordo com o comparativo apresentado, pode-se afirmar que é interessante usar a API JAXM como provedor de mensagens em aplicações que necessitam se comunicar assincronamente ou que seja necessário o envio de mensagens para mais de um destinatário, enquanto a API JAX- RPC é ideal para Web Services que trocam mensagens síncronas, devido à facilidade de implementação. 6. Referências Bibliográficas BASIURA, Russ et al. Profissional ASP.NET Web Service. São Paulo: Pearson Education, CBDI Web Services Roadmap, The Web Services Protocol Stack, Disponível em< Acessado em setembro de CEDRO, Daniela Medeiros; MOURA, Hélio Augusto Sabóia; SOUZA, Viviane Maria da Conceição de. Java API for XML Messaging: JAXM API em Rede Ponto-a- Ponto. Disponível em < >. Acessado em julho de IST, Instituto Superior Ténico: Universidade Técnica de Lisboa. Disponível em < Acessado em setembro de JWSDP, Tutorial Java Web Service. Sun Microsystem, Disponível em < Acessado em setembro de LACERDA, Rogério Lourenco Lima de Araújo; PINHEIRO, Cleidson de Macedo; SERRUYA, Moyses Isaac. Estudo e Aplicação de Ferramentas para a

10 Construlção de Web Services. Belém, Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) Universidade da Amazônia Centro de Ciências Exata e Tecnologia, Belém, Disponível em < >. Acessado em setembro de MENÉNDEZ, Andrés Ignácio Martinez. Uma Ferramenta de Apoio ao Desenvolvimento de Web Services. Campina Grande, Dissertação (Pósgraduação em Informática) Universidade Federal de Campina Verde, Campina Verde, SUN, Over of JAXM. Disponível em < Acessado em setembro de UDDI, Programmer s API 1.0 UDDI.org, jun Disponível em < Acessado em setembro de XML, Extensible Markup Language (XML). Word Wide Web Consortion. Disponível em < Acessado em setembro de 2005.