Repositório de Arquivos Online utilizando Web Services
Ricardo Takazu Hatae, Rogério Homem da Costa, Felipe Mancini
Instituto Federal de Educação, Ciência e Tecnologia de São Paulo - Campus Guarulhos
[email protected], {rogerio.costa,fmancini}@cefetsp.br
Resumo. Existe atualmente um novo paradigma na Tecnologia da Informação
referente à adoção de soluções envolvendo hardware e software de forma remota, e
em grande escala, com a finalidade da guarda de informações de forma ubíqua,
imune a imprevistos e disponibilizados como serviços em ambientes de Computação
em Nuvem. O objetivo deste trabalho é a apresentação da utilização de conceitos e
tecnologias que permitem o acesso ao recurso computacional de armazenamento de
informações baseada no modelo arquitetural orientada a serviços, independente da
plataforma em uso pelo cliente através do uso de Serviços Web como meio para
facilitar o envio e recebimento de arquivos.
Palavras-chave: Web Services; SOA; IaaS
1. Introdução
Segundo Capron e Johnson (2004), nas primeiras décadas após o surgimento dos
computadores de uso pessoal, as primeiras formas de armazenamento de dados eram obtidas
através de dispositivos móveis de armazenamento em meio magnético.
Naturalmente, o maior problema neste tipo de armazenamento de dados eram os
desgastes resultantes no processo de gravação e leitura das informações ali armazenadas e as
dimensões e pesos destes dispositivos.
Com o passar do tempo, a partir do início da década de 70, surgiram os primeiros
dispositivos portáteis de armazenamento, conhecidos como disquetes, com capacidade de
armazenamento de até 80 KB de informações, pela dimensão deste dispositivo melhorou-se a
forma de transporte e armazenamento de dados de forma otimizada, mas mesmo assim ainda
estavam presentes os problemas advindos no desgaste físico no uso destes dispositivos e
também a limitação no armazenamento de dados do mesmo.
A partir da década de 90 surgiram os Compact Discs (CDs) como forma de
armazenamento de dados computacionais, imagens e músicas.
Como vantagem deste tipo de armazenamento, temos a ausência do desgaste físico no
processo de armazenamento de dados e informações, maior capacidade de armazenamento de
cada dispositivo (em torno de 600 MB de dados) e a total digitalização no processo de leitura
e gravação de dados.
Como desvantagem no uso deste dispositivo, temos a fragilidade na superfície de
leitura e gravação destes dados.
Posteriormente, a partir do ano de 2002, surgiram os primeiros dispositivos de
armazenamento de informações em memória Flash, os chamados pendrives.
Como vantagens desta forma de armazenamento de informações, temos a
possibilidade de armazenamento de uma quantidade considerável de dados (em torno de
alguns GB de dados), portabilidade no transporte destes dispositivos e grande ciclo de vida de
gravação, leitura e regravação de dados.
Atualmente, verificamos a tendência da disponibilidade desses e de outros recursos
computacionais nas nuvens, ou seja, o chamado Cloud Computing.
Alecrim (2008) afirma que a Computação nas Nuvens ou Cloud Computing se refere,
à idéia de utilizarmos, em qualquer lugar e independentemente de plataforma, as mais
variadas aplicações através da Internet.
Seu conceito ainda é um pouco incerto, mas pode-se definir como a virtualização de
produtos e serviços computacionais, ou seja, é uma maneira de armazenar todas as
informações em servidores virtuais chamados de “nuvem”, onde há uma tendência mundial
para este modelo, não necessitando de máquinas velozes com um grande potencial de
hardware e sim de um simples computador conectado à Internet para rodar todos os
aplicativos.
“A idéia de Computação nas Nuvens certamente não é uma novidade, mas a forma de
implementá-la é um tanto inovadora” (CARNEIRO; DA COSTA RAMOS, 2010, p 6).
“Para alguns, é apenas um nome novo para iniciativas já feitas no passado, como o
outsourcing (obter recursos computacionais de terceiros) e Grid Computing, que é uma rede
de computadores ligados por baixo acoplamento” (TAURION, 2009, p 2).
“Grandes empresas estão investindo nessa nova tecnologia, onde se destacam: Google,
IBM, Amazon, Dell, HP e Microsoft” (CARNEIRO; DA COSTA RAMOS, 2010, p 6).
Este tipo de acesso a recursos têm como grande vantagem a garantia da
disponibilidade destes mesmos, tendo como único requisito a possibilidade de acesso à
Internet, e a liberdade por parte do usuário de não se preocupar com a segurança no
armazenamento de dados utilizando esse novo padrão de uso de recursos computacionais.
Após verificarmos as vantagens de armazenamento de dados baseado no conceito de
Cloud Computing, e segundo publicação da revista B2B Magazine do dia 13 de Junho de
2011, uma pesquisa realizada pela Universidade do Texas, nos Estados Unidos em 2011 feito
com pequenas e médias empresas afirma que 94% não conseguiriam sobreviver caso
perdessem todos os seus dados armazenados nos computadores dos funcionários e servidores
– 51% fechariam em até dois anos e 43% não voltariam a funcionar, consideramos a real
viabilidade no desenvolvimento de um projeto baseado na disponibilização de um local de
armazenamento de arquivos disponível na Internet, de forma a garantir um acesso fácil e
seguro ao usuário cadastrado para fazer uso do sistema proposto neste trabalho.
Este conceito, assim como os demais relacionados ao termo Cloud Computing, fazem
parte de uma tendência onde recursos - neste caso a infraestrutura - são compartilhados, onde
o cliente em vez de comprar servidores de alto desempenho, softwares complexos e
equipamentos de rede pode adquirir esses recursos como um serviço totalmente terceirizado.
Segundo Alecrim (2008), as principais características da Computação nas Nuvens são:
- Acesso às aplicações independente de sistema operacional ou hardware;
- O usuário não precisará se preocupar com a estrutura para execução da aplicação:
hardware, backup, controle de segurança, manutenção, entre outros, ficam a cargo do
fornecedor de serviço;
- Compartilhamento de dados e trabalho colaborativo se tornam mais fáceis, uma vez
que todos os usuários acessam as aplicações e os dados do mesmo lugar;
- Dependendo do fornecedor, o usuário pode contar com alta disponibilidade, já que,
se por exemplo, um servidor parar de funcionar, os demais que fazem parte da estrutura
continuam a oferecer o serviço.
Ainda segundo Taurion (2009), algumas das vantagens que as empresas podem obter
ao adotar o modelo de computação nas nuvens são:
- Melhor utilização dos recursos computacionais, podendo as empresas se abstrair de
uma camada de complexidade demandada pela infraestrutura computacional e se concentrar
na geração de valor de nível mais alto, ou seja, as empresas podem ao adotar este modelo de
computação investir mais tempo e energia para otimizar ou expandir os seus negócios.
- Disposição de uma elasticidade em sua infraestrutura, permitindo à organização
aumentar ou diminuir seu “parque computacional virtual” de acordo com a demanda de
recursos.
Entretanto, uma vez comprovado que o modelo de Cloud Computing é uma solução
que provê recursos computacionais de forma rápida e sob demanda, surge a questão de como
implementar os recursos de infraestruturas, de transporte de dados e utilização de software
necessários para que os elementos chave do negócio, os usuários e o provedor possam
respectivamente ter acesso a esse serviço computacional nas nuvens, e disponibilizá-lo de
forma transparente e independente da plataforma em uso pelo cliente.
Através da análise de tecnologias disponíveis que possibilitam a criação de aplicações
que podem ser acessadas entre computadores diferentes, identificamos que o uso da
tecnologia de Web Services permite ao desenvolvedor, a criação de aplicações de software,
que podem ser acessadas remotamente.
Conforme cita Gomes (2011), os Web Services são uma evolução dos modelos de
computação distribuída, muito utilizados na segunda metade da década de noventa, no entanto
essas tecnologias eram utilizadas na integração de softwares em ambientes de redes locais e
homogêneos.
Quando a Internet avançou para o mercado corporativo, surgiu também a necessidade
de integrar aplicações além das redes locais e, por conseqüência, em ambientes heterogêneos.
“É nesse contexto que surge a tecnologia que chamamos de Web Services, proveniente
de um consórcio formado por grandes empresas como IBM, Microsoft e BEA, entre outras
pertencentes ao W3C” (GOMES, 2011, p13).
Ainda segundo Gomes (2011), de uma forma genérica, podemos entender que os Web
Services são uma tecnologia de integração de sistemas, podendo ser empregada em ambientes
heterogêneos, atendendo assim a necessidade prevista para a implementação de serviços
conforme descrito anteriormente a respeito da modelagem de Computação nas Nuvens.
Em suma, podemos utilizar essa tecnologia para desenvolvimento de softwares ou
componentes de software capazes de interagir; seja enviando ou recebendo informações, com
outros softwares, não importando a linguagem de programação em que estes forem
desenvolvidos, o sistema operacional em que rodam e o hardware utilizado.
Portanto, para a implementação do transporte de dados, incluindo dados não-caracteres
que é requisito fundamental para a realização deste trabalho, visando a disponibilização do
armazenamento remoto de arquivos junto a um servidor, utilizaremos a tecnologia dos Web
Services para esse fim, e também para a implementação de geração de relatórios
possibilitando acesso a informações, contendo o registro de todo os eventos realizados pelo
usuário.
2. Objetivo
O presente trabalho tem por objetivo apresentar uma aplicação baseada na utilização da
tecnologia dos Web Services para disponibilização de espaço físico de armazenamento de
arquivos, demonstrando a disponibilização de uma infraestrutura como serviço.
3. Método
O meio adotado para a disponibilização do serviço de armazenamento de arquivos de forma
remota, que é o repositório remoto online deste trabalho, foi basicamente a utilização da
tecnologia de Web Services para a disponibilização dos métodos que possibilitem o consumo
do serviço proposto neste trabalho por parte do cliente e a plataforma de desenvolvimento
NetBeans, específica para desenvolvimento de softwares em linguagem Java, escolhida para a
concepção do sistema deste trabalho, de uma forma rápida e otimizada.
Também foi adotado o uso do Sistema Gerenciador de Banco de Dados Java DB, para
gerenciamento das informações dos eventos realizados relacionado ao repositório de arquivos
remoto do sistema deste trabalho, pelo fato deste gerenciador ser totalmente integrado ao
ambiente de desenvolvimento NetBeans.
3.1. Web Services
Segundo Potts e Kopack (2003), um Web Service é uma aplicação de software que pode ser
acessada remotamente usando diferentes linguagens baseadas em XML (Extensible Markup
Language), sendo que sua identificação na Web é realizada por um URL (Uniform Resource
Locator), exatamente como qualquer outro site Web mas o tipo de informação que os Web
Services podem oferecer é diferente com relação aos sites Web comuns.
Para que se possa entender como os Web Services funcionam, é necessário
primeiramente o entendimento da metalinguagem XML.
Uma metalinguagem é uma linguagem que pode descrever e integrar-se com outras
linguagens, fundamentada no uso de padrões construtivos criadas pelo W3C (World Wide
Web Consortium), que é uma instituição de padronização das mais abertas, dinâmicas e
difundidas.
Portanto a principal característica do XML, de criar uma infra-estrutura única para
diversas linguagens, é que linguagens desconhecidas e de pouco uso também podem ser
definidas sem maior trabalho e sem necessidade de ser submetidas aos comitês de
padronização.
Pelas características citadas anteriormente, os Web Services utilizam essa
característica do XML para a intercomunicação entre softwares baseadas em plataformas
diferentes.
As transações de Web Services acontecem entre componentes. Você pode
programar esses componentes por si mesmo, baixá-los de fundações de
software de fonte aberta, como Apache, ou comprá-los de fornecedores
comerciais como Microsoft ou IBM. Você não precisa adquirir todos os
componentes que usa de um único fornecedor; pode escrever alguns, fazer
download de outros e comprar ainda outros (POTTS; KOPACK, 2003 p5).
3.1.1. Padrões para o desenvolvimento de Web Services
Segundo Gomes (2011), atualmente existem dois padrões para o desenvolvimento de Web
Services: o padrão SOAP (Simple Object Access Protocol) e o padrão REST
(Representational State Transfer) ou RESTfull.
Os Web Services desenvolvidos seguindo o padrão REST baseiam-se no uso de
requisições em HTTP (Hypertext Transfer Protocol), como mostra a ilustração a seguir:
Figura 1. Arquitetura dos Web Services REST
O HTTP é um protocolo de aplicação responsável pelo tratamento de pedidos e
respostas entre cliente e servidor na Web, ele surgiu da necessidade de distribuir informações
pela Internet e para que essa distribuição fosse possível foi necessário criar uma forma
padronizada de comunicação entre os clientes e os servidores da Web e entendida por todos os
computadores ligados à Internet.
Com isso, o protocolo HTTP passou a ser utilizado para a comunicação entre
computadores na Internet e a especificar como seriam realizadas as transações entre clientes e
servidores, através do uso de regras básicas, através de 4 métodos que indicam a ação a ser
realizada em uma comunicação:
GET – Solicitação de algum recurso, como um arquivo por exemplo.
PUT – Envia certo recurso.
POST – Envio de dados para serem processados.
DELETE – Exclui certo recurso.
Os Web Services baseados no padrão SOAP, fazem uso de um formato de mensagem
que permite que chamadas de métodos sejam enviadas em XML de um computador para
outro, e também é possível o envio de um documento inteiro, contendo apenas dados.
O site de pesquisas Wikipédia define o SOAP como um protocolo para troca de
informações estruturadas em uma plataforma descentralizada e distribuída, ele se baseia na
linguagem XML para seu formato de mensagem, e também se baseia em outros protocolos
como o HTTP, para negociação e transmissão de mensagens.
Este protocolo baseado em XML, como mencionado anteriormente, consiste de três
partes, um envelope, que define o que está na mensagem e como processá-la, um conjunto de
regras codificadas para expressar instâncias dos tipos de dados definidos na aplicação e uma
convenção para representar chamadas de procedimentos e respostas.
Em um Web Service baseado no protocolo SOAP, os demais componentes envolvidos
na sua arquitetura são:
- WSDL (Web Service Description Language): arquivo do tipo XML que descreve de
forma detalhada um Web Service. Especifica as operações e métodos que compõem o Web
Service definindo de forma clara como deve ser o formato de entrada e saída de cada
operação.
Segundo Potts e Kopack (2003), este arquivo contém todas as informações de que
você precisa para contatar um serviço, independente de plataforma e linguagem. Um
programador ou programa é capaz de ler esse arquivo e criar uma mensagem clara que pode
chamar um método ou métodos nesse serviço.
Verificando na figura a seguir, o WSDL pode tanto ficar armazenado no “Provedor de
Web Services” quanto no UDDI.
Figura 2. Arquitetura para Web Services SOAP adaptada de Gomes (2011)
- UDDI (Universal Description Discovery and Integration): o UDDI segundo Gomes
(2011), é um mecanismo que visa atender tanto ao cliente do Web Service quanto ao
provedor, pois ele fornece ao provedor de Web Services meios para que os Web Services
sejam registrados e publicados, permitindo assim que os Web Services sejam pesquisados e
localizados pelos clientes. O UDDI também possibilita o armazenamento de arquivos WSDL.
- Cliente: segundo Gomes (2011), é um software que consumirá Web Services, ou
seja, utilizará as operações disponibilizadas por um determinado Web Service.
Um cliente possui várias etapas de seu ciclo de vida, que começa pela preexistência,
quando este obtém o arquivo WSDL do Web Service que se deseja consumir, até o momento
em que o software cliente já está em operação, fazendo solicitações e recebendo resultados
dos Web Services, ambos no formato XML.
- Provedor de Web Services: Esse componente tanto pode ser um servidor de
aplicações, como o GlassFish, criado pela Sun Microsystems, subsidiária da Oracle, ou um
Web container, como o Apache criado pela Apache Foundation. Ele também pode armazenar
os arquivos WSDL.
3.1.2. Integração dos componentes de um Web Service
De acordo com a figura 2, adaptada da estrutura citada por Gomes (2011), os componentes de
um Web Service se integram da seguinte forma:
1. Registra e publica o web service: após criado o Web Service, ele é disponibilizado
em um provedor de Web Services, onde o cliente a partir deste provedor obtém o seu
endereço ou URI (Uniform Resource Identifier) através do diretório de registro de Web
Services, também conhecido como UDDI.
2. Obtém informações sobre o Web Service: quando um desenvolvedor de software
necessita utilizar um Web Service, utiliza o UDDI para obter seu endereço e seu documento
WSDL.
3. Efetua download do WSDL: efetuando o download do arquivo WSDL, pelo UDDI
ou provedor de Web Services, o desenvolvedor poderá criar um cliente que fará uma chamada
ao Web Service e obterá uma resposta, dependendo do serviço solicitado.
4. Envia solicitação XML: o software cliente criado fará chamadas ao Web Service,
enviando solicitações no formato de mensagens em XML.
5. Recebe resposta XML: o Web Service recebendo a solicitação do cliente, efetuará
um processamento e produzirá um resultado, podendo enviar ou não uma resposta também no
formato XML.
Além dos componentes descritos, existe também a questão de qual o protocolo pode
ser adotado para o tráfego de mensagens SOAP.
Gomes (2011) afirma que a arquitetura proposta pelo W3C especifica que as
solicitações e respostas XML possam trafegar por meio de qualquer protocolo como HTTP,
FTP (File Transfer Protocol), entre outros. Na prática o que se utiliza é mensagens em XML
trafegando sobre o protocolo HTTP, isso porque esse protocolo atualmente é o dominante na
Web e é suportado por praticamente todo tipo de plataforma de software/hardware e não
possui problemas de restrições por firewalls.
3.2. Tecnologias utilizadas
As tecnologias utilizadas para a implementação do sistema proposto no projeto foram a
escolha da linguagem de programação Java, o ambiente de desenvolvimento IDE (Integrated
Development Environment) NetBeans versão 6.9.1, o Sistema Gerenciador de Banco de
Dados Java DB, e o servidor de aplicações em Java GlassFish versão 3.1.
3.2.1. A linguagem de programação Java
Segundo Mendes (2009), a linguagem Java foi desenvolvida inicialmente para ser uma
ferramenta de programação de um projeto da Sun Microsystems, chamado The Green Project,
iniciado por Patrick Naughton, Mike Sheridam e James Gosling, em 1991. Esse projeto tinha
como principal objetivo criar uma nova plataforma para a computação interativa, ou seja, a
linguagem de programação não era o principal objetivo do projeto.
A linguagem de programação Java representa uma linguagem simples,
orientada a objetos, multithread, interpretada, neutra de arquitetura, portável,
robusta, segura e que oferece alto desempenho. É importante observar que a
tecnologia Java é composta de uma linguagem de programação e de uma
plataforma (API e a máquina virtual) (MENDES, 2009, p17)
É importante observar que a linguagem Java segue o paradigma de orientação a objeto,
que existe desde a década de 70, cujo êxito obtido possibilitou que a Linguagem Java
alcançasse maior credibilidade.
Mendes (2009) afirma que o paradigma de orientação a objetos traz um enfoque
diferente da programação estruturada, no sentido de adotar formas mais próximas do
mecanismo humano para gerenciar a complexidade de um sistema. Nesse paradigma, o
mundo real é visto como sendo construído por objetos autônomos, concorrentes, que
interagem entre si, e cada objeto tem seu próprio estado (atributos) e comportamento
(métodos), semelhante a seu correspondente no mundo real.
A característica de robustez, devido ao fato da linguagem Java ter sido projetada para
gerar manipulação de exceções, foi relevante para a escolha desta linguagem de programação
para o desenvolvimento do projeto deste trabalho.
3.2.2. O IDE NetBeans
Uma explicação preliminar se faz necessária a respeito do que são ambientes de
desenvolvimento IDE antes da explanação sobre o ambiente de desenvolvimento NetBeans.
Um IDE é um aplicativo que reúne características e ferramentas de apoio ao
desenvolvimento de software com o objetivo de agilizar este processo.
Geralmente os IDEs facilitam a técnica de RAD (de Rapid Application Development,
ou "Desenvolvimento Rápido de Aplicativos"), que visa a maior produtividade dos
desenvolvedores.
Segundo pesquisa realizado no site da Wikipédia, as características e ferramentas mais
comuns encontradas nos IDEs são:
Editor - edita o código-fonte do programa escrito na(s) linguagem(ns) suportada(s)
pela IDE;
Compilador (compiler) - compila o código-fonte do programa, editado em uma
linguagem específica e a transforma em linguagem de máquina;
Linker - liga os vários "pedaços" de código-fonte, compilados em linguagem de
máquina , em um programa executável que pode ser executado em um computador ou outro
dispositivo computacional.
Depurador (debugger) - auxilia no processo de encontrar e corrigir defeitos no códigofonte do programa, na tentativa de aprimorar a qualidade de software;
Modelagem (modelling) - criação do modelo de classes, objetos, interfaces,
associações e interações dos artefatos envolvidos no software com o objetivo de solucionar as
necessidades-alvo do software final.
Distribuição (deploy) - auxilia no processo de criação do instalador do software, ou
outra forma de distribuição, seja discos ou via internet.
Testes Automatizados (automated tests) - realiza testes no software de forma
automatizada, com base em scripts ou programas de testes previamente especificados,
gerando um relatório, assim auxiliando na análise do impacto das alterações no código-fonte.
Ferramentas deste tipo mais comuns no mercado são chamadas robôs de testes.
Refatoração (refactoring) - consiste na melhoria constante do código-fonte do
software, seja na construção de código mais otimizado, mais limpo e/ou com melhor
entendimento pelos envolvidos no desenvolvimento do software. A refatoração, em conjunto
com os testes automatizados, é uma poderosa ferramenta no processo de erradicação de
"bugs", tendo em vista que os testes "garantem" o mesmo comportamento externo do software
ou da característica sendo reconstruída.
O NetBeans é um exemplo de ambiente IDE, atualmente mantido pela empresa Sun
Microsystems, subsidiária da Oracle, que gera códigos em linguagem de programação Java,
assim como outros: C++ e Phyton.
Figura 3. O IDE NetBeans versão 6.9.1
O NetBeans IDE é um ambiente de desenvolvimento - uma ferramenta para
programadores escrever, compilar, depurar e implantar programas. É escrito
em Java - mas pode suportar qualquer linguagem de programação. Existem
também um enorme número de módulos para aprimorar o NetBeans IDE. O
NetBeans IDE é um produto gratuito sem restrições de como ser utilizado
(http://netbeans.org/index_pt_BR.html).
O NetBeans atualmente é disponibilizado pelo órgão chamado netbeans.org.
O NetBeans apresentou-se como uma boa ferramenta para a construção de Web
Services, uma vez que o desenvolvimento deste tipo de aplicativo neste ambiente é rápido e
fácil, devido a principal característica desta IDE: a possibilidade da otimização de tarefas a
serem realizadas pelo programador.
Desde que a palavra Web Service foi pronunciada pela primeira vez ao
mundo, todas as linguagens de programação voltadas para a construção de
aplicações Web começaram a correr em busca de trabalhar com esta forma
de serviço.
Alguns padrões foram estabelecidos e isto facilitou o desenvolvimento de
rotinas aplicáveis a IDEs como o NetBeans (GONÇALVES, 2007 p421).
3.2.3. Java DB
Segundo Reese (2000), o Java DB, anteriormente conhecido como Apache Derby é um banco
de dados relacional Java que pode ser embutido em programas Java e usado para
processamento de transações online. Consome apenas 2 MB de espaço em disco. O Apache
Derby é desenvolvido como um projeto open source pela Apache Foundation. O Derby era
anteriormente distribuido como IBM Cloudscape.
Em meados de Julho de 2005, a Sun Microsystems uniu-se ao projeto Derby com a
intenção de usar o Derby como um componente de seus produtos, e com o lançamento do
Java 6 em Dezembro de 2006, a Sun incluiu o Derby no pacote de Kit de Desenvolvimento do
Java, renomeado como Java DB.
As principais características de banco de dados incluem a facilidade de uso, totalmente
transacional, baseado em padrões SQL (Structure Query Language) e se apresenta como uma
aplicação que pode ser embutida ao servidor de aplicativos Java GlassFish.
Por apresentar um alto grau de compatibilidade com aplicações desenvolvidos em
Java, este sistema gerenciador de banco de dados foi adotado para ser utilizado com a
finalidade de armazenar as informações de eventos do sistema proposto neste trabalho.
3.2.4. Servidor de aplicações GlassFish
Heffelfinger (2009) afirma que o GlassFish é um servidor de aplicações Java e é uma versão
open source do Sun Java Application Server. Ele oferece diversas facilidades que vão desde a
gerência das aplicações que estão hospedadas, de forma online, facilitadores para aplicar
softwares criados para ambiente Web até a gerência completa de pools de conexão de bancos
de dados, e tudo isso pode ser feito através de uma página de gerência do servidor.
Para a criação do projeto proposto neste trabalho, o GlassFish foi escolhido para servir
como container da aplicação do sistema principalmente devido a dois fatores:
- possibilidade da utilização do framework Metro, para a concepção de Web Services
que permitem a otimização de mensagens transmitidas pela Internet de maneira mais
eficiente, em comparação ao framework Axis, disponibilizada pelo servidor Web Java
conhecido como Tomcat.
- possibilidade de utilização da tecnologia de componentes EJB (Enterprise Java
Beans) no projeto. O EJB é uma tecnologia que oferece um rápido e simplificado
desenvolvimento de aplicações Java baseado em componentes distribuídas, transacionais,
seguras e portáveis.
4. Resultado
Os procedimentos adotados para a geração do software deste projeto baseou-se primeiramente
na definição do cronograma de construção do software com a utilização da ferramenta de
EAP (Estrutura Analítica do Projeto) para decompor um projeto como todo em módulos ou
partes mais manejáveis, com o intuito de melhor planejar o seu desenvolvimento.
A seguir foram realizados estudos em termos de viabilidade e performance no uso da
tecnologia de Web Services para atender os requisitos do sistema proposto, desenvolvimento
do software com as técnicas definidas para a concepção do sistema e por fim, foram
realizados testes de validação dos casos de uso definidos para o sistema com a criação de
aplicativos cliente para o serviços oferecidos pelo mesmo.
4.1. Construção do software
Para a construção do software deste trabalho, foi elaborado inicialmente a EAP do sistema
proposto, gerando como resultado o diagrama da EAP apresentada a seguir:
Implantação do
produto do Projeto
do TCC
Padronização do
Projeto
Desenvolvimento
Testes e revisão
Finalização
Padronização na
organização de
arquivos
Implantação do
escopo do Projeto
Criação e execução
de sequência de
testes
Validação do
Sistema
Criação de
programas
auxiliares (se
necessário)
Refatoração do
código do Sistema
Elaboração da
Documentação
Técnica do Sistema
Padronização do
Banco de Dados
Padronização de telas
Criação da versão
beta do Sistema
Criação da versão
final do Sistema
Criação da versão
final da
Documentação
do Projeto
Figura 4. O diagrama de EAP do sistema do projeto
Após definidas as etapas da construção do software foram realizados levantamentos
relacionados a viabilidade do uso da tecnologia de Web Services e ao melhor tipo de padrão
de projeto a serem adotados para a implementação do sistema.
4.1.1. Estudo da viabilidade do uso da tecnologia de Web Services para transferência de
arquivos
Segundo afirmam Potts e Kopack (2003), uma das principais críticas aos Web Services que
utilizam XML para troca de mensagens, é a área de transmitir dados não-caracteres. A idéia
de converter tudo em caracteres não é considerada viável para certos tipos de dados, como
fotografias e código executável.
Um documento XML é transmitido apenas como um conjunto de caracteres, outros
tipos de dados não binários – como imagens, arquivos de áudio ou programas compilados, são
problemáticos para seu envio.
Diante desse cenário, uma possível solução seria o envio desses arquivos como anexos
em uma mensagem SOAP, através dos seguintes recursos:
- Conversão de dados binários usando codificação Base64 para que estes possam ser
enviados como texto.
- Codificação de anexos utilizando o protocolo MIME (Multipurpose Internet Mail
Extensions).
A codificação Base64 é baseada na popular codificação US-ASCII, com a diferença de
que este, ao contrário da codificação ASCII (American Standard Code for Information
Interchange), permite transmitir qualquer documento binário como arquivos de áudio, vídeo e
executável em anexo de correio eletrônico codificando-o com ajuda de caracteres clássicos.
A codificação Base64 provoca um aumento global de 33% do volume dos dados a
codificar, e também provoca um alto grau de consumo de recursos tanto do lado do cliente
como do lado do servidor, para a realização dos processos de codificação e decodificação das
mensagens, e é necessário que haja garantia de abundância de largura de banda para que o
envio de anexos dentro de transações de Web Services funcione bem.
Para a transmissão de dados não-ASCII como anexo é necessário a utilização do
protocolo MIME.
Segundo Potts e Kopack (2003), o MIME funciona incluindo um cabeçalho ContentType que pode ser usado para especificar o tipo e o subtipo dos dados sendo enviados no
anexo, e conforme citado, sete tipos de dados são especificados
- Tipo 1 – Texto – Dados de texto em um conjunto de caracteres
- Tipo 2 – Imagem – Dados de imagem estática
- Tipo 3 – Áudio – Dados de áudio ou voz
- Tipo 4 – Vídeo – Dados de imagem dinâmica
- Tipo 5 – Mensagem – Encapsulação de uma mensagem de e-mail
- Tipo 6 – Multiparte – Combinações de outros tipos em uma única mensagem
- Tipo 7 – Aplicação – Dados binários ou de aplicação
Inicialmente foi levado em consideração o uso do framework Axis de código aberto,
baseado em linguagem Java e no padrão XML, para a construção dos Web Services
responsáveis pela transmissão de dados em anexo para o repositório de arquivos do sistema.
Entretanto, o Metro, que é um framework de código aberto, e faz parte do servidor de
aplicativos GlassFish para criação de Web Services, apresentou suporte para envio e
recebimento para grande quantidade de anexos em forma de streaming (fluxo) de dados
através de seu componente IR (Implementação de Referência) JAX-WS (Java API for XML
Web Services).
O envio desses arquivos utilizando o framework Metro é possível através do modelo
baseado na codificação Base64 e o acesso a esses dados através do recurso de
StreamingDataHandler (manipulador de fluxo de dados).
O órgão netbeans.org através de seu site disponibiliza um tutorial de como
implementar um projeto para envio de anexos de forma binária através da IDE NetBeans, por
meio da alteração do arquivo WSDL do Web Service criado para a utilização da codificação
de dados Base64 e protocolo de envio de anexos MIME fazendo uso do framework Metro.
Uma vez definido a viabilidade do uso de Web Services para transporte de dados
(arquivos) remotos, realizamos diversos levantamentos de pesquisas realizadas para
dimensionar a real eficácia do uso de Web Services por parte de programadores e arquitetos
de software.
Segundo Wong (2009), os serviços de upload e download de arquivos através de Web
Services para grandes arquivos regulares como doc, pdf e jpg pode gerar consumo excessivo
de memória, uma vez que a transmissão de arquivos de ponta a ponta, ou seja, do cliente para
o repositório de arquivos remoto e o contrário é realizado através do uso de um array de bytes,
e também podem ocorrer problemas de escalabilidade, se houver muitos clientes usando o
mesmo serviço.
O modelo proposto por Wong (2009) relata que a melhor solução para transmissão e
recepção de arquivos seria através do uso do protocolo FTP (File Transfer Protocol). O uso de
Web Services neste caso seria para armazenamento e posterior acesso a todas as informações
da movimentação do repositório remoto, ou seja, a tecnologia de Web Services seria utilizado
para fins de troca de mensagens a respeito da utilização do serviço oferecido para
armazenamento de arquivos.
O armazenamento das informações intrínsecas dos arquivos hospedados no repositório
neste caso necessitaria do uso de um banco de dados.
Concluiu-se portanto neste estudo preliminar que em termos de desempenho e
eficácia, a melhor solução a ser adotada para transferência de arquivos seria através da
utilização do protocolo FTP, e a tecnologia de Web Services poderá ser utilizada para geração
de informações de movimentação dos arquivos armazenados no repositório remoto do sistema
ao cliente utilizador deste serviço.
4.1.2. Desenvolvimento do software
Definido a utilização do protocolo FTP para transferência de arquivos do sistema, foram
realizados pesquisas por ferramentas open source e de desempenho garantido para a criação
de um servidor FTP do sistema, que possibilitasse o serviço de armazenamento remoto de
arquivos.
O FTP é uma forma rápida e versátil para transferência de arquivos, sendo a muito
tempo uma das formas mais utilizadas na Internet.
O aplicativo
open
source CesarFTP
0.99g,
disponibilizado
pela empresa
desenvolvedora ACLogic, permite a mudança na estrutura dos arquivos contidos em um HD,
ou seja, permite a configuração rápida da escolha de quais arquivos se deseja disponibilizar de
forma pública para que esta possa se acessada remotamente.
Figura 5. Interface do servidor FTP CesarFTP 0.99g
Pelas suas características, este aplicativo permitiu a criação de um servidor FTP como
um serviço do sistema proposto neste projeto.
O gerenciamento do servidor FTP, que é o repositório remoto deste projeto e
disponibilização das informações dos arquivos contidos nele, foi desenvolvido através da
criação de Web Services dentro da IDE NetBeans.
Como padrão utilizado para a construção desta parte do sistema, foi utilizado o design
pattern Façade, que permite a definição de uma interface comum para as classes que
compõem este componente do sistema, vide Apêndice J - Diagrama de Componentes em
anexo.
Como pode ser observado no Apêndice G - Diagramas de Classes em anexo, no
componente do sistema responsável pela manipulação de arquivos , foi criada uma classe
chamada ArquivoORM, que por meio de seu atributo privado do tipo EntityManager, fará
acesso aos registros do Banco de Dados do sistema para realizar as operações de localização,
listagem, exclusão, inserção e registro da data de download dos arquivos no servidor FTP do
sistema.
O Web Service CadastrarArqWs disponibilizará as funcionalidades deste componente
ao cliente remoto do sistema.
De forma análoga, no componente do sistema responsável pela manipulação dos
cadastros de usuários junto ao repositório remoto, a classe UsuarioORM, por meio de seu
atributo privado do tipo EntityManager, fará acesso ao Banco de Dados na tabela Usuario
para realizar as operações de inserção, localização e exclusão dos usuários para fins de
autenticação ao acesso do servidor FTP do sistema.
O Web Service CadastrarUsWs disponibilizará as funcionalidades deste componente
ao cliente remoto do sistema.
Definidos os componentes que farão parte do sistema que oferecerá o serviço de
repositório de arquivos remoto, foram criados neste projeto dois modelos de aplicação cliente
para este serviço apenas para fins de demonstração e teste do software do lado do servidor,
que é a aplicação real proposta neste projeto.
4.2. Teste do software
Com a finalidade de se realizar testes de verificação e validação dinâmica da aplicação
proposta neste projeto, para assegurar que esta cumpra com suas especificações e atenda às
necessidades do usuário referente a usabilidade do serviço proposto, foram criados duas
aplicações clientes para o servidor FTP do sistema em conjunto com os clientes do Web
Service responsável pela geração de registros de movimentação deste servidor por parte do
usuário.
A tabela a seguir demonstra os casos de uso definidos para o sistema, conforme
encontrado no Apêndice E – Diagramas de casos de uso do Sistema Repositório de Arquivos
Online, sendo atendidos pelas aplicações clientes desenvolvidas apenas para fins de teste do
software proposto neste trabalho:
Casos de uso
Aplicação cliente em Java Aplicação cliente em C#
Acessar sistema
X
X
Salvar arquivo
X
X
Acessar lista de arquivos
X
X
Recuperar arquivo
X
X
Excluir arquivo
X
X
Visualizar data do último download dos
arquivos
X
X
Visualizar data de upload dos arquivos
X
X
Tabela 1. Validação dos casos de uso do sistema pelas aplicações clientes
O primeiro modelo de aplicação cliente construído para teste de consumo do Web
Service e de acesso ao servidor FTP do sistema foi a criação e execução de um projeto Web
criado na IDE NetBeans.
Figura 6. Tela de abertura de um novo projeto na IDE NetBeans
Neste modelo de aplicação, foi adotado o uso de um servidor de aplicação, neste caso,
o GlassFish versão 3.1, e também o uso de uma API para a criação de uma classe cliente do
servidor FTP do sistema, disponibilizada pela Apache Foundation, o commons-net 2.2.
A API commons-net 2.2 permite a disponibilização de clientes para muitos protocolos
básicos da Internet, como o Telnet (Telecommunications Network), SMTP (Simple Mail
Transfer Protocol) e FTP.
Figura 7. Utilização da API commons-net 2.2 no modelo de aplicação cliente do
sistema
Foi utilizado neste modelo de aplicação um Servlet para a camada de controle da
mesma, com a finalidade de instanciar e invocar os métodos da classe responsável pelo acesso
ao servidor FTP do sistema e também instanciar a classe cliente do Web Service disponível na
aplicação que disponibiliza o serviço do sistema.
Um Servlet é basicamente uma classe que recebe requisições da camada Web de um
projeto e gera respostas a essas requisições, no caso deste projeto as requisições são referentes
ao acesso do servidor FTP no sistema para realização de upload, download, e exclusão de
arquivos deste servidor, e requisições de chamadas dos métodos dos Web Services do sistema
para registro das atividades pelos usuários do sistema.
Para teste de consumo dos Web Services disponíveis pela aplicação do Sistema, foram
criados clientes para os mesmos como mostra a figura 8, repare que é possível especificar a
URL do arquivo WSDL do Web Service nesta etapa.
Figura 8. Criação de um novo cliente para Web Service na IDE NetBeans
Neste modelo de aplicação, para fins de controle de acesso, foi criado um cliente para
o Web Service responsável pela autenticação dos usuários cadastrados no sistema, através de
consulta aos registros da tabela Usuario do sistema (vide Apêndice H – Modelo conceitual da
base de dados do sistema).
Os dados de acesso ao sistema são passados pelo cliente através de uma página
disponibilizada pela Web por meio de um arquivo JSP (Java Server Pages).
Figura 9. Página de login do sistema disponibilizada por um arquivo JSP
Um arquivo JSP é um arquivo em HTML com tags especiais que delimitam o início e
o fim de trechos de código em Java que serão compilados e executados pelo servidor de
aplicação adotado.
Os relatórios de movimentação de arquivos do repositório remoto do sistema é
disponibilizado por meio de uma tabela conforme mostra a figura 10.
Figura 10. Tabela do sistema contendo relatório de movimentação de arquivos
O segundo modelo de aplicação cliente construído para teste de consumo do Web
Service e de acesso ao servidor FTP do sistema foi desenvolvido na IDE Visual Studio 2010,
por meio de um projeto desktop criado usando-se a linguagem de programação C#, com a
finalidade demonstrar a interoperabilidade entre a aplicação proposta neste trabalho e um
exemplo de cliente criado em um ambiente de programação distinto ao anterior.
A interface utilizada para criação do projeto foi o Windows Forms Application, este é
parte integrante do framework .NET da Microsoft, que oferece a possibilidade da utilização
de recursos do sistema operacional Windows.
A figura 11 mostra a tela de abertura de um novo projeto do Visual Studio 2010, com
a opção da utilização da API (Application Programming Interface) gráfica Windows Forms.
Figura 11. Tela de abertura de um novo projeto na IDE Visual Studio 2010
Neste modelo de aplicação também foi utilizado uma API para acesso ao servidor FTP
do sistema e dois clientes, um para o Web Service que permite acesso ao banco de dados
remoto com as informações dos arquivos do repositório do sistema e outro para acesso ao
banco de dados remoto com os cadastros de username e login de cada usuário cadastrado no
sistema (vide Apêndice H – Modelo conceitual da base de dados do sistema).
Figura 12. Criação de Web Service client no Visual Studio 2010
A interface gráfica deste modelo de aplicação para o usuário cliente é mostrada na
figura 13, o acesso das informações de arquivos do repositório remoto também é
disponibilizada na forma de uma tabela.
Figura 13. Interface gráfica do modelo de aplicação desenvolvido no Visual Studio
2010
Neste segundo modelo de aplicação, o acesso às funcionalidades disponibilizadas pelo
serviço do sistema deste trabalho é baseado em eventos.
Desta forma, uma vez acessado a tabela contendo a lista de arquivos disponíveis pelo
servidor FTP do sistema, o usuário no evento duplo clique na linha onde está nomeado o
arquivo em que se pretende efetuar alguma ação, terá acesso a uma segunda tela que permite a
exclusão do arquivo no repositório remoto ou o download deste localmente para o usuário.
Assim como o primeiro modelo de aplicação apresentado, esta segunda aplicação
permitiu a validação de forma dinâmica das funcionalidades do sistema proposto neste
trabalho.
5. Discussão
A disponibilização de um serviço, através do modelo de computação nas nuvens,
como o produto proposto neste trabalho, segue o princípio de computação em grade, através
do uso da Internet.
A computação em grade é um modelo computacional anterior ao modelo de
computação nas nuvens, em que toda a taxa de processamento de dados é realizada de forma a
ser dividida em diversas máquinas, através de redes locais ou distribuídas formando o que
chamamos de máquina virtual, cujo objetivo é justamente a garantia de interoperabilidade,
portabilidade e reutilização de serviços.
A utilização de Web Services para a construção do aplicativo apresentado neste
trabalho, para a implementação dos requisitos anteriores mencionados, nos permitiu a
observação das seguintes vantagens e desvantagens no uso desta tecnologia apontados por
Potts e Kopack (2003).
Vantagens:
- Obtenção de relatórios de status remotos: Pelo fato de dois computadores poderem
participar de uma transação Web Service, significa que é possível obtermos um relatório de
status do recurso ou serviço oferecido remotamente em qualquer lugar, ou qualquer hora do
dia ou da noite, conforme apresentado neste trabalho.
- Menos custo de desenvolvimento de software: O fato dos Web Services poderem
interoperar independente de plataforma, permite que a reutilização de código ocorra, por
exemplo, por meio da descoberta de um novo programa de um código já criado, assim, se um
código já existisse e não fosse possível a sua descoberta, também não seria possível o
benefício da existência deste.
A interoperabilidade oferecida pelos Web Services é um enorme desenvolvimento no
mundo da reutilização de código.
Desvantagens:
- Disponibilidade: Como a Internet não garante 100% de disponibilidade o tempo
todo, os Web Services, que usam a mesma estrutura dos sites Web, também não estarão
totalmente disponíveis, mesmo que o servidor esteja funcionando plenamente, o serviço
oferecido nas nuvens não estará se seu provedor de serviços de Internet não estiver disponível.
- Problemas de desempenho: O processo de comunicação entre Web Services ou entre
um Web Service com seus clientes acontece com mensagens XML codificadas em um
formato especial (um envelope SOAP), e essa conversão leva tempo.
Dependendo da complexidade dos seus dados e de sua complexidade, esse tempo pode
ser uma série penalidade.
Como exemplo, podemos citar a tentativa de envio de uma imagem binária como um
parâmetro de método, neste caso, estes dados precisam ser codificados em um formato que
possa ser representado em XML, isso certamente não é tão rápido quanto transferir a imagem
através de um fio em seu formato original, e diante deste cenário, no sistema apresentado
neste trabalho, foi adotado o uso do protocolo FTP para transferência de dados.
7. Conclusão
A partir do aplicativo desenvolvido neste trabalho, podemos concluir que a utilização
de serviços adotando a cultura de computação nas nuvens apresenta-se como uma ferramenta
dinâmica, prática e simples para a finalidade de proteção de dados por meio da prática de
backups, que são um dos ativos mais importantes de uma empresa ou mesmo pessoas físicas
contra perdas de informações.
7. Trabalhos futuros
A partir do produto apresentado neste trabalho, existem diversas opções de aperfeiçoamento e
incrementação de vários recursos para a disponibilização do serviço de armazenamento
remoto de arquivos.
Podemos ver a adição destes recursos como possíveis trabalhos futuros a serem
desenvolvidos a partir deste projeto, dentre as principais podemos destacar:
- Maior garantia de segurança e privacidade: Segundo Potts e Kopack (2003),
partindo da premissa que tudo o que é enviado pela Internet pode ser visto por outras pessoas,
o uso de técnicas de criptografia como o SSL (Structure Sockets Layer) faz um ótimo trabalho
de salvaguardar informações e é fácil de ser configurada, entretanto, fazendo o uso desta
técnica em conjunto com o protocolo HTTP, o chamado HTTPS temos maior lentidão nas
transações entre cliente e servidor do que somente fazendo uso do protocolo HTTP puro.
O uso do protocolo FTPS para controle de canais FTP como meio para garantir a
confidencialidade, integridade e disponibilidade dos dados transportados entre cliente e
servidor em uma rede insegura como a Internet, também é um recurso a ser considerado para
melhoria na camada de segurança de dados.
- Sincronização automática de arquivos entre cliente e servidor: Este recurso
possibilita o envio somente de arquivos que forem alterados nas nuvens em relação aos que já
foram salvos no repositório remoto, possibilitando maior rapidez na salvaguarda do que
realmente é importante ao usuário.
Agradecimentos
Agradeço ao professor Msc. Felipe Mancini por aceitar e apoiar o tema deste trabalho e pela
oportunidade em colocar em prática os conhecimentos adquiridos nas disciplinas de
Linguagem de Programação III e Desenvolvimento Web I e II, que foi a motivação para a
escolha do tema, e ao professor Rogério Homem da Costa pela orientação na documentação
deste trabalho.
Agradeço também a todos os professores pelo empenho nas orientações e incentivos
ao longo deste curso.
Referências
ALECRIM, EMERSON. O que é Cloud Computing (Computação nas Nuvens)?.
Disponível em: <http://www.infowester.com/cloudcomputing.php>. Acesso em: 18 Mar.
2011.
AMBIENTE de desenvolvimento integrado – Wikipédia, a enciclopédia livre. Disponível em:
<http://pt.wikipedia.org/wiki/Ambiente_de_Desenvolvimento_Integrado>. Acesso em: 21
Mar. 2011.
APACHE Commons Net. Disponível em: <http://commons.apache.org/net/>. Acesso em: 21
Mar. 2011.
BACKUP na nuvem: opção segura para pessoas e empresas. Disponível em:
<http://www.jornaldooeste.com.br/informatica/noticias/3465/?noticia=backup-na-nuvemopcao-segura-para-pessoas-e-empresas>. Acesso em: 21 Mar. 2011.
CAPRON, H. L.; JOHNSON, J. A. Introdução à Informática. 8° ed. São Paulo: Prentice –
Hall, 2004. ISBN 8587918885
CARNEIRO, R. J. G.; DA COSTA RAMOS, C. C. L. A SEGURANÇA NA
PRESERVAÇÃO E USO DAS INFORMAÇÕES NA COMPUTAÇÃO NAS NUVENS.
Disponível em: <http://www.4learn.pro.br/guarino/sd/08-Cloud%20Computing.pdf>.
Acesso em: 21 Mar. 2011.
CODIFICAÇÃO Base64. Disponível em: < http://pt.kioskea.net/contents/base/base64.php3 >.
Acesso em: 21 Mar. 2011.
C# FTP Library. Disponível em: <http://ftplib.codeplex.com/>. Acesso em: 21 Mar. 2011.
GOMES, D. A. Web Services Soap em Java. São Paulo: Novatec, 2011. ISBN
9788575222188.
GONÇALVES, E. Desenvolvendo aplicações Web com NetBeans IDE 5.5. Rio de Janeiro:
Ciência Moderna, 2007. ISBN 9788573935790
GUERRA, GLAUCIO. Desenvolvendo um Cliente FTP. Disponível em:
<http://www.devmedia.com.br/post-3547-Desenvolvendo-um-Cliente-FTP.html>.
Acesso
em: 21 Mar. 2011.CARNEIRO, R. J. G.; DA COSTA RAMOS, C. C. L. A SEGURANÇA
NA PRESERVAÇ\ AO E USO DAS INFORMAÇ\ OES NA COMPUTAÇ\ AO NAS
NUVENS. [S.l.], [S.d.].
HEFFELFINGER, D. Java EE 6 with GlassFish 3 Application Server. [S.l.]: Packt
Publishing, 2010. ISBN 1849510369.
MENDES, D. R. Programação Java com ênfase em orientação a objetos. São Paulo: Novatec,
2009. ISBN 9788575221761
METRO
Guide
–
Large
Attachments
–
Java.net.
Disponível
<http://metro.java.net/guide/Large_Attachments.html>. Acesso em: 21 Mar. 2011.
em:
O que é o NetBeans?. Disponível em: <http://netbeans.org/index_pt_BR.html>. Acesso em:
22 Mar. 2011.
POTTS, Stephen; KOPACK, Mike. Aprenda web services em 24 horas. Rio de Janeiro
Campus, 2003. ISBN 853521321X
REESE, G.; REESE, G. Database Programming with JDBC and Java. 2nd ed. [S.l.]:
O’Reilly Media, 2000. ISBN 1565926161.
SOAP
Wikipédia,
a
enciclopédia
livre.
Disponível
http://pt.wikipedia.org/wiki/SOAP>. Acesso em: 21 Mar. 2011.
em:
<
TAURION, C. CLOUD COMPUTING - COMPUTAÇAO EM NUVEM:
TRANSFORMANDO O MUNDO DA TECNOLOGIA DA INFORMAÇAO. [S.l.]:
BRASPORT, 2009. ISBN 9788574524238.
TUTORIAL:
Como
criar
um
servidor
FTP.
Disponível
em:
<http://www.babooforum.com.br/forum/index.php?/topic/232337-tutorial-como-criar-umservidor-ftp/>. Acesso em: 21 Mar. 2011.
VAZ,
VERÔNICA
TARQUETTE,
MIME.
Disponível
<http://www.gta.ufrj.br/grad/07_2/veronica/MIME.html>. Acesso em: 22 Mar. 2011.
em:
WONG, RYAN. File Transfer through Java Web Service. Disponível em:
<http://www.programcreek.com/2009/02/file-transfer-through-java-web-service/>. Acesso
em: 19 Mar. 2011.
Lista de abreviaturas e siglas
API – Application Programming Interface
ASCII – American Standard Code for Information Interchange
BEA – Bill Coleman, Ed Scott, Alfred Chuang
DB – Data Base
EAP – Estrutura Analítica do Projeto
EJB – Enterprise Java Beans
FTP – File Transfer Protocol
HD - Hard Disk
HP – Hewlett Packard
HTTP – Hypertext Transfer Protocol
IaaS – Infrastructure as a Service
IBM – International Business Machines
IDE – Integrated Development Environment
JAX-WS – Java API for XML Web Services
JSP – Java Server Pages
MIME – Multipurpose Internet Mail Extensions
RAD – Rapid Application Development
REST – Representational State Transfer
SOAP – Simple Object Access Protocol
SMTP – Simple Mail Transfer Protocol
SQL – Structured Query Language
SSL – Secure Sockets Layer
TELNET – Telecommunications Network
UDDI – Universal Description Discovery and Integration
URI – Uniform Resource Identifier
URL – Uniform Resource Locator
WSDL – Web Service Description Language
W3C – World Wide Web Consortium
XML – Extensible Markup Language
Apêndice A - Descrição dos requisitos funcionais do Sistema do Projeto
- O Sistema deve permitir a inclusão, exclusão e atualização de arquivos diversos
armazenados em um repositório disponibilizado em um servidor pela Internet.
- O usuário deverá ser capaz de buscar as informações presentes em um relatório de dados
disponibilizados um BD acessado pelo Sistema.
- Todas as funcionalidades e métodos disponibilizados pelo Sistema deverão estar
disponibilizados para o usuário através do recurso de serviços Web e através de um meio
versátil que utilize a internet como meio para esse fim.
- O Sistema fornecerá telas apropriadas para que o usuário possa recuperar e salvar
documentos que este julgar importantes do repositório de arquivos para o seu dispositivo local
e vice-versa.
- Uma vez acessando o sistema cada ação de upload, download e exclusão de arquivo do
repositório pelo usuário serão registrados pelo banco de dados do Sistema.
- O Sistema garantirá apenas acesso ao repositório de arquivos por usuários cadastrados no
Sistema.
-Cada usuário cadastrado no Sistema terá acesso somente à área do repositório correspondente
à sua cota reservada.
Apêndice B - Descrição dos requisitos não funcionais do Sistema do Projeto
- Facilidade do usuário no acesso às telas de login e visualização dos arquivos armazenados
no repositório do Sistema (interoperabilidade), basicamente fazendo uso de qualquer Web
Browser, ou interface independente da plataforma utilizado pelo usuário.
- Garantia de portabilidade, com acesso e recuperação de arquivos salvos no repositório do
Sistema necessitando apenas acesso à Internet.
- Garantia de acesso à mesma área do repositório por mais de uma pessoa.
- O local físico do repositório de arquivos ficará em um servidor cujo acesso estará disponível
pela Internet.
Apêndice C - Técnicas utilizadas para a obtenção dos requisitos funcionais e não
funcionais do Sistema:
- Observação direta: Através das funcionalidades de programas já existentes e disponíveis no
mercado.
- Brainstorming: Realizado através da reunião entre o orientador do projeto e possíveis
usuários para o Sistema que está sendo desenvolvido neste projeto.
Apêndice D - Perfil dos potenciais usuários do Sistema
- Atender empresas como gráficas, editoras, birôs, agências de publicidade e fotografia que
trabalham com grandes fluxos de informação e necessitam de um sistema que permita o envio
de arquivos pesados.
Apêndice E - Diagrama de casos de uso do Sistema Repositório de Arquivos
Online
Acessar Sistema
<<include>>
<<include>>
Salvar Arquivo
Acessar lista de arquivos
Recuperar arquivo
Usuário
Excluir arquivo
Visualizar data do último download dos arquivos
Visualizar data de upload dos arquivos
Apêndice F - Documentação dos Casos de Uso do Sistema
UC 001 - Acessar Sistema
Descrição
Este caso de uso define as etapas percorridas para o acesso ao Sistema
Repositório de Arquivos online
Ator
Usuário cadastrado do Sistema
Pré-condições
Usuário deve estar cadastrado no Sistema
Fluxo principal
Ator
Sistema
1. Acessa a tela de acesso do Sistema
2. Solicita nome e senha de acesso
3. Informa nome e senha
4. Verifica o nome e senha informados
5. Libera o acesso à tela principal do Sistema
Fluxo alternativo
A - Usuário não cadastrado no Sistema
O fluxo começa no passo 3 do fluxo principal quando o usuário informa senha e/ou nome
inválidos
Ator
Sistema
1. Informa usuário e/ou senha inválidos
UC 002 - Salvar arquivo
Descrição
Este caso de uso define as etapas percorridas pelo usuário para salvamento
de arquivo no repositório do Sistema
Ator
Usuário cadastrado do Sistema
Pré-condições
Usuário deve estar cadastrado e tendo feito login de acesso no Sistema
Fluxo principal
Ator
Sistema
1. Executar o UC001 - Acessar Sistema
2. Requisita salvamento de arquivo no
repositório do Sistema
3. Realiza conexão com o servidor FTP do Sistema
4. Solicita o arquivo para salvamento
5. Informa o arquivo a ser salvo
6. Realiza o salvamento do arquivo na no
repositório
7. Exibe mensagem de arquivo salvo
8. Fecha a conexão com o servidor FTP do Sistema
Fluxo alternativo
A - Erro durante o processo de salvamento do arquivo no repositório do Sistema
O fluxo começa no passo 6 do fluxo principal quando o Sistema lança uma exceção no
processo de upload do arquivo no repositório do Sistema
Ator
Sistema
1. Informa erro no processo de upload do arquivo no repositório do
Sistema
B - Usuário não informa o arquivo, mas solicita salvamento no repositório
O fluxo começa no passo 5 do fluxo principal quando o usuário informa o arquivo a ser salvo
Ator
Sistema
1. Sistema retorna ao passo 4 do fluxo principal
UC 003 - Recuperar arquivo
Descrição
Este caso de uso define as etapas percorridas pelo usuário para recuperação
de arquivo salvo no repositório do Sistema
Ator
Usuário cadastrado do Sistema
Pré-condições
Usuário deve estar cadastrado, ter feito login de acesso no Sistema e ter feito
solicitação da lista de arquivos disponíveis no repositório de arquivos
Fluxo principal
Ator
Sistema
1. Executar o UC 005 - Acessar lista de arquivos
2. Requisita recuperação de arquivo do
repositório do Sistema a partir da lista
de arquivos
3. Realiza conexão com o servidor FTP do Sistema
4. Solicita a pasta de destino onde será salvo o
arquivo do repositório
5. Informa a pasta de destino do arquivo
6. Realiza a cópia do arquivo do repositório
7. Envia cópia do arquivo na pasta de destino
informado pelo usuário
8. Informa o sucesso da operação de download do
arquivo
9. Sistema fecha a conexão com o servidor FTP do
Sistema
10. Confirma o sucesso da operação
Fluxo alternativo
A - Arquivo não encontrado
O fluxo começa no passo 5 do fluxo principal quando o usuário informa a pasta de destino
para recuperação de arquivo
Ator
Sistema
1. Informa arquivo não encontrado
B- Erro no envio do arquivo
O fluxo começa no passo 7 do fluxo principal quando o Sistema lança uma exceção ao tentar
enviar o arquivo solicitado pelo usuário para a pasta de destino informado pelo usuário
Ator
Sistema
1. Informa falha na operação de download do arquivo
UC 004 - Excluir arquivo
Descrição
Este caso de uso define as etapas percorridas pelo usuário para exclusão
de arquivo salvo no repositório do Sistema
Ator
Usuário cadastrado do Sistema
Pré-condições
Usuário deve estar cadastrado, ter feito login de acesso no Sistema e ter
feito solicitação da lista de arquivos disponíveis no repositório de
arquivos
Fluxo principal
Ator
Sistema
1. Executar o UC 005 - Acessar lista de arquivos
2. Requisita exclusão de arquivo do
repositório do Sistema
3. Realiza conexão com o servidor FTP do Sistema
4. Realiza a exclusão do arquivo informado pelo
usuário no repositório do Sistema
5. Informa o sucesso da operação
Fluxo alternativo
A - Arquivo não encontrado
O fluxo começa no passo 2 do fluxo principal quando o usuário informa o arquivo para
exclusão
Ator
Sistema
1. Informa arquivo não encontrado
UC 005 - Acessar lista de arquivos
Descrição
Este caso de uso define as etapas percorridas pelo usuário para acesso e
visualização da lista de arquivos no repositório do Sistema
Ator
Usuário cadastrado do Sistema
Pré-condições
Usuário deve estar cadastrado e ter feito login de acesso no Sistema
Fluxo principal
Ator
Sistema
1. Executar o UC001 - Acessar Sistema
2. Requisita acesso a tabela contendo a
lista com os registros dos arquivos no
Banco de Dados do Sistema
3. Realiza conexão com o Banco de Dados do
Sistema
4. Consulta a tabela correspondente aos
registros de arquivos no Banco de Dados do
Sistema
5. Informa os registros existentes para o usuário
6. Visualiza os registros da tabela
correspondente aos arquivos no repositório
do Sistema
Fluxo alternativo
A - Nenhum acesso encontrado
O fluxo começa no passo 3 do fluxo principal quando o Sistema consulta a tabela
correspondente aos registros de arquivos no Banco de Dados do Sistema
Ator
Sistema
1. Apresenta uma tabela sem nenhum registro ao usuário
UC 006 - Visualizar data do último download dos arquivos no Sistema
Descrição
Este caso de uso define as etapas percorridas pelo usuário para acesso a
tabela de visualização das datas do último download dos arquivos no
repositório do Sistema
Ator
Usuário cadastrado do Sistema
Pré-condições
Usuário deve estar cadastrado, ter feito login de acesso no Sistema e ter
feito solicitação da lista de arquivos disponíveis no repositório de arquivos
Fluxo principal
Ator
Sistema
1. Executar o UC 005 - Acessar lista de
arquivos
2. Visualiza a coluna correspondente aos
registros da data do último download dos
arquivos no repositório do Sistema
UC 007 - Visualizar data de upload dos arquivos no Sistema
Descrição
Este caso de uso define as etapas percorridas pelo usuário para acesso a
tabela de visualização das datas de upload dos arquivos no repositório do
Sistema
Ator
Usuário cadastrado do Sistema
Pré-condições
Usuário deve estar cadastrado, ter feito login de acesso no Sistema e ter
feito solicitação da lista de arquivos disponíveis no repositório de arquivos
Fluxo principal
Ator
Sistema
1. Executar o UC 005 - Acessar lista de arquivos
2. Visualiza a coluna correspondente aos
registros da data de upload dos arquivos
no repositório do Sistema
Apêndice G – Diagrama de classes do sistema
Apêndice H - Modelo conceitual da base de dados do sistema
O diagrama DER apresentado foi baseado a partir do modelo proposto por Peter Chen, a partir
da técnica de ER.
Nesta técnica, o modelo de dados é representado através de um modelo entidaderelacionamento (modelo ER). Usualmente, um modelo ER é representado graficamente,
através de um diagrama entidade relacionamento (DER). A abordagem ER foi criada em 1976
por Peter Chen. Ela pode ser considerada como um padrão de fato para modelagem
conceitual.
A modelagem ER envolve os seguintes conceitos principais: entidade, relacionamento,
atributo, generalização/especialização e entidade associativa.
“Entidade = conjunto de objetos da realidade modelada sobre os quais deseja-se
manter informações no banco de dados” (HEUSER, 2001, p 23).
Relacionamento = conjunto de associações entre entidades.
“Em um DER, um relacionamento é representado através de um losango, ligado por
linhas aos retângulos representativos das entidades que participam do relacionamento”
(HEUSER, 2001, p 24).
Em uma representação de relacionamento, existe uma propriedade muito importante
que é a representação de quantas ocorrências de uma entidade podem estar associadas a uma
determinada ocorrência através deste relacionamento, essa propriedade é chamada de
cardinalidade.
Existem duas cardinalidades a serem consideradas: a cardinalidade máxima e mínima.
“Cardinalidade (mínima, máxima) de entidade em relacionamento = número (mínimo,
máximo) de ocorrências de entidade associadas a uma ocorrência da entidade em questão
através do relacionamento” (HEUSER, 2001, p 26).
No diagrama de ER do projeto, além da representação do relacionamento binário, ou
seja, relacionamento representando duas entidades foi representado também a representação
de mais de duas entidades associadas (através da entidade Relatório relacionada com Arquivo,
Pasta e Cliente).
A esse tipo de relacionamento, damos o nome de Relacionamento Ternário.
“Atributo = dado que é associado a cada ocorrência de uma entidade ou de um
relacionamento” (HEUSER, 2001, p 34)
Em cada entidade, existe um ou mais atributos que o distinguem das demais entidades,
esse atributo é chamado de atributo identificador.
“Um identificador é um conjunto de um ou mais atributos cujos valores servem para
distinguir uma ocorrência da entidade das demais ocorrências da mesma entidade” (HEUSER,
2001, p 35)
“Além de relacionamentos e atributos, propriedades podem ser atribuídas a
entidades através do conceito de generalização/especialização. Através deste
conceito é possível atribuir propriedades particulares a um subconjunto das
ocorrências (especializadas) de uma entidade genérica” (HEUSER, 2001, p
39).
O símbolo para representar generalização/especialização é um triângulo isósceles,
conforme mostra a seguinte figura:
No modelo proposto para representar o Banco de Dados relacional deste projeto não
houve a ocorrência de generalização/especialização.
Entidade Associativa = é a ocorrência de uma nova entidade surgida através da
associação de duas entidades que possuem um relacionamento de n : n (muitos para muitos).
No código-fonte do projeto, o mapeamento do Banco de Dados Relacional adotado
para o Sistema do projeto foi realizado através do mecanismo de ORM (Object-Relational
Mapping).
Este mecanismo mapeia automaticamente objetos Java (classes de entidade de banco
de dados, por exemplo) para e a partir de um banco de dados relacional, oferece linguagem de
consulta semelhante a SQL para trabalhar com estes objetos, e são responsáveis pelas ações
que envolvem a persistência ao banco de dados para realizar as seguintes tarefas:
– Gerenciamento do mapeamento Objeto-Relacional;
– Possibilidade para criar consultas, localizar objetos, sincronizar objetos e inserir
objetos no banco de dados;
– Co-gerenciamento das transações que envolvem entidades Objeto-Relacional.
Este serviço gerencia (acopla) o objeto Java que realiza o mapeamento OR.
Quando este objeto está acoplado ao serviço de Entity Manager:
– O Entity Manager monitora as alterações no estado da entidade do banco de dados;
– Sincroniza essas alterações com o banco de dados;
A representação do modelo ER representando as entidades existentes para a criação da
Base de Dados do Sistema do projeto (modelo conceitual) segue abaixo:
Documentação do modelo lógico da base de dados do Projeto
Modelo lógico = modelo de dados que representa a estrutura de dados de um banco de
dados conforme vista pelo usuário do SGBD.(HEUSER, 2001, p 18)
A representação do modelo lógico para a criação da Base de Dados do Sistema do
projeto segue abaixo:
Usuario (Codigo, Username, Senha)
Arquivo (Codigo, Nome, Tamanho, TipoArquivo, DataUpload, DataDownload,
DataExclusao, Usuario)
Usuario referencia Usuario
Documentação do modelo físico da base de dados do Projeto
Modelo físico = Detalha o armazenamento interno de informações, que não tem influencia
sobre a programação de aplicações no SGBD, mas podem influenciar a performance das
aplicações (por exemplo, as estruturas de arquivos usadas no acesso as informações).
A representação do modelo físico para a criação da Base de Dados do Sistema do
projeto é apresentada a seguir:
Nome da
Tabela
Descrição
Coluna
Codigo
Username
Senha
Usuario
Estrutura que armazena informações sobre os usuários do Sistema
Descrição
Tipo de dado
ID do cliente
Int(10)
Nome do cliente
Varchar(50)
Senha do cliente
Int(10)
Nome da
Tabela
Descrição
Coluna
Codigo
Nome
Tamanho
TipoArquivo
DataUpload
DataDownload
DataExclusao
Usuario
Arquivo
Estrutura que armazena informações sobre os arquivos dos usuários
Descrição
Tipo de dado
ID do arquivo
Int(10)
Nome do arquivo
Varchar(50)
Tamanho (em bytes) do arquivo
Int(10)
0 = arquivo, 1 = diretório
Int(10)
Data de inclusão do arquivo no repositório
Varchar(50)
Última data de download do arquivo
Varchar(50)
Data de exclusão do arquivo
Varchar(50)
Nome do usuário dono do arquivo
Varchar(50)
Nulo
N
N
N
Nulo
N
N
N
N
N
S
S
N
Seqüencial Consistência
S
PK
N
N
Seqüencial
S
N
N
N
N
N
N
N
Consistência
PK
A representação das tabelas para a criação da Base de Dados do Sistema do projeto
segue abaixo:
Bibliografia:
HEUSER, C. A. Projeto de banco de dados. [S.l.]: Sagra Luzzatto, 2001. ISBN
8524105909.
Softwares utilizados para a modelagem do Banco de Dados:
Brmodelo Versão 2.0.0
Desenvolvedores: Carlos Henrique Cândido sob a orientação do Prof. Dr. Ronaldo dos Santos
Mello (UFSC), como trabalho de conclusão do curso de pós-graduação em banco de dados
(UNVAG - MT e UFSC).
DBDesigner Versão 4.0.5.6
Desenvolvedor: Michael G. Zinner (fabForce)
Apêndice I – Diagramas de seqüência do sistema
Apêndice J – Diagrama de componentes do sistema