interoperabilidade de webservices por meio do

Anais do 14º Encontro de Iniciação Científica e Pós-Graduação do ITA – XIV ENCITA / 2008
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 20 a 23, 2008.
INTEROPERABILIDADE DE WEBSERVICES POR MEIO DO
DESENVOLVIMENTO DE UMA ARQUITETURA ORIENTADA A
SERVIÇO – AOS (SERVICE ORIENTED ARCHITECTURE – SOA)
Ítalo Fernandes Aguiar
Instituto Tecnológico de Aeronáutica
Bolsista PIBIC-CNPq
Correio eletrônico: [email protected]
Prof. Dr. Adilson Marques da Cunha
Instituto Tecnológico de Aeronáutica
Correio eletrônico: [email protected]
Diogo Branquinho Ramos
Instituto Tecnológico de Aeronáutica
Correio eletrônico: [email protected]
Breno Lisi Romano
Instituto Tecnológico de Aeronáutica
Correio eletrônico: [email protected]
Resumo
A presente Pesquisa tem como objetivo dotar o Projeto Integrado de Cooperação Amazônica para a Modernização do
Monitoramento Hidrológico - ICA-MMH de uma SOA envolvendo Web Services da Agencia Nacional de Água – ANA, a fim de
aumentar sua qualidade e reduzir os desperdícios de recursos envolvidos na disseminação e concentração do conhecimento
hidrológico.
O Projeto foi desenvolvido em duas etapas. Na Primeira estudou-se: o Processo Unificado da IBM-Rational (Rational
Unified Process – RUP), a Linguagem de Modelagem Unificada (Unified Modeling Language – UML), a eXtensible Markup
Language – XML, conceitos básicos de uma SOA e suítes de desenvolvimento baseada nos frameworks Java juntamente com seus
Ambientes Integrados de Engenharia de Software Ajudada por Computador (Integrated Computer Aided Software Engineering
Enviroment – I-CASE-E). Na Segunda Etapa, realizou-se a Modelagem de Web Services em uma SOA, utilizando as principais
ferramentas pesquisadas na etapa anterior.
Ao final deste Trabalho de Iniciação Científica e com base nos resultados nele obtidos, realizou-se com sucesso o
treinamento e a capacitação do bolsista nos principais conceitos que envolvem uma SOA bem como se realizou com sucesso a
implementação de uma SOA baseada em componentes Web Services rodando num cenário similar ao sistema de Componentes
Computacionais distribuídos do Projeto ICA-MMH.
Palavras chave: Web Services, SOAP, XML, SOA
1.
Introdução
O Projeto ICA-MMH tem como objetivo desenvolver, para uma região hidrográfica de referência, um sistemapiloto que contemple a modernização e a integração de pontos de coleta telemétrica de dados hidrológicos, que servirá
como base para gestão dos recursos hídricos.
Por meio desse sistema, serão disponibilizadas as informações, em tempo real, para diferentes entidades e para a
sociedade, como insumo para o desenvolvimento de estudos e para a tomada de decisões.
A disponibilização dessas informações contribuirá, também, para o apoio a tomada de decisões no campo
econômico, principalmente as inerentes às atividades agrícolas, pesqueiras e de navegação, assim como no campo da
segurança.
Dentre os pontos de coletas, estão previstas algumas estações de referência para o acompanhamento das condições
hidrológicas visando à previsão de eventos extremos, tais como secas e inundações, para o que deverão ser
consideradas, também, informações de previsão de clima, como também dados e informações obtidas em países
limítrofes.
Nas estações de referência, deverão prever-se formas alternativas de comunicação de dados (via celular, rádio
freqüência e/ou satélite), garantindo a redundância e interrogação, em tempo real. Em alguns dos pontos de coleta,
deverão monitorar-se determinados parâmetros de qualidade de água, integrados e disponibilizados pelo sistema.
O desenvolvimento desse sistema como um todo deverá contribuir para: o progresso científico e tecnológico
nacional na área de coleta, transmissão, tratamento e difusão de dados; a melhoria da atuação do poder público no
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
gerenciamento de recursos hídricos; e o desenvolvimento da cooperação técnica com países limítrofes na área de
monitoramento hidrológico.
Desta forma, para completar com êxito o objetivo do Projeto ICA-MMH, far-se-á necessário lidar com diversos
componentes e aplicativos computacionais distribuídos em diversas estações situadas no Brasil e nos países limítrofes.
Devido ao grau de complexidade no qual o Projeto encontra-se inserido, torna-se necessário a adoção de um
conjunto de metodologias bem definidas, por meio das quais todas as etapas do projeto possam ser concluídas da forma
esperada.
Destarte, decidiu-se por utilizar o RUP como processo regente dos trabalhos. Este processo oferece uma
abordagem baseada em Disciplinas, atribuindo tarefas e responsabilidades, dentro de uma organização de
desenvolvimento de software. A sua meta é garantir a produção de softwares de alta qualidade, que atendam às
necessidades dos Usuários, dentro de Cronogramas e Orçamentos previsíveis.
Uma vez definidos o processo e a notação para o desenvolvimento do Projeto, a investigação das tecnologias supra
citadas resultou na escolha das Ferramentas Sun Java para desenvolvimento de Web Services e IBM Rational Rose
Professional Data Modeler Edition, como parte integrante da Suíte IBM Rational.
2.
Resultados Obtidos
As atividades realizadas neste Projeto de Iniciação Científica foram divididas em duas etapas. A primeira etapa Capacitação Tecnológica do Bolsista encontra-se descrita na seção 2.1, e a segunda etapa - Modelagem de Web Services
em uma SOA, na seção 2.2.
2.1. Etapa de Capacitação
Nesta primeira etapa do Trabalho de IC, houve o estudo e a pesquisa do Processo Unificado, assim como a sua
aplicabilidade no contexto do Projeto ICA-MMH. Em seguida, passou-se às pesquisas bibliográficas dos padrões UML
e XML bem como dos conceitos de SOA, visando a familiarização com os objetivos finais do Projeto, que consiste em
modelar Web Services obedecendo ao paradigma de uma SOA.
O início desta pesquisa se deu por meio de uma investigação sobre o RUP, que consiste de um Processo de
Engenharia de Software que aumenta a produtividade da equipe de desenvolvedores e oferece melhores práticas
relacionadas a software através de diretrizes, templates e orientações sobre ferramentas para atividades críticas de
desenvolvimento de software.
No desenvolvimento de um software, não é possível definir o problema e construir o projeto em um único passo.
Os requisitos freqüentemente mudarão no decorrer do projeto. Para isso, o RUP é baseado num desenvolvimento
iterativo e incremental, oferecendo ao projeto um constante processo de refinamento. Uma iteração incorpora um
conjunto seqüencial de atividades, conforme representado na Figura 1.
Figura 1: Desenvolvimento Iterativo no RUP
O RUP obedece a uma arquitetura geral conforme representado na Figura 2. O processo é representado em duas
dimensões. O eixo horizontal apresenta a dimensão de tempo, onde se descrevem as fases, marcos e iterações. O eixo
vertical apresenta a dimensão de conteúdo, onde se descrevem as Atividades, agrupadas no que chamamos de
Disciplinas. Desta forma, o RUP cobre todo o ciclo de vida de desenvolvimento de um software. [1]
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
Figura 2: Gráfico Modelo de Iteração
Após esta abordagem sobre o RUP, passou-se para o estudo do XML. Tendo em vista o atual estágio de
desenvolvimento em que se encontram as aplicações distribuídas pela internet e mesmo numa rede interna de uma
determinada empresa, sentiu-se a necessidade de se implementar uma nova linguagem que atendesse os seguintes
objetivos:
• Que fosse idêntico na hora de enviar e receber informações em HyperText Markup Language - HTML,
para aproveitar toda a tecnologia implantada para este último;
• Que fosse extensível, para que possa ser utilizado em todos os campos do conhecimento; e.
• Que fosse fácil de ler, editar, implantar, programar e aplicar aos distintos sistemas.
Portanto, a World Wide Web Consortium – W3C desenvolveu o projeto de linguagem eXtensible Markup Language
- XML. Esta consiste em um subconjunto da Standard Generalized MarkupLanguage – SGML, permitindo que uma
marcação específica seja criada para especificar idéias e compartilhá-las na rede [15].
A UML é uma linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de
orientação a objetos. Ela tornou-se, nos últimos anos, a linguagem padrão para a modelagem adotada pelos engenheiros
de software em âmbito internacional. [4]
A UML surgiu da união de três metodologias de modelagem: o método de Booch, o método Object Modeling
Technique - OMT de Jacobson e o método Objected Oriented Software Engineering - OOSE. A partir delas, surgiu em
1996 a primeira versão propriamente dita da UML. Finalmente, em 1997, a UML foi adotada pela Object Management
Group - OMG como uma linguagem padrão de modelagem.
Torna-se importante notar que a UML, enquanto linguagem de modelagem, não possui utilidade na programação
em si do sistema. Esta linguagem possui como objetivo ajudar na definição de características do sistema como
requisitos, seu comportamento, estrutura lógica, dinâmica dos processos e até mesmo nas suas necessidades físicas
sobre o qual o sistema deverá ser implantado.
Um sistema de informação necessita também de uma documentação detalhada, precisa e atualizada, para que seja
possível realizar uma manutenção com facilidade e rapidez, sem a indesejável produção de novos erros.
O desenvolvimento de um projeto através da UML é feito basicamente através de diagramas objetivando fornecer
diversas visões do sistema a ser modelado, procurando-se desta forma atingir a completude da modelagem. Dentre os
treze tipos Diagramas característicos na UML, quatro deles se destacam como os de maior relevância em um projeto.
São eles os diagramas de Casos de Uso, Classes, Seqüência e Gráficos de Estados.
O Diagrama de Casos de Uso identifica os atores (usuários e outros sistemas) que utilizam alguma forma o
software bem como os serviços (chamados de Casos de Uso) que o sistema disponibiliza aos atores.
O Diagrama de Classes, um dos mais utilizados em UML, define a estrutura de classes utilizadas pelo sistema,
especificando métodos e atributos de cada classe bem como a forma com que estas estão relacionadas entre si.
O Diagrama de Seqüência representa a ordem temporal em que as mensagens são trocadas entre os objetos
envolvidos em um determinado processo. Normalmente, este diagrama identifica o evento gerador do processo, o ator
responsável pelo evento e como o processo deve se desenvolver até sua conclusão.
No Diagrama de Gráficos de Estados, são representadas as mudanças sofridas por um objeto em um determinado
processo. Para atingir este objetivo, esse diagrama, muitas vezes, baseia-se em um Caso de Uso e em classes
relacionadas no Diagrama de Classes.
Dessa forma, a UML possibilita a análise da estrutura do sistema em desenvolvimento a partir de diferentes
perspectivas. Assim a modelagem através dessa linguagem mostra-se como uma ferramenta eficiente para se atingir de
forma mais completa o objetivo desta pesquisa.
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
Concluída a etapa de pesquisa sobre a UML, passou-se a pesquisa sobre Arquiteturas Orientadas a Serviços.
Primeiramente é importante desenvolver o conceito de arquitetura de software. A definição usada pelo Institute of
Electrical and Electronics Engineers - IEEE estabelece que uma arquitetura de software trata basicamente de como os
componentes fundamentais de um sistema se relacionam intrinsecamente e extrinsecamente [7].
Uma SOA tem como seu componente fundamental o conceito de Web Services, portanto, torna-se de fundamental
importância desenvolver este conceito para que seja possível atingir o objetivo desta pesquisa.
Web Services, genericamente, são serviços ofertados via web. Existem grande divergências sobre a real definição
desse conceito. Porém, de forma simplificada, pode-se dizer que Web Service consiste em um padrão para integrar
sistemas através da utilização de protocolos de Internet como HTTP.
Um fato que diferencia os Serviços Web dos demais padrões de integração, é que estes se caracterizam por serem
baseados em tecnologias neutras como os protocolos de Internet e da tecnologia XML.
A utilização de um padrão neutro, como XML, para descrever e utilizar os Web Services faz com que esta
modalidade para integração de sistemas se torne mais prática, fácil e viável, pois independem de qualquer linguagem ou
plataforma. Por exemplo, um sistema de reserva de passagens aéreas feitas em Java sendo executado em um servidor
Linux pode acessar, com transparência, um Serviço de reserva de hotel feito em.Net sendo executado em um servidor
Microsoft [12].
A tecnologia de Web Services permite que aplicações se comuniquem. Ou seja, o conteúdo pode ser transmitido
através da Internet pelo Serviço Web e recebido por uma aplicação remota, pela qual os dados podem ser utilizados de
variadas maneiras: processados e exibidos em uma página da Internet, em uma aplicação desktop, ou em um dispositivo
móvel.
Para comunicar com o Web Service, faz-se necessário uma implementação do protocolo Simple Object Access
Protocol – SOAP. Com este protocolo, responsável pela independência nos Web Services, torna possível se encontrar
diversas implementações disponíveis em várias linguagens.
Na Figura 3, encontra-se um diagrama com as mensagens trocadas entre cliente e servidor em uma comunicação
SOAP. Existem duas aplicações se comunicando, um Client Wrapper e um Server Wrapper que estão disponibilizando
a transparência para as aplicações. Entre eles só trafega XML, seguindo o protocolo SOAP sobre HTTP.
Figura 3: Esquema Básico de Funcionamento de um Web Service
Para que um Web Service seja acessado, necessita-se definir suas propriedades, a forma de acesso, e que valores ele
retornará. Estas definições são descritas em um arquivo XML de acordo com a padronização Web Service Description
Language - WSDL. Este arquivo será de acesso público, para que os possíveis clientes possam identificar os serviços
oferecidos.
O processo de publicação/pesquisa/descoberta de Web Services utiliza o protocolo Universal Description,
Discovery and Integration - UDDI. Dessa Forma, todos os conceitos apresentados sobre essa forma de oferecer servicos
pela internet podem ser sintetizados através da Figura 4, na qual são apresentadas as principais tecnologias envolvidas
em um Web Service.
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
Figura 4: Esquematização das Tecnologias em um Web Service
Com o exposto acima, finaliza-se o breve desenvolvimento sobre os conceitos que envolvem a tecnologia Web
Service, retomando os conceitos pesquisados sobre SOA’s.
Os sistemas desenvolvidos até pouco tempo eram tipicamente fechados, de maneira que caso fosse necessária uma
extensão era preciso criar outra aplicação e compô-la de maneira a ficar transparente. Com o uso da orientação a objetos
e o encapsulamento, tornou-se possível compor distintas aplicações com alguma alteração de código, porém uma
alteração menos significativa que no desenvolvimento com linguagens procedurais [7].
Porém, atualmente, os requisitos de um sistema mudam muito rapidamente. A orientação a objetos por si só não
resolve mais o problema da composição de aplicações. Mesmo uma pequena alteração de código pode causar um
grande impacto no sistema. O ideal perseguido é compor ou recompor aplicações sem tocar em código já constituído e
devidamente testado.
Assim, um grupo de profissionais da área criou a Aliança Agile, com o objetivo de descobrir melhores meios de
desenvolver software e ajudar outros a fazê-lo. Junto com essa Aliança, surgiu o SOAP, criado para facilitar a chamada
remota de métodos de classes, dando origem assim aos XML Web Services.
Uma SOA consiste basicamente em uma nova metodologia que permite ao engenheiro de software aproveitar as
aplicações já existentes no ambiente para integração com os novos processos de negócios por meio Web Services. Uma
conseqüência imediata deste fato consiste na redução do tempo no desenvolvimento das novas aplicações.
Dentro de uma arquitetura orientada a serviço, aplicativos, informações e outros recursos de Tecnologia da
Informação - TI são vistos como serviços ou "blocos de construção". Cada um desses serviços pode ser misturado e
combinado para criar novos e flexíveis processos de negócios, derivando deste fato a importante característica de baixo
acoplamento entre os serviços.
De uma forma geral, os sistemas que se baseiam em uma SOA contêm pontos em comuns nas seguintes, não
necessariamente em todas, características listadas a seguir: Reuso “Caixa-Preta”; Distribuição; Heterogeneidade no
Ambiente; Dinamismo e Adaptabilidade; e Granularidade.
O passo seguinte incide na capacitação da utilização da Plataforma Sun Java de desenvolvimento de Web Services.
Tendo em vista que o foco da pesquisa trata-se de desenvolver Web Services em uma SOA, a escolha da plataforma
de desenvolvimento não pode representar um fator decisivo, justamente porque a proposta de uma SOA consiste em
trabalhar na interoperabilidade entre diferentes plataformas.
Portanto, definiu-se plataforma Java para se desenvolver a maior parte desta pesquisa. Os principais motivos que
levaram a essa escolha inicial foram:
• Java roda em múltiplas plataformas, desde mainframes até celulares;
• Java é estável e seguro; e
• Montar uma completa plataforma Java de desenvolvimento é gratuito.
Primeiramente, para possibilitar o desenvolvimento de qualquer aplicativo Java, foi adotado o Java Development
Kit 5.0 - JDK da Sun. Nele encontramos o compilador Java e muitas das classes essenciais para se trabalhar na
plataforma Java.
No contexto desta pesquisa, mostra-se essencial à escolha de um programa que possibilite uma fácil comunicação
através do protocolo HTTP. Um Cotainer Java 2 Enterprise Edition – J2EE representa um programa dedicado a esse
tipo de comunicação e normalmente vem com algumas Application Programming Interfaces – API’s que facilitam o
tratamento de mensagens XML. Para esse intuito, foi escolhido o Container Sun Application Server 8.2 - SAS.
A Sun também disponibiliza o Java Web Services Developer Pack - JWSDP, que consiste num conjunto de
ferramentas para auxiliar no desenvolvimento de Web Services e Clients. Adotou-se para esse intuito o JWSDP 1.5.
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
A capacitação nesse conjunto de ferramentas da Sun se iniciou com a elaboração de um Web Service, um Cliente
Java 2 Standard Edition – J2SE e um Cliente J2EE. Todos esses aplicativos desenvolvidos ainda estão bem aquém da
complexidade do objetivo final desta pesquisa, porém serviram para consolidar uma base consistente sobre o
funcionamento das tecnologias envolvidas neste projeto.
Primeiramente, foi criado, conforme a seqüência representada na Figura 5, um Web Service a partir da abordagem
Java-WSDL, na qual o arquivo WSDL será gerado a partir de classes e tipos Java padrões.
CRIACAO DA
INTERFACE
REMOTA
CRIAÇÃO DA
CLASSE DO
SERVIÇO
GERAÇÃO DO
WSDL E DO
MAPPING FILE
CRIAÇÃO DO
ARQUIVO DE
CONFIGURAÇÃO
DEPLOYMENT
DO WEB SERVICE
Figura 5: Esquematização da Criação de um Web Service Simples
Depois de elaborado por completo o Web Service, foram criados dois aplicativos Clientes para esse Serviço. O
primeiro Cliente, um aplicativo desktop, foi desenvolvido em J2SE e o segundo, um aplicativo web, em J2EE.
Para a criação do Cliente J2SE, podem ser usados diversos métodos. O método escolhido neste trabalho usa classes
Stub. Essas classes são geradas pelas ferramentas Java API for XML based on Remote Procedire Call – JAX-RPC. Sua
função é converter uma chamada de método da interface em uma request SOAP e uma response SOAP em valores de
retorno para o Cliente. Para desenvolver esse método de criação de Cliente J2SE, foi usado o paradigma descrito na
Figura 6.
CRIAÇÃO DO
ARQUIVO DE
CONFIGURAÇÃO
CRIAÇÃO DAS
CLASSES STUB
COMPILAR E
EXECUTAR O
CLIENTE
Figura 6: Esquematização da criação de um Cliente J2SE
Para desenvolver esse método de criação de Cliente J2EE, foi usado o paradigma descrito na Figura 7.
CRIACAO DO
CLIENTE NO
DEPLOYTOOL
CRIAÇÃO DA
PAGINA EM JSP
ELABORAÇÃO
DO WAR FILE
DEPLOYMENT
CLIENTE J2EE
Figura 7: Esquematização da criação de um Cliente J2EE
Portanto, a partir do êxito na criação de um Web Service gerador de senhas e aplicativos Cliente J2SE e J2EE,
conclui-se a Etapa de capacitação nas ferramentas JDK, JWSDP e SAS da Sun, escolhidas para desenvolver o objetivo
desta pesquisa.
O passo seguinte é a capacitação na utilização da Suite IBM Rational de I-CASE-E. Essa capacitação consistiu na
aprendizagem de conceitos básicos que envolvem a programação em UML na ferramenta Rational Rose Professional
Data Modeler Edition.
Nessa capacitação, foram modelados alguns diagramas UML de um software que realiza o controle de dados para
uma locadora fictícia de vídeo. Nesta modelagem, foram abordados apenas os já citados quatro principais diagramas.
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
2.2. Etapa de Modelagem de Web Services
2.2.1. Estudo de Caso
Como descrito anteriormente na presente pesquisa, o Projeto ICA-MMH objetiva o desenvolvimento, para uma
região hidrográfica de referência, de um sistema que contemple a modernização e a integração de pontos de coleta
telemétrica de dados hidrológicos, que servirá como base para gestão dos recursos hídricos.
Nas estações de referência, deverão ser monitorados determinados parâmetros de qualidade de água, integrados
e disponibilizados pelo sistema. Para isso foram implantadas as Plataformas de Coleta de Dados – PCD. Estas adquirem
dados hidrometeorológicos e enviam vias satélites, celulares ou radio-freqüência para o Sistema de Aquisição de Dados
– SAD. Este Sistema também é responsável por receber os dados de órgãos externos, os quais enviam dados em seus
respectivos formatos proprietários.
Depois de coletados no SAD, os dados passam pelo Sistema de Tratamento de Dados – STD. Este sistema
define domínios de dados, utilizando filtros para procurar e localizar exceções de dados, para só assim persistir o dado
no Banco de Dados – BD Hidrometeorológico do Sistema de Banco de Dados – SBD. Este, por sua vez, possui toda
modelagem e regras de negócios definidas para permitir a persistência dos dados.
Com os dados já tratados e persistidos, realiza-se o monitoramento e controle sobre estes dados por meio do
Sistema de Monitoramento, Controle e Apoio a Decisão – SMCAD. Após a passagem por esses três sistemas acima
descritos, é possível difundir estes dados, para as entidades nacionais e internacionais, via Sistema de Difusão de Dados
– SDD. A Figura 8 ilustra como as Entidades e Sistemas envolvidos no Projeto ICA-MMH se relacionam entre si.
Figura 8: Entidades e Sistemas envolvidos no Projeto ICA-MMH
A presente Pesquisa, baseada na proposta do Projeto ICA-MMH, concentra seu enfoque no desenvolvimento de
uma SOA para dar suporte ao funcionamento de um sistema que simula a função do SAD. Tal sistema recebe dados de
Órgãos Externos e tem a tarefa de persistir tais informações em um BD, simulando o Banco de Dados do SBD.
Desta forma, implementa-se um Web Service em Java que disponibiliza alguns métodos predefinidos para que os
Órgãos Externos possam enviar os seus dados ao sistema. Por sua vez, para cada um desses Órgãos, cria-se um
programa cliente que irá carregar um arquivo de dados (medições obtidas) e invocar os métodos do Web Service
desenvolvido para que este persista as informações no BD.
A Figura 9 ilustra como se desenvolveram a comunicação entre clientes, Web Service e Banco de Dados.
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
Figura 9: Estrutura dos Sistemas envolvidos nesta pesquisa
2.2.2. Regras de Negociação
Para este estudo de caso, estabeleceram-se diversas regras de negociação, simulando parcialmente o contexto no
qual se insere o Projeto ICA-MMH. O sistema desenvolvido nesta pesquisa, com a sua proposta de uma SOA baseada
em Web Services, deve ser capaz de atender as seguintes especificações:
• Cada Órgão Externo envolvido no projeto possui seu respectivo código, nome e jurisdição;
• Cada Estação possui seu respectivo código, nome, jurisdição e país. Esta também se encontra situada em
uma determinada sub-bacia em uma massa d’água específica;
• Cada Equipamento (PCD) usado nas medições possui um código, nome, fabricante e mede um
determinado tipo de parâmetro;
• Cada unidade de medida envolvida nas medições possui um código, nome, abreviação e descrição;
• Cada medição contém um código e um valor. Além disso, a medição traz informação sobre data e hora,
bem como localização, representados por latitude, longitude e altitude;
• Um Órgão, a cada momento que tiver de enviar medições, deve fazê-lo por meio de um arquivo texto.
Cada um desses arquivos enviados possui um determinado formato e guarda as informações de data e hora
de envio;
• Cada medição origina-se de um e apenas um equipamento. Este por sua vez pode dar origem a muitas
medições;
• Cada equipamento mede um parâmetro de uma determinada unidade de medição. Dessa forma, uma
unidade de medição associa-se a diversos equipamentos diferentes; e
• Cada equipamento localiza-se em uma determinada estação. Esta, por sua vez, pode conter diversos
equipamentos.
Dessa forma, o BD do sistema desenvolvido deve implementar um modelo que suporte todas as regras de
negociação especificadas acima. As classes Java devem também obedecer as mesmas regras, para realizar um
interfaceamento entre os aplicativos Java e o BD desenvolvido.
2.2.3. Desenvolvimento
No decorrer da presente pesquisa, constatou-se necessário adotar, além das ferramentas computacionais já
estudadas, um conjunto adicional de softwares para que seja possível atingir com eficiência o objetivo do trabalho.
Dessa forma, foi necessário utilizar os softwares:
• NetBeans 6.1: O NetBeans 6.1 é um Ambiente de Desenvolvimento Integrado - IDE em Java
desenvolvido pela empresa Sun Microsystems. Esta IDE automatiza o processo de criação de Web
Services por meio dos pacotes JAX-WS [16].
• MySQL Server 5.0: O MySQL é um Sistema de Gerenciamento de Banco de Dados que utiliza a
Linguagem de Consulta Estruturada (Structured Query Language - SQL) como interface. O MySQL,
além de um software gratuito, disponibiliza um conjunto de ferramentas de interface gráfica que
facilita tarefas de consulta, inserção, alteração e deleção de dados do BD [17];
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
•
•
Erwin Data Modeler: O CA ERwin Data Modeler é uma ferramenta de software utilizada para a
modelação de sistemas de informação. Por meio desta ferramenta, o desenvolvedor de um sistema de
informação pode especificar os dados envolvidos, as suas relações e os requisitos de análise. A
ferramenta permite a criação das bases de dados e dos mecanismos de sincronização de dados
necessários e engenharia reversa [18]; e...
Hibernate 3.2: O Hibernate é um framework para o mapeamento objeto-relacional escrito na
linguagem Java, além de ser um software livre de código aberto. Este programa facilita o
mapeamento dos atributos entre uma base de dados relacionais e o modelo objeto de uma aplicação,
mediante o uso de arquivos XML [19].
Depois de definido o novo conjunto de Ferramentas, partiu-se para a implementação do projeto. O sistema
desenvolvido foi arquitetado para suportar sua operação utilizando três computadores/servidores geograficamente
dispersos. Em um deles encontra-se o BD com os dados já inseridos e disponíveis para receber conexões externas. Em
um outro computador, implantou-se o Web Service, que realiza conexão com o banco de dados. Por fim, no terceiro e
último computador, instalou-se um aplicativo desktop cliente, o qual solicita métodos oferecidos pelo serviço web.
As operações disponibilizadas pelo Web Service dividem-se em duas: adicionar histórico e adicionar medição.
Assim, o aplicativo cliente, o qual possui uma versão instalada em cada um dos órgãos externos, com acesso
encapsulado a somente estas duas operações.
A ferramenta Rational Rose Professional Data Modeler Edition, utilizada para elaboração dos diagramas UML
desta pesquisa, serviu para modelar o Diagrama de Caso de Uso, representado na Figura 10, que apresenta o
relacionamento e a distribuição dos aplicativos na SOA desenvolvida.
Figura 10: Diagrama de Caso de Uso dos aplicativos envolvidos no Projeto
Para dar suporte ao sistema, modelou-se um Diagrama de Classes. As regras de negociação, especificadas na seção
2.2.2, constituíram o ponto de partida para construção deste diagrama.
O framework Hibernate, conforme exposto anteriormente, possui a função de realizar a comunicação da camada do
aplicativo Java, no caso o Web Service, com a camada de BD. Para realizar esta função, necessita-se que cada uma das
classes Java contenha, dentre outros métodos, os métodos getters e setters para cada um dos atributos definidos.
A técnica exposta acima se denomina Plain Old Java Objects – POJO. Porém, para evitar poluição visual do
diagrama de classes, omitiram-se os métodos que caracterizam a técnica de POJO.
Nas associações definidas no Diagrama de Classes, implementou-se um método para realizar a associação nos dois
sentidos de navegação entre dois objetos em apenas uma etapa. Dessa forma, ao se associar, por exemplo, um
equipamento a uma medição, esta automaticamente relaciona-se ao equipamento em questão. A Figura 11 ilustra o
Diagrama de Classes desenvolvido.
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
Figura 11: Diagrama de Classes do Projeto
Baseado no Diagrama de Classes e nas regras de negociação especificadas ao sistema implementou-se o modelo de
BD representado na Figura 12.
Figura 12: Banco de Dados modelado
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
A partir do modelo de BD desenvolvido, a ferramenta ERwin gera automaticamente um script SQL que implementa
o BD originalmente modelado.
O Diagrama de Seqüência elaborado ilustra como se dá o processo de interfaceamento entre o aplicativo cliente e o
Web Service. O primeiro, implementado em um Java Archive – JAR de nome “Cliente”, possui, como classe principal,
um arquivo de mesmo nome. O segundo, implementado em um WAR File denominado “ProjetoServidor”, possui, como
classe principal, um arquivo de nome “setBD”.
O processo de envio, do cliente para o Web Service, do histórico com o conjunto de medições obtidas nas diversas
estações encontra-se representado no Diagrama de Seqüência da Figura 13 e acontece da seguinte forma:
• O programa cliente lê um arquivo externo ao JAR que contém os dados de configuração do Órgão Externo
em que ele se encontra instalado;
• Em cada Órgão Externo coletam-se atributos suficientes para se formar um novo objeto da classe
“Historico”, por meio de um arquivo texto “txt”;
• Por meio do método “addHistorico(parâmetros coletados para o histórico)” disponibilizado pelo serviço
web, o cliente persiste no BD um novo histórico, tendo, como valor de retorno do método, o código do
histórico persistido;
• Um arquivo “txt” com diversas linhas, cada linha representando uma medição completa, simulando uma
PCD, é lido pelo cliente. A cada linha lida, coletam-se dados suficientes para se formar um novo objeto da
classe “Medição”.
• Utilizando o método “addMedicao( parâmetros coletados para a medição)” do Web Service, o cliente
persiste no BD a medição formada e tem como valor de retorno do método o código do histórico
persistido; e
• Repetem-se os dois itens acima até que sejam lidas e persistidas todas as medições contidas no arquivo
texto.
Figura 13: Diagrama de Seqüência para o processo de interfaceamento entre Cliente e Web Service
O Diagrama de Seqüência, elaborado para ilustrar como se dá o método “addHistorico” do Web Service, recebe
parâmetros do aplicativo cliente e, com estes, forma um novo objeto da classe “Historico” e persiste este no BD. Este
processo se dá da seguinte forma:
• A classe “setBD” obtém uma sessão Hibernate com o BD MySQL, por meio da classe “HibernateUtility”;
• A partir dos parâmetros recebidos do cliente, forma-se o objeto da classe “Historico”;
• A partir da sessão obtida, persiste-se este objeto. Com um objeto Query, implementa-se um mecanismo de
retornar para a classe “setBD” o código do histórico persistido; e
• O código obtido é retornado para o cliente que o solicitou e encerra-se a sessão Hibernate aberta.
O Diagrama de seqüência para o método “addHistorico” encontra-se representado na Figura 14.
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
Figura 14: Diagrama de Seqüência para o método "addHistorico" do Web Service
O processo de adicionar uma medição, implementado no método “addMedicao” no Web Service, segue um padrão
análogo ao processo para adicionar um histórico. Esse processo para medição está representado no Diagrama de
Seqüência apresentado na Figura 15.
Figura 15: Diagrama de Seqüência para o método "addMedicao" do Web Service
2.2.4. Resultados obtidos na etapa de Modelagem de Web Services
Inicialmente, foi executada a classe “CarregarBD”, que faz parte do sistema servidor onde encontra-se o Web
Service, tendo assim acesso direto ao BD. Como resultado desta execução, persistiu-se uma série de registros no BD:
Estações, Unidades, Equipamentos e Órgãos Externos. Tal resultado é apresentado na Figura 16.
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
Figura 16: Resultado, no console, da execução da Classe CarregarBD
Após esta etapa de persistência, na qual mobiliou-se o BD com dados essenciais, o projeto servidor como um todo
foi implantado no computador de IP 161.24.73.136, conforme especificado no Diagrama de Caso de Uso da Figura 10
Assim, o site http://161.24.75.162:16733/ProjetoServidor/setBDService?wsdl fornece o WSDL para o serviço
implantado.
Com os dados essenciais já persistidos e com o Web Service disponível para receber chamadas remotas, deu-se
inicio a etapa de interação Cliente – Web Service. O exemplo desenvolvido neste trabalho considera o aplicativo cliente
executado no Órgão Externo de código 1. Porém, existe um arquivo externo ao Jar cliente no qual é possível alterar
esse código. Assim, torna-se viável aplicar o mesmo programa a todos os Órgãos.
Dessa forma, quando executado o Jar cliente no suposto Órgão de código 1, as 168 medições armazenadas em um
arquivo “txt” foram carregadas pelo aplicativo cliente e repassadas ao Web Service. Este, por sua vez, concluiu com
êxito a inserção de todas as medições no BD. O resultado da execução do “Cliente.jar” encontra-se resumido nas
Figuras 17 e 18.
Figura 17: Resultado da execução do aplicativo Cliente (Parte 1)
Figura 18: Resultado da execução do aplicativo Cliente (Parte 2)
Anais do XIV ENCITA 2008, ITA, Outubro, 20-23, 2008
3.
Conclusões
Ao final desta Pesquisa de Iniciação Científica e com base nos resultados nele obtidos, realizou-se com sucesso o
treinamento e a capacitação do bolsista nos principais conceitos acerca do RUP. Além disso, abordou-se também: a
linguagem XML; o padrão da Linguagem de Modelagem Unificada UML; o ambiente Rational Rose da IBM, com
enfoque na ferramenta Rational Rose Professional Data Modeler Edition; e a suíte de ferramentas da Sun Java, que
proporcionou um desenvolvimento metódico de Web Services e outros aplicativos desktop.
Conforme inicialmente previsto, realizou-se com sucesso a implementação de uma Arquitetura Orientada a
Serviços baseada em componentes Web Services rodando num cenário similar ao sistema de Componentes
Computacionais distribuídos do Projeto ICA-MMH.
Para o desenvolvimento com sucesso de uma SOA baseada em Web Services, utilizou-se: 5 (cinco) Diagramas
UML (1 (um) de Caso de Uso, 1 (um) de Classes e 3 (três) de Seqüência); 1(um) Modelo de Banco de Dados; e 1550
linhas de código-fonte produzidas a partir das ferramentas IBM Rational Rose Professional Data Modeler Edition,
NetBeans 6.1, Hibernate 3.2, Erwin Data Modeler e MySQL Server 5.0.
No decorrer desta pesquisa, estudaram-se diversas tecnologias envolvidas não só no campo referente a SOA e Web
Service, como também ferramentas das mais variadas áreas computacionais. Assim, a realização deste Trabalho
possibilitou a agregação de valor de interdisciplinaridade no currículo de pesquisador, visando o futuro acadêmico do
bolsista de iniciação científica envolvido.
4.
Agradecimentos
O autor deste Trabalho de Iniciação Científica agradece aos profissionais da Área de Computação do Instituto
Tecnológico de Aeronáutica – ITA que muito o apoiaram em toda a trajetória desta Pesquisa: ao Prof. Dr. Adilson
Marques da Cunha e aos Alunos de Pós-Graduação do ITA Diogo Branquinho Ramos e Breno Lisi Romano.
Por meio da oportunidade desta pesquisa, boa parte dos conhecimentos da área de computação foram aprendidos,
principalmente os relacionados com o desenvolvimento de Web Services e os conceitos por trás de uma SOA.
Agradece também ao CNPq, que vinculado ao Ministério da Ciência e Tecnologia – MCT, vem apoiando a
pesquisa brasileira e contribuindo diretamente para a formação de jovens pesquisadores, investindo e promovendo o
aumento da produção de conhecimento, e gerando novas oportunidades para os universitários, que possuem o objetivo
de adquirir conhecimentos acadêmicos que transcendem o que lhes são oferecidos nas grades-padrão de ensino de suas
respectivas Universidades.
5.
Referências
[1] Tutorial RUP da Rational: www.wthreex.com/rup/ ;
[2] RUP – Rational Unified Process: Otávio Rodolfo Piske, 2003;
[3] Site oficial da UML : www.uml.org;
[4] Guedes, Gilleanes T. A., 2006, “UML, Uma Abordagem Prática”;
[5] Sampaio, Cleuton, 2006, “SOA e Web Services em Java”;
[6] Cesta, André Augusto, 2004, “A LINGUAGEM DE PROGRAMAÇÃO JAVA”;
[7] Machado, João Coutinho, 2004, “Um Estudo sobre o Desenvolvimento Orientado a Serviços”;
[8] Duarte, John Anderson M., 2005, “Arquitetura Orientada a Serviços como um Diferencial em uma Fábrica de
Software”;
[9] Esmin, Ahmed Ali Abdalla, 2001, “Modelando com UML – Unified Modeling Language”;
[10] Camelo, Dioclécio Moreira, 2002, Web Service;
[11] Santos, Michael Schuenck, 2003, “Utilização de Web Services na plataforma. NET para a criação de um aplicativo
visualizador de notícias para dispositivos móveis”;
[12] Pamplona, Vitor Fernando, 2006, “Web Services. Construindo, disponibilizando e acessando Web Services via
J2SE e J2ME”, http://www.javafree.org/content/view.jf?idContent=4;
[13]Erl, Tomas, 2007, “Introdução às tecnologias Web Services: SOA, SOAP, WSDL e UDDI”,
http://www.devmedia.com.br/articles/viewcomp.asp?comp=2873;
[14]Duarte,
Otto Carlos
Muniz
Bandeira,
2006,
“XML
Extensible
Markup
Language”,
http://www.gta.ufrj.br/grad/00_1/miguel/ ;
[15] Introdução a XML, endereço eletrônico: http://www.criarweb.com/xml/;
[16]Introdução aos serviços Web JAX-WS, endereço eletrônico: http://www.netbeans.org/kb/60/websvc/jaxws_pt_BR.html;
[17] MySQL 5.0 Refrerence Manual, endereço eletrônico: http://dev.mysql.com/doc/refman/5.0/en/index.html;
[18] ERwin Getting Started Guide: Tutorial incluso no programa Erwin; e
[19] Bahuer, Christian; King, Gavin. “Hibernate em Ação”, 2005.