2.3 Tecnologias Escolhidas - Projetos
Propaganda
UNIVERSIDADE FEDERAL DE SANTA CATARINA - UFSC CURSO DE CIÊNCIAS DA COMPUTAÇÃO FERNANDO MARÇAL SENRA DOUGLAS SCHROEDER Protótipo de Um Sistema de Agendamento de Consultas Para A Integração de Centros de Saúde e Hospitais Públicos FLORIANÓPOLIS, JULHO DE 2006. FERNANDO MARÇAL SENRA DOUGLAS SCHROEDER Protótipo de Um Sistema de Agendamento de Consultas Para A Integração de Centros de Saúde e Hospitais Públicos Proposta para o Trabalho de Conclusão de Curso, a ser apresentado para obtenção do grau de bacharel no curso de Ciências da Computação da Universidade Federal de Santa Catarina, UFSC. Orientador: Dr. João Bosco Mangueira Sobral Dedicatória. AGRADECIMENTOS Espaço reservado para agradecimentos àqueles que tornaram possível à realização deste trabalho. “Nossa vida é desperdiçada em detalhes... Simplifique, simplifique”. Henry ThoureauRESUMO O trabalho tem como objetivo propor e implementar uma arquitetura confiável que forneça o serviço de marcação de consultas em hospitais da rede pública de saúde, sendo acessado a partir de terminais remotos localizados nos postos de saúde. Isso será feito na forma de um protótipo de sistema, já que não temos acesso ao sistema real dos hospitais da rede publica. Nosso propósito é implementar não somente os sistemas necessários para tal tarefa, como também integrar todo o software necessário para que o sistema possa executar de maneira estável. Também é objetivo aplicar técnicas normalmente aceitas de engenharia de software, em todas as etapas do projeto, desde sua concepção até a sua fase de testes. A motivação nasce da idéia de que um serviço como este estando disponível poderá trazer maior qualidade de vida para os usuários do sistema público, evitando que os mesmos passem horas em filas desnecessárias, muitas vezes em condição enferma. Palavras-chave: WEB SERVICES, AXIS, SOAP. ABSTRACT This academic work consists had as objective implementing a trustworthy architecture that supplies the service of marking of consultations in the public hospitals, being had access from located remote terminals in the health centers. This will be made in the form of a system archetype, because I do not have access to the real system at the hospitals. The intention is implement the systems necessary for this archetype, and also integrate all necessary software that make the enterprise system to execute in a steady way. Also had the objective to apply normally accepted techniques of software engineering, in all stages of the project, since its conception until its phase of tests. The motivation born in a idea that a service as this being available will be able to bring bigger quality of life for the users of the public health system, preventing that the someone pass hours in unnecessary lines. LISTA DE ILUSTRAÇÕES Figura 1. H. Voormann distribuída GNU....................................26LISTA de maneira legal DE ABREVIATURAS E SIGLAS W3C – World Wide Web Consortium URL – Uniform Resource Locator HTTP – Hyper Text Transfer Protocol sobre a licença HTML – Hyper Text Markup Language CERN – European Organization for Nuclear Research DARPA – Defense Advanced Research Project Agency MIT – Massachusetts Institute of Technology LCS – Laboratory for Computer Science XML – Extensible Markup Language SOAP – Service Oriented architectural Pattern RPC – Remote Procedure Call RMI – Remote Method Invocation WS-I – Web Services Interoperability Organization FTP – File Transfer Protocol SMTP – Simple Mail Transfer Protocol XMPP – Extensible Messaging and Presence Protocol DOM – Document Object Model CORBA – Common Object Request Broker Architecture OMG – Object Management Group API – Application Programming Interface OASIS – Organization for the Advancement of Structured Information Standards UFSC – Universidade Federal de Santa Catarina INE – Departamento de Informática e Estatística SGBD – Sistema Gerenciador de Banco de Dados UDDI – Universal Description, Discovery and Integration Service XML DSIG – XML Digital Signature# JVM – Java Virtual Machine SUMÁRIO 1 APRESENTAÇÃO ................................................................................................. 11 1.1 Entidade ............................................................................................................. 11 1.2 Titulo................................................................................................................... 11 1.3 Autores ............................................................................................................... 11 1.4 Orientador .......................................................................................................... 11 1.5 Banca Avaliadora .............................................................................................. 11 2 INTRODUÇÃO ...................................................................................................... 12 2.1 Descrição do Problema..................................................................................... 12 2.2 Objetivos ............................................................................................................ 12 2.2.1 Objetivos Gerais ............................................................................................. 12 2.2.2 Objetivos Específicos .................................................................................... 13 2.3 Tecnologias Escolhidas.................................................................................... 14 2.3.1 Servidor Web .................................................................................................. 14 2.3.1.1 Servidor Apache HTTP Server ................................................................... 14 2.3.1.2 Apache Tomcat ............................................................................................ 15 2.3.2 O PSH e a tecnologia Java ............................................................................ 16 2.3.3 Resumo sobre o SGBD escolhido e o porquê da escolha .......................... 21 2.3.4 Resumo sobre a tecnologia escolhida para o desenvolvimento do web service e o porquê da escolha ............................................................................... 23 3 VISÃO GERAL SOBRE WEB SERVICES............................................................. 25 3.1 SOAP Simple Object Access Protocol ............................................................ 28 3.3 Web Service Description Language (WSDL) ................................................... 32 REFERÊNCIAS ......................................................................................................... 34 APACHE SOFTWARE FOUNDATION. Apache Derby Tutorial. Disponível em: <http://db.apache.org/derby/papers/DerbyTut/index.html>. Acesso em: 27 de Março de 2005.......................................................................................................... 35 [1] WIKIPEDIA. Servidor Apache. Disponível em: <http://pt.wikipedia.org/wiki/Servidor_Apache>. Acesso em: 19 de Março de 2006. ......................................................................................................................... 35 [3] Network Research Group. Hypertext Transfer Protocol -- HTTP/1.1. Disponível em: <http://www.w3.org/Protocols/rfc2616/rfc2616.html>. Acesso em: 13 de Março de 2006. ....................................................................................... 35 [5] W3C. SOAP Version 1.2 Part 1: Messaging Framework. Disponível em: ...... 35 [6] W3C. 3. SOAP Extensibility Model. Disponível em: <http://www.w3.org/TR/soap12-part1/#extensibility>. Acesso em: 11 de Março de 2006. .................................................................................................................... 35 [7] W3C. 4. SOAP Protocol Binding Framework. Disponível em: ....................... 35 [8] W3C. 5. SOAP Message Construct. Disponível em: ....................................... 35 [9] W3C. Web Services Description Language (WSDL) 1.1. Disponível em: ...... 35 113 6 1 APRESENTAÇÃO 1.1 Entidade Universidade Federal de Santa Catarina Curso de Ciências da Computação 1.2 Titulo Protótipo de Um Sistema de Agendamento de Consultas Para A Integração de Centros de Saúde e Hospitais Públicos. 1.3 Autores Fernando Marçal Senra. Douglas Schroeder. 1.4 Orientador Prof° João Bosco Mangueira Sobral, Doutor. 1.5 Banca Avaliadora Prof° Fernando Augusto da Silva Cruz, Doutorando. Prof° Leandro José Komosinski, Doutor.(a confirmar) Profª Patrícia Vilain, Doutora. 123 6 2 INTRODUÇÃO O presente documento tem por objetivo definir a proposta de projeto de conclusão do curso de Ciências da computação da Universidade Federal de Santa Catarina (UFSC). Neste Será definidos objetivos gerais e específicos do trabalho, apresentar-se-á fundamentação teórica necessária para realização do mesmo, além de descrever brevemente a motivação de se atingir os objetivos. Este documento é, portanto, apenas um rascunho inicial do trabalho final a ser apresentado nas disciplinas de Introdução ao Projeto em Ciências da Computação (INE 5373) e Pesquisa Bibliográfica (CIN5100) cursadas no semestre 2005.2 na UFSC. 2.1 Descrição do Problema Um hospital da rede pública de saúde possui geralmente sistemas computacionais gerenciando seus vários setores, emergência, financeiro, lavanderia, cozinha, laboratórios, etc. Assim como também gerenciam seus serviços, como marcação de consultas, marcação de cirurgias, exames, etc. A marcação de consultas invariavelmente se dá de uma mesma forma. A pessoa se dirige até o hospital, onde normalmente, em caso de emergência, vai buscar um atendimento imediato para seu problema, o que pode levar minutos ou horas, dependendo da gravidade de seu problema e do tamanho da fila no setor de emergência do hospital. Em outra situação, a pessoa pode não estar procurando o serviço de emergência, mas sim, deseja um atendimento preventivo com um clinico geral, ou foi encaminhada por um clinico geral ao hospital com a finalidade de agendar consulta com um médico especialista. Este atendimento pode se transformar em questão de horas, dias ou mesmo meses, principalmente no caso de marcação de especialistas. Essas pessoas encaminhadas ao hospital, normalmente receberam atendimento médico prévio em um posto ou centro de saúde, em sua localidade, no qual são realizadas consultas com clínicos gerais, que encaminham o paciente a um hospital quando o mesmo necessita de atendimento especializado. 2.2 Objetivos 2.2.1 Objetivos Gerais 133 6 O objetivo central deste trabalho é discutir, apresentar e implementar uma arquitetura estável, para executar um web service, que permitirá o acesso a um protótipo de sistema hospitalar, o qual iremos nos referir no texto como PSH.Este web service ao qual iremos construir terá a finalidade fornecer o serviço de marcação de consultas em um hospital presente no PSH. O serviço ficará acessível através de uma aplicação web, que será executada a partir de um navegador de Internet (Browser), acessando através do web service (WS), o PSH que estará executando como uma aplicação Desktop. A idéia é de que este serviço, estando disponível em um sistema real, forneceria o serviço de marcação de consultas a partir de qualquer centro de saúde, desde que o mesmo possua um computador conectado a Internet, evitando dessa maneira, que o paciente do sistema público de saúde necessite se dirigir a uma fila de hospital após ser atendido em um posto de saúde no qual recebeu a indicação para marcar consulta em hospital publico. 2.2.2 Objetivos Específicos Implementar: O PSH como aplicação Desktop. Um web service que permita ao PSH expor seu serviço de agendamento de consultas sem expor a aplicação. Uma aplicação web comum (baseada no protocolo HTTP) que permita acesso ao web service. Utilizar: Tecnologia de servidor web que ofereça integridade, escalabilidade, robustez, segurança, tolerância a falhas, bem como pertencer à categoria de softwares livres, para que a aplicação web possa ser executada de maneira estável. Tecnologia não proprietária para implementação do PSH, que ofereça suporte a execução dessa aplicação em ambientes diversos de maneira simples e barata. Utilizar Sistema Gerenciador de Banco de Dados (SGBD) livre para armazenar os dados a serem salvos pelo PSH. Utilizar tecnologia igualmente livre para criação do web service a ser 143 6 construído para integrar o PSH a aplicação web. 2.3 Tecnologias Escolhidas O objetivo deste item é descrever um pouco as escolhas tecnológicas que fizemos para a execução do projeto, e isso será feito de forma independente para cada tecnologia escolhida. Neste presente texto não será apresentado resultado prático de desenvolvimento, apesar dos autores se reservarem o direito de demonstrar através de fragmentos de código o quem pretendem executar depois maior escala. É possível que haja alterações futuramente, já a tecnologia de web services está em pleno desenvolvimento, bem como toda a tecnologia Java™, a qual é base para a maioria, senão todas, as implementações que serão realizadas. 2.3.1 Servidor Web Como foi apresentado antes, iremos desenvolver uma pequena aplicação web bastante simples que será a interface do usuário para acesso ao web service a ser desenvolvida, essa aplicação web poderá ser implementada com diferentes linguagens de programação, como por exemplo, PHP, mas nós iremos optar por desenvolver uma aplicação bastante simples em JSP (Java Server Pages). O importante é que desejamos que servidor web, no qual essa aplicação web ira executar ofereça alguns recursos que consideramos importantes a aplicações desta natureza. Em especial, que o servidor ofereça integridade, escalabilidade, robustez, segurança, tolerância a falhas, bem como pertencer à categoria de softwares livres, para que a aplicação web possa possuir alta disponibilidade, afinal, nada é pior que uma pagina web fora do ar. Para atender a esse requisito de aplicação iremos implantar no servidor da aplicação Web uma estrutura baseada no servidor Apache HTTP Server, junto com o Apache Tomcat, a qual pode ser configurada para executar em um ambiente de cluster oferecendo todas as qualidades especificadas acima. Não é objetivo desta seção apresentar como isso será feito, o que valerá um capítulo à parte no texto futuramente. 2.3.1.1 Servidor Apache HTTP Server 153 6 O servidor Apache é o mais bem sucedido servidor web livre. Foi criado em 1995 por Rob McCool, então funcionário do NCSA (National Center for Supercomputing Applications), da Universidade de Illinois.[1] Faz parte da Apache Software Foundation[2], a qual provem suporte para comunidade Apache de projetos de código livre. Sendo considerado por muitos seu principal projeto. É responsável por mais de uma dezena de projetos envolvendo tecnologias de transmissão via web, processamento de dados e execução de aplicativos distribuídos. O projeto do Apache HTTP Server é um esforço para desenvolver e manter um servidor HTTP open-source para modernos sistemas operacionais incluindo o Windows, Novell, Netware, OS/2 e diversos padrões de POSIX (UNIX, GNU, FreeBSD, etc). O objetivo deste projeto é fornecer um servidor seguro, eficiente e extensível que forneça a serviços que necessitem do protocolo HTTP um servidor de alto desempenho. O servidor Apache HTTP Server, hoje na versão 2.2, é compatível com o protocolo HTTP versão 1.1 especificado pelo documento RFC2616 [3] do W3C. Suas funcionalidades são mantidas através de uma estrutura de módulos, podendo inclusive o usuário escrever seus próprios módulos - utilizando a API do software. O Apache tem sido o mais popular servidor de Internet desde abril de 1996, e em novembro do ano de 2005 Necraft Web Server Survey encontrou mais de 70% dos web sites usando Apache.[4] 2.3.1.2 Apache Tomcat O Tomcat é um servidor de aplicação Java para web. É distribuído como software livre e desenvolvido como código aberto dentro do conceituado projeto Apache Jakarta e oficialmente endossado pela Sun como a Implementação de Referência (RI) para as tecnologias Java Servlet e Java Server Pages (JSP). O Tomcat é robusto e eficiente o suficiente para ser utilizado mesmo em um ambiente de produção. Em muitos lugares esta escrito que o Tomcat é um container para execução de Servlet e JSP, mas ele é muito mais que isso, ele implementa parte da plataforma J2EE que abrange as tecnologias de Servlet e JSP, incluindo tecnologias de apoio relacionadas como Realms e segurança, JNDI Resources e JDBC Datasources. O 163 6 Tomcat tem a capacidade de atuar como servidor web sob o protocolo http sozinho, ou pode funcionar integrado a um servidor web dedicado como o Apache HTTP Server ou o Microsoft IIS. A escolha do Tomcat deve-se ao fato da mesma ser implementação de referencia da tecnologia JSP, além disso, já vem integrado e ativado por default ao Servidor Apache HTTP Server, e para a nossa necessidade de alta disponibilidade, poder ser configurado como um cluster. Cluster hoje é um termo muito abusado na computação, e pode ser utilizado para vários fins, mas no nosso caso, um cluster de servidores Tomcat é uma estrutura onde as requisições HTTP são recebidas pelo Apache HTTP Server, e repassadas para várias instancias do Tomcat, as quais realizam replicações da seção http da requisição. O fato é que, um servidor web, pode falhar, por diversas razões, e um container JSP, pode falhar com muito maior probabilidade.Então a idéia será implementar essa arquitetura de cluster no servidor para que, no momento que um container falhar, o seu trabalho possa ser atendido em outro nó do cluster, como veremos futuramente na fase de implementação da aplicação Web e configuração do Servidor. 2.3.2 O PSH e a tecnologia Java O objetivo deste tópico é falar um pouco a respeito da tecnologia que decidimos utilizar para a construção do protótipo de sistema hospitalar (PSH), o qual deverá possuir apenas algumas funções básicas de um sistema real de um hospital. Funções estas que serão posteriormente definidas, mas que basicamente se resumirão a coletar dados sobre um usuário a fim de agendar marcação de consultas. Um sistema hospitalar real e completo, em geral possui tarefas muito avançadas para serem implementadas em um protótipo, e, portanto seria inviável construirmos um sistema completo de gerencia hospitalar. Nosso desejo é substituir esse protótipo PSH por um sistema real futuramente, mas para isso será necessário o patrocínio de algum município, ou até mesmo de uma instância maior, como por exemplo, um governo de estado, para que possamos ter acesso a um sistema real em produção. 173 6 Vamos falar nesta seção, um pouco sobre a tecnologia Java, a qual escolhemos para a implementação do protótipo por diversos motivos, dentre eles: Por ser amplamente difundida, já estando presente hoje em mais de 2,5 bilhões de dispositivos segundo números da Sun. Por ser linguagem utilizada em várias disciplinas do curso de Ciências da Computação na UFSC onde estamos desenvolvendo este documento. Por ser uma linguagem em constante evolução (O release final para a versão do novo Java seis, codinome Mustang, será lançada apenas 21 meses após a versão final do Java cinco, codinome Tiger ter sido lançada). Pelo gigantesco esforço da Sun Microsystems™ em popularizar e facilitar a cultura de web services, inclusive integrando ao próximo Java (Mustang) APIs para facilitar o desenvolvimento de services.Como por exemplo, a JSR-181: Metadados para Web Services, além de disponibilizar diversas outras APIs para download separadamente do JSE(Java Standard Edtion). Pela enorme disponibilidade de projetos opensource (de código livre) que utilizam a tecnologia e disponibilizam ferramentas e APIs que reduzem drasticamente o esforço de desenvolvimento. Pelas constantes melhorias de desempenho, possibilitando que as modernas JVM (Java Virtual Machines) com seus compiladores JIT (Just in Time Compiler) possam apresentar desempenho semelhante, e muitas vezes superior, ao de compiladores tidos como mais velozes, por exemplo, o GCC (GNU Compiler Collection), o qual compila diversas linguagens, inclusive Java, diretamente para linguagens de maquina, isso será explicado adiante. Enfim, por ser objeto de estudo de ambos os autores em projetos paralelos, e estudos específicos voltados à certificação na tecnologia. 183 6 Nós poderíamos escrever um trabalho completo de conclusão de curso apenas sobre esta tecnologia, mas tentaremos falar um pouco sobre o que é o Java sem se aprofundar demais nas especificações da linguagem. Vamos começar tentando respondendo a pergunta “O que diabos é Java?”.De uma forma prática podemos imaginar que Java é um computador, um computador virtual que só habita no mundo dos computadores reais como x86 ou Sparc´s. É a chamada JVM, ou seja, uma maquina virtual (embora hoje já existam implementações físicas dessa maquina). A JVM disponibiliza vários recursos, como por exemplo, tarefas de impressão, e renderização de telas gráficas de alta qualidade. Então alguém pode pensar “Esta maquina deve custar uma verdadeira fortuna”, mas eu te respondo agora que essa maquina tem um custo zero para a maioria das pessoas que a utilizam. A não ser no caso das pessoas que compram implementações desta maquina de outros fornecedores de JVM que não a Sun Microsystems, isso para sistemas específicos, a maioria das pessoas, podem ter em seu computador pessoal, em seu notebook, ou ainda em diversos outros dispositivos, uma implementação da JVM. Você pode realizar o download gratuito da JVM a partir do sitio Web da Sun. Por se tratar de uma maquina virtual, ou seja, fisicamente ela não existe (com raras exceções), a maquina virtual Java se torna bastante versátil por poder estar presente em dezenas de computadores de diferentes arquiteturas, com diferentes sistemas executando sobre a arquitetura e ainda assim executar programas escritos em Java. E nesse ponto vem a pergunta “Mas esse tal Java não era uma maquina virtual, como pode agora ser usado para escrever programação de computador?”.Então, nesse ponto, respondemos, Java não é uma linguagem de programação (como infelizmente muitos ainda pensam), menos ainda, uma maquina que nem existe no mundo real. Java é um conjunto de especificações, dezenas delas...Bem, pra falar a verdade são centenas de especificações que definem a linguagem de programação, o formato do arquivo java, o formato do arquivo class, uma API qualquer, ou mesmo a JVM. Essas Especificações conhecidas como JSR (Java Specification Requests) são textos que especificam o que é necessário para que um software implemente 193 6 aquela JSR.Uma lista completa com todas as JSR´s pode ser encontrada em http://www.jcp.org/en/jsr/all . Logo, por conseqüência natural, um programa que execute algum processo Java, especificado por uma JSR, deverá executar sobre esse computador virtual, a JVM, seja qual for à plataforma em que o mesmo se encontra atualmente, por exemplo, Unix ou Windows. Claro que isso em um mundo ideal, mas como as coisas idéias são difíceis de alcançar, ainda existem alguns cuidados que são necessários para que os programas executem em qualquer JVM. Algumas características da linguagem Java: POO - É uma linguagem de programação orientada a objetos(POO), implementando quase todos os recursos que se tem como consenso na comunidade de POO, apenas evitando aqueles que não foram julgados convenientes pelos engenheiros da Sun, em especial James Gosling, considerado pai da tecnologia Java. Garbage Collector - Possui um mecanismo chamado Garbage Collector que elimina a necessidade do programador ficar gerenciando a liberação da memória consumida pelos seus objetos que não serão mais utilizados. Na maioria das linguagens, como C esta tarefa é responsabilidade do programador. Threads - Java possui suporte nativo ao mecanismo de threads, o que significa que seu programa pode rodar vários processos paralelamente, ficando a cargo do programador permitir ou não que seu programa libere recursos para outros processos. Exceptions - o tratamento de erros no Java é feito por meio de exceções. Exceptions são objetos que são disparado sempre que um programa executa algo inesperado, como por exemplo, uma divisão por zero, o que na maioria das linguagens tradicionais como C, encerraria a execução com um erro fatal. Em Java o programador pode, através do conhecimento da exception disparada, tratar o erro corretamente. 203 6 Controlled Resources – O Controle de Recursos demonstra o grande esforço, desde o início, em tornar Java uma referencia em implementação segura. Para tanto, o acesso a recursos, como arquivos e rede, é enormemente controlado. Isso se faz necessário, principalmente pelas diversas formas que uma pessoa pode invocar um programa Java, sem ter nem mesmo o conhecimento de que aquilo é um programa. Java API - seguindo o paradigma da orientação a objetos de se reaproveitar tudo ao máximo, uma API (Application Programming Interface) do Java é bastante extensa e abrangente. Não perca seu tempo reinventando a roda, use as classes da API! Write once, run everywhere - O principio de que um programa Java, depois de compilado para a linguagem que a JVM interpreta, linguagem esta chamada Java bytecodes, os quais ficam guardados em arquivos de extensão class (que possuem sua própria especificação, como tudo em Java), deverão executar sem problemas em qualquer implementação de JVM (desde que essa implementação seja aceita pela Sun) sobre qualquer sistema.E este é o segredo da portabilidade de programas Java: a única parte que necessita ser portada é a JVM, e não o seu programa. Logo como foi apresentado, Java é uma plataforma tecnológica, a qual apresenta solução para dezenas de categorias de problemas computacionais, criando sistemas portáveis entre diferentes plataformas de sistemas. É possível construir aplicações Desktop, distribuídas em rede, seja esta rede uma Intranet ou mesmo a Internet, aplicações Web, aplicações para dispositivos portáteis como celulares e PDA´s, e no momento atual se encontra em pleno desenvolvimento. O que implica que a plataforma de desenvolvimento esta cada vez mais completa e funcional, solucionando de forma mais simples, cada vez mais e mais situações complexas no mundo da computação. 213 6 2.3.3 Resumo sobre o SGBD escolhido e o porquê da escolha Como um dos objetivos do projeto é utilizar software livre, foram pesquisados alguns SGBDs no mercado que atendem a este requisito. Dentre os bancos de dados pesquisados, os que mais se destacaram foram o Derby e o HSQLDB. 2.3.3.1 Derby Apache Derby é um banco de dados relacional escrito inteiramente em Java, e como tal, roda em qualquer JVM certificada, sendo assim, é independente de plataforma. Além disso, é um banco compacto, que suporta a maior parte das instruções SQL. Principais Características: Possui driver JDBC para conexão com aplicações Java™; Pode ser embutido em aplicações Java, rodando na mesma JVM da aplicação; Suporta o modo cliente/servidor, com várias conexões simultâneas; Está a pouco tempo no mercado, se comparado ao HSQLDB; A documentação é um tanto quanto escassa; Uma vez que os dois SGBDs possuem características muito parecidas, fomos obrigados a nos ater aos detalhes, afim de decidir positivamente sobre um dos dois. Em virtude da maior maturidade do HSQLDB, acabamos optando por utilizá-lo como SGBD da aplicação. 2.3.3.2 Hypersonic SQL Database (HSQLDB) O HSQLDB é um banco de dados relacional inteiramente escrito em Java, podendo operar embutido em uma aplicação, ou como um servidor de rede independente. Além de suportar a maior parte das funções SQL, incluindo triggers, integridade referencial, outer joins, visões, transações, entre outras. Sua arquitetura foi projetada para ser leve, com pouca demanda de processador, memória e armazenamento. Ele é voltado para uso embarcado, em aplicações desktop, ou dentro de um hardware especialmente projetado. Já foi, 223 6 inclusive, utilizado como parte do sistema de apuração de votos das eleições brasileiras, o que, sem dúvida atesta a sua credibilidade. Alguns fatores que contribuíram para a escolha do HSQLDB: É um SGBD com código aberto, escrito totalmente na linguagem Java™; Pode ser agregado ao pacote da aplicação. Ou seja, não necessita ser instalado e configurado separadamente no Sistema Operacional para entrar em funcionamento; É multiplataforma, ou seja, independe do Sistema Operacional; Possui driver JDBC para conexão com aplicações Java; Permite a manipulação de banco de dados em uma arquitetura clienteservidor, ou standalone. Benchmarks criados pelo projeto PolePosition (polepos.org) colocaram o HSQLDB, de modo geral, com performance superior a outros bancos de dados livres, entre eles o MySQL e o Apache Derby; O banco de dados em si, sem as ferramentas para administração, e o servidor web, pode ser compilado em um arquivo “.jar” com menos de 200 KB; Segundo o manual, apenas 170 KB de memória são necessários para rodar a engine do banco; Está consolidado no mercado, estando embutido em aplicações importantes como o Open Office; Possui documentação vasta e detalhada, inclusive em português; 2.3.3.2.1 Componentes do HSQLDB Apesar de ser uma ferramenta pequena, o HSQLDB engloba algumas funcionalidades interessantes, que serão brevemente descritas abaixo: Database Manager: Ferramenta gráfica para gerenciamento de banco de dados. Com ela é possível visualizar o esquema do banco de dados, conjunto de tabelas e submeter instruções SQL; Transfer Tool: Ferramenta que possibilita a transferência de esquemas SQL ou dados de uma fonte JDBC para outra. Muito útil quando se deseja migrar de um banco de dados para outro; 233 6 Query Tool: provê ao desenvolvedor uma interface para interação com o SGBD através de instruções SQL; SQL Tool: outra ferramenta que permite a construção e submissão de instruções SQL; 2.3.3.2.2 Modos de operação do HSQLDB Há quatro modos de operação do banco de dados, que determinam como aplicações-clientes se comunicam com o engine SQL: Standalone: O HSQLDB roda na mesma JVM que a aplicação. Containers web ou EJB podem usar o modo Standalone, visando maior segurança, uma vez que não é necessário abrir nenhuma porta TCP. Server: Modo preferencial para desenvolvimento, ou para uso como banco de dados departamental. Neste caso são aceitas conexões por uma porta TCP (9001 por padrão) através de um protocolo de aplicação do próprio HSQLDB. Assim, várias aplicações em JVMs diferentes podem acessar o banco de dados ao mesmo tempo. Web Server: Empregado quando se deseja utilizar uma conexão remota com o banco de dados. Neste modo são aceitas conexões TCP/IP encapsulando comandos SQL, sendo que os resultados são retornados pela mesma conexão. Servlet: Visa atender usuários de serviços de hospedagem compartilhada em sites web. Neste caso o servlet recebe comandos SQL como parte dos parâmetros da requisição HTTP, e devolve os resultados como resposta à requisição. 2.3.4 Resumo sobre a tecnologia escolhida para o desenvolvimento do web service e o porquê da escolha Ainda não está definida uma tecnologia para a implementação do web service. Como há várias opões no mercado, que atendem ao requisito de serem gratuitas, terá de ser feito um estudo mais aprofundado sobre o assunto para se poder chegar a um senso comum. Tal decisão deverá ser tomada com cuidado, uma vez que pode determinar os rumos de todo o trabalho. 243 6 Estamos no aguardo também, da chegada do Java 6.0, uma vez que ele trará algumas facilidades no que diz respeito à criação de web services. Apesar disso, algumas tecnologias já foram cogitadas, entre elas destacam se as plataformas: AXIS Desenvolvida pela Apache, a plataforma Axis é um projeto open source para um servidor e cliente SOAP, composta por vários subsistemas, ou módulos que trabalham conjuntamente, separando, assim, as responsabilidades. Isto permite que, nos casos em que não for necessário invocar todo o sistema, apenas alguns módulos atuem, economizando recursos do sistema. Basicamente, o Axis trabalha com processamento de mensagens. É muito comum esta plataforma ser considerada basicamente um SOAP engine – um framework para a construção de processadores de mensagens SOAP. Atualmente está implementado apenas na linguagem Java, mas uma versão para cliente C++ está em andamento [11]. JWSDP O Java Web Services Developer Pack (JWSDP) é um conjunto de ferramentas gratuitas que permite aos desenvolvedores Java implementarem web services ou aplicações web com XML. O Java WSDP engloba várias APIs que visam facilitar a construção de aplicações web. Entre elas incluem-se: Java Architecture for XML Binding, que como o próprio nome sugere, tem a funcionalidade de manipular arquivos XML; JavaServer Faces; Web Services Interoperability Sample Application; Web Services Security; JavaServer Pages Standard Tag Library (JSTL) e Java WSDP Registry Server; As ferramentas Ant Build Tool e Apache Tomcat container também fazem parte deste pacote distribuído pela Sun. O servidor de aplicação da Sun é o Sun ONE™ Application Server 7.0 [11]. GLUE A plataforma webMethods Glue™ é uma plataforma projetada para o desenvolvimento e distribuição de aplicações com serviços web.[FURTADO, 2005] 253 6 Projetado para simplificar a criação de aplicações utilizando web services, servlets e JSP e possui uma API para expor objetos Java como web services, a plataforma Glue pode ser configurada para para atuar em dois modos diferentes: Standalone e Hosted. No modo standalone, o Glue atua como um servidor de aplicações, já no modo hosted, pode se comunicar com outros servidores de aplicações e prover web services. Algumas características: Possui uma ferramenta de gerenciamento que roda em browser http, permite verificar o status de todas as aplicações que foram publicadas. Suporta hot-deployment de arquivos web.xml, o que permite editar tais arquivos enquanto o servidor está rodando e as novas configurações serão detectadas automaticamente; Suporta SSL sobre HTTP para comunicação segura, usando Java Secure Socket Extensions ; Suporta clusterização de servlets e JSPs; 3 VISÃO GERAL SOBRE WEB SERVICES De acordo com o W3C [1]: “There are many things that might be called "Web services" in the world at large. However, for the purpose of this Working Group and this architecture, and without prejudice toward other definitions, we will use the following definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAPmessages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” 1 Existem outras definições, mais simples, mas acreditamos que essa é a mais completa e aceita, tendo em vista o W3C(Word wide web consortium) ser 1 A tradução será omitida por motivos óbvios. Alterar depois. 263 6 amplamente respeitado na comunidade mundial de computação. A grande função de um WS é integrar sistemas escritos em diferentes linguagens, executando sobre diferentes plataformas de uma maneira padronizada e independente de fornecedores. No decorrer deste trabalho será apresentado mais sobre esta técnica, suas vantagens e desvantagens. Houve muita badalação há alguns anos sobre o XML (Extensible Markup Language) apontada por alguns entusiastas como solução final para todos os problemas de integração.Hoje este entusiasmo recai sobre a tecnologia de web services.Houve aqueles que não enxergam nada de novo no modelo proposto para services. Handerson Ferreira Gomes[HFG 2004], em seu pequeno artigo, “Integração de Sistemas? Há mais que Web Services.”, apresentado na revista Java Magazine, n° 15: “Ainda não me convenceram que de que seja possível que aplicações web services automaticamente localizem novos serviços na rede e reconheçam mensagens e seus formatos, integrando-se facilmente e, como num passe de mágica, concebendo uma nova aplicação”. O pequeno artigo citado expunha em uma página, uma solução baseada em URI/HTTP/XML, a qual, segundo ele poderia retirar boa parte da complexidade da tecnologia de web services com pouco investimento em servidores e treinamento de desenvolvedores e infra-estrutura. A realidade observada hoje, após curto período de tempo é que o mercado acreditou sim, na possibilidade de simplificar o trabalho daqueles que desejem, expor de maneira segura, alguns serviços já prestados por suas aplicações Desktop, na rede mundial de computadores. Nomes fortes da computação, como IBM, Oracle, Microsoft, Adobe, Xerox, SAP, Canoo, BEA Systens, Sun Microsystems trabalham junto a W3C em um forte empenho na definição de padrões e tecnologias para que a integração entre sistemas independentes deixe de ser uma experiência muitas vezes traumática nas diversas equipes de TI incumbidas de tal tarefa. 273 6 Dentre os padrões definidos por diversas equipes diferentes, além de contar com a colaboração de qualquer profissional da área que venha a ter interesse em colaborar com os projetos movidos pelo W3C, destaca-se a WSDL (Web Service Description Language). Uma linguagem para descrição de web services a ser utilizada como padrão pelos diversos fornecedores e consumidores de serviços.Uma lista completa com os desenvolvedores do projeto pode ser encontrado no sítio web http://www.w3.org/2002/ws/desc/#participants. Outro padrão mantido pelo W3C é o protocolo SOAP, atualmente na versão 1.2 o qual especifica um protocolo de uma maneira para a passagem de dados codificados em XML [Ethan, 2002]. Estes dois padrões serão melhores explicados posteriormente. A grande vantagem da web está em seu fácil acesso. E com o advento da computação móvel, os serviços poderão estar disponíveis em qualquer lugar. As possibilidades são infinitas. Desde de distribuidores deixando seus produtos a venda em forma de web services e mecanismos de busca, com enorme poder de busca, encontrando estes serviços e reunindo-os de forma fácil em termos de usabilidade para o usuário final, em uma gigantesca loja virtual, onde os consumidores poderiam encontrar qualquer item que desejarem com a vantagem de poder comparar o produto de diversos fornecedores em tempo real, serviços específicos de acesso restrito aos parceiros e colaboradores, como a compra de produtos por uma loja que mantém a política de não possuir estoque, serviços públicos como emissão de documentos ou declaração de impostos, ou mesmo fornecer informação ao usuário final, como um simples horário de ônibus na tela de seu celular. Grandes empresas detentoras de informação podem formar complexos esquemas de troca de informação para conhecer melhores os desejos e hábitos de uma população na qual possua interesse. É muito fácil perceber que há hoje no mundo enorme interesse nessa tecnologia, basta para isso visitar os sítios web de grandes fornecedores de software como a Sun Microsystems, IBM e Oracle. Então um Web service é um componente de software projetado para suportar interações maquina-maquina operando sob uma rede. Para tanto é necessária uma linguagem comum para definição de serviços na maquina que processa o serviço (WSDL), e um protocolo de comunicação para que outros sistemas possam interagir com o Web Service, o protocolo SOAP (Simple Object Access Protocol), o qual possui SOAP-messages as quais viajam por uma rede qualquer, privada ou não, de computadores em formato de Strings XML, utilizando-se do protocolo HTTP. 283 6 Figura 1. H. Voormann distribuída de maneira legal sobre a licença GNU. Na figura pode ainda ser visto a sigla UDDI (Universal Description, Discovery and Integration). As informações de um web service são publicadas usando este protocolo. E os aplicativos poderão acessar estas informações para determinar como utilizar os web services disponíveis em uma rede.O UDDI também receberá uma especial atenção posteriormente. 3.1 SOAP Simple Object Access Protocol O SOAP é a especificação de um protocolo de transmissão de dados codificados em XML. Define formas de simplificar a chamada remota de funções na Internet, permitindo que dois programas se comuniquem de forma muito semelhante à invocação de páginas Web. Foi submetido em 2003 pela IBM, Microsoft, Userland e DevelopMentor ao W3C que aceitou continuar o trabalho como mantenedor da especificação que hoje se encontra na versão 1.2. A atual versão é especificada em um documento produzido pelo XML Protocol Working Group que é também o responsável por futuras versões. Segundo a definição do W3C: 293 6 “SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.” Os dois principais objetivos do projeto para o SOAP, segundo o W3C2 são simplicidade e extensibilidade [XMLP]. O projeto SOAP procura atingir esses objetivos e omitir, do framework de mensagens, características que sejam encontradas com freqüência em sistemas distribuídos. Tais características incluem, mas não se limitam a “confiabilidade”, “segurança”, “correlação” e “distribuição”, além das SOAP Message Exchange Patterns (MEPs) , ou em português “Padrões para troca de mensagens SOAP”.Sendo este último o principal foco do documento de especificação do protocolo SOAP.Outras características são deixadas para ser definida como extensões por outras especificações. A especificação do protocolo SOAP versão 1.2 consiste em três partes. À parte 1 define que o framework de mensagens SOAP consiste de3: O SOAP processing model, define as regras para o para o processamento de uma SOAP message.[5] 1. O SOAP Extensibility model define os conceitos de características SOAP e de módulos SOAP.[6] 2. O SOAP underlying protocol descreve as regras para definir a ligação com uma outra camada de protocolo subjacente que pode ser usada para trocar mensagens SOAP entre nodos SOAP.[7] 3. O construtor de mensagens SOAP define a estrutura de uma mensagem SOAP.[8] À parte 0 (zero) do protocolo, é um documento não normativo que tem a intenção de prover um tutorial de fácil entendimento sobre as características da 2 3 http://www.w3.org/TR/soap12-part1/#intro http://www.w3.org/TR/soap12-part1/#intro 303 6 especificação SOAP versão 1.2, e pode ser encontrada no sitio Web http://www.w3.org/TR/2003/REC-soap12-part0-20030624/ . À parte dois descreve um conjunto de tecnologias que podem ser usadas em conexão com o framework de mensagens SOAP e pode ser acessado a partir do sitio web http://www.w3.org/TR/2003/REC-soap12-part2-20030624/ . De uma maneira bastante resumida, o protocolo funciona assim: Uma mensagem SOAP é contida em um pacote. Dentro deste pacote existem duas seções adicionais: Uma seção de cabeçalho (header) e o corpo da mensagem (body). A seção header possui informações relevantes sobre a mensagem, por exemplo, pode conter a data de quando a mensagem foi emitida, ou informações necessárias à autenticação. Não é obrigatória, mas quando presente deve estar no topo da mensagem. As seções body contem a mensagem em si. Dois protocolos, a saber, SMTP e HTTP, são suportados pelo protocolo SOAP para o transporte de mensagens SOAP em uma rede, mas o protocolo HTTP tem ganhado maior aceitação já que hoje trabalha melhor com a infra-estrutura existente na Internet. Existem diversas outras tecnologias de distribuição e comunicação como CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model), RMI (Remote Method Invocation), Mas os web services através do protocolo SOAP possuem uma grande vantagem, especificamente, ao utilizar o protocolo HTTP, as mensagens SOAP terão fácil acesso através de firewalls. Sendo está uma grande vantagem, já que os outros modelos de solução de integração citados geralmente terão suas mensagens barradas nos filtros dos firewalls, tecnologia já presente na maioria das maquinas ligadas a Internet. Não é objetivo deste documento tratar das características avançadas da especificação do protocolo SOAP, bem como não é o objetivo discutir implementações. Está seção visa apenas esclarecer algumas características do protocolo SOAP e no decorrer do texto, conforme venha a ser necessário, daremos maiores detalhes de implementação. Existem diversas alternativas ao uso do protocolo SOAP, deixamos aqui só para fins de registro algumas delas JSON, XINS, RST, XML-RPC, BEEP, entre outras. Estas tecnologias não serão objeto de estudo no presente documento. 313 6 3.2 UDDI (Universal Description, Discovery and Integration Service) O UDDI é uma plataforma independente baseada em XML, e tem como função registrar serviços na Internet, ou em outras palavras. “Fornece um mecanismo para a descoberta dinâmica de serviços na web. Utilizando-se a interface do UDDI, negócios podem se conectar dinamicamente a outros serviços fornecidos por parceiros externos. Um registro UDDI é similar a um registro CORBA, ou pode ser imaginado com um serviço DNS para uma aplicação de negócios”. [CM2005] Um registro UDDI possui dois tipos de clientes: negócios que querem publicar um serviço, como no caso da loja virtual que procura por serviços de vários fornecedores a fim de exibir os preços, e clientes que querem obter serviços de certo tipo, como quando uma empresa disponibiliza certas funções de seu sistema, como acesso através de web services, dado a certos colaboradores e parceiros, a serviços que estão disponíveis em seus sistemas. O UDDI é uma iniciativa aberta da industria, patrocinada pela OASIS ( http://www.oasis-open.org/home/index.php ) desenvolvido sobre o SOAP e assume que as requisições e respostas são objetos UDDI enviados como mensagens SOAP. Um registro de serviço UDDI é formado pro três componentes: Páginas Brancas – Fornecem o nome, endereço, telefone e outras informações de contato de um determinado negócio. São responsáveis pela publicação, ou seja, é como um fornecedor de serviço registra suas informações. Contêm a Informação do negócio, a qual é armazenada em um objeto BusinessEntity, o qual contém informações sobre os serviços, categorias, contatos, URLs e outros dados necessários para interagir com a empresa. Páginas Amarelas – Contêm informações que determinam a categoria do negócio. É responsável pela descoberta e mostra como uma aplicação descobre um serviço web em particular através dessas informações e fornece a informação do serviço, ou seja, descreve um grupo de serviços web. Estes estão contidos em um objeto BusinessService. 323 6 Páginas Verdes – Contêm as informações técnicas sobre um serviço Web. É responsável pela conexão e mostra como uma aplicação se conecta e interage com um serviço web após sua descoberta. As informações de conexão provem os detalhes técnicos necessários para invocar um serviço web. Isto inclui URLS, informações sobre os nomes dos métodos, tipos de argumentos e assim por diante. Estes dados são representados no objeto BindingTemplate. O UDDI é, normalmente, um dos padrões do núcleo core da tecnologia de implementação de Web services. Ele foi projetado para ser acessado através de mensagens SOAP e providenciar acesso aos documentos WSDL que descrevem o protocolo de ligação e os formatos das mensagens que são necessários para a interação com os serviços web listados em um diretório. 3.3 Web Service Description Language (WSDL) A Web Services Description Language (WSDL), conforme já informado no texto, é um formato publico de XML para a descrição de Web Services atualmente desenvolvida e mantida pelo W3C. É fruto de uma submissão de diversas empresas ao W3C (Ariba, IBM and Microsoft), as quais possuem os direitos sobre a versão corrente, o WSDL versão 1.1. [9] No entanto, já existe um release para uma versão 2.0 de maio de 2005 que se tornará uma recomendação do W3C assim que for formalmente aprovada[10]. A WSDL (pronuncia-se wiz-dell) descreve uma interface publica para um web service. É um documento baseado em XML que descreve o serviço e a forma como o mesmo se comunica. Ou seja, descreve o protocolo de ligação e os formatos de mensagens requeridos para a interação com os web services listados em um diretório de services. As operações suportadas e as mensagens são descritas de maneira abstrata. 333 6 A WSDL é freqüentemente combinada com o protocolo SOAP e com UDDI para prover web services na Internet. Dessa Maneira um programa cliente se conecta a um web service e pode ler seus arquivos WSDL a fim de determinar quais funções estão disponíveis no servidor. Alguns tipos especiais de dados são embarcados no arquivo WSDL na forma de um arquivo XML, o cliente pode então usar o protocolo SOAP para chamar uma dessas funções listadas no documento WSDL. Um documento WSDL define Services como coleções de pontos finais em uma rede, ou portos (do inglês Ports). Em WSDL uma definição abstrata de pontos finais e mensagens, é separada de sua implementação concreta na rede, ou das suas ligações aos dados. Isto permite o reuso de definições abstratas: mensagens, as quais são as descrições abstratas de como os dados podem ser trocados, e tipos de porto que são coleções abstratas de operações. O protocolo concreto, com os formatos específicos dos dados para um tipo de porto em particular, constitui uma ligação reutilizável. Um porto é definido como a associação de um endereço de rede com uma ligação re-usável, e uma coleção de portos define um serviço. Freqüentemente, um documento WSDL utiliza os seguintes elementos na definição de serviços de rede: Tipos – um container para tipos de dados usando em alguns tipos de sistemas, como em XSD (XML Schema Definition). Mensagem – Uma forma abstrata de definir como os dados serão comunicados. Operações – Uma descrição abstrata das ações suportadas pelo serviço. Tipos de Portos – um conjunto abstrato de operações suportado por um ou mais pontos finais. Ligação – um protocolo concreto com formato de dados específicos para um tipo de porto particular. Porto – Um ponto final único, definido com uma combinação de forma de ligação e um endereço na rede. Serviço – Uma coleção de endpoints que possuem relação. 343 6 Talvez, neste ponto, você leitor esteja muito confuso, mas com o passar do tempo, à medida que as implementações sejam realizadas e apresentadas, esperamos tornar mais claro a integração destes três padrões como a solução ideal para implementação do Web Service proposto neste trabalho. REFERÊNCIAS FURTADO, Carlos Alberto; BOTELHO, Maurício. Avaliação de Plataformas para o Desenvolvimento de Web Services. 2005. 200 p. Tese (Bacharelado em Sistemas de Informação) – Curso de Bacharelado em Sistemas de Informação, Universidade Federal de Santa Catarina, Florianópolis, 2005. 353 6 APACHE SOFTWARE FOUNDATION. Apache Derby Tutorial. Disponível em: <http://db.apache.org/derby/papers/DerbyTut/index.html>. Acesso em: 27 de Março de 2005. LOZANO, Fernando. O Novo HSQLDB. Java Magazine, Grajaú-RJ, n. 30, p. 18-22, 24-28, nov. 2005. LOZANO, Fernando; GALVÃO, Leonardo. Seção Cafeína, News e Bits. Java Magazine, Grajaú-RJ, n. 29, p. 6, out. 2005. CERAMI, Ethan – Web Services Essentials. Distributed Applications with XML-RPC, UDDI & WSDL. O´Reilly. Janeiro 2002. [1] WIKIPEDIA. Servidor Apache. Disponível em: <http://pt.wikipedia.org/wiki/Servidor_Apache>. Acesso em: 19 de Março de 2006. [2] < http://www.apache.org/>. Acesso em: 11 de Março de 2006. [3] Network Research Group. Hypertext Transfer Protocol -- HTTP/1.1. Disponível em: <http://www.w3.org/Protocols/rfc2616/rfc2616.html>. Acesso em: 13 de Março de 2006. [4] < http://httpd.apache.org/>. Acesso em: 22 de Janeiro de 2006. [5] W3C. SOAP Version 1.2 Part 1: Messaging Framework. Disponível em: <http://www.w3.org/TR/soap12-part1/#msgexchngmdl>. Acesso em: 19 de Fevereiro de 2006. [6] W3C. 3. SOAP Extensibility Model. Disponível em: <http://www.w3.org/TR/soap12-part1/#extensibility>. Acesso em: 11 de Março de 2006. [7] W3C. 4. SOAP Protocol Binding Framework. Disponível em: <http://www.w3.org/TR/soap12-part1/#transpbindframew >. Acesso em: 17 de Fevereiro de 2006. [8] W3C. 5. SOAP Message Construct. Disponível em: < http://www.w3.org/TR/soap12-part1/#soapenv >. Acesso em: 17 de Fevereiro de 2006. [9] W3C. Web Services Description Language (WSDL) 1.1. Disponível em: < http://www.w3.org/TR/wsdl >. Acesso em: 17 de Fevereiro de 2006. 363 6 [10] MILLER, John; VERMA, Kunal; RAJASEKARAN, Preeda.WSDL-S: A Proposal to W3C WSDL 2.0 Committee. Disponível em: <http://lsdis.cs.uga.edu/projects/wsdls/WSDL-S.pdf >. Acesso em: 18 de Fevereiro de 2006. [11] GIRALDI, Reubem Alexandre D’Almeida. FRAMEWORK PARA COORDENAÇÃO E MEDIAÇÃO DE WEB SERVICES MODELADOS COMO LEARNING OBJECTS PARA AMBIENTES DE APRENDIZADO NA WEB. 2004. 213 p. Dissertação (Obtenção do Grau de Mestrado) - Programa de Pós-graduação em Informática do Departamento de Informática do Centro Técnico e Científico. Rio de Janeiro, 2004. Glue user guide. Disponível em: <http://www1.webmethods.com/docs/glue/guide/index.html>. Acesso em: 18 de Fevereiro de 2005.
