Transferência de Tecnologia

SENADO FEDERAL
Secretaria Especial do Interlegis - SINTER
Subsecretaria de Tecnologia da Informação - SSTIN
RELATÓRIO DE PROJETO
versão 2.1
Transferência de Tecnologia
1.Termo de Referência
Esse relatório diz respeito ao edital número 46, “OBJ-REL - Camada de
Persistência Objeto-Relacional”, publicado entre os dias 04 a 11 de maio de 2008,
a ser realizado no período de maio/2008 a outubro/2008.
2.Introdução
De acordo com o descrito no termo de referência desse projeto, os frameworks
utilizados pelo Interlegis permitem o armazenamento de informações tanto em
banco de dados relacionais (PostgreSQL e MySQL) quanto em banco de dados
orientados a objetos (ZODB).
De forma geral, quando trata-se de representar informações dentro do Plone
(utilizando-se o framework Archetypes), a persistência dos dados costuma ser
orientada a objetos (OO) e realizada diretamente no banco de dados orientado a
objetos ZODB. Há algumas soluções do Interlegis como, por exemplo, o SAPL
(Sistema de Apoio ao Processo Legislativo), que podem ser consideradas soluções
“híbridas”, armazenando informações em diferentes modelos (parte das
informações em banco de dados relacional e parte em banco de dados orientado a
objetos). No entanto, o SAPL não utiliza o framework Archetypes e, por sua vez, não
está relacionado com esse projeto.
Esse relatório tratará apenas das considerações relevantes ao primeiro caso, o
mapeamento de informações objeto-relacional. Nesse caso, as informações que
normalmente seriam armazenadas em bancos de dados OO precisam ser mapeadas
para um banco de dados relacional.
Esse quarto relatório complementa os Relatório 1, 2 e 3 já entregues anteriormente
e diz respeito a entrega “transferência de tecnologia”. Esse relatório tratará dos
procedimentos a serem adotados para que o produto desenvolvido seja facilmente
integrado as solução já existentes do Interlegis.
3. Considerações Gerais
Antes de relatar a respeito da integração do produto desenvolvido com as soluções
Interlegis já existentes, é oportuno fazer algumas considerações.
O Relatório 1 explana a respeito dos requisitos a serem atendidos por esse produto,
requisitos esses tem relação direta com as escolhas feitas durante o
desenvolvimento. O Relatório 2 relata a respeito da entrega do código fonte
produzido e o Relatório 3 detalha o processo de instalação desse código fonte. Esse
último relatório cobre o último aspecto importante do projeto, que será como utilizar
esse código fonte na prática, permitindo que o mesmo seja integrado facilmente as
soluções que o Interlegis já possui.
Apesar desse relatório ser bastante breve, a maior parte do esforço realizado foi
justamente para que o processo de integração e, por sua vez, a transferência da
tecnologia implementada fosse simples e objetiva. Todo o código fonte produzido foi
implementado com essa preocupação em mente e, nesse sentido, acredita-se que a
solução implementada seja bastante produtiva.
1
SENADO FEDERAL
Secretaria Especial do Interlegis - SINTER
Subsecretaria de Tecnologia da Informação - SSTIN
4. Transferência de Tecnologia
De acordo com o que foi especificado nos capítulos 6 e 7 do Relatório 1, existem
duas perguntas a serem respondidas a fim de permitir a transferência da tecnologia
e sua utilização em soluções do Interlegis:
1) Como são definidas quais serão as classes mapeada?
2) Como alteramos o modo de persistência para que os dados sejam persistidos
apenas no ZODB, apenas do banco de dados relacional ou em ambos?
Essas perguntas são, de fato, resultado dos requisitos definidos ainda no Termo de
Referência e, em última instancia, os objetivos práticos desse projeto.
O produto interlegis.sqlalchemystorage foi desenvolvido para permitir que esse
processo de integração seja o mais simples possível. Para isso, todo processo de
integração é guiado por um arquivo de configuração que armazena parâmetros de
persistência. Esse arquivo faz parte do código fonte produzido e encontra-se em
src/interlegis.sqlalchemystorage/interlegis/sqlalchemystorage/storage.conf.
O
arquivo tem o seguinte formato:
[general]
storage = SQL
[classes]
importpath = Products.ATContentTypes.content.document.ATDocument
Products.ATContentTypes.content.newsitem.ATNewsItem
O arquivo de configuração segue a sintaxe do módulo ConfigParser do python.
Nele existem duas seções distintas.
A primeira seção (general) define o modo como o mapeamento objeto-relacional
ocorre. Os valores possíveis para o parâmetro “storage” são: ZODB (todas as
informações são persistidas no ZODB, nada é gravado no banco de dados
relacional), SQL (os campos das classes a serem mapeadas são armazenados em
um banco de dados relacional de acordo com a tabela descrita no capítulo 6 do
Relatório 1) e BOTH (todas as operações de leitura são efetuadas apenas no ZODB
e todas as operações de escritas são efetuadas no ZODB e no banco de dados
relacional também, funcionando como uma “replicação”).
A segunda seção (classes), define quais classes Archetypes devem ser mapeadas.
Isso é feito através do parâmetro “importpath”, onde devem ser informadas quais
são as classe de conteúdo Archetypes que devem ter todos seus campos mapeados.
Por definição, o mapeamento é feito por classe de conteúdo Archetypes e o modo de
mapeamento é valido por instancia de Zope.
5. Considerações sobre a Implementação
Existem duas razões importantes para que a implementação em modo BOTH
processe todas as operações de leitura diretamente no ZODB. A primeira razão é
performance, preocupação essa explícita no Termo de Referência. Acredita-se que
operar um Plone Site com mapeamento em modo BOTH não tenha diferença
significativa de performance quando comparado ao mesmo Plone Site usando
informações apenas no ZODB. O próprio ZODB é um banco de dados planejado para
2
SENADO FEDERAL
Secretaria Especial do Interlegis - SINTER
Subsecretaria de Tecnologia da Informação - SSTIN
ter performance otimizada nas operações de leitura e, evitando-se que consultas
SQL sejam feitas no banco de dados para “buscar” uma informação que estaria
disponível no ZODB, temos uma economia de processamento.
As operações de escrita, por sua vez, são sempre feitas no ZODB e no banco de
dados relacional. Isso permite que todas as informações mapeadas esteja
atualizadas no ZODB e numa base relacional ao mesmo tempo, permitindo a
integração das soluções do Interlegis com outras plataformas através do acesso as
informações armazenadas no banco de dados relacional (através de ferramentas de
geração de relatórios ou “data mining”, por exemplo).
No modo de operação SQL, todas as operações de leitura e escritas são realizadas
no banco de dados relacional. Isso traz uma sobrecarga de processamento
(minimizada pelo framework SQLAlchemy, mas significativa quando comparada a
operação apenas com o ZODB). No entanto, esse modo de operação permite que
aplicações externas alterem o conteúdo do banco de dados relacional e que essa
alteração tenham impacto direto no conteúdo servido pelo Zope.
Por fim, mo modo de operação ZODB, nada é modificado no comportamento normal
do Zope; é como se a solução de mapeamento objeto-relacional não estivesse
instalada.
3