Arquitetura PRODEPA: Uma soluo para criao de sistemas distribudos

Amanda Monteiro Sizo, Adriana Nunes Teles Xisto, Jos Augusto da Silva Fernandes, Leila Riodades Daher Santos, Cludio Roberto de Lima Martins PRODEPA Processamento de dados do Par Rodovia Augusto Montenegro km 10, s/n 66.820-000 Belm PA Brasil
{amanda.sizo,adriana.teles, augusto.fernandes,leila.daher, claudio.martins}@prodepa.pa.gov.br

Abstract. This paper describes the components of the development architecture applied at the PRODEPA company (Processamento de Dados do Estado do Par), how it integrates with different frameworks to provide an increase in productivity in the company's software factory, and demonstrate how it allows to create distributed applications from the use of EJB technology. A case study demonstrates its applicability and the benefits achieved from the beginning of its implementation within a public organizational settings demanding software development. Resumo. Este artigo descreve os componentes da arquitetura de desenvolvimento utilizado na Empresa de Processamento de Dados do Estado do Par PRODEPA, como ela se integra a diferentes frameworks visando prover aumento na produtividade na fbrica de software da empresa, alm de demonstrar como ela cria aplicaes distribudas a partir da utilizao da tecnologia EJB. Um estudo de caso demonstra sua aplicabilidade e benefcios alcanados desde sua implantao dentro de um cenrio organizacional pblico, com forte demanda em construo de software.

1. Introduo
Uma arquitetura de software de um programa ou sistema computacional a estrutura que abrange os componentes de software, propriedades externamente visveis desses componentes e as relaes entre estes componentes [Pressman 2001]. Pode ser entendida tambm como a organizao fundamental de um sistema, incluindo seus componentes, o relacionamento entre eles e com o ambiente computacional, alm dos princpios que definem o desenho e a evoluo dos componentes [IEEE 2000]. Definir um padro arquitetural uma maneira de estimular o reuso de componentes e padronizar a estrutura atravs do uso rotineiro de solues existentes. A implantao de uma arquitetura para criao de sistemas distribudos norteou o ciclo de desenvolvimento de software, tornando-o mais gil. Diversas arquiteturas de software so propostas para o desenvolvimento de softwares e sistemas, para as mais diversas plataformas. Apesar de uma grande quantidade permanecer privada e pertencer a grandes organizaes, diversas arquiteturas esto publicamente disponveis [Carvalho 2009]. Como o caso da plataforma de desenvolvimento Pinho [Pinhao 2009], e a plataforma de desenvolvimento Demoiselle

1431

[Demoiselle 2009] que do suporte s aplicaes no mesmo ambiente computacional, isto , no mesmo servidor de aplicao. A crescente demanda para desenvolvimento de novos sistemas de forma gil e eficiente nas mais variadas plataformas, estimulou a necessidade da criao de uma arquitetura padro para o desenvolvimento de sistemas distribudos na PRODEPA Empresa de Processamento de Dados do Par. Esta arquitetura, denominada Arquitetura PRODEPA, integrada ao framework definido para uso interno (chamado Muiraquit), veio suprir a necessidade de prover um meio de reutilizao de componentes e arcabouos no ciclo de construo de sistemas na fbrica de software da empresa. Este trabalho visa apresentar a Arquitetura PRODEPA, que segue o padro arquitetural em camadas com algumas adaptaes, mas fundamentada em alguns princpios de GoF [Gamma et al 1995] e padres estabelecidos em Alur et al (2003). Foram integrados nessa arquitetura os frameworks Jboss-Seam, EJB3 e Hibernate, auxiliando o trabalho do desenvolvedor de software da empresa, alm de viabilizar o processo proposto neste trabalho. Diversas melhorias na qualidade do produto final podem ser observadas desde sua implantao, como: maior robustez, flexibilidade, extensibilidade, reusabilidade e alta disponibilidade. Tais caractersticas so difceis de serem alcanadas em uma empresa pblica, onde as tecnologias so freqentemente substitudas. O restante deste artigo est organizado como descrito a seguir: a seo 2 define o cenrio organizacional, a seo 3 examina os frameworks utilizados, na seo 4 apresentada a Arquitetura PRODEPA, na seo 5 mostrada a otimizao da arquitetura, na seo 6 um estudo de caso implementado e finalmente a seo 7 apresenta as concluses e os trabalhos futuros relativos a este artigo.

2. Contexto Organizacional
Atualmente a PRODEPA conta com aproximadamente 330 colaboradores e sua atual misso "Prover servios baseados no uso de tecnologia da informao e comunicao, aos poderes pblicos e sociedade do Estado do Par, em benefcio do cidado [Prodepa, 2009]. Culturalmente, a empresa apresenta fortes aspectos polticos e, por conseguinte, alta rotatividade de tecnologias. Nas gestes anteriores, os sistemas eram desenvolvidos em plataformas variadas, como Natural/Adabas, Delphi/Oracle, Ltus Notes entre outras. Porm, na atual gesto da PRODEPA foi observada a necessidade de uma mudana completa de paradigma que abrangesse no s o processo, mas tambm a engenharia de software para viabilizar o desenvolvimento mais gil de sistemas, visando atender s necessidades de TI Tecnologia da informao dos demais rgos do Estado, promovendo assim a insero do Estado no e-government. A criao da fbrica de software, a adoo de metodologias e padres, a implantao do Nvel F do MPS-br, alm de uma reciclagem completa dos tcnicos, foram vitais para conseguir avanos no ciclo de desenvolvimento de software. Dentro desse contexto, a criao da arquitetura PRODEPA e do framework Muiraquit so exemplos do progresso obtido na fase de projeto e desenvolvimento, viabilizando e

1432

uniformizando os procedimentos, diminuindo prazos e aumentando a produtividade, proporcionando a obteno de melhores resultados com menores custos.

3. Frameworks Utilizados
Frameworks so estruturas de software cujo princpio ser uma soluo reutilizvel, estvel e bem documentada, que tm como objetivo auxiliar o trabalho do desenvolvedor [Minetto 2007]. Pode-se dizer ainda que frameworks so um conjunto de classes que colaboram entre si gerando um projeto reutilizvel para um tipo especfico de software. Cagnin (2005) conclui que nesta abordagem de reutilizao, est implcito no apenas o aproveitamento do cdigo, mas tambm os esforos realizados em todas as fases do desenvolvimento de software. 3.1. Framework Muiraquit Integrado arquitetura PRODEPA est o framework Muiraquit, que fornece vrios recursos, agregados em trs componentes, como ilustra a Figura 1 e detalhados a seguir.

Figura 1. Framework Muiraquit

a) prodepa-architecture: fornece uma biblioteca de classes reutilizveis comum a todas as aplicaes desenvolvidas sob a Arquitetura PRODEPA, para prover recursos bsicos que possibilitam que o projeto mantenha o foco no negcio, em vez da tecnologia. Alguns exemplos desses recursos so: criao de relatrio, criao de DAOs genricos, criao de DTOs, entre outros; b) prodepa-utils: fornece uma biblioteca de classes que oferecem alguns recursos adicionais j definidos pela linguagem Java, porm adaptados Arquitetura PRODEPA como, por exemplo, manipulao de arquivos, datas, colees, entre outros; c) prodepa-exception: responsvel por padronizar as excees decorrentes do tratamento de erros e validaes exigidos pela arquitetura PRODEPA. Alguns frameworks abertos foram adotados como padres na Arquitetura PRODEPA, como o Jboss-Seam, EJB3 e Hibernate, proporcionando maior

1433

produtividade a partir da reutilizao de seus componentes. A seguir, so explicadas essas tecnologias. a) EJB3: um modelo de componente padro do lado do servidor para aplicativos de negcio distribudo. Ele permite que os objetos chamados de enterprise beans sejam expostos como servios web, de modo que seus mtodos possam ser invocados por outro aplicativo J2EE, e tambm por aplicativos escritos por outras linguagens de programao em diferentes plataformas. Nesta verso, temse o recurso de persistncia na prpria especificao, chamada de Java Persistence API (JPA), que define uma maneira de mapear objetos Java simples (POJO) para um banco de dados relacional [Burke 2007]. o principal framework responsvel por prover o acesso distribudo aos servios disponibilizados pelos sistemas desenvolvidos na arquitetura; b) Jboss-Seam: unifica o modelo de componentes do JSF e do EJB3, eliminando o cdigo de integrao, deixando o desenvolvedor dispensar mais ateno s regras de negcio [Seam Reference 2007]. Segundo Yuan e Heute (2007, p. 5), o Seam foi projetado para aplicaes Web com estado (Statefull). O framework garante, por exemplo, que os componentes de uma conversao sejam excludos da sesso do usurio caso ela seja finalizada ou expirada; c) Hibernate: responsvel por mapear objetos Java em tabelas de um banco de dados relacional, estreitando o gap conceitual que existe entre os dois, deixando o desenvolvedor livre para se concentrar no negcio da aplicao [Bauer 2007]. Na arquitetura utilizado por fornecer alguns recursos adicionais no que tange o mapeamento objeto-relacional. Na seo seguinte apresentado como elas se integram na arquitetura PRODEPA.

4. Arquitetura PRODEPA
A arquitetura aqui definida utiliza o padro arquitetural Model-View-Controller (MVC) que, por definio, desacopla as camadas provendo maior flexibilidade. O padro MVC tem como objetivo bsico separar as funes da aplicao (model) das funes de apresentao (view), permitindo a comunicao entre elas atravs de um controller [Araujo 2009]. A principal meta desta arquitetura modularizar o software de tal forma que possa oferecer facilidades de visualizao, reuso e na construo dos componentes, ao mesmo tempo em que busca um alto grau de satisfao nos atributos de confiabilidade, funcionalidade, desempenho e segurana. Em termos gerais, a arquitetura PRODEPA busca atender alta coeso e baixo acoplamento entre os componentes, pois cada camada possui uma interface que define os servios que devem ser implementados. A arquitetura possui fundamentos no padro facade [Gamma et al 1995] que define um nico ponto de acesso para os recursos do sistema. O domnio da aplicao tratado em uma camada especfica, onde so trabalhadas todas as funcionalidades que devero ser atendidas pelo sistema, ficando a camada business responsvel por validar as regras de negcio, e a camada DAO

1434

responsvel por persistir os dados; o transporte de dados entre as camadas se d por meio de DTOs. Uma viso geral da arquitetura PRODEPA vista na Figura 2. Os principais elementos da arquitetura so descritos adiante.

Figura 2. Integrao da Arquitetura PRODEPA com demais componentes

4.1. Facade O facade [Gamma et al 1995] o padro que simplifica o uso de servios oferecidos pela aplicao corporativa aos clientes (web services, pginas web, etc). a porta de entrada para efetuar uma transao. Funciona como ouvinte da camada de apresentao, ou seja, toda ao efetuada pelo usurio do sistema ser ouvida pelo facade e repassada para o servio executar. Uma vez que o facade seja visto como uma porta de entrada, responsabilidade dele receber pedidos de diferente formas, seja por meio de RMI-IIOP [RIIOP, 2009] ou web-services. 4.2. Servio A camada de servio segue o padro Roteiro de Transao [Fowler 2006], que organiza a lgica de negcio em procedimentos, onde cada procedimento lida com uma nica solicitao da apresentao. As classes encontradas neste pacote so responsveis por executar as transaes que a aplicao cliente necessita; as classes so compostas por anotaes EJB3 e instancia os componentes de persistncia. 4.3. DAO O Data Access Object (DAO) um padro conhecido na literatura como responsvel por intermediar o acesso aos dados armazenados em um banco de dados [Fowler 2006]. Cada DAO deve possuir uma interface, que especifica os mtodos de manipulao de dados. Os servios acessam apenas as interfaces dos DAOs,

1435

desconhecendo a implementao utilizada. Na arquitetura h duas opes para trabalhar com DAOs, atravs de instncias nos servios ou estendendo a classe AbstractServico. Esta uma classe do framework Muiraquit que j traz encapsulada a lgica de persistncia utilizando os frameworks de persistncia, alm de agregar a funcionalidade de gerao automtica de consultas parametrizadas (usando EJBQL). 4.4. Business A camada business semelhante ao padro Business Delegate [Alur et al, 2003], isto , o cdigo cliente limita-se a enxergar invocaes locais, e toda a complexidade das chamadas remotas ficam ocultas dentro dele. Caso haja a necessidade de migrar de EJB3 para qualquer outra tecnologia de componentes de negcios, a aplicao cliente permaneceria intacta, ficando as conseqncias limitadas apenas nos Business Delegates. A camada business no obrigatria, aplicvel somente quando existem objetos de interao complexa com outros objetos persistidos ou no. 4.5. Entity O entity [Alur 2003] o modelo de classes de domnio da aplicao, tambm conhecido por POJO (Plain Old Java Objects), contendo apenas os atributos do domnio do negcio. Objetos entity podem ser utilizados tanto pela camada business, como camada DAO, que os utiliza para persistir atravs de um mapeamento objeto-relacional. 4.6. DTO So objetos de transporte entre as camadas cliente e servidora (facade e servio). O objetivo expor somente os contratos estabelecidos nos servios, fornecendo informaes suficientes para realizar cada funcionalidade da aplicao, mantendo alta coeso com baixo acoplamento. 4.7. Converter O Converter uma camada que tem a funo de traduzir o DTO em entidades e viceversa. Ao expor DTOs no facade, isola-se os modelos de negcio do mundo externo, podendo publicar um servio web sem expor os modelos de negcio a terceiros. O diagrama de classes apresentado na Figura 3 mostra a integrao entre as camadas citadas neste tpico.

1436

Figura 3. Diagrama de classes - Integrao entre as camadas da arquitetura

5. Customizao da Arquitetura
De acordo com Hohmann (2003), uma das caractersticas principais de uma arquitetura de software sua flexibilidade e adaptabilidade. A arquitetura deve ser capaz de ser estendida e modificada a partir da contextualizao da aplicao, do qual se pode formar um plano para a implementao ou modificao do sistema. Em termos arquiteturais, a Arquitetura PRODEPA tem como caracterstica a adaptabilidade, possibilitando a instanciao da mesma de forma personalizada. A arquitetura pode ser instanciada e simplificada para atender sistemas de baixa complexidade, que no tm seus servios distribudos, e onde esses servios se restringem basicamente a mtodos CRUD (Create, Read, Update e Delete) e mtodos que no precisam de uma estrutura mais sofisticada. A instncia da arquitetura PRODEPA resultante desta otimizao inclui a camada facade, servio (sem injeo de EJBs) e camada business, se houver regras de negcio para serem validadas. As camadas de DTO e converter so retiradas, e na camada DAO no h necessidade de criao de classes e interfaces para esta camada, pois as classes de servio herdam os servios genricos de persistncia j disponibilizados pela classe AbstractServico.

1437

6. Estudo de Caso
Frameworks de integrao de middleware so usados para integrar aplicaes e componentes distribudos. Estes frameworks escondem o baixo nvel da comunicao entre componentes distribudos, possibilitando que os desenvolvedores trabalhem em um ambiente distribudo de forma semelhante a que trabalham em um ambiente no distribudo [Junior 2006]. Para demonstrar a utilizao da arquitetura no desenvolvimento de sistemas distribudos foi implementado um sistema de controle de acessos que fornece servios de autenticao e autorizao para diversas aplicaes clientes, independente da linguagem utilizada. Na Figura 4, v-se o diagrama de implantao que apresenta os componentes do sistema de controle de acesso (aplicao servidora) e as interfaces disponibilizadas para as aplicaes clientes, dependendo da linguagem utilizada por tais aplicaes. A aplicacao_cliente2, desenvolvida na linguagem de programao Java, acessa os servios disponibilizados pela aplicao servidora atravs da interface remota (FacadeRemote); a aplicao_cliente1, desenvolvida em PHP, obtm os servios da aplicao servidora atravs da interface web service. A camada cliente da prpria aplicao servidora disponibiliza suas funcionalidades acessando a interface local (FacadeLocal).

Figura 4. Diagrama de implantao - Integrao entre as aplicaes distribudas

A Figura 5 fornece uma viso estrutural de como as classes utilizadas pela aplicao servidora interagem para disponibilizar seus servios para uma aplicao cliente Java. A classe ModuloFacadeBean e a interface ModuloFacadeRemote fazem parte da camada facade da arquitetura PRODEPA e, para disponibilizar seus recursos remotamente, a classe ModuloFacadeBean utiliza anotaes disponibilizadas pela API JEE. A aplicacao_cliente2, que tambm foi desenvolvida na arquitetura PRODEPA, acessa a fachada da aplicao servidora utilizando o mtodo getProxy(String), disponibilizado pela classe BusinessFactory que faz parte do componente prodepa_util, do framework Muiraquit.

1438

Para manipular os dados e acessar os servios disponibilizados pela aplicao servidora, a aplicao cliente depende do componente cliente (apl_servidora_cliente), onde se encontra classes e interfaces disponibilizadas pela aplicao servidora.

Figura 5. Diagrama de classes - Integrao entre as camadas da arquitetura

Na Figura 6, utilizado um diagrama de seqncia para representar uma viso dinmica de como ocorre a comunicao entre as duas aplicaes distribudas e dos recursos que so utilizados.

Figura 6. Diagrama de seqncia - Integrao entre aplicaes distribudas

1439

Diversas aplicaes utilizam servios disponibilizados pelo sistema de controle de acesso. A maioria dessas aplicaes foram desenvolvidas seguindo a arquitetura PRODEPA, como por exemplo, o Sistema de Protocolo e o Sistema de Patrimnio do Estado do Par. O uso da arquitetura PRODEPA proporciona maior agilidade no desenvolvimento das aplicaes, visto que permite a reusabilidade das estruturas prexistentes, diminui o esforo dispensado para resolver detalhes de acesso a dados e padroniza o desenvolvimento de sistemas. Tal padronizao fundamental para diminuir a curva de aprendizagem e facilitar a comunicao entre os membros da fbrica de software, pois estabelece um vocabulrio comum e um fluxo padro de tarefas. Desta forma, possvel definir quais componentes sero empregados, que tipo de integrao ocorrer entre eles, e quais frameworks auxiliares devem ser utilizados para complementar a soluo. Assim, o desenvolvedor direcionado para resolver problemas relacionados com as regras de negcios que surgem no domnio da aplicao, e no com a construo e adaptao de componentes de infraestrutura.

7. Concluso e Trabalhos Futuros

O presente trabalho descreveu a arquitetura de software utilizada na Empresa de Processamento de Dados do Par PRODEPA, e como ela se integra ao framework denominado Muiraquit, objetivando reusabilidade, maior produtividade e qualidade nos produtos gerados em sua rea de desenvolvimento de sistemas. A arquitetura apresentada tem como diferencial integrar frameworks consagrados na plataforma Java, para desenvolvimento de aplicaes distribudas. O emprego da arquitetura conjuntamente com o framework Muiraquit trouxeram os seguintes benefcios: Para a PRODEPA: a) unificao, padronizao e reuso de solues implementadas por diferentes equipes facilitando a manuteno e evoluo de sistemas; b) maior rapidez no desenvolvimento de novos sistemas; c) capacitao dos tcnicos envolvidos a partir do conhecimento adquirido com os padres de mercado, o que tambm elevou a auto-estima da equipe. Para o Estado: a) desenvolvimento gil de solues com menor custo, permitindo dispensar mais recursos para projetos da rea fim de cada rgo; b) maior integrao das solues adotadas pelos mais diversos rgos do Estado, o que facilita o combate s fraudes e corrupo. Para o cidado: a) atendimento mais rpido devido automao dos processos;

1440

b) mais servios de auto-atendimento so disponibilizados, permitindo que o cidado no perca tempo em filas de espera, por exemplo. Como trabalho futuro, pretende-se adicionar o padro Factory [Gamma et al 1995] para criao de objetos de persistncia, acrescentar recursos como paginao por demanda e transformar em frameworks os mdulos de auditoria e controle de acesso, a fim de utiliz-los de forma no intrusiva, facilitando a reutilizao destes mdulos.

Referencias
Alur, Deepak; Crupi, John; Malks;Dan. Core J2EE Patterns: Best Practices and Design Strategies, Second Edition. Pearson. 2003. Araujo, D.F. Machado,R.P. Um Framework para Desenvolvimento de Aplicaes em Ajax, Disponvel em: http://prestesmachado.com.br/artigos/DanielaFeitosaAraujo.pdf , Acesso: 16 mar 2009. Bauer, C., King G., Java Persitence com Hibernate. Cincia Moderna, 2007 Burke,B., Monson-Haefel,R., Enterprise javaBeans 3.0. 5th. Peason, 2007 Cagnin, M. I. P., uma contribuio para a reengenharia de software baseada em linguagens de padres e frameworks. So Paulo: USP, Tese de doutorado. Instituto de Cincias Matemticas e de Computao, Universidade de So Paulo, 2005. Disponvel em: http://www.teses.usp.br/teses/disponiveis/55/55134/tde-08092005152316/. Acesso: 12 mar 2009. Carvalho,A. G. Carvalho Uma Proposta de Arquitetura de Software Genrica para Mobile Games Utilizando J2ME. Disponvel em: http://www.unibratec.com.br/jornadacientifica/diretorio/DEFININDO.pdf, Acesso: 12 mar 2009 Demoiselle, Sitio Oficial do Demoiselle Framework. Disponvel em: http://www.frameworkdemoiselle.gov.br/menu/framework/download-1/das, Acesso: 30 mar. 2009. Fowler, M. Padres de Arquitetura de Aplicaes Corporativas. Bookman, 2006. Gamma, E., Helm, R., Johnson, R. & Vlissides, J. Design patterns: Elements of reusable object oriented software. Reading, MA. 1995. Hohmann, L., Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley Professional, 2003. Junior, C.G.B., Agregando Frameworks de Infra-Estrutura em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet. Disponvel em: http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0410823_06_cap_02.pdf, Acesso: 21 mar 2009 IEEE 2000. IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems, IEEE Std 1471-2000. New York, NY: Institute of Electrical and Electronics Engineers. Minetto, Elton Lus; MASETO, Jhony Maiki. Anlise avaliativa entre frameworks de PHP. PHP Magazine, n.2, p.9-15, mar. 2007.

1441

Pinhao Sitio Oficial da Plataforma Pinho Paran. Disponvel em: http://www.frameworkpinhao.pr.gov.br/modules/conteudo/conteudo.php?conteudo= 5#pfc_CelRUP_arquitetura.pdf, Acesso: 18 mar 2009 Pressman, R. S. Engenharia de Software. 5th ed. McGraw Hill. 2001. Prodepa, Sitio da empresa de processamento de dados do Par. Disponvel em: http://www.prodepa.gov.br/index.php?q=node/117. Acesso: 12 mar 2009 RMI-IIOP (2009): Documentao da tecnologia RMI-IIOP. <http://java.sun.com/products/rmi-iiop/>. Acesso: 18 mar 2009. Disponvel em em:

Seam, Sitio oficial do framework seam Disponvel http://seamframework.org/Documentation/SeamDocumentation#HSeamReferenceDocumentation, Acesso: 16 mar 2009

Yuan, M. J.; Heute, T. JBoss Seam Simplicity and Power Beyond Java EE, Primeira Edio, Upper Saddle River: Prentice Hall, 2007.

1442