Java Web Services APIs

Resumo

Este documento tem o objectivo de fornecer algum background sobre web services, as diversas APIs que servem de suporte aos mesmos. Tem também como objectivo dar a conhecer algumas frameworks e toolkits que permitam o desenvolvimento e consumo de web services e será também apresentado uma spike solution que demonstre o seu funcionamento.

Palavras-chave

JAVA, XML, SOAP, WSDL, UDDI, Web Services, JAXRPC, JAXR, JAXP, JAXB, SAAJ

INTRODUÇÃO

Com o surgimento da Internet e o desenvolvimento da computação distribuída começam a surgir as primeiras tecnologias para a integração de sistemas. Tecnologias como Remote Procedure Calls (RPC), Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (Microsoft DCOM) permitem ainda hoje a integração. Com o passar do tempo surgem os web services de modo a tornar a integração de sistemas mais flexível.

Embora os web services surjam como uma evolução natural das tecnologias anteriores estes vêm também resolver alguns dos problemas das tecnologias referidas (como passagem por firewalls, dependências da linguagem de programação, etc.) e trazer outros para resolver, nomeadamente problemas de segurança.

WEB SERVICES

Os web services são, de um modo simplista, aplicações que disponibilizam os seus serviços para o ambiente exterior nomeadamente a Web. Podem representar funções de negócio, estão situados algures na Internet ou numa intranet e podem ser acedidos via protocolos como o HTTP, SMTP, etc. Os web services vêm permitir uma maior interoperabilidade entre sistemas visto que têm como suporte standards abstractos, ou seja, standards que permitem uma separação das linguagens de desenvolvimento e dos sistemas sobre o qual este poderão estar a correr. Os web services assentam principalmente sobre três tecnologias base: Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) e Universal Description, Discovery and Integration (UDDI).

Simple object access protocol (SOAP)

Inicialmente desenvolvido pela IBM e Microsoft, o SOAP é um protocolo baseado em XML que define o modo como são trocadas mensagens num ambiente descentralizado e distribuído. O SOAP é um protocolo independente da linguagem ou do sistema operativo o que o torna extremamente poderoso a nível da interoperabilidade. A arquitectura deste protocolo consiste em três partes distintas: um envelope onde é descrito o conteúdo da mensagem e como processá-la; as regras para a definição do modo de codificação de tipos de dados; convenção para representação de chamadas remotas a métodos (RPC) e respectivas respostas [3].

Web services description language (WSDL)

Trata-se de uma linguagem em XML usada para descrever as capacidades de um web service sobre a forma de canais de comunicação para a troca de mensagens que representam operações. O WSDL é extensível de modo a permitir que a descrição do serviço seja independente do formato da mensagem ou dos protocolos de rede que sejam usados. Ou seja, as operações permitidas pelo web service são descritas de forma abstracta e depois associadas a um formato de mensagem e protocolo de comunicação específico de modo a definir um endpoint [4]. Esse endpoint surge na forma de um URL a partir do qual se pode obter o WSDL do web service e serve como endereço de ligação para o cliente.

Universal description, discovery and integration (UDDI)

É uma iniciativa de várias empresas que visa a criação de uma framework para a descoberta, publicação e integração de web services [1]. O UDDI, ao contrário do SOAP e WSDL, não está associado ao W3C mas sim ao consórcio OASIS. O conceito adjacente ao UDDI é o de um repositório global com redundância de informação entre os diversos pontos de acesso onde os diversos fornecedores de serviços possam publicar os seus web services para que outras entidades os possam encontrar, através de métodos de pesquisa, e interagir com os mesmos. Um registo do UDDI é composto por três componentes: white pages é onde se especifica informação relativa ao negócio. Itens como o nome da companhia, do negócio, contacto, identificadores únicos da empresa como o número de contribuinte fazem parte desta informação; yellow pages contem a informação que descreve o web service publicado. Neste modo aos web services são atribuídas categorias como por exemplo, atribuir a categoria bolsa a um web service que retorne as cotações da bolsa; green pages é onde é descrita informação técnica que descreve o comportamento e funcionalidades do web service. Esta informação inclui dados como o local onde se encontra o web service, etc.

