interoperabilidade de webservices por meio do ... · treinamento e a capacitação do bolsista nos...

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 sistema-

piloto 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]


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.


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.

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.

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.

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.

CRIAÇÃO DO ARQUIVO DE

CONFIGURAÇÃO

CRIAÇÃO DAS CLASSES STUB

COMPILAR E EXECUTAR O

CLIENTE

CRIACAO DA INTERFACE

REMOTA

CRIAÇÃO DA CLASSE DO

SERVIÇO

CRIAÇÃO DO ARQUIVO DE

CONFIGURAÇÃO

GERAÇÃO DO WSDL E DO

MAPPING FILE

DEPLOYMENT DO WEB SERVICE

CRIACAO DO CLIENTE NO

DEPLOYTOOL

CRIAÇÃO DA PAGINA EM JSP

ELABORAÇÃO DO WAR FILE

DEPLOYMENT CLIENTE J2EE


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.


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];


• 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.


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.


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.


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)


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/jax-ws_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.

interoperabilidade de webservices por meio do ... · treinamento e a capacitação do bolsista nos...

Documents