UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA – UEFS
Larissa Rocha Soares
UMA ARQUITETURA ORIENTADA A SERVIÇOS PARA MAPAS
CONCEITUAIS
FEIRA DE SANTANA 2010
LARISSA ROCHA SOARES
UMA ARQUITETURA ORIENTADA A SERVIÇOS PARA MAPAS
CONCEITUAIS
Trabalho de Conclusão de Curso apresentado ao curso de Engenharia de Computação da Universidade Estadual de Feira de Santana para a obtenção do título de Bacharel em Engenharia de Computação.
Orientador: Prof. Dr. Gabriela Ribeiro P. R. Pinto Co-orientador: Prof. David Moises B. Santos
FEIRA DE SANTANA 2010
Dedico este trabalho à senhora Bondade e ao senhor Humildade personificados, respectivamente, em Adenilde e Lourival, meus pais. Obrigada por me ensinarem a fazer as melhores escolhas e lutar pelo que desejo. Dedico este trabalho também a Igor, pelo amor, força e dedicação nesta minha caminhada. Sem seu apoio a realização deste trabalho não seria possível.
RESUMO
A aprendizagem significativa é o processo por meio do qual novas idéias se relacionam de maneira não-arbitrária e substantiva com idéias já existentes (MOREIRA, 2006). Para Ausubel et al. (1978), há três tipos de aprendizagem significativa: representacional, de conceitos e proposicional. Este trabalho está relacionado com a aprendizagem de conceitos, o qual envolve a criação de mapas conceituais. As aplicações que proporcionam a construção de mapas conceituais através do computador são uma ferramenta didática muito importante para o aprendizado. Entretanto, elas são, geralmente, restritas a um determinado conjunto de plataformas. O trabalho que foi desenvolvido está intrinsecamente ligado a essa problemática: como construir uma arquitetura flexível para mapas conceituais de forma que possam ser trabalhados em diferentes plataformas? A estratégia que se utilizou para solucionar a questão foi o desenvolvimento de uma arquitetura orientada a serviços (Service Oriented Architecture - SOA). Para esta arquitetura, foram desenvolvidos 15 serviços com o propósito de auxiliar na construção de mapas conceituais, como criar conceitos, frases de ligações e inserir recursos (áudio, vídeo, entre outros). Para testar e validar a arquitetura desenvolvida, foram criados dois clientes, o WSmaps, um software implementado pela própria autora deste trabalho, e um cliente inserido no ambiente Problem Basic Learning – Virtual Enviroment (PBL-VE), ambiente virtual de aprendizagem que tem o objetivo de possibilitar a realização de sessões tutoriais do método PBL.
ABSTRACT
Meaningful learning is the process by which new ideas are related in a non-arbitrary manner and substantive with existing ideas (MOREIRA, 2006). To Ausubel et al. (1978), there are three kinds of meaningful learning: representational, of concepts and propositional. This work is concerned with learning of concepts, which involves the creation of concept maps. The applications that provide the construction of conceptual maps through the computer is a very important teaching tool for learning. However, these applications are generally restricted to a limited set of platforms. The work that was developed is intrinsically linked to this problem: how to build a flexible architecture for conceptual maps so they can be worked on different platforms? The strategy que was used to solve this issue was the development of a service-oriented architecture (Service Oriented Architecture - SOA). The strategy that was used to resolve the issue was to develop a service-oriented architecture (Service Oriented Architecture - SOA). For this architecture were developed 15 services with the purpose of assisting in the construction of concept maps, creating concepts, phrases, links and insert features (audio, video, etc.). To test and validate the architecture developed there were two customers, WSmaps, a software implemented by the very author of this work, and a customer entered into the Problem Basic Learning Environment - Virtual Environment (VE-PBL), virtual learning environment that is order to enable the realization of the method PBL tutorial sessions.
LISTA DE FIGURAS
Figura 01: Exemplo de mapa conceitual ...15
Figura 02: Paradigma find-bind-execute do SOA...18
Figura 03: Encapsulamento de serviços. ...19
Figura 04: Modelo Publish-Discover-Invoke de Web Services...21
Figura 05: Estrutura da mensagem SOAP...23
Figura 06: Camada de descrição dos serviços. ...25
Figura 07: Mapa conceitual sobre a metodologia de pesquisa aplicada...31
Figura 08. Tecnologias adotadas para o desenvolvimento do trabalho...32
Figura 09. Visão geral da arquitetura Axis...33
Figura 10: Exemplo uefs.cxl. Fonte: próprio autor. ...38
Figura 11: Design de mapa gerado no CmapTools a partir do arquivo uefs.cxl. ...39
Figura 12: Diagrama de casos de uso para a arquitetura desenvolvida. ...40
Figura 13: Diagrama de sequência referente ao caso de uso “Criar mapa”. ...42
Figura 14: Código em JAVA por detrás do serviço “criarMapaConceitual”. ...44
Figura 15: Exemplo de saída do serviço “inserirConceito”. ...45
Figura 16: Arquivo cxl do mapa conceitual com os conceitos “novela” e “atores”...47
Figura 17: Arquivo cxl do mapa conceitual apenas com o conceito “atores”...48
Figura 18: Parta do WSDL da arquitetura referente a seção type. ...49
Figura 19: Parta do WSDL da arquitetura referente a seção message...50
Figura 20: Parta do WSDL da arquitetura referente a seção portType...50
Figura 21: Parta do WSDL da arquitetura referente a seção binding...51
Figura 22: Parta do WSDL da arquitetura referente a seção serivce...52
Figura 23: Tela inicial do WSmaps. ...53
Figura 24: Mapa conceitual criado no WSmaps...53
Figura 25: Arquivo CXL do mapa conceitual SOA. ...54
Figura 26: Mapa conceitual gerado no software CmapTools a partir do arquivo cxl originado no WSmaps...55
Figura 27: Tela do PBL-VE onde foi inserida a aba referente a criação dos mapas conceituais. ...56
Figura 28: Arquivo cxl referente ao mapa “MapaAula”. ...57
LISTA DE TABELAS
Tabela 01 Etapas do trabalho...28
Tabela 02 Documentação do caso de uso criar frase de ligação. ...41
Tabela 03 Web Services da arquitetura para mapas conceituais ...43
LISTA DE ABREVIATURAS E SIGLAS
ACM – Association for Computing Machinery API – Application Programming Interface CXL – Concept Mapping eXtensible Language HTML – HyperText Markup Language
IDE – Integrated Development Environment
IEEE – Institute of Electrical and Electronics Engineers JDOM – JAVA Document Object Model
JSP – Java Server Pages
MIME – Multipurpose Internet Mail Extensions PBL – Problem Based Learning
PBL-VE – Problem Based Learning-Virtual Enviroment SOA – Service-Oriented Archicteture
SOAP – Simple Object Access Protocol
UDDI – Universal Description, Discovery, and Integration UML – Unified Modeling Language
W3C – World Wide Web Consortium WS – Web Services
WSDL – Web Services Description Language XML – eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO ...10
2 FUNDAMENTAÇÃO TEÓRICA...13
2.1 Mapas Conceituais...13
2.1.1 Elementos e Características ...13
2.1.2 Uso dos Mapas Conceituais...15
2.1.3 Ferramentas para construção de mapas conceituais ...16
2.2 Service -Oriented Archicteture (SOA)...17
2.2.1 Serviços ...18
2.2.2 Princípios da orientação a serviços...19
2.2.3 Web Services...20
2.2.4 Padrões de comunicação de Web Services ...22
2.2.4.1 Simple Object Access Protocol (SOAP)...22
2.2.4.2 Universal Description, Discovery, and Integration (UDDI)...23
2.2.4.3 Web Services Description Language (WSDL)...24
2.2.5 Vantagens e Desvantagens dos Web Services ...25
3 METODOLOGIA...28
3.1 Tecnologias utilizadas para o desenvolvimento da arquitetura ...31
3.3.1 Apache Axis2 ...32
3.3.2 Apache TomCat...34
3.3.3 XML Schema...35
3.3.4 JDOM ...35
4 UMA ARQUITETURA ORIENTADA A SERVIÇOS PARA MAPAS CONCEITUAIS ...37
4.1 Características gerais da arquitetura desenvolvida ...37
4.2 Modelagem em diagramas UML...39
4.3 Implementação da arquitetura...42
4.4 WSDL gerado...48
4.5 Análise e discussão dos resultados obtidos...52
4.5.1 Software WSmaps ...52
4.5.2 Ambiente PBL-VE ...55
REFERÊNCIAS ...61 APÊNDICES ...65
1 INTRODUÇÃO
A aprendizagem significativa, uma das teorias de ensino/aprendizagem, é o processo por meio do qual novas idéias se relacionam de maneira não-arbitrária (há relação lógica entre a nova idéia e as antigas) e substantiva (o indivíduo consegue explicar com as próprias palavras o conteúdo aprendido) com idéias já existentes (MOREIRA, 2006).
Para Ausubel et al. (1978), há três tipos de aprendizagem significativa: representacional, de conceitos e proposicional. O tipo mais básico e do qual os demais tipos dependem é a aprendizagem representacional. Ela “envolve a atribuição de significados a determinados símbolos (tipicamente palavras), isto é, a identificação, em significado, de símbolos com seus referentes (objetos, eventos, conceitos)” (MOREIRA, 2006, p. 25).
A aprendizagem de conceitos provém da representacional pelo fato dos conceitos serem também representados por símbolos, porém “são genéricos e categóricos já que representam abstrações dos atributos criteriais (essenciais) dos referentes, isto é, representam regularidades em eventos ou objetos” (MOREIRA, 2006, p. 25). Por exemplo, a palavra “bola” para uma criança pequena: na aprendizagem representacional é estabelecida uma equivalência, em significado, entre o som bola (um símbolo) e o objeto “bola” (um referente). Na aprendizagem de conceitos a equivalência é estabelecida entre símbolo e os atributos criteriais comuns a múltiplos exemplos do referente (diferentes bolas) (MOREIRA, 2006).
A aprendizagem proposicional tem como finalidade aprender o significado de idéias em forma de proposição. As palavras combinadas em uma sentença para construir uma proposição representam conceitos (MOREIRA, 2006).
Este trabalho está relacionado com o segundo tipo de aprendizagem significativa, a aprendizagem de conceitos. Ou seja, está ligado à técnica do mapeamento conceitual, a qual é uma estratégia facilitadora da aprendizagem significativa. Essa estratégia envolve a criação de mapas conceituais que são diagramas que indicam relações entre conceitos (MOREIRA, 2006). Eles podem ser utilizados como instrumentos didáticos, de avaliação e ainda como recurso para análise de conteúdo.
As aplicações que proporcionam a construção de mapas conceituais através do computador são uma ferramenta didática muito importante para o aprendizado, pois permitem a elaboração de forma rápida e automatizada dos mapas. Dentre as aplicações mais conhecidas estão o CMapTools (CMAPTOOLS, 2010) e o Compendium (COMPENDIUM,
2010). Há sites também que permitem a criação de mapas conceituais on-line, como por exemplo, o Nestor (NESTOR, 2010).
Entretanto, essas aplicações são, geralmente, restritas a um determinado conjunto de plataformas. Por exemplo, o CMapTools é um ferramenta para desktop, se um usuário desejasse utilizar no celular ou TV Digital Interativa, não poderia. O trabalho que será desenvolvido está intrinsecamente ligado a essa problemática: como construir uma arquitetura flexível para mapas conceituais de forma que possam ser trabalhados em diferentes plataformas?
A estratégia que se utilizou para solucionar a questão é usar uma arquitetura orientada a serviços, denominada Service Oriented Architecture – SOA (ERL, 2005). Uma das suas características mais importantes é, justamente, a sua natureza de baixo acoplamento, ou seja, a interface do serviço é independente da implementação. Deste modo, os desenvolvedores de aplicativos podem construir aplicações, constituindo um ou mais serviços, sem conhecer as implementações dos serviços de base.
O objetivo geral desse trabalho consiste no desenvolvimento de uma arquitetura orientada a serviços para mapas conceituais. Para cumprir tal objetivo é necessário: investigar o estado da arte de arquitetura para mapas conceituais; definir o modelo padrão para mapeamento de mapas conceituais em dados semi-estruturados baseado em Extensible
Markup Language (XML); definir os serviços relativos à construção e edição de mapas
conceituais; e propor, modelar e implementar uma arquitetura de software usando princípios de SOA.
Este projeto de pesquisa tem relevância na área educacional e em outras árreas como matemática, física, psicologia e a própria computação, pois os mapas conceituais são uma ferramenta, hoje, muito utilizada por pesquisadores e educadores. Assim, os benefícios desse trabalho vão desde facilitar o estímulo à aprendizagem significativa, a apreensão de novos conceitos proporcionados pelos mapas, além de proporcionar mais um meio para organizar e representar o conhecimento.
A motivação para a realização deste trabalho partiu da afeição da estudante que o desenvolveu pela área de educação em engenharia. Esta área em conjunto com o prazer pelo desenvolvimento de sistemas, principalmente no que diz respeito à utilização de novas tecnologias, como SOA, antes desconhecidas, trouxe a vontade e o anseio para o desenvolvimento do projeto.
Este documento está organizado da seguinte forma: no Capítulo 2, Fundamentação Teórica, são abordados os principais conceitos e características a respeito de mapas
conceituais e SOA. O Capítulo 3, Metodologia, apresenta as etapas do projeto e as suas respectivas descrições. O Capítulo 4, Projeto, refere-se à descrição do trabalho desenvolvido e o os resultados alcançados. Por fim, no Capítulo 5, Considerações Finais, há as conclusões correspondentes aos objetivos do trabalho e as perspectivas vislumbradas.
2 FUNDAMENTAÇÃO TEÓRICA
Nesta seção serão apresentados os principais conceitos de Mapas Conceituais e
Service Oriented Architecture (SOA). A Seção 2.1 se refere à conceituação dos mapas, seus
elementos, características e utilização. A Seção 2.2 trata da definição de SOA, seus princípios, padrões, vantagens e desvantagens.
2.1 Mapas Conceituais
O mapa conceitual, de acordo com o seu criador, Joseph D. Novak, é uma técnica apresentada como “estratégia”, “método” e “recurso esquemático”. Segundo Novak e Gowin (1988, p.19) deve-se procurar dar exemplos de estratégias simples, mas potencialmente poderosas, para ajudar os estudantes a aprender e para ajudar os educadores a organizar os materiais objeto dessa aprendizagem.
Em relação ao método, ele diz que a construção dos mapas conceituais “é um método para ajudar estudantes e educadores a captar o significado dos materiais que vão aprender” (NOVAK, 1988, p. 29). E, por fim, por recurso ele expõe que “um mapa conceitual é um recurso esquemático para representar um conjunto de significados conceituais incluídos em uma estrutura de proposições” (NOVAK, 1988, p. 33).
2.1.1 Elementos e Características
Mapas conceituais são diagramas que indicam relações entre conceitos. Nesta perspectiva, o mapa conceitual contém três elementos fundamentais: conceito, proposição e palavras de ligação. O conceito é dito, segundo Novak (1988, p. 22), como uma regularidade nos acontecimentos ou nos objetos que se designa mediante algum termo. Acontecimentos são “qualquer coisa que ocorre ou pode ser provocada” e objetos “são qualquer coisa que existe e pode ser observada” (PEÑA et tal, 2005, p.44) .
Uma proposição é constituída de dois ou mais conceitos conectados a palavras (palavras de ligação) para formar uma unidade semântica. “É a menor unidade semântica que tem valor de verdade, pois se afirma ou nega algo de um conceito” (PEÑA et tal, 2005, p.44).
Palavras de ligação são palavras que têm a funcionalidade de juntar conceitos e indicar o tipo de relação existente entre eles. Por exemplo, na frase “a flor é branca”, os dois termos conceituais “flor e branca”, estariam ligados pelo verbo “é”. Tem-se assim uma proposição.
Segundo Peña (2005, p. 46), há três características dos mapas conceituais que os diferenciam de outros recursos gráficos ou técnicas cognitivas: hierarquização, seleção e impacto visual.
Em relação à hierarquia, nos mapas conceituais os conceitos estão organizados por ordem de importância. Os conceitos mais inclusivos ocupam os lugares mais elevados da estrutura gráfica. Quanto à segunda característica, seleção, os mapas constituem uma síntese de um assunto ou de um texto. Antes de construí-los, faz-se necessário determinar o seu escopo, se será sobre o texto escolhido ou parte do texto. Em relação ao impacto visual, Novak (1988, p. 106) diz que um mapa é conciso se apresenta de modo simples e atraente as relações entre as idéias principais. A Figura 01 mostra um mapa conceitual com o tema: mapas conceituais. Ela resume a definição dos mapas mostrando: o que ele é (recurso para representação), do que distingue-se (por exemplo, de resumos), como é caracterizado e como é representado (por conceitos).
Figura 01: Exemplo de mapa conceitual (PEÑA et tal, 2005). 2.1.2 Uso dos Mapas Conceituais
Os mapas conceituais, segundo Moreira (2006), podem ser utilizados como instrumento didático, instrumento de avaliação ou recurso para análise do conteúdo.
Como instrumentos didáticos, os mapas podem ser utilizados de forma a apontar as relações hierárquicas entre os conceitos ensinados em um curso inteiro, uma aula ou uma unidade de estudo. São representações das estruturas conceituais que facilitarão o aprendizado de quem está estudando. As vantagens do uso de mapas conceituais vão desde enfatizar a estrutura conceitual de uma disciplina, mostrar que há uma hierarquia entre os conceitos que facilita a aprendizagem e retenção do assunto, até o fato de proporcionar uma visão integrada do conteúdo abordado (MOREIRA, 1993). Já as desvantagens, estas podem ser: alunos encararem o mapa como algo a mais para ser memorizado, além de que mapas confusos e complexos dificultam a aprendizagem; a habilidade dos alunos em construir os mapas pode ficar inibida se eles recebem sempre os mapas feitos pelo professor (MOREIRA, 1993).
A avaliação de aprendizagem é outra possibilidade para o uso de mapas conceituais. Porém, esta avaliação não tem como objetivo dar nota ou testar o aluno, mas sim conhecer o tipo de estrutura que o aluno vê para um conjunto de conceitos. A principal idéia na avaliação por mapas conceituais é a de avaliar o que o aluno conhece em termos conceituais, ou seja, “como ele estrutura, hierarquiza, diferencia, relaciona, discrimina, integra conceitos de uma determinada unidade de estudo, tópico, disciplina, etc.” (MOREIRA, 2006, p. 55). Desta forma, os mapas conceituais são úteis também para investigar mudanças na estrutura cognitiva do aluno.
Finalmente, os mapas podem ser bastante úteis na análise de quais são os conceitos centrais para o entendimento de programas educacionais. Segundo Moreira (2006, p. 62):
Os mapas conceituais podem ser uma ferramenta importante para focalizar a atenção do planejador de currículo para o ensino de conceitos e para distinção entre conteúdo curricular e conteúdo instrumental. Ou seja, entre o conteúdo que se espera que seja aprendido e aquele que servirá de veículo para a aprendizagem.
2.1.3 Ferramentas para construção de mapas conceituais
Embora o objetivo deste trabalho não seja a comparação entre as ferramentas existentes, ou seja, o foco do trabalho não está na construção de mais um software para concepção de mapas conceituais, mas sim pautado numa outra forma de possibilitar a construção de mapas conceituais através de serviços, mesmo assim é interessante apresentar quais as principais ferramentas da área.
O CMap Tools é uma ferramenta para construção e compartilhamento de mapas conceituais. O CMap Tools é composto de duas versões: a do cliente (que constrói mapas, tem funções de busca numa base de dados centralizados para mapas e recursos associados) e a do servidor (que centraliza a funções de armazenamento de mapas e retorna resultados de busca). O CMap Tools é um sistema do Institute for Human and Machine Cognition (IHMC), desenvolvido sob a supervisão de Alberto J. Cañas (MORAES, 2006).
O Inspiration, disponível em <http://www.inspiration.com/home.cfm>, utiliza a web como uma estrutura de grafos, bases e repositórios. Essa ferramenta não reforça nenhuma estrutura de grafo em particular, e a representação não requer frases de ligação. Ela permite ao usuário trocar entre visualização de grafo e de consulta (MORAES, 2006).
O Compendium, disponível em: <http://compendium.open.ac.uk/institute/>, é uma ferramenta de software que fornece uma flexível interface visual para gerenciar as conexões entre informações e idéias. Validado em ambos os projetos de pequeno e grande porte em diversos setores da sociedade, é o resultado de pesquisa e desenvolvimento de mais de 15 anos na intersecção de hipertexto, modelagem colaborativa, memória organizacional, argumentação apoiada pelo computador, além de ser um facilitador de reuniões.
Maiores informações sobre as funcionalidade e características de cada uma dessas ferramentas descritas anteriomente, podem ser visualizadas no apêndice B deste documento, onde há uma comparação entre as três.
2.2 Service -Oriented Archicteture (SOA)
Embora existam outras formas de construir aplicações desacopladas e que permitem ser utilizadas em diferentes plataformas e sistemas, como RESTful, SOA foi escolhida devido a sua facilidade de implementação e grande variedade de livros e materiais de estudo existentes.
Quando juntamos “arquitetura” com orientação a serviços isto toma uma conotação técnica, mão mais apenas teórica. “Arquitetura orientada a serviços” é um termo que representa um modelo em que a lógica automática é decomposta em unidades menores, unidades distintas de lógica. Coletivamente, estas unidades abrangem uma parte maior da lógica automática de negócios. Individualmente, estas unidades podem ser distribuídas (ERL, 2005).
Arquitetura orientada a serviços (SOA) encoraja unidades de lógica individuais a existir de forma autônoma, ainda que não isoladas umas das outras. Unidades de lógica são ainda obrigadas a obedecer um conjunto de princípios que lhes permitam evoluir de forma independente, mantendo uma quantidade suficiente de uniformização e padronização. Em SOA, estas unidades de lógica são conhecidas como serviços (services) (ERL, 2005).
De forma a exemplificar o que significa orientação a serviços, podemos fazer uma analogia com uma cidade. Ela seria, então, cheia de empresas orientadas a serviços. Companhias são orientadas a serviços no sentido que provê um serviço distinto que pode ser utilizado por múltiplos clientes. Estas empresas abrangem uma comunidade empresarial. Faz sentido para uma comunidade empresarial não ser servida por um único fornecedor para todos os serviços, já que cada empresa é diferente.
SOA usa o paradigma find-bind-execute, como mostrado na Figura 02. Neste paradigma, provedores de serviços registram o seu serviço em um registro público. Este registro é utilizado pelos clientes para encontrar os serviços que atendem certos critérios (find). Se o registro tem um dado serviço, ele proporciona ao consumidor um contrato e um endereço para aquele serviço (bind-execute) (MAHMOUD, 2005). Retomando a analogia, este registro de serviços poderia ser visto como as páginas amarelas de um catálogo telefônico – mesmo que ainda seja pouco usado atualmente – através do qual os interessados buscam por provedores de um determinado serviço.
Figura 02: Paradigma find-bind-execute do SOA (MAHMOUD, 2005).
2.2.1 Serviços
Para manter sua independência, os serviços encapsulam lógica dentro de um contexto distinto. Esse contexto pode ser específico para uma tarefa de negócio, uma entidade empresarial, ou algum outro agrupamento lógico. Como a preocupação com os destinatários de um serviço pode ser pequena ou grande, o tamanho e o escopo da lógica representada por um serviço pode variar. Além disso, a lógica do serviço pode abranger a lógica provida por outros serviços. Neste caso, um ou mais serviços são compostos em um coletivo (ERL, 2005).
Como pode ser observado na Figura 03, embora a construção de uma solução automática consistir de serviços, “cada serviço pode encapsular uma tarefa realizada por um passo individual ou um sub-processo composto por um conjunto de passos. Um serviço pode encapsular toda a lógica do processo” (ERL, 2005, p. 34).
Figura 03: Encapsulamento de serviços (ERL, 2005).
Dentro de SOA, serviços podem ser utilizados por outros serviços ou por programas. O relacionamento entre serviços é baseado no entendimento de que para os serviços interagirem, eles devem ser conscientes uns dos outros.
2.2.2 Princípios da orientação a serviços
Os principais princípios do conceito de orientação a serviços são (ERL, 2005, p. 37): - Baixo acoplamento: Serviços mantêm um relacionamento que minimiza dependência e apenas requer que eles se mantenham cientes da existência de cada um;
- Contrato de serviço: Serviços aderem ao acordo de comunicação, como definido coletivamente por um ou mais descrições de serviços e documentos relacionados. Uma descrição de serviço, em sua forma mais básica, estabelece o nome e a localização do serviço, bem como suas requisições de troca de dados;
- Autonomia: Serviços têm controle sobre a lógica que eles encapsulam;
- Abstração – Além do que é descrito no contrato do serviço, serviços ocultam a lógica do resto do mundo.
- Reusabilidade – A lógica é dividida em serviços que têm a intenção de promover o reuso.
-Agregabilidade – Coleções de serviços podem ser coordenados e agregados para formar serviços compostos.
-Apátrida – Serviços minimizam a retenção da informação específica para uma atividade.
- Descobrimento – Serviços são projetados para serem aparentemente descritivos para que eles possam ser encontrados e avaliados através de mecanismos de descoberta disponíveis.
Com o conhecimento da arquitetura básica de SOA e o conjunto dos princípios de
design já é possível moldar e padronizar arquiteturas, mas falta uma plataforma de
implementação que permitirá puxar estas peças para construir soluções automatizadas orientadas a serviços. A tecnologia Web Services é uma das possibilidades que oferece essa plataforma (ERL, 2005).
2.2.3 Web Services
O termo “orientado a serviços” e diversas abstrações de modelos SOA existiam antes da chegada de Web Services. Entretanto, nenhum avanço da tecnologia tem sido tão adequado e bem sucedido na manifestação do SOA quanto Web Services (ERL, 2005).
Segundo Erl (2005), todas as principais plataformas de desenvolvimento atualmente suportam a criação de soluções orientadas a serviços, e mais, fazem com que a compreensão de SOA seja baseada na utilização de Web Services. SOA é normalmente realizado através de
Web Services, já que a tecnologia de Web Services fornece um mecanismo padrão de
interoperabilidade entre diversas aplicações de softwares, executando em uma variedade de plataformas e/ou frameworks (W3C, 2007). “Ou seja, Web Services é uma metodologia para conectar e comunicar. Enquanto SOA é uma estratégia de TI” (KOCH, 2006). Especificações de Web Services pode ser a melhor forma de utilizar SOA para resolver problemas de negócios (MAHMOUD, 2005).
Web Services são sistemas de software projetado para suportar interação
máquina-máquina interoperáveis sobre uma rede. Essa interoperabilidade é obtida através de um conjunto de padrões abertos baseados em XML, tais como Web Services Description
Language (WSDL), Simple Object Access Protocol (SOAP) e Universal Description, Discovery and Integration (UDDI). Estes padrões fornecem uma abordagem comum para a
definição, publicação e utilização de Web Services (MAHMOUD, 2005).
A Figura 04 apresenta o funcionamento de Web Services. Uma vez que um Web
Service é descoberto, o cliente faz uma solicitação para um Web Service. O Web Service
processa o pedido e envia a resposta de volta para o cliente. A Figura 04 mostra como um cliente se comunica com um Web Service Java na plataforma J2EE 1.4. Pode-se observar que as aplicações J2EE podem usar Web Services publicados por outros provedores, independentemente de como eles são implementados (MAHMOUD, 2005).
Todos os detalhes entre o pedido e a resposta acontecem nos bastidores. O desenvolvedor lida apenas com a típica semântica da linguagem de programação Java, tais como chamadas de método Java, tipos de dados, e assim por diante. Ele não precisa se preocupar com o mapeamento de Java para XML e vice-versa, ou a construção de mensagens SOAP (MAHMOUD, 2005).
Figura 04: Modelo Publish-Discover-Invoke de Web Services (MAHMOUD, 2005).
Como pode ser observada, a arquitetura Web Services é baseada na interação de três entidades: provedor de serviços, consumidor de serviços ou cliente e catálogo de serviços. As três entidades interagem entre si através das operações de publicar, localizar e ligar (IBM, 2002):
• Provedor de serviços: cria e desenvolve o serviço Web que serve para expor alguma funcionalidade de negócio da sua organização para a invocação por outros usuários externos;
• Consumidor de serviços ou cliente: qualquer usuário que deseja utilizar algum serviço Web;
• Catálogo de Serviços (UDDI): um diretório central onde o provedor de serviços possa cadastrar e descrever seus serviços, e onde o consumidor possa procurar pelo serviço desejado.
2.2.4 Padrões de comunicação de Web Services
Um Web Services é caracterizado pelos três padrões baseados em XML citados anteriormente. O SOAP define um protocolo XML para mensagens transportadas. UDDI fornece a infra-estrutura necessária para a publicação de descoberta de serviços e WSDL introduz uma gramática comum para a descrição de serviços (BPE, 2002).
A arquitetura de representação de dados XML representa a camada de fundação de SOA. Dentro dela, o XML define o formato e a estrutura das mensagens que viajam ao longo de serviços. XSD schemas preservam a integridade e a validade dos dados da mensagem, e XSLT é utilizada para permitir a comunicação entre as representações de dados diferentes por meio do mapeamento do esquema. Em outras palavras, não tem como fazer um movimento dentro SOA sem envolver XML (ERL, 2005).
2.2.4.1 Simple Object Access Protocol (SOAP)
O SOAP é um protocolo simples para troca de informação em um ambiente distribuído e descentralizado, como é o ambiente da Internet. SOAP habilita dois processos comunicarem entre si desconsiderando o hardware e a plataforma que eles estão rodando. Um dos grandes benefícios do SOAP é que ele é aberto e provê a base para a comunicação aplicação-aplicação: os Web Services (LEOPOLDO, 2003).
Uma mensagem SOAP é formada por três elementos: envelope, elemento principal do XML que representa toda a mensagem; cabeçalho, um mecanismo genérico de adição de características à mensagem SOAP em maneira descentralizada; e corpo, contém a codificação atual de uma chamada a um método e todos os argumentos de entrada ou uma resposta
codificada que contém o resultado de uma chamada a um método (LEOPOLDO, 2003). A estrutura da mensagem SOAP pode ser observada na Figura 05.
Figura 05: Estrutura da mensagem SOAP (LEOPOLDO, 2003).
2.2.4.2 Universal Description, Discovery, and Integration (UDDI)
De acordo com Reckziegel (2006), o Universal Description, Discovery, and
Integration (UDDI) é uma especificação técnica que tem como objetivo descrever, descobrir e
integrar Web Services. Além disso, a Organization for the Advancement of Structured
Information Standards (OASIS, 2001), define que este é um elemento central do grupo de
padrões que compõe a pilha de componentes dos Serviços Web.
Gunzer (2002) define UDDI como um padrão desenvolvido para fornecer um diretório de busca para os negócios e seus serviços. Tem como objetivo ser um mediador do serviço, permitindo que os clientes requisitantes encontrem um fornecedor do serviço apropriado.
À primeira vista o processo de descoberta de Web Services pode parecer simples. No entanto, quando é necessário descobrir quais provedores oferecem os serviços desejados, a capacidade de descobrir as respostas torna-se muito mais complicada. Com a intenção de resolver este problema, UDDI usa uma abordagem baseada em uma base de registros distribuídos de provedores de serviços e suas descrições de serviços, implementada utilizando um formato XML comum (ANDRADE, 2002).
Na maioria dos casos, programas e desenvolvedores usam a base de registros UDDI para localizar informações sobre serviços. No caso específico de programadores a utilização está focada na preparação de sistemas compatíveis com Web Services anunciados ou para descrever seus próprios serviços que serão utilizados por terceiros (ANDRADE, 2002).
O registro UDDI pode ser considerado um grande catálogo de Web Services. Os repositórios mais conhecidos são o XMethods (http://www.xmthods.net) e o Salcentral (http://www.salcentral.com) . Algumas empresas disponibilizam também APIs específicas para acessos a seus Web Services, como o site Google (http://code.google.com/intl/pt-BR/apis/soapsearch/reference.html ) e Amazon (http://aws.amazon.com/. Para que se possa utilizar os serviços, o usuário deve estar registrado na empresa.
2.2.4.3 Web Services Description Language (WSDL)
Segundo W3C (2001), Web Services Description Language (WSDL) é um formato XML para descrever serviços em rede. As operações e mensagens são descritas abstratamente e então destinadas para um protocolo de rede que formata a mensagem para os endpoints definidos.
É a descrição WSDL que habilita qualquer programa a entender como interagir com o
Web Service, pois ela possui as informações sobre quais operações um serviço possui, quais
os tipos de entrada e saída de cada operação e qual a localização e o tipo de protocolo utilizado para invocar o serviço (GOVERNO ELETRÔNICO, 2008).
O uso do WSDL na arquitetura de Web Services convencionalmente divide a descrição do serviço em duas partes: a interface do serviço e a implementação do serviço (Figura 6). A definição da interface do serviço é uma descrição abstrata que pode ser referenciada e utilizada por múltiplos serviços. É análoga à definição de uma classe abstrata em uma linguagem de programação orientada a objetos. A definição da implementação do serviço é um documento WSDL que descreve como uma determinada interface é implementada por algum provedor de serviço (service provider) (GOVERNO ELETRÔNICO, 2008).
Figura 06: Camada de descrição dos serviços (HANSEN, 2003).
A interface do serviço contém a definição de serviço WSDL, de forma a permitir que uma interface possa ser utilizada por múltiplas definições de implementação de serviços, incluindo diretivas (HANSEN, 2003):
• Binding: descreve protocolos, formato de dados, segurança e outros atributos para uma interface (portType) em particular;
• PortType: informa elementos de operações do Web Services;
• Message: define entrada e saída de dados referentes a operações. Pode assumir a forma de um documento inteiro ou de argumentos que devem ser mapeados para invocação de métodos;
• Type: define tipos de dados complexos em uma mensagem.
A camada de definição de implementação do serviço descreve onde o serviço está instalado e como pode ser acessado. A definição de um serviço (service, Figura 6) contém uma coleção de elementos port com um elemento binding. Um arquivo de implementação além de descrever onde o Web Service está instalado e como é acessado, a WSDL especifica extensões para ligações com protocolos e formatos de mensagem como SOAP e HTTP GET/POST (HANSEN, 2003) .
2.2.5 Vantagens e Desvantagens dos Web Services
Atualmente existem inúmeras empresam que utilizam a tecnologia Web Services, como a Amazon.com, o ebay.com, o Google.com, entre outras. A Amazon.com, por exemplo,
fornece um conjunto de Web Services muito completo, o “Amazon Web Services” disponível em <http://aws.amazon.com/>, que permite aos parceiros analisar toda a informação relativa a livros, CD e DVD, bem como qualquer produto vendido no seu site.
Dentre os benefícios da tecnologia Web Services citam-se (ZAVALIK, 2004):
• Facilidade de Integração: a utilização de Web Services facilita e integração de diferentes sistemas através de um protocolo de comunicação de alto nível;
• Abstração: ao implementar Web Services, o desenvolvedor cria uma camada de acesso aos serviços da aplicação, de forma que o cliente precisa conhecer apenas a descrição dos métodos disponibilizados, suas assinaturas e parâmetros. Assim, o fornecedor do serviço não expõe o código desenvolvido nem a lógica do domínio do problema.
• Portabilidade: um cliente Web Services não precisa utilizar a mesma tecnologia que o fornecedor do serviço. O fornecedor disponibiliza a descrição dos métodos em WSDL e, assim, não importa o sistema operacional, linguagem de programação ou equipamento de onde o serviço está sendo solicitado. A única exigência é que a comunicação siga os padrões estabelecidos entre as partes.
• Conectividade: os Web Services são sistemas não invasivos, ou seja, são acionados somente quando há a necessidade de utilização do serviço. Eles normalmente trafegam sob HTTP, e estas requisições não exigem a liberação de portas de comunicação adicionais em firewalls de rede.
Nenhuma tecnologia é perfeita, ou seja, Web Services também têm desvantagens. Alguns desses problemas são intrínsecos às fundações tecnológicas sobre as quais os Web
Services assentam e outros resultam das suas próprias especificações. Alguns dos possíveis
problemas são (MOREIRA, 2005):
• Disponibilidade: Web Services utilizam a infra-estrutura da Web, portanto, tal como um site da Web, podem não estar disponíveis a todo o momento;
• Garantia de execução: Web Services, em sua maioria, usam o protocolo HTTP para transportar as mensagens, porém, o HTTP não garante a entrega e a resposta das mensagens;
• Segurança: esta é uma das questões mais importante em relação a um ambiente distribuído, e susceptível a ataques, como é o caso da Internet. As mensagens que trafegam entre um fornecedor de Web Service e seu cliente são transportadas em for mato XML, usando o protocolo SOAP. Isto significa que estas informações não
estão devidamente criptografadas e poderiam ser interceptadas por sistemas não autorizados. Para solucionar este problema, há alguns padrões que podem provê mais segurança a Web Services, como XML-Signature, XML-Encryption e
3 METODOLOGIA
Para a realização deste trabalho, adotou-se como técnica de pesquisa a pesquisa bibliográfica, já que o trabalho possuiu um caráter bastante teórico acerca das características da arquitetura – SOA – e do estudo a fim de descobrir como aplicá-la e quais tecnologias utilizar. Em relação à metodologia, o projeto se adapta mais em uma metodologia de abordagem qualitativa, visto que se faz uso de Estudo de Caso. Segundo Marconi e Lakartos (2008), o Estudo de Caso é um dos tipos de metodologia qualitativa o qual pode ser caracterizado como o estudo de uma entidade bem definida, como um programa, uma instituição, um sistema educativo, uma pessoa ou uma unidade social. É ainda interessante ressaltar que o sujeito do estudo não são pessoas, mas aplicações, como descrito posteriormente.
Assim, para a realização do trabalho, o mesmo foi dividido em quatro etapas, conforme pode ser observado por meio da Tabela 01.
Tabela 01: Etapas do trabalho.
Etapas Descrição Ações
Etapa 1 Levantamento de informações • Pesquisa bibliográfica
Etapa 2 Preparação do ambiente de trabalho
• Identificação de softwares voltados para mapas conceituais;
• Identificação, estudo e compreensão das tecnologias existentes;
• Seleção das tecnologias que foram utilizadas na implementação.
Etapa 3 Produção da arquitetura para mapas conceituais
• Levantamento dos requisitos funcionais e não funcionais • Elaboração de diagramas UML • Implementação da aplicação
• Estudo de caso:Verificação e validação Etapa 4 Análise dos resultados obtidos • Discussão dos resultados
Fonte: próprio autor.
Para desenvolver a arquitetura orientada a serviços para mapas conceituais, inicialmente, Etapa 1 – Levantamento de informações, foi necessário levantar o estado da arte acerca de mapas conceituais, arquiteturas SOA e Web Services, através de pesquisa bibliográfica e documental. Desta forma, na primeira etapa foram investigados livros e artigos sobre o referido assunto, tanto de eventos quanto de periódicos publicados por organizações,
como o Institute of Electrical and Electronics Engineers (IEEE) – sociedade internacional criada em 1884 – e a Association for Computing Machinery (ACM) – sociedade internacional que promove a pesquisa e comunicação na computação. De forma a sintetizar os artigos e documentos analisados, ao final desta etapa foi elaborada uma tabela com os artigos estudados. A tabela encontra-se no Apêndice A deste relatório.
Na Etapa 2 - Preparação do ambiente de trabalho, foram buscados softwares voltados para mapas conceituais além de um estudo acerca das tecnologias envolvidas com a aplicação dos princípios de SOA e Web Service, solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Após a identificação e compreensão das tecnologias existentes para a implementação de uma arquitetura orientada a serviços, houve a seleção de quais das tecnologias identificadas seriam utilizadas1. Logo, nesta fase, houve a configuração do ambiente de trabalho, ou seja, definiu-se um framework para implementação de SOA (Apache AXIS 2), o servidor web (Apache TomCat 6.0) e também o ambiente integrado para desenvolvimento de software (IDE NetBeans 6.7.1).
Há outros frameworks para implementação de SOA em JAVA, porém AXIS 2 foi escolhido devido à facilidade de construir serviços a partir de classes e métodos JAVA convenientes. Dentre os benefícios do AXIS 2, estão: geração automática de WSDL, criação e otimização de softwares-clientes para o Web Services e a abstração na manipulação de elementos XML da arquitetura SOAP. O AXIS2 traduz estes elementos XML em objetos Java para manipulação pela aplicação.
Em relação a IDE de desenvolvimento, utilizou-se o NetBeans devido a maior familiaridade com esta IDE. O TomCat foi utilizado por recomendação do próprio site do NetBeans, o qual informa que “os serviços AXIS são executados mais rapidamente no Tomcat do que no GlassFish” (NETBEANS, 2010).
Ainda na segunda etapa, houve a necessidade de realizar um levantamento sobre os modelos existentes para mapas conceituais, isto é, estruturas de dados semi-estruturados que possam representá-los e armazená-los baseados em XML. O modelo escolhido (XML
Schema) é o mesmo utilizado pela ferramenta CmapTools, este schema define a linguagem Concept Mapping Extensible Language (CXL) – disponível em: <http://cmap.ihmc.us/xml/
cmap.xsd>. Escolheu-se este schema para definir os mapas conceituais da arquitetura, por ser bastante simples, fácil de compreender e contemplar todas as tags necessárias para a criação de um mapa conceitual em XML.
1 As tecnologias utilizadas para o densenvolvimento da arquitura são explicadas de forma mais detalhada na seção 3.1 deste relatório.
Ao final desta etapa, foi elaborada uma tabela comparativa entre três ferramentas para confecção de mapas (CMap Tools, Inspiration e Compendium). Esta comparação foi realizada apenas para analisar quais os recursos mais comuns e mais interessantes entre as ferramentas, porém o objetivo deste trabalho não é construir mais uma ferramenta, mas sim uma arquitetura Web Services para os mapas conceituais, de forma que outros possam construir ferramentas baseadas nos serviços desenvolvidos. Esta tabela citada anteriormente encontra-se no Apêndice B deste relatório.
O objetivo da Etapa 3, Produção da arquitetura para mapas conceituais, consiste na modelagem e implementação da arquitetura baseada em serviços para construção, uso e edição de mapas conceituais. Para isto, foram definidos previamente os requisitos a serem modelados em forma de serviços, utilizando Web Services. Após o levantamento dos requisitos, como suporte ao desenvolvimento da modelagem, utilizou-se a linguagem de
Unified Modeling Language (UML) para criação de diagramas.
Na terceira etapa, também, foi implementada a arquitetura proposta de acordo com os requisitos definidos anteriormente e os diagramas elaborados. O último passo desta etapa consistiu na verificação e validação da arquitetura desenvolvida com o propósito de realizar uma avaliação experimental. Nossa estratégia consistiu em efetuar tal avaliação a partir de um estudo de caso que consistiu de dois cenários: a inserção dos serviços providos, pela arquitetura, no ambiente de aprendizagem Problem Based Learning –Virtual Enviroment (PBL – VE), cuja finalidade é provê a realização de uma sessão do método Problem-Based
Learning (PBL) on-line (COSTA, 2010) e a inserção dos serviços numa aplicação desktop,
desenvolvida especialmente para também testar os serviços implementados. Esta aplicação foi implementada pela estudante que realizou este projeto.
Por fim, a Etapa 4 foi dedicada à análise e discussão dos resultados obtidos e levantamento dos possíveis trabalhos futuros. Uma síntese da metodologia apresentada foi representada através do mapa conceitual presente na Figura 07.
Figura 07: Mapa conceitual sobre a metodologia de pesquisa aplicada. Fonte: próprio autor.
3.1 Tecnologias utilizadas para o desenvolvimento da arquitetura
A arquitetura orientada a serviços foi desenvolvida de acordo com dois principais conceitos: SOA e Web Services. Para tanto, adotou-se as seguintes tecnologias: um framework para implementação de SOA (Apache AXIS2), um servidor web (Apache TomCat 6.0), uma linguagem padrão de modelagem (Unified Modeling Language - UML), uma linguagem baseada em Extensible Markup Language (XML) chamada de Concept Mapping Extensible
Language – CXL e desenvolvida pelo CmapTools, a linguagem de implementação JAVA e
também a API JDOM para manipulação de documentos XML. Estas tecnologias encontram-se ilustradas na Figura 08.
Figura 08. Tecnologias adotadas para o desenvolvimento do trabalho. a) JDOM. Fonte: Próprio autor. b) Linguagem de programação JAVA (CAJU-MT, 2010). c) Apache TomCat (Apache TomCat, 2010). d) AXIS2 (IBM, 2005). e) Unified Modeling Language (UML) (UMBRELLO UML MODELLER, 2003). f)
Extensible Markup Language (XML). Fonte: Próprio autor.
3.3.1 Apache Axis2
Apache Axis (Apache EXtensible Interaction System) é uma implementação do envio do SOAP (Simple Object-Access Protocol) para o W3C. O Apache Axis2 é uma versão mais eficiente, modular e mais orientada a XML do Axis. O Axis2 não somente dá suporte a SOAP 1.1 e SOAP 1.2, mas também possui suporte integrado para serviços Web RESTful (estilo de arquitetura para sistemas de hipermídia distribuídos, como a World Wide Web) (NETBEANS, 2010).
Axis2 é a geração que sucede o Apache Axis. Axis2 é inspirado no modelo do manipulador Axis 1.x, mas é baseado em uma nova arquitetura muito mais flexível e extensível. O Axis2 é completamente reescrito baseado na nova arquitetura e não possui nenhum código comum com o Axis 1.x (IBM, 2005).
Os recursos do Axis2 incluem (IBM, 2005):
• Um novo modelo de processamento XML principal chamado AXIS Object
Model (AXIOM);
• Suporte para padrões de troca de mensagens (MEP) somente de entrada e de entrada e saída;
• Suporte integrado para WS-Addressing (provê mecanismos de transporte neutro para endereçamento de Web Services e mensagens);
• Suporte à ligação de dados de XMLBeans (tecnologia para acesso a XML ligando-os aos tipos de Java);
• Um novo modelo de implementação;
• Suporte para Protocolo de Transporte de Hipertexto (HTTP), Protocolo Simples de Transporte de Correio (SMTP) e Protocolo de Controle de Transmissões (TCP).
A Figura 09 apresenta a visão geral da arquitetura Axis. Esta arquitetura separa lógica e estado. O estado estático e dinâmico do serviço e da chamada estão armazenados nas classes Description e Context, respectivamente.
Figura 09. Visão geral da arquitetura Axis (IBM, 2005).
A arquitetura Axis2 é implementada usando-se sete módulos independentes (IBM, 2005):
1. Modelo de informações: gerencia o estado do mecanismo SOAP. Esse modelo
vida desses objetos de informações. O modelo de informações possui dois tipos de classes para conter o estado: Description e Context.
2. Modelo de processamento XML: o Axis2 introduz um novo modelo chamado
AXIOM para processar mensagens SOAP. O AXIOM usa Streaming API for XML (StAX) para analisar o XML. O AXIOM é muito leve e efetua construção adiada do conjunto de informações XML -- ou seja, um objeto é criado somente quando é absolutamente necessário.
3. Modelo de processamento SOAP: a arquitetura Axis2 define dois canais
chamados InPipe (InFlow) e OutPipe (OutFlow) para manipulação de mensagens de pedido e mensagens de resposta do lado do servidor. Do lado do cliente, os canais são invertidos -- ou seja, a mensagem de pedido SOAP flui através do
OutPipe e a mensagem de resposta flui através do InPipe.
4. Módulo de implementação: configura o mecanismo Axis e implementa os
serviços e módulos. A configuração de cada serviço está contida em um arquivo
services.xml no archive de serviço.
5. WSDL e geração de códigos: cuida da geração de código stub cliente e estrutura
do servidor do arquivo WSDL. O gerador de código Axis2 emite arquivos XML aplicados com as folhas de estilo XML corretas para gerar código na linguagem necessária.
6. API do cliente: chama operações seguindo padrões de mensagens somente de
entrada e de entrada e saída definidos por WSDL 2.0.
7. Transportes: contém manipuladores que interagem com a camada de transporte.
Há dois tipos de manipuladores de transporte, TransportListener e
TransportSender.
3.3.2 Apache TomCat
O TomCat, servidor de aplicações Java para web, é software livre e de código aberto, surgido dentro do conceituado projeto Apache Jakarta e que teve apoio e endosso oficial da
Sun Microsystems como Implementação de Referência (RI) para as tecnologias Java Servlet e JavaServer Pages (JSP). Atualmente, o Tomcat tem seu próprio projeto de desenvolvimento
O Tomcat é um Conteiner Web, parte da plataforma corporativa Java Enterprise
Edition (Java EE, anteriormente denominada J2EE) que abrange as tecnologias Servlet e JSP.
O Tomcat tem a capacidade de atuar também como servidor web/HTTP autônomo, ou pode funcionar integrado a um servidor web dedicado, como Apache httpd ou Microsoft IIS, ou ainda como parte integrante de um servidor de aplicações mais amplo, como JBoss AS, provendo os recursos de Java Servlet e JSP (D'ÁVILA, 2003).
3.3.3 XML Schema
XML Schema foi originalmente proposto pela Microsoft, mas se tornou uma recomendação oficial do W3C em Maio de 2001. A especificação está estável e foi revisada pelos membros do W3C. Um esquema XML descreve a estrutura de um documento XML. A linguagem XML Schema também é chamada de XML Schema Definition (XSD) (MAIA, 2005).
O propósito de um XML Schema é definir os blocos de construção permitidos em um documento XML. Um XML Schema define (MAIA, 2005):
• elementos que podem aparecer em um documento • atributos que podem aparecer em um documento • que elementos são elementos filhos
• a ordem dos elementos filhos • o número de elementos filhos
• se um elemento é vazio ou pode incluir texto • tipos de dados para elementos e atributos
• valores padrão e fixos para elementos e atributos
3.3.4 JDOM
A linguagem JAVA foi adotada para desenvolver a arquitetura orientada a serviços proposta por ter todos os recursos necessários para o desenvolvimento deste projeto, além de ser a linguagem que a estudante, que desenvolveu o projeto, tem mais facilidade e
proximidade. Além das APIs JAVA padrão, utilizou-se a API JDOM para que pudesse ser feita a manipulação de arquivos XML.
JDOM é um framework Java, baseado em árvore e de código fonte aberto, para manipulação de documentos XML. Suas funcionalidades se integram com outras APIs para processamento de documentos XML: Document Object Model (DOM) e Simple API para XML (SAX).
A API JDOM é composta por elementos que definem a construção/manipulação de arquivos XML. Os principais elementos são:
• Document: esta classe representa um documento xml inteiro. Ela pode conter apenas um elemento que é denominado root, comentários e outros elementos de definição;
• Element: esta classe representa um elemento XML. Um elemento XML, também conhecido como nó, pode conter outros elementos, atributos e comentários, além do seu próprio valor;
• Attribute: esta classe representa um atributo que pode ser atribuído a um elemento.
4 UMA ARQUITETURA ORIENTADA A SERVIÇOS PARA MAPAS CONCEITUAIS
O projeto proposto se refere ao desenvolvimento de uma arquitetura orientada a serviços para mapas conceituais. Para desenvolvê-la utilizou-se o conceito de SOA, implementado através de Web Services – reiterando, componentes que permitem às aplicações enviar e receber dados em formato XML. Assim, com Web Services, um diferencial deste trabalho é desenvolver uma arquitetura que seja independente de plataforma de hardware ou
software.
Este capítulo tem por objetivo descrever o que foi desenvolvido, as principais características da arquitetura e os resultados obtidos. Desta forma, a primeira subseção descreve as caracteríticas gerais da arquitetura, a subseção 4.2 apresenta a modelagem em diagramas UML, a 4.3 descreve os serviços desenvolvidos, como foram implementados e as suas peculiaridades, a 4.4 apresenta o arquivo WSDL gerado e por fim, a subseção 4.5 mostra a análise e discussão dos resultados obtidos através da criação de dois clientes SOAP: o WSmaps e um cliente inserido no ambiente PBL-VE.
4.1 Características gerais da arquitetura desenvolvida
A arquitetura desenvolvida possui, basicamente, quinze requisitos. Eles podem ser agrupados em três grupos: inserção, exclusão e edição de informações nos mapas conceituais. Estes requisitos são:
• criar mapa conceitual; • inserir conceito;
• inserir frase de ligação; • inserir conexão;
• inserir recurso; • apagar conceito;
• apagar frase de ligação; • apagar conexão;
• editar conceito;
• editar frase de ligação;
• editar a aparência do conceito; • editar a aparência da frase; • editar estilo do conceito; • editar estilo da frase.
Em relação à criação dos mapas conceituais, a arquitetura utiliza o XML Schema que descreve a linguagem CXL. CXL é uma linguagem baseada em XML, criada pelos desenvolvedores do software CmapTools, para descrever o conteúdo de mapas conceituais. A Figura 10 contém um exemplo simples de um mapa conceitual em CXL.
Há quatro seções básicas em um arquivo CXL. A primeira seção, as três primeiras linhas da Figura 10, define o tipo de documento XML e o name space de mapeamentos. A segunda seção, especificada como um elemento “res-meta” na Figura 10, contém informações sobre o mapa como título, descrição e autor. A terceira seção contém a lista de conceitos, frase de ligação, as conexões que ligam todos os elementos e recursos dos conceitos, como vídeo ou texto. A última seção define as informações gráficas do mapa, como localização, tamanho, cores e fontes. Ao importar este código simples (arquivo uefs.cxl) para o software CmapTools, este será visualizado como está representado na Figura 11.
Figura 11: Design de mapa gerado no CmapTools a partir do arquivo uefs.cxl.
4.2 Modelagem em diagramas UML
Diagramas UML são ferramentas muito úteis para visualizar e entender sistemas. Cada diagrama analisa o sistema sob uma determinada ótica, de forma que alguns diagramas apresentam uma visão mais geral do sistema, enquanto outros podem apresentar uma visão um pouco mais detalhada, com um enfoque mais técnico como, por exemplo, diagramas de classes. A utilização de diversos diagramas permite que falhas sejam descobertas, diminuindo a possibilidade da ocorrência de erros futuros.
O diagrama de casos de uso é o mais geral da UML, utilizado geralmente nas fases de levantamento e análise de requisitos do sistema, embora venha a ser consultado durante todo o processo de modelagem e possa servir de base para outros diagramas. A Figura 12 apresenta o diagrama de casos de uso da arquitetura orientada a serviços desenvolvida para o ator cliente. Este diagrama apresenta todas as funcionalidades que a arquitetura provê em forma de serviços.
Figura 12: Diagrama de casos de uso para a arquitetura desenvolvida.
De forma a exemplificar o fluxo de execução dos casos de uso da Figura 12, a Tabela 2 apresenta a documentação referente ao caso de uso Criar mapa e o caso de uso Criar conexão, linhas que ligam os conceitos às frases e as frases aos conceitos. Os fluxos referentes aos outros casos de uso são bastante semelhantes ao fluxo apresentado pela Tabela 2 e podem ser visualizados no Apêndice C – Documentação dos quinze casos de uso.
Tabela 2: Documentação do caso de uso criar frase de ligação.
Caso de uso Precondição Fluxo principal
Criar Mapa
Não há precondição
1. O cliente escolhe o serviço referente a criação do
mapa.
2. O cliente passa o nome do mapa.
Criar conexão
1. O cliente deve já
ter criado o mapa
2. O cliente deve
ter inserido no mínimo dois conceitos no mapa conceitual.
1. O cliente escolhe o serviço referente a criação de conexão.
3. O cliente passa o nome do mapa
que ele deseja criar a conexão.
4. O cliente escolhe o conceito de
onde vai partir a conexão.
5. O cliente escolhe o conceito para
onde vai chegar a conexão. Fonte: próprio autor.
Já o diagrama de sequência tem a preocupação de demonstrar a ordem temporal em que as mensagens são trocadas entre objetos envolvidos em um determinado processo. Geralmente, ele é baseado em um caso de uso definido pelo diagrama de mesmo nome. A Figura 13 apresenta o diagrama de sequência para o caso de uso “Criar mapa” apresentado no diagrama de casos de uso da Figura 12. Em geral, os diagramas de sequência referentes aos outros casos de uso da Figura 12 apresentam um fluxo semelhante ao diagrama de sequência “Criar Mapa”.
A Figura 13 contém um ator e quatro objetos. O ator corresponde ao cliente, pessoa/programa que vai utilizar os serviços, e os objetos são: serviço “criarMapa”, a classe “GerenteXML”, a classe “Mapa” e a classe “Impressão”. Quando o cliente solicita o serviço “criarMapa”, ele chama a classe “GerenteXML”, que é responsável por gerenciar a criação do arquivo CXL, ou seja, criar, editar e apagar os elementos de um mapa conceitual. Esta classe, por sua vez, cria uma instância da classe “Mapa” e retorna este objeto para “GerenteXML”. Apenas o serviço “criarMapa” realiza esta tarefa, os outros serviços não criam esta instância, apenas a utilizam, já que para os outros funcionarem, o serviço de criar mapa deve ser chamado primeiro.
Após o método “criarMapa” da classe “GerenteXML” receber a instância do mapa, ele realiza todas as tarefas necessárias para a criação de um mapa conceitual e envia o resultado para a classe “Impressão”. Esta classe é responsável por realizar a conversão do resultado do método “criarMapa”, transformando-o em uma string que será enviada ao cliente, ou seja, este é o conteúdo do arquivo CXL referente ao serviço que o cliente solicitou, criar mapa.
Figura 13: Diagrama de sequência referente ao caso de uso “Criar mapa”.
4.3 Implementação da arquitetura
O mapa conceitual contém três elementos fundamentais: conceito, proposição e palavras de ligação. Assim, para criar mapas precisam-se criar, fundamentalmente, estes três elementos, sendo que a proposição possui as conexões que ligam os conceitos, o relacionamento. Além destes, há outras características que podem ser inseridas em cada conceito, a exemplo de recursos como vídeo, áudio e imagem.
Para implementar a arquitetura orientada a serviços para mapas conceituais, houve a necessidade de avaliar as funcionalidades que se desejava disponibilizar como serviços. Desta forma, optou-se por desenvolver os seguintes serviços contemplando os quinze requisitos listados anteriormente: criar mapa conceitual, inserir conceito, inserir frase de ligação, inserir
conexão, inserir recurso, apagar conceito, apagar frase de ligação, apagar conexão, apagar recurso, editar conceito, editar frase de ligação, editar a aparência do conceito, editar a aparência da frase, editar estilo do conceito e editar estilo da frase. A Tabela 3 apresenta todos os Web Services implementados e os seus respectivos parâmetros de entrada e saída.
Tabela 3: Web Services da arquitetura para mapas conceituais.
Serviço Parâmetros de entrada Parâmetros Retornados
criarMapaConceitual Titulo: String Mapa: String
inserirConceito
Titulo: string Conceito: string Position_X: integer
Position_Y: integer Mapa: String
inserirFraseLigacao
Titulo: string Relacao: string Position_X: integer
Position_Y: integer Mapa: String
Inserirconexao Titulo: string From_id: integer To_id: integer Mapa: String inserirRecurso Titulo: string Parent_id: integer NameRecurso: string url: string Mapa: String
apagarConceito Titulo: string Id: integer Mapa: String
apagarFraseLigacao Titulo: string Id: integer Mapa: String
apagarConexao Titulo: string Id: integer Mapa: String
apagarRecurso Titulo: string idConceito: integer idRecurso: string
Mapa: String
editarNomeConceito Titulo: string idConceito: integer
nomeNovo: string Mapa: String
editarNomeFrase Titulo: string idFrase: integer nomeNovo: string Mapa: String editarAparenciaConceito Titulo: string idConceito: string novoX: integer
novoY: integer Mapa: String
editarAparenciaFrase
Titulo: string idFrase: string novoX: integer
novoY: integer Mapa: String
editarFontStyleConceito Titulo: string idConceito: string fontStyle: string
Mapa: String
editarFontStyleFrase Titulo: string idFrase: string
fontStyle: string Mapa: String
Observa-se que em todos os Web Services apresentados na Tabela 3 é passado como parâmetro o título do mapa conceitual. Isto se faz necessário para que possa ser identificado para qual mapa conceitual o cliente está solicitando o serviço. Outra característica comum é o parâmetro retornado, pois todos retornam o mapa conceitual, ou seja, os serviços incluem novos parâmetros no mapa e o retornam em forma de string. Essa string nada mais é que o conteúdo do arquivo CXL gerado.
Para desenvolver os Web Services da arquitetura e criar os mapas conceituais em CXL utilizou-se a linguagem JAVA aliada ao framework SOA AXIS 2 e à API JDom. AXIS 2 é responsável por mascarar a implementação dos serviços, fazendo com que o desenvolvedor possa criá-los como métodos JAVA comuns e o framework se responsabiliza por criar o serviço automaticamente. Desta forma, é o próprio AXIS 2 que cria também o arquivo WSDL – formato XML que descreve os serviços.
Já o JDOM é responsável por manipular XML. Neste modelo, o documento XML inteiro é armazenado na memória do computador em um formato de árvore de nós, todos descendendo de uma raiz. É possível, então, aplicar vários métodos para localizar e manipular os nós.
Para utilizar os serviços da arquitetura, o Web Service inicial é o “criarMapaConceitual”, cujo diagrama de sequência foi mostrado na Figura 13. Este serviço tem como entrada o título do mapa conceitual. Com este título o serviço cria o objeto do tipo
document (objeto responsável pela criação da estrutura de árvore JDOM), que representa o
elemento raiz do arquivo XML, e insere no elemento “res-meta” a tag responsável pelo título do arquivo, como pode ser visto no exemplo uefs.cxl da Figura 10. O código abaixo, Figura 14, apresenta o método em JAVA por detrás do serviço “criarMapaConceitual”.