Service-oriented architecture (SOA)

SOA é uma arquitectura que permite atingir os objectivos definidos pelo modelo computacional composto (Composite Computing Model). Este modelo, que foi desenhado de modo a resolver um grupo de problemas de natureza empresarial, especifica os seguintes requisitos:

• Descoberta dinâmica das capacidades do modelo de negócios

• Separação entre a descrição das capacidades do modelo de negócio e a sua implementação

• A habilidade para associar rapidamente comunidades computacionais com o mínimo de esforço de planeamento coordenado, procedimentos de instalação ou intervenção de humanos

O SOA atinge estes objectivos/requisitos fazendo uso do conjunto de tecnologias anteriormente referidas sobre as quais assenta a estrutura dos web services [1].

A arquitectura define três actores: O requestor; o provider; o registry ou broker. Ao enquadrá-la nos web services obtém-se a seguinte figura, onde o cliente é o requestor, o web service o provider e o UDDI o broker.

Figura 1. Service-oriented Architecture (SOA)

O papel do requestor é o de procurar e invocar serviços de um ou mais providers. A procura é feita recorrendo ao broker que retorna o(s) provider(s) que satisfaz um condição de procura. O requestor pode ser um browser, uma aplicação ou mesmo um provider, que neste caso, faz o papel de requestor.

O provider, é o actor que fornece e detêm o serviço. Este deve conter a descrição do serviço (documento em XML) e a sua implementação. No caso do web service o descritor do serviço é representado pelo WSDL, que permite saber quais as funcionalidades que este expõem mais a implementação do mesmo (Lógica do negócio). O provider poderá submeter ainda informação a seu respeito para o broker.

A função do broker é a de gerir a informação relativa aos diversos providers do qual este tem conhecimento e responder a pedidos dos requestors que procurem determinados tipos de serviços. Para tal é necessário que os providers submetam essa informação ao broker. A informação fornecida inclui dados do tipo dos que já foram referidos anteriormente quando se falou sobre UDDI (white pages, green pages, yellow pages). O requestor fará os pedidos e a resposta será baseada no conteúdo da informação guardada no broker.

WEB SERVICES APIs PARA J2EE

Na plataforma J2EE não existe uma API única que permita o uso de web services. Como tal existem um conjunto de APIs com funcionalidades variadas que tornam o seu uso possível.

Java API for XML Registries (JAXR)

A JAXR é uma API que disponibiliza mecanismos de acesso a diversos tipos de XML registries. O facto de ser possível

o acesso a diversos tipos de registries (UDDI, ebXML, etc.) é devido ao seu grau de abstracção. Através desta API é possível implementar clientes que acedam e escrevam nos registries.

A arquitectura de alto nível da API define duas partes: O cliente (JAXR Client) e o provider (JAXR Provider). O cliente que faz uso da API para aceder ao registry através do respectivo provider e o provider que implementa o modo de acesso e manipulação de um registry. Na versão actual do JAXR já existem dois providers implementados, um para registries ebXML e outro para registries UDDI. Como já foi referido, devido ao seu grau de abstracção, a API permite a implementação de outros providers para aceder a outros tipos de registries.

Java API for XML Processing (JAXP)

Esta API permite efectuar o processamento de dados no formato XML. De modo a efectuar o processamento dos dados, a JAXP assenta sobre dois tipos de parsers standards: Simple API for XML Processing (SAX) que permite que os dados sejam processados como uma stream de eventos; Document Object Model (DOM) que permite construir uma representação dos dados.

Para além destas características a API oferece suporte para o standard Extensible Stylesheet Language Transformations (XSLT), permitindo assim controlar o modo como os dados são representados e a conversão dos dados para documentos XML ou de outro tipo de formatos como o HTML. Existe ainda suporte para namespaces, permitindo trabalhar com DTDs, que de outro modo, poderiam conter conflitos de nomes. Deve também destacar-se o nível de flexibilidade da API que permite, através do que é chamado de pluggability layer, o uso de outras implementações das APIs SAX e DOM. O pluggability layer permite ainda o uso de processadores XSL, controlando assim o modo como os dados são mostrados.

Java Architecture for XML Binding (JAXB)

A API JAXB fornece mecanismos que permitem o uso de schemas XML como se de objectos Java se tratassem. Esta API é disponibilizada apenas no Java Web Services Development Toolkit. Dos componentes contidos na API destacam-se dois. O JAXB Binding Compiler (compilador) e a JAXB framework. O compilador é responsável por gerar classes e interfaces Java a partir de um schema XML. Essas classes e interfaces são geradas consoante as regras definidas no schema. Esta etapa é semelhante à geração de stubs a partir de um WSDL de um web service. As classes e interfaces geradas são depois compiladas e submetidas à framework.

Após a geração e compilação das classes e interfaces, a framework da API efectua o mapeamento dos valores dos elementos contidos no schema XML para os respectivos objectos instanciados a partir das classes geradas. Os objectos são organizados numa hierarquia (Java content trees) que reflicta a estrutura do schema XML. A esta operação é dados o nome de unmarshalling. A framework permite também efectuar a operação inversão, ou seja efectuar o marshalling dos objectos para um schema XML. Para além destas funcionalidades, a framework ainda permite a validação dos schemas durante o acto de marshalling ou unmarshalling.

Java API for XML-Based RPC (JAX-RPC)

Esta API permite a criação de web services e clientes que usem RPC e XML. Deste modo é permitido aos clientes a execução de procedimentos em sistemas remotos seguindo na maioria dos casos o modelo distribuído cliente-servidor. No JAX-RPC, os procedimentos remotos são representados recorrendo ao protocolo SOAP. Este define a estrutura do envelope, as regras de codificação e as normas para a representação de pedidos e respostas. Os pedidos e respostas são por sua vez transmitidos para os seus destinos através do protocolo HTTP. Esta API vem ocultar do programador a complexidade na manipulação das mensagens SOAP. Em runtime é a API que faz as conversão dos pedidos e resposta de e para mensagens SOAP.

Como o JAX-RPC usa tecnologias definidas pelo World Wide Consortium (W3C), existe flexibilidade e independência da plataforma, é possível consumir serviços que não estão a correr na plataforma Java e vice-versa.

SOAP with Attachment API for Java (SAAJ)

A API SAAJ permite aos programadores produzir e consumir mensagens de acordo com as especificações SOAP1.1 e SOAP with Attachments. Esta API é principalmente usada pelas APIs JAX-RPC e JAXR para o construção e troca de mensagens SOAP. É também utilizada em situações na qual os programadores não optam por usar a API JAX-RPC e optam sim, pela construção manual e envio das mensagens SOAP. A SAAJ permite a construção de dois tipos de mensagens SOAP. A mensagem segundo a especificação SOAP 1.1, a extensão desta de modo a permitir a inclusão de attachments.

As mensagens com attachments poderão incluir um ou mais attachments. Os attachments servem para transportar todo o conteúdo da mensagem que não seja XML. Ou seja, a SOAP Part da mensagem apenas deverá ter conteúdo XML enquanto que o attachment poderá ter conteúdo em diversos formatos (textual ou binário).

FRAMEWORKS E TOOLKITS PARA WEB

SERVICES

De modo a suportar os web services é necessária a existência de containers preparados para tal. Neste tópico serão descritas algumas soluções para containers de web services.

Jakarta Tomcat + AXIS – O Jakarta Tomcat é um servidor web com suporte para HTML, JSP e Servlets. Este não possui suporte de raiz para web services sendo necessário o uso do AXIS. O AXIS é uma implementação do protocolo SOAP e uma framework para a construção de SOAP processors (clientes, serviços, gateways, etc.) [9] que permite ao Jakarta Tomcat correr web services. O AXIS permite a execução e deploy de web services e também a criação de clientes que os consumam.

JBoss – É um servidor aplicacional que implementa a especificação J2EE na sua totalidade. No que diz respeito aos web services, até ao momento este recorre ao AXIS para efectuar o processamento dos web services. No entanto não se deve pensar que é necessário instalar o AXIS no Jboss, este já o trás embebido na sua implementação [6]. Em implementações futuras do JBoss este já terá a sua própria implementação do protocolo SOAP de modo a eliminar a

dependência das implementações do AXIS [6].

Java Web Services Development Toolkit – É um toolkit gratuito criado pela Sun que permite aos programadores desenvolverem e testarem aplicações Web, web services etc. O toolkit, para além das APIs necessárias para desenvolver o tipo de aplicações referidas anteriormente, permite escolher como servidores aplicacionais/web o Sun Java System Application Server Platform Edition 8, ou o Sun Java System Web Server 6.1 ou ainda o Jakarta Tomcat 5.0 [5].

IBM WebSphere – Desenvolvido pela IBM, o WebSphere é uma plataforma de integração empresarial. Composta por diversos componentes entre eles o WebSphere Application Server, este contem capacidade para a criação, teste, instalação e publicação de web services [7] [8].

SPIKE SOLUTION

Como spike solution foi desenvolvido um web service que permite a inscrição de alunos em turnos práticos de disciplinas. Nesta implementação recorreu-se ao Jakarta Tomcat com AXIS e a ferramenta de desenvolvimento escolhida foi o Eclipse.

Para este cenário foi criada uma base de dados para guardar os alunos, as disciplinas e respectivos turnos. Essa base de dados foi colocada a correr no servidor de base de dados SAPDB. Ainda do lado do web service foi criado um módulo que implementa a lógica do negócio, classes que representam as entidades da base de dados e uma interface que disponibilize o serviço para a Web.

Para o lado do cliente, recorrendo ao AXIS, foi gerado um conjunto de classes que permite consumir o web service através do WSDL do mesmo. Essas classes foram depois agrupadas num ficheiro JAR de modo a utiliza-las como uma livraria. Para interagir com o web service foi desenvolvido um conjunto de páginas JSP e Servlets. Em seguida serão descritas, de um modo mais pormenorizado, as diversas etapas para se atingir esta spike solution.

Figura 2. Arquitectura da spike solution

Criação da base de dados

Para esta solução foi necessário guardar informação sobre os alunos, disciplinas e respectivos turnos. Procedeu-se então à criação de um tabela na base dados que representasse cada uma destas entidades.

Criação da camada do Modelo de negócios

Para esta camada foi criada uma factory (FactorySql) que faz o mapeamento da base de dados para as classes que representam as suas entidades (Objectos Mapeamento: Classes Aluno, Disciplina e Turno). Foi também criada uma classe (SITPServico) que encapsula a factory de modo a disponibilizar para as classes consumidoras apenas os métodos relativos ao modelo de negócios e os tipos de dados mapeados, tornando assim transparente que para o programador o uso deste serviço. A criação desta classe, por exemplo, permitiria o acesso ao serviço de inscrição nos turnos práticos sem ser via web service. Para além destas classes existe ainda mais uma (SitpLogger) que permite efectuar o logging das chamadas feitas ao serviço. Esta classe faz uso framework de logging log4j.

Criação da camada Serviço

Para esta camada foi criada apenas uma classe que consome a camada de negócios e contém os métodos que são disponibilizados pelo web service. De modo a fazer deploy deste web service no container AXIS foi criado um web service deploy descriptor (deploy.wsdd). Neste ficheiro é indicada informação relativa ao web service incluindo informação sobre como é que, tipos de dados que não nativos, podem ser serializados para XML de modo a permitir o seu transporte sobre SOAP e o tipo de web service (RPC ou Messaging). De modo tornar o deploy mais fácil recorreu-se ao Apache ANT para criar a makefile (build.xml) que contém as directivas para ser efectuado o deploy/undeploy, compilar o projecto etc.

Criação do cliente

Como já foi referido anteriormente recorreu-se ao AXIS para gerar as classes que permitem ao cliente consumir o web service como se de um objecto local se tratasse (stubs). Estas classes foram geradas com base no WSDL do web service. Após a geração dessas classes estas foram compiladas e agrupadas num ficheiro do tipo JAR. Para mostrar a informação existente na base de dados e fazer uso das funcionalidades que o web service disponibilizava recorreu-se a uma aplicação Web criada fazendo uso de JSP e Servlets. A aplicação disponibiliza serviços de administração para a visualização de informação relativa as disciplinas e serviços para um aluno se poder inscrever nos turnos das disciplinas disponíveis.

Makefile

Todas as tarefas de compilação, criação de JARs, deploy, undeploys, geração de stubs foram efectuadas através da makefile referida anteriormente na alínea “Criação da camada Serviço”. Como tal a makefile deve ser configurada no PC no qual se pretende fazer uso da spike solution.

CONCLUSÃO

Com o aparecimento dos web service, as aplicações baseadas nesta tecnologia vêm ganhar uma maior flexibilidade garantindo assim uma maior interoperabilidade entre plataforma heterogéneas. Esta flexibilidade foi em parte garantida pela separação das tecnologias sobre a qual os web services assentam. Como tal foram também separadas as APIs que permite usufruir destas tecnologias. Esta separação possibilita que os web services possam ser implementados de diversas formas (como por exemplo sobre JAX-RPC ou JAXM), não estando ligadas a um leque exclusivo de tecnologias. Contudo o uso combinados das diversas APIs permite tirar um maior partido do potencial dos web services, usando por exemplo o JAX-RPC para ligação e invocação e o JAXR para publicação e pesquisa em UDDIs. Contudo os web services ainda possuem algumas lacunas, sendo a principal problemas relacionados com segurança. Muito trabalho tem vindo a ser desenvolvido de modo a criar soluções para estes problemas. Esta soluções encontram- se na forma de especificações e respectivas APIs, em que algumas já se encontram disponíveis para uso (XML and Web Services Security Implementation Version: FCS 1.0). Para além da segurança existem também questões relacionadas com a tolerância a falhas. Problemas que possam ocorrer durante os pedidos, por exemplo a nível da rede, poderão danificar o decorrer de uma transacção. Para este tipo de problemas existe a especificação Web Services Reliable Messaging. Para além das especificações faladas neste artigo existem outras para outros tipos de dispositivos e plataformas o que faz com que se possa concluir que os web services, mesmo com os problemas apontados, tenham ganho uma grande importância a nível de integração de sistemas no mercado empresarial (o facto de empresas como a Microsoft, IBM, SUN entre outras se terem juntado de modo a desenvolver os standards que permitem hoje o uso de web services foi um factor de sucesso). Um exemplo disse é o facto de a partir de se poder consumir web services através de dispositivos móveis.

AGRADECIMENTOS

Docente Catarina Reis, Docente Vítor Carreira

REFERENCIAS

[1] O’Reilly, Java Web Services

[2] AXIS Documentation http://ws.apache.org/axis/java/index.html

[3] Simple Object Access Protocol (SOAP) 1.1 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

[4] Web Services Description Language (WSDL) 1.1 http://www.w3.org/TR/wsdl

[5] Java Web Services Developer Pack (Java WSDP) http://java.sun.com/webservices/jwsdp/index.jsp

[6] JbossWS http://www.jboss.org/wiki/Wiki.jsp?page=JBossWS

[7] WebSphere Web Services http://www106.ibm.com/developerworks/websphere/zones/webservices/

[8] WebSphere Application Server Zone http://www-128.ibm.com/developerworks/websphere/zones/was/bigpicture.html

[9] AXIS – What is AXIS? http://ws.apache.org/axis/java/userguide.html#WhatIsAxis

[10] JSR 5: XML Parsing Specification http://www.jcp.org/en/jsr/detail?id=5

[11] JSR 93, Java API for XML Registries 1.0 (JAXR) http://www.jcp.org/en/jsr/detail?id=93

[12] JSR 101, Java APIs for XML-based RPC (JAX-RPC) http://www.jcp.org/en/jsr/detail?id=101

[13] JSR 222, Java Architecture for XML Binding (JAXB) 2.0 http://www.jcp.org/en/jsr/detail?id=222

[14] JAXM http://java.sun.com/xml/downloads/jaxm.html

[15] JAXP http://java.sun.com/xml/downloads/jaxp.html

[16] JAXR http://java.sun.com/xml/downloads/jaxr.html

[17] SAAJ http://java.sun.com/xml/downloads/saaj.html

[18] SUN, The J2EE 1.4 Tutorial