UNIVERSIDADE FEDERAL DE SANTA CATARINA
Framework para Controle de Concorrência
aplicado a Objetos Compostos
ADRIANO FERLIN
UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE CIÊNCIAS DA COMPUTAÇÃO
ADRIANO FERLIN
Framework para Controle de Concorrência
aplicado a Objetos Compostos
Monografia apresentada como requisito parcial à obtenção do grau de bacharel em Ciências da Computação da Universidade Federal de Santa Catarina.
Prof. Dr. Marcello Thiry C. da Costa Orientador
Prof. Dr.João Bosco M. Sobral Co-orientador
Gian Ricardo Berkenbrock, Mestrando Banca
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
Framework para Controle de Concorrência
aplicado a Objetos Compostos
ADRIANO FERLIN
A presente monografia foi aprovada como requisito para a obtenção do grau de bacharel em Ciências da Computação na Universidade Federal de Santa Catarina UFSC.
Florianópolis, 03 de fevereiro de 2004.
___________________________________________________ Prof. Dr. Marcello Thiry C. da Costa
Orientador
___________________________________________________ Prof. Dr. João Bosco M. Sobral
Coorientador
___________________________________________________ Gian Ricardo Berkenbrock, Mestrando
Agradecimentos
A Deus por ter me proporcionado esse privilégio de prestigiar, por alguns anos da minha vida, a convivência em um meio universitário. Além da aquisição da graduação, também evolui como pessoa durante esse processo.
Aos meus pais, pelo apoio irrestrito à minha escolha. Mesmo com as adversidades surgidas no decorrer desse período, o curso sempre teve um alto grau de prioridade. Obrigado pela compreensão e confiança aplicadas a mim.
Aos meus irmãos, que, através de seus atos, me incitam a ir além do ponto onde estou. Sou grato pelo amor e carinho que renovam o meu espírito constantemente.
Ao meu orientador, Marcello Thiry, que confiou na minha capacidade aceitando essa orientação em um momento crítico, com pouco tempo para o desenvolvimento do projeto. Mesmo sobrecarregado com outras atividades, sempre esteve presente nos momentos que necessitei de seu auxílio.
Ao meu co-orientador, professor João Bosco Sobral, que, assim como o meu orientador, confiou na minha capacidade, e aceitou esse projeto a poucos meses da conclusão do semestre.
Aos meus colegas e amigos de trabalho, que muitas vezes recorri para discutir questões pertinentes ao projeto. Parte desse trabalho se deve ao alto nível de conhecimento técnico desta equipe.
Aos meus amigos, que, insistentemente e incansavelmente, me cobraram a conclusão deste projeto. Agora essa história acabou. Mas sei que haverá outras, e os incentivos também.
A todas as pessoas, que direta ou indiretamente contribuíram para a conclusão deste projeto.
Sumário
LISTA DE SIGLAS...III LISTA DE FIGURAS ...IV
RESUMO ... 1 ABSTRACT ... 2 1. INTRODUÇÃO ... 3 1.1. OBJETIVOS... 4 1.1.1 Objetivo Geral ... 4 1.1.2 Objetivos Específicos... 5 1.2. JUSTIFICATIVA... 5 1.3. ESTRUTURA DO TRABALHO... 6 2. A ARQUITETURA J2EE... 7 2.1. INTRODUÇÃO... 7 2.2. TECNOLOGIA DE COMPONENTES... 10 2.2.1 Tipos de Clientes... 11 2.3. CONTÊINERES J2EE... 13 2.4. SERVLETS E JSP... 13 2.4.1 Servlets ... 14 2.4.2 JavaServer Pages... 15
2.5. ENTERPRISE JAVABEANS... 15
2.5.1 Session Beans... 16
2.5.2 Entity Beans ... 17
2.5.3 Message-Driven Beans ... 18
2.6. CONCLUSÃO... 20
3. PADRÕES DE PROJETO E FRAMEWORKS ... 21
3.1. PADRÕES DE PROJETO... 21
3.1.1 Classificação de Padrões ... 24
3.1.2 Anti-Padrões ... 25
3.1.3 Padrões J2EE... 26
3.1.3.1 Value Object ...27
3.1.3.2 Value Object Assembler ...30
3.1.3.3 Composite Entity ...32
3.2. FRAMEWORKS... 33
3.2.1 Frameworks Caixa Branca e Caixa Preta ... 37
3.2.2 Frameworks e J2EE... 39
4. TRANSAÇÕES... 41
4.1. TRANSAÇÕES DE BANCOS DE DADOS... 41
4.2. TRANSAÇÕES EM EJBS... 42
4.2.1 Transações gerenciadas por bean... 42
4.2.2 Transações gerenciadas por contêiner ... 43
4.2.3 Problema de atualização com transações... 44
5. MODELAGEM E IMPLEMENTAÇÃO DO FRAMEWORK ... 46
5.1. ESTUDO DE CASOS... 46
5.1.1 Mecanismos de Bloqueio de Registro ... 47
5.1.2 Controle de Concorrência de Objetos... 47
5.2. O ARQUIVO DE CONFIGURAÇÃO... 49
5.2.2 A tag <campo> ... 51 5.3. IMPLEMENTAÇÃO DO PROTÓTIPO... 52 5.4. EXEMPLO DE APLICAÇÃO... 56 6. CONSIDERAÇÕES FINAIS ... 58 6.1. DIFICULDADES ENCONTRADAS... 58 6.2. CONCLUSÃO... 58 6.3. TRABALHOS FUTUROS... 59 REFERÊNCIAS BIBLIOGRÁFICAS ... 60 ANEXO 1 ARTIGO ... 63
Lista de Siglas
API - Application Programing Interface AWT - Abstract Window Toolkit COS - CORBA Object Services DOM - Document Object Model EIS Enterprise Information System EJB - Enterprise JavaBeans
HTTP - Hiper Text Markup Language J2EE - Java 2 Platform, Enterprise Edition J2SE - Java 2 Platform, Standard Edition JAF - JavaBeans Activation Framework JAXP - Java API for XML Processing JDBC - Java Database Connectivity JMS - Java Message Service
JNDI - Java Naming and Directory Interface JSP - Java Server Pages
JTA - Java Transaction API
LDAP - Lightweight Directory Access Protocol SAX - Simple API for XML
SQL - Structured Query Language XML - Extensible Markup Language
XSTL - Extensible Styleshet Language Transformations WML - Website Meta Language
Lista de Figuras
Figura 1 Arquitetura J2EE básica (SUN, 2003) ... 11
Figura 2 Acoplamento entre camadas (GOMES, 2002) ... 26
Figura 3 Padrões J2EE (SUN, 2003) ... 28
Figura 4 Diagrama de classe do padrão Value Object (SUN, 2003) ... 29
Figura 5 Diagrama de classe Value Object Assembler (SUN, 2003)... 30
Figura 6 Diagrama de classe da estratégia Composity Entity implementado com Objeto de Granulação Grossa (SUN, 2003) ... 32
Figura 7 Diagrama de classe Composite Entity Implements Object Coarse-Grained (SUN, 2003)... 33
Figura 8 Aplicação desenvolvida totalmente (SILVA, 2000) ... 35
Figura 9 Aplicação desenvolvida reutilizando classes de biblioteca (SILVA, 2000) ... 35
Figura 10 Aplicação desenvolvida reutilizando um framework (SILVA, 2000) ... 36
Figura 11 Framework Caixa Branca (MALDONADO et. al) ... 38
Figura 12 Framework Caixa Preta (MALDONADO et. al) ... 38
Figura 13 Transações e execução de programa (DATE, 1988) ... 41
Figura 14 Diagrama das classes que devem ser herdadas ... 48
Figura 15 Esquema XML para o arquivo de configuração... 49
Figura 16 Diagrama de classes para o esquema do arquivo de configuração... 50
Figura 17 Principais classes do framework... 52
Figura 18 Diagrama de seqüência para verificar ValueObject ... 54
Figura 19 Diagrama de seqüência para verificar um CompositeEntity ... 55
Figura 20 Diagrama de seqüência para o incremento da versão do objeto de negócio . 55 Figura 21 Diagrama de classes de objetos de negócio... 56
Resumo
A demanda por aplicações voltadas para a web está crescendo notoriamente. Parte deste crescimento é devido à flexibilidade para atualizações e à facilidade de disponibilizar informações. Entretanto, aplicações deste tipo necessitam de controles adicionais quando comparadas a aplicações cliente-servidor. Neste sentido, este projeto foi desenvolvido na área de aplicações distribuídas, fundamentada na plataforma J2EE. O propósito deste trabalho é suprir uma deficiência de aplicações inseridas neste contexto.
Em aplicativos que possuem vários usuários realizando tarefas simultâneas, é necessário que seja permitido o compartilhamento e a manipulação de informações comuns. Considerando que existe uma camada de persistência de dados (EJB), as alterações são armazenadas de modo assíncrono. Em função disso, algumas informações desatualizadas podem ser salvas, gerando uma inconsistência das informações. Sendo assim, este projeto procura contribuir com uma proposta de framework para o controle de concorrência, tanto para objetos de granulação fina quanto de granulação grossa.
Inicialmente, é feita uma contextualização do tema tratado. Após esta breve introdução, é apresentada uma revisão bibliográfica sobre as tecnologias envolvidas e sobre o problema principal. Em seguida, é apresentada uma proposta de tratamento do controle de concorrência utilizando objetos de valor. Ao final, são apresentados os resultados obtidos e as conclusões são discutidas.
Palavras-chave: Controle de Concorrência, Aplicação Distribuída, Padrão de Projeto, Framework, J2EE.
Abstract
The demand for applications directed toward web is growing notoriously. Part of this growth is due to flexibility for updates and to the easiness to dispose information. However, applications of this type need additional controls when compared to the client-server applications. In this direction, this project was developed in the area of distributed applications, based on J2EE platform. The intention of this work is to supply a deficiency of applications in this context.
In applications with simultaneously tasks and some users carrying through, it is necessary that it is allowed to the sharing and the manipulation of common information. Considering that a layer of persistence of data exists (EJB), the alterations are stored in asynchronous way. In function of this, some outdated information can be stored, generating an inconsistency of the information. In this way, this project try to contribute with a proposal of framework for the concurrency control, to both fine and thick granularity objects.
Initially, an overview of the treat subject is made. After that, it is presented a proposal of treatment of the concurrency control having used value objects. In the end, the gotten results are presented and the conclusions are argued.
Key-words: Control of Concurrency, Distributed Applications, Design Patterns, Framework, J2EE.
1.
Introdução
Ao longo dos anos, o processo de desenvolvimento de sistemas tem mudado constantemente, elevando significativamente a maturidade desta área.
O avanço tecnológico, munido à informatização cada vez maior de empresas de várias áreas, impulsionou a automatização da maior parte dos processos passíveis de serem submetidos a um computador. A informatização de empresas passou a se tornar fundamental para a alta competitividade exigida pelo mercado.
A tecnologia de interconexão entre computadores evoluiu, permitindo o compartilhamento de dados entre terminais. Usuários precisavam ter acesso aos sistemas em locais diferentes. O processamento centralizado das informações em grandes terminais, além de caro, se tornou ineficiente para as novas exigências do mercado. Era preciso criar um novo paradigma de desenvolvimento de sistemas. Surge então o modelo cliente/servidor, onde vários usuários compartilham informações cujo processamento é centralizado em um terminal.
Na década de 90, a Internet atrai a atenção de todos os setores, com a promessa de sistemas revolucionários, de acesso e processamento de informações de qualquer lugar do planeta. Os sistemas passaram a ser desenvolvidos em plataformas distribuídas e orientados a transações, usufruindo das vantagens da velocidade, segurança e confiabilidade da tecnologia do lado servidor. Porém, os clientes já estavam acostumados a interfaces amigáveis com um bom tempo de resposta dos sistemas atuais. Era necessário construí-los com as mesmas funcionalidades e praticidade de seus concorrentes, para tomar uma posição de maior credibilidade no mercado.
Novas tecnologias surgiram para reduzir os custos e acelerar o desenvolvimento, dentre elas a Java 2 Plataform, Entreprise Edition (J2EE) (Sun, 2003), que oferece um modelo de aplicação distribuída multicamada baseada em componentes, com a capacidade de reutilização de componentes, troca de dados integrada baseada na Extensible Markup Language (XML) (W3C, 2003), um modelo de segurança unificado e um flexível controle de transações.
As informações de uma aplicação empresarial são armazenadas em uma ou mais bases de dados. A integridade dos dados seria afetada se múltiplos programas pudessem atualizar os dados simultaneamente. Uma falha de sistema durante o processamento de
uma transação causaria um afeto parcial dos dados, gerando problemas de consistência. As transações de software devem ser precisas, atuais e confiáveis. Deve prover o controle de acesso concorrente aos dados por múltiplos programas, e em caso de falha do sistema, devem certificar que, após a recuperação, os dados estarão em um estado consistente.
Em sistemas distribuídos, este cenário é comum. Múltiplos usuários podem visualizar os mesmos dados em terminais diferentes. Quando dois usuários, A e B, visualizam o mesmo registro em terminais separados, e o usuário A altera o registro, o usuário B não tomará conhecimento da atualização, a menos que recupere novamente o dado da base. Conseqüentemente, se o usuário B alterar o registro, estará alterando um registro desatualizado, pois há uma nova versão armazenada na base de dados pelo usuário A. Já existem padrões de projetos para implementar uma solução para isso, e alguns servidores de aplicação já disponibilizam este recurso. A complexidade aumenta quando as informações visualizadas são compostas por mais registros. O usuário pode estar visualizando os dados pessoais de uma pessoa cadastrada no sistema, e seu endereço, que estão armazenados em tabelas diferentes de uma base de dados. Mesmo com o controle de versão do registro, não será possível detectar uma alteração dos dados do endereço feitas por outro usuário.
Programas desenvolvidos em arquitetura distribuída multicamada requerem um dispositivo que permita fazer o controle de versão dos dados manipulados pelas operações de negócio da aplicação, a fim de garantir a consistência destas informações. Isto pode ser feito com o uso de um framework que permita gerenciar as transações do software, e detectar quando um dado desatualizado estiver sendo alterado, possibilitando a emissão de mensagens de alerta ao usuário.
1.1.
Objetivos
1.1.1
Objetivo Geral
Este trabalho objetiva a definição e implementação de um framework que permita fazer o controle de versão de registros em aplicações desenvolvidas em plataforma distribuída e multicamada J2EE.
1.1.2
Objetivos Específicos
Estudar a arquitetura J2EE.
Estudar padrões de projeto para controle de transações. Estudar frameworks.
Avaliar soluções para controle de transações. Propor uma solução de controle de transações. Modelar e implementar o protótipo.
Avaliar o ambiente em modo controlado.
1.2.
Justificativa
O problema com o controle de versão de registros é inerente em todas as aplicações desenvolvidas em ambientes distribuídos com vários usuários interagindo com o sistema, e tendo acesso simultâneo de dados compartilhados. Equipes de desenvolvimento gastam muito tempo desenvolvendo soluções para esses problemas. Isto envolve aumento de custo do software em função da mão-de-obra, além de tomar muito tempo para gerar a solução, que muitas vezes não é robusta.
Já existem alguns padrões de desenvolvimento que possibilitam resolver esse tipo de problema, e alguns servidores de aplicação J2EE até já implementa estas soluções. Porém, estas soluções se aplicam apenas a entidades de granulação fina. O problema tende a se agravar quando se trabalha com objetos compostos, de granulação grossa. Neste caso, a verificação do estado dos objetos deve ser feita em profundidade, e não tratando apenas um objeto simples.
A proposta deste projeto é abordar os componentes envolvidos neste cenário, e modelar uma solução para ser aplicada em sistemas inseridos neste contexto. Trata-se de um framework para gerência de controle de persistência de objetos compartilhados em ambiente distribuído, com a finalidade de garantir a consistência dos dados.
Um padrão bem definido para controle de concorrência aumenta a confiabilidade e robustez de um sistema. Além disso, reduz os gastos adicionias com o desenvolvimento desta solução, e a equipe de desenvolvimento pode focar sua maior atenção na lógica de negocio, deixando a verificação do estado dos componentes para este dispositivo.
1.3.
Estrutura do Trabalho
Este trabalho está estruturado em seis capítulos. Este primeiro capítulo procura contextualizar o tema principal dentro da abrangente área de desenvolvimento baseado em componentes e das plataformas distribuídas.
O capítulo 2 trata especificamente da arquitetura J2EE, descrevendo os principais pontos desta tecnologia e como estes recursos podem ser utilizados para resolverem problemas comuns, como o que está sendo tratado neste projeto.
O capítulo 3 fala de padrões de projeto e frameworks. Como a plataforma J2EE tem um vasto campo de recursos, o que pode gerar muitas soluções para um mesmo problema, podendo induzir o analista de programação ao erro. Desta forma, é fundamental o estudo de padrões já criados por profissionais mais experientes que atuam com esta tecnologia. Alguns dos principais padrões de projeto criados são discutidos neste capítulo, focando sempre sua funcionalidade no escopo deste projeto.
O capítulo 4 aborda transações, que pode ser tomado como uma unidade de trabalho, onde ocorrem várias ações que podem resultar em alterações de dados. Neste capítulo é feito um paralelo entre transações de bancos de dados e transações com a tecnologia Enterprise JavaBeans (EJB).
No capitulo 5 é apresentado o modelo e a implementação de um framework para o tratamento do problema de concorrência entre objetos compostos.
O capítulo 6 contém as considerações finais, onde são apresentadas as dificuldades encontradas no desenvolvimento do projeto, a conclusão e possíveis trabalhos futuros para o melhoramento do framework.
2.
A Arquitetura J2EE
2.1.
Introdução
A arquitetura Java 2 Platform, Enterprise Edition (J2EE) (Sun, 2003) compõe um conjunto de especificações baseadas em componentes para implementação de software em várias camadas (BROEMMER, 2003). Trata-se de um modelo baseado em componentes desenvolvidos segundo definições bem formadas para maximizar o reuso e produtividade de programadores e permitir a compatibilidade entre servidores (SINGH e STEARNS, 2002). Este modelo de aplicação multicamada objetiva padronizar e simplificar o desenvolvimento em sistemas distribuídos (BODOFF et al, 2002).
A plataforma J2EE é baseada na Java 2 Platform, Standard Edition (J2SE) (Sun, 2003). Ela fornece os principais APIs (Application Programing Interface) para escrever componentes J2EE, ferramentas de desenvolvimento importantes e a máquina virtual Java. O J2EE SDK contém um conjunto de APIs para serem usados nas aplicações J2EE (BODOFF et al, 2002).
Na seqüência é feito uma breve descrição sobre cada uma das principais APIs da plataforma J2EE.
Enterprise JavaBeans (EJB) (SUN, 2003) é uma tecnologia para desenvolver componentes contendo a lógica de negócio de uma aplicação que será executada do lado servidor. Existem três tipos de enterprise beans: beans de sessão (session beans), beans de entidade (entity beans) e beans orientados a mensagem (message-driven beans). Enterprise beans freqüentemente interagem com banco de dados, abstraindo o código Structured Query Language (SQL) do programador. Os componentes são hospedados em um contêiner EJB. A comunicação com o banco pode ser gerenciada pelo contêiner ou pode ser feita por um bean de sessão através do API JDBC.
A API Java Database Connectivity (JDBC) permite executar comandos SQL a partir de métodos de linguagem de programação Java. Quando a persistência dos dados não é gerenciada pelo contêiner, a API JDBC é utilizada para executar os comando SQL no banco de dados. Ela possui duas partes: uma interface em nível de aplicação usada
pelos componentes da aplicação para acessar um banco de dados e uma interface provedora de serviço para anexar um driver JDBC à plataforma J2EE.
Servlet é um componente que estende a funcionalidade de um servidor web de uma forma portável e eficiente. Um servidor web hospeda classes de Servlets que são executadas por um contêiner Servlet. O servidor web mapeia as requisições HTTP (Hiper Text Markup Language) (W3C, 2003) para um servlet. Quando um servlet recebe uma requisição de um cliente, pode fazer um processamento local ou delegar uma função para outros componentes, e emitir uma resposta para o cliente.
A tecnologia Java Server Pages (JSP) permite gerar conteúdo dinâmico para clientes web. Uma página JSP é um documento texto que descreve como processar uma requisição e gerar uma resposta (SINGH e STEARNS, 2002). Uma página JSP pode ser dividida em duas partes: dados estáticos, que podem ser expressos em qualquer formato baseado em texto como HTML, WML e XML, e elementos JSP, que determinam como a página constrói o conteúdo dinâmico (BODOFF et al, 2002).
O Java Message Service (JMS) (SUN, 2003) é um sistema de mensagens padrão que permite que os componentes da aplicação J2EE criem, enviem, recebam e leiam mensagens. Isso permite a comunicação distribuída que é livremente mantida, confiável e assíncrona.
A Java Naming and Directory Interface (JNDI) (SUN, 2003) é uma interface unificada para acessar diferentes tipos de serviços de nome e diretório. A JNDI é utilizada para registrar e consultar componentes de negócios e outros objetos orientados a serviço em um ambiente J2EE. Ele inclui suporte para Lightweight Directory Access Protocol (LDAP), para CORBA Object Services (COS), serviço de nome e o Java RMI Registry (BODOFF et. al, 2002) (SUN, 2003). Isso permite que as aplicações J2EE coexistam com aplicações e sistemas legados.
A Java Transaction API (JTA) (SUN, 2003) proporciona uma interface padrão para demarcar as transações. A arquitetura J2EE proporciona uma confirmação automática padrão para tratar as confirmações (commit1) e rollbacks2 das transações. Uma confirmação automática significa que qualquer outra aplicação que visualiza dados verá os dados atualizados depois de cada operação de leitura ou gravação no banco de dados. Entretanto, se sua aplicação executa duas operações de acesso a banco de dados
1
Commit comando executado ao término de uma transação bem sucedida. Armazena as alterações feitas pela transação.
2
Rollback - comando executado quando ocorrer uma falha da transação. Desfaz todas as alterações da transação.
separadas e dependentes entre si, você desejará usar o API JTA para demarcar onde a transação inteira, inclusive as duas operações, começa, desfaz e confirma.
As aplicações J2EE podem usar a JavaMail API para enviar notificações de correio eletrônico. O API JavaMail tem duas partes: uma interface em nível de aplicação usada pelos componentes da aplicação para enviar mensagens de correio e uma interface de provedor de serviços.
A JavaBeans Activation Framework (JAF) está incluído porque é usado pelo JavaMail. Ele proporciona serviços padrão para determinar o tipo de uma parte arbitrária de dados, encapsular o acesso a ela, descobrir as operações disponíveis para ela e criar o componente JavaBeans apropriado para executar essas operações (BODOFF et. al, 2002). Extensible Markup Language (XML) é uma linguagem para representar dados baseados em texto para que os dados possam ser lidos e tratados por qualquer programa ou ferramenta (W3C, 2003). Os programas e ferramentas podem gerar documentos XML que outros programas de ferramentas podem ler e tratar. A Java API for XML Processing (JAXP) fornece suporte ao processamento de documentos XML usando Document Object Model (DOM), Simple API for XML (SAX) e Extensible Styleshet Language Transformations (XSLT) (SUN, 2003) (W3C, 2003). O JAXP permite que as aplicações analisem e transformem documentos XML independente de uma implementação de processamento XML específica. Uma aplicação J2EE pode usar XML para produzir relatórios e as diferentes empresas que recebem esses relatórios podem tratar os dados da maneira mais adequada às suas necessidades. Uma empresa poderia processar os dados XML em um programa para converter o XML em HTML de forma a publicar os relatórios na web, outra poderia processar os dados XML em uma ferramenta para criar uma apresentação de marketing e, ainda, outra empresa poderia ler os dados XML para processá-los em uma aplicação J2EE.
A arquitetura J2EE também provê conectores. Um conector J2EE é usado por fornecedores de ferramentas e integradores de sistema J2EE para criar adaptadores de recursos que suportam acesso a componentes da camada EIS que possam estar conectados a qualquer produto J2EE. Um adaptador de recursos é um componente de software que permite que componentes da aplicação acessem e interajam com o gerente de recursos subjacente. Como um adaptador de recursos é específico para seu gerente de recursos, normalmente há um adaptador de recursos diferente para cada tipo de banco de dados ou EIS.
2.2.
Tecnologia de Componentes
Um componente é uma unidade de software em uma camada da aplicação. Juntamente com componentes JavaBeans, que fazem parte da plataforma J2SE, a plataforma J2EE especifica os seguintes componentes (SINGH, e STEARNS e JOHNSON, 2002):
Clientes da aplicação e applets são componentes que são executados no cliente. Componentes da tecnologia Java Servlet e JavaServer Pages (JSP) são componentes Web que são executados no servidor.
Componentes Enterprise JavaBeans (EJB) são componentes de negócios que são executados no servidor.
Todos os componentes J2EE, em tempo de execução, dependem de uma entidade chamada do contêiner. Os contêineres permitem o gerenciamento do ciclo de vida dos componentes, segurança, publicação e controle de concorrência. A arquitetura J2EE é composta das seguintes camadas:(ALUR e CRUPI e MALKS, 2002)
Cliente A camada do cliente interage com o usuário e exibe as informações do sistema para o usuário. A plataforma J2EE suporta diferentes tipos de clientes, incluindo clientes HTML, applets Java e aplicações Java.
Web A camada da Web gerra uma lógica de apresentação e aceita as respostas
do usuário a partir dos clientes da apresentação, que são a partir dos clientes da apresentação, que são normalmente clientes HTML, Applets Java e outros clientes da Web. Baseada na solicitação recebida do cliente, a camada de apresentação gera a resposta apropriada para uma solicitação recebida do cliente. Na plataforma J2EE, os servlets e JSPs em um contêiner da Web implementam essa camada. Negócios Essa camada trata da principal lógica de negócios da aplicação. Ela fornece as interfaces necessárias aos componentes de serviços de negócios subjacentes. Os componentes de negócios são, normalmente, implementados como componentes EJB com suporte a partir de um contêiner EJB, facilitando o
ciclo de vida do componente e gerência à persistência, as transações e a alocação de recursos.
EIS (Enterprise Information Systems) Esta camada é responsável pelo sistema de informações da empresa, incluindo os sistemas de banco de dados, o de processamento de transação, os sistemas legados e os sistemas de planejamento de recurso da empresa. A camada EIS é o ponto onde as aplicações J2EE se integram com os sistemas que não são J2EE e sistemas legados.
A figura 1 mostra como as camadas e contêineres são organizados na arquitetura J2EE.
Figura 1 Arquitetura J2EE básica (SUN, 2003)
2.2.1
Tipos de Clientes
A plataforma J2EE disponibiliza diferentes clientes para fazer a comunicação com os componentes do lado servidor.
Um cliente Web consiste em duas partes: páginas Web dinâmicas contendo vários tipos de linguagem de marcação (HTML, XML e assim por diante) que são geradas por componentes Web executando na camada da Web, e um navegador Web que apresenta as páginas recebidas do servidor (BODOFF et
Camada EIS Aplicações Base de dados
Camada cliente Navegador web, applet, web service B2B Aplicação cliente
Camada de negócio Entity Bean Conector J2EE Session Bean Contêiner Web Contêiner EJB Servlet JSP
al, 2002). Algumas vezes também é denominado cliente magro. Clientes magros normalmente não realizam atividades como consultar banco de dados, executar complexos papéis de negócios ou conectar-se a aplicações legadas. Nesta situação é comum as operações de consulta e lógica de negócio serem executadas no servidor J2EE, onde podem tirar vantagem da segurança, velocidade e confiabilidade das tecnologias do servidor.
Um applet é uma pequena aplicação cliente escrita em linguagem de programação Java que é executada em uma máquina Java virtual instalada no navegador Web. Entretanto, os sistemas cliente irão provavelmente precisar do Java Plug-in e possivelmente de um arquivo de políticas de segurança para que o applet possa ser executado com sucesso no navegador Web.
Um cliente da aplicação J2EE é executado em uma máquina cliente e proporciona uma maneira dos usuários tratarem as tarefas que exijam uma interface com o usuário mais elaborada do que a que pode ser fornecida por uma linguagem de marcação. Normalmente há uma interface gráfica com o usuário criada a partir dos APIs Swing ou Abstract Window Toolkit (AWT), mas uma interface de linha de comandos certamente é possível.
A figura 1 mostra os vários elementos que podem compor a camada do cliente. O cliente se comunica com a camada de negócios que está sendo executada no servidor J2EE diretamente ou, como no caso de um cliente executando em um navegador, através de páginas JSP ou servlets executando na camada da Web.
Um componente web é uma entidade de software que provê uma resposta para uma requisição (SINGH e STEARNS, 2002). Os componentes J2EE da Web podem ser servlets ou páginas JSP. Os servlets são classes da linguagem de programação Java que processam dinamicamente solicitações e constroem respostas. As páginas JSP são documentos baseados em texto que são executados como servlets, mas permitem um enfoque mais natural para criar conteúdo estático.
Estes componentes são hospedados por contêineres de servlet, JSP e contêineres Web. Estes contêineres, também chamados de contêineres web, são responsáveis pelo processamento das requisições executadas a partir de um cliente remoto. O contêiner servlet disponibiliza os serviços de rede, nos quais requisições e respostas são enviadas. É necessário que suporte a comunicação com o protocolo HTTP, e também pode suportar
outros como HTTPS. O contêiner JSP provê os mesmos serviços que um contêiner servlet.
2.3.
Contêineres J2EE
As aplicações multicamada de cliente magro são difíceis de serem escritas, pois envolvem muitas linhas de código complicado para tratar transação e gerenciamento de estado, multiencadeamento, pool de recursos e outros detalhes complexos de nível baixo. O servidor J2EE fornece serviços subjacentes na forma de um contêiner para todo tipo de componente (BODOFF et al, 2002).
Os contêineres são a interface entre um componente e a funcionalidade específica da plataforma de nível baixo que dá suporte ao componente. Antes que um componente Web, enterprise bean ou cliente da aplicação possa ser executado, ele deve ser montado em uma aplicação J2EE e implantado no seu contêiner.
O contêiner também gerencia serviços não-configuráveis como ciclos de vida do enterprise bean e do servlet, pool de recursos de conexão de banco de dados, persistência de dados e acesso às APIs da plataforma J2EE. A arquitetura J2EE permite também cancelar a persistência de dados gerenciada por contêiner (container-managed) incluindo o código apropriado na implementação do enterprise bean.
A arquitetura J2EE oferece dois tipos de contêineres: Web e EJB.
Contêiner Web gerencia a execução dos componentes da página JSP e do servlet para aplicações J2EE.
Contêiner EJB gerencia a execução de enterprise beans para aplicações J2EE.
2.4.
Servlets e JSP
Quando um cliente web se comunica com uma aplicação J2EE, ele o faz através de objetos do lado servidor denominados componentes web. Existem dois tipos de componentes Web: Java Servlets e páginas JavaServer Pages (JSP).
2.4.1
Servlets
Devido à importância da geração de conteúdo dinâmico para o desenvolvimento da web, foi natural que a Sun propusesse extensões para Java em seu domínio. Da mesma forma que a Sun introduziu applets como pequenas aplicações baseadas em Java para adicionar funcionalidade interativa aos navegadores da web, em 1996 a Sun introduziu servlets como pequenas aplicações baseadas em Java para adicionar funcionalidade dinâmica a servidores da web. Os servlets de Java têm um modelo de programação similar aos scripts de CGI3, na medida em que eles recebem uma solicitação de HTTP de um navegador da web como input e espera-se que localizem e/ou construam o conteúdo apropriado para a resposta do servidor (FIELDS e KOLB, 2000).
Diferentemente dos programas tradicionais baseados em CGI que necessitam da criação de um novo processo para tratar de cada nova solicitação, todos os servlets associados com um servidor da web rodam dentro de um único processo. Este processo roda uma Java Virtual Machine (JVM), que é o programa específico de plataforma para rodar programas de Java compilados (compatível com várias plataformas). Ao invés de criar um novo processo a cada solicitação, a JVM cria um encadeamento de Java para tratar de cada solicitação de servlet.
Em essência, servlets fornecem uma metodologia baseada em Java para mapear solicitações de HTTP em respostas HTTP. A geração de conteúdo da web dinâmico usando-se servlets é, então, realizada através de código Java que fornece a HTML (ou outros dados) representando aquele conteúdo. No caso dos dados de HTML, uma abordagem é fazer com que o código de Java construa cadeias contendo o texto de marcação apropriado e depois imprima estas cadeias no fluxo de saída associado com a resposta de HTML. Isto é, freqüentemente, chamado de abordagem out.println , porque uma parte significativa do código resultante consiste de linhas que começam com esta seqüência de caracteres (ou uma seqüência bem similar).
Um servlet é uma classe da linguagem de programação Java usada para estender as capacidades dos servidores que hospedam aplicações acessadas via um modelo de programação do tipo solicitação, eles são mais usados para estender as aplicações
3
Common Gateway Interface primeiro padrão para conteúdo da web dinâmico que especifica um mecanismo para servidores da web passarem as informações da solicitação para programas externos, que eram então, rodados pelo servidor da web para gerar respostas no tempo de execução.
hospedadas em servidores Web. Para tais aplicações, a tecnologia Java Servlet define classes servlet específicas para http (BODOFF et al, 2002).
2.4.2
JavaServer Pages
Uma página JSP é um documento baseado em texto que podem ser expressos em qualquer formato baseado em texto, como HTML, SVG (Scalable Vector Graphics), WML (Website Meta Language) e XML; e elementos JSP, que constroem conteúdo dinâmico. Ela atende às solicitações como um servlet. Assim, o ciclo de vida e a maioria dos recursos das páginas JSP (particularmente os aspectos dinâmicos) são determinados pela tecnologia Java Servlet (W3C, 2003) (WML, 2003).
Quando uma solicitação é mapeada para uma página JSP, ela é tratada por um servlet especial que primeiro verifica se o servlet da página JSP é mais antigo do que a página JSP. Se for, ela traduz a página JSP para uma classe de servlet e compila a classe. Durante o desenvolvimento, uma das vantagens das páginas JSP sobre os servlets é que o processo de construção é executado automaticamente (BODOFF et al, 2002).
2.5.
Enterprise JavaBeans
A tecnologia Enterprise JavaBeans (EJB) é uma arquitetura de componente para publicar os componentes no lado servidor. Trata-se de uma padronização entre componentes e servidores de aplicação que permitem a qualquer componente rodar em qualquer servidor de aplicação. Componentes EJB, ou enterprise beans, são instalados, e podem ser importados e carregados em outros servidores de aplicação, que hospedam estes componentes (ROMAN e AMBLER e JEWELL, 2002).
Em uma aplicação multicamada J2EE, a lógica de negócio pode ser implementada na camada de negócio EJB, em componentes entreprise beans. Esta camada dispõe de serviços de gerenciamento de transações, controle de concorrência e segurança. Isso proporciona que o desenvolvedor foque sua atenção na lógica de negócio do sistema, abstraindo estes serviços.
EJB define três tipos de enterprise beans:
Session beans. Modela processos de negócio, executam ações. Uma ação pode ser qualquer coisa, como a adição de números, acesso à base de dados, chamadas a sistemas legados ou a outro enterprise beans.
Entity beans. Representa a visão de um objeto de uma entidade que está armazenada em um meio persistente, como base de dados. Em contraste com session beans, uma entity bean tem um identificador único definido como chave primária.
Message-driven beans. São componentes que processam mensagens assíncronas liberadas via Java Message Service (JMS) API.
Enterprise beans são hospedadas em um contêiner EJB, que gerencia seu ciclo de vida, transações, segurança, persistência, e muitos outros serviços. Quando um cliente invoca uma operação de um enterprise bean, a chamada é interceptada pelo contêiner. Por interposição entre clientes e componentes em nível de chamada de método, o contêiner pode executar serviços que se propagam através de chamadas e componentes, e ainda através de contêineres que estão rodando em outros servidores e outras máquinas (SINGH e STEARNS e JOHNSON, 2002).
2.5.1
Session Beans
Um session bean (bean de sessão) representa um único cliente dentro do servidor J2EE. Para acessar uma aplicação que está implementada no servidor, o cliente chama os métodos do bean de sessão. O bean de sessão executa o trabalho para seu cliente, protegendo-o da complexidade executando as tarefas de negócios no servidor.
Da mesma maneira que uma sessão interativa pode ter apenas um cliente, o bean de sessão não pode ser compartilhado, e também não é persistente, ou seja, seus dados não são armazenados em um meio secundário de armazenamento.
Há dois tipos de bean de sessão: com informações de estado (stateful) e sem informações de estado (stateless).
Session Bean Stateful. O estado de um objeto consiste em valores de suas variáveis de instância. Em um bean de sessão com informações de estado, as variáveis de instância representam o estado de uma única sessão cliente-bean.
Como o cliente interage com seu bean, seu estado é freqüentemente denominado estado conversacional. O estado é mantido enquanto durar a sessão cliente-bean. Se o cliente remover o bean ou terminar, a sessão é concluída e o estado desaparece. Entretanto, essa natureza transiente do estado não constitui um problema porque quando a conversação entre o cliente e o bean termina não há necessidade de manter o estado.
Session Bean Stateless. Um bean de sessão sem informações de estado não mantém um estado conversacional para um cliente específico. Quando um cliente chama o método de um bean sem informações de estado, as variáveis de instância do bean podem conter um estado, mas apenas enquanto durar a chamada. Quando o método é concluído, o estado não é mais mantido. Exceto durante a chamada do método, todas as instâncias de um bean sem informações de estado são equivalentes, permitindo que o contêiner EJB atribua uma instância a qualquer cliente.
Às vezes, o contêiner EJB pode gravar um bean de sessão com informações de estado em um armazenamento secundário. Entretanto, os beans de sessão sem informações de estado nunca são gravados em armazenamento secundário. Portanto, os beans sem informações de estado podem oferecer melhor desempenho do que os beans com informações de estado.
2.5.2
Entity Beans
Um dos principais benefícios da tecnologia EJB é a característica de permitir a criação de entity beans (beans de entidade). Entity beans são objetos persistentes que podem ser armazenados permanentemente em meios secundários. Isso permite que os fundamentos da lógica de negócio possam ser modelados com a demarcação de dados como beans de entidade (ROMAM e AMBLER e JEWELL, 2002).
Os beans de entidade diferem dos beans de sessão de várias maneiras. Os beans de entidade são persistentes, permitem acesso compartilhado, têm chaves primárias e podem participar de relacionamentos com outros beans de entidade.
O estado de um bean de entidade é salvo em um mecanismo de armazenamento, logo ele é persistente. Persistência significa que o estado do bean existe além da existência da aplicação ou de um processo do servidor J2EE. Um mecanismo de
persistência utilizado com muita freqüência é o banco de dados. A persistência de um bean de entidade pode ser gerenciada por bean (bean-managed persistence BMP), ou
por contêiner (container-managed persistence CMP). Em entidades BMP o
programador escreve os códigos de acesso a banco de dados, já entidades CMP tem todas os serviços gerenciados pelo contêiner EJB, como transações e controle de concorrência.
Um bean de entidade pode ser compartilhado entre vários clientes. Em função disso, é importante que o bean seja acessado dentro de uma transação, a fim de garantir sua consistência. Todo bean de entidade tem um identificador único, ou chave primária (primary key). Isso permite que o cliente localize um bean de entidade específico.
Como tabelas em banco de dados, um bean de entidade pode ser relacionado a outros beans de entidade. A implementação do relacionamento difere entre bean de entidade BMP e CMP. Em BMP o relacionamento é implementado diretamente no código. Já entidades CMP têm seus relacionamentos gerenciados pelo contêiner EJB.
O termo persistência gerenciada por contêiner (container-managed persistence) significa que o contêiner EJB manipula todos os acessos a banco de dados requeridos pelo bean de entidade. O código do bean não contém nenhuma chamada de acesso a banco de dados (SQL). Como resultado, o código do bean não está vinculado a um mecanismo de armazenamento persistente (banco de dados). Por causa dessa flexibilidade, mesmo se você reimplantar o mesmo bean de entidade em diferentes servidores J2EE que usam diferentes bancos de dados, não será necessário modificar ou recompilar o código do bean. Resumindo, seus beans de entidade são mais portáveis (BODOFF et al, 2002).
2.5.3
Message-Driven Beans
Message-Driven Beans (bean orientado a mensagem) é um enterprise bean que permite a aplicações J2EE receber mensagens JMS assincronamente4.
A diferença mais visível entre os beans orientados a mensagens e os beans de sessão e de entidade é que os clientes não podem acessar os beans orientados a mensagens por meio de interfaces. Ao contrário de um bean de sessão ou de entidade, um bean orientado a mensagens tem apenas uma classe de bean.
4
Mensagens assíncronas a comunicação de aplicações e componentes com outras aplicações e
componentes, através de troca de mensagens, onde o receptor independe do remetente. O remetente envia a mensagem e não precisa aguardar que o receptor receba ou processe a mensagem.
Beans orientados a mensagens são componentes que recebem mensagens internas de um provedor JMS. A responsabilidade primária de um bean orientado a mensagens é processar mensagens, porque o contêiner do bean gerencia outros aspectos do ambiente do bean orientado a mensagens. Beans orientados a mensagem contém lógica de negócio para manipular mensagens recebidas (ROMAM e AMBLER e JEWELL, 2002).
Em diversos aspectos, um bean orientado a mensagem se parece com um bean de sessão sem informações de estado:
As instâncias de um bean orientado a mensagens não mantêm nenhum dado ou estado conversacional para um cliente específico.
Todas as instâncias de um bean orientado a mensagens são equivalentes, permitindo que o contêiner EJB atribua uma mensagem a qualquer instância do bean. O contêiner pode colocar essas instâncias em pool para permitir que os fluxos de mensagens sejam processados concorrentemente.
Um único bean orientado a mensagem pode processar mensagens para múltiplos clientes.
As variáveis de instância da instância do bean orientado a mensagem podem conter alguns estados através do tratamento das mensagens do cliente por exemplo uma conexão de API JMS, uma conexão de banco de dados aberto ou uma referência de objeto a um objeto enterprise bean.
Quando uma mensagem chega, o contêiner chama o método onMessage do bean orientado a mensagem para processar a mensagem. O método normalmente transforma a mensagem em um dos cinco tipos de mensagens JMS e a trata de acordo com a lógica de negócios da aplicação. O método onMessage pode chamar os métodos auxiliares ou pode chamar um bean de sessão ou de entidade para processar as informações na mensagem ou armazená-las em um banco de dados.
Uma mensagem pode ser entregue a um bean orientado a mensagem dentro do contexto da transação, para que todas as operações no método onMessage façam parte de uma única transação. Se o processamento da mensagem for desfeito, a mensagem será novamente entregue.
O bean de sessão e de entidade permite enviar e receber mensagens JMS sincronamente, mas não assincronamente. Isso evita a obstrução dos recursos do servidor, descartando o uso de receptores síncronos de componentes do lado servidor (BODOFF et al, 2002).
2.6.
Conclusão
A arquitetura J2EE dispõe de um vasto arsenal de recursos para o desenvolvimento de sistemas, tanto para aplicativos simples quanto complexos sistemas distribuídos em várias camadas, e que precisam ter seus componentes distribuídos também fisicamente. São muitas as soluções que um analista pode encontrar, porém, isso pode induzi-lo ao erro, implantando uma modelagem com mau uso dos recursos. Padrões de projetos são fundamentais para sistemas desenvolvidos na plataforma J2EE, assim como de frameworks, que, além de nortear o desenvolvimento do sistema, também aceleram o processo.
Normalmente a manipulação de entidade do banco, como inserção, edição e remoção, é chamado através de um bean de sessão. Quando um usuário tenta salvar alterações de entidades, conseqüentemente a ação será executada através de um bean de sessão. Desta forma, um dispositivo que permite verificar se a entidade que está sendo salva está atualizada ou não deve ser inserido no bean de sessão, antes da ação ser executada. Caso a entidade não esteja atualizada com os dados do banco, uma exceção será disparada alertando o usuário, para que o mesmo atualize seus dados.
Alguns servidores de aplicação J2EE implementam uma solução para detectar entidades desatualizadas, porém, trata apenas de entidades simples. Ainda não há uma solução portável que trate também de objetos compostos. O propósito deste projeto é identificar dados desatualizados, tanto em entidades simples, referenciando apenas um registro, como para objetos compostos, com uma entidade referenciando outros objetos dependentes. A aplicação deste projeto permitirá fazer estas verificações e alertar o usuário, garantindo a consistência das informações.
3.
Padrões de Projeto e Frameworks
A compreensão de programas é um dos problemas mais críticos dentro do ciclo de vida de software. O sucesso de atividades tais como manutenção, depuração e reutilização dependem, em grande parte, da facilidade com a qual um programador possa compreender um dado programa. Este problema é ainda maior para o caso de programas orientados a objetos e, particularmente, frameworks. A dicotomia entre o modelo de execução e o modelo estático de hierarquias de classes, a distribuição de funcionalidade entre múltiplas classes, o acoplamento dinâmico e sua combinação com o polimorfismo, tornam os programas orientados a objetos difíceis de compreender (CAMPO et. al, 1997).
3.1.
Padrões de Projeto
Programadores freqüentemente empregam soluções que eles já utilizam antes em situações parecidas. Estas soluções envolvem o projeto de classes, redefinições de métodos, combinação de objetos, delegação de mensagens e assim por diante. Padrões de projeto nada mais são que documentação destas soluções. Os padrões de projeto aplicam-se a tudo, desde cidades, organizações, construções, até programas de computador. O estudo de padrões, sejam eles arquitetônicos ou relacionados à orientação de objetos, mostra como é possível reutilizar idéias anteriores em novos projetos (GUIMARÃES, 2000).
Em meados da década de 70, o arquiteto Christopher Alexander buscava reconhecer quando um projeto arquitetônico era bom e por quê. Através de observações, Alexander constatou que se a qualidade em um projeto é o objetivo, então seria possível quantificar o que torna um desenho bom ou ruim. Alexander descobriu que diminuindo o foco, ou seja, procurando estruturas que resolvam problemas similares, ele pode discernir similaridades entre projetos de alta qualidade. Ele chamou essas similaridades de padrões (SOUZA e MENEZES e TOGNERI, 2001).
Os padrões permaneceram esquecidos por um tempo, até que ressurgiram na conferência sobre programação orientada a objetos (OOPSLA) (BECK e CUNNINGHAM, 1987) de 1987, mais especificamente, no Workshop sobre
Especificação e Projeto para Programação Orientada a Objetos. Nesse trabalho, Beck e Cunningham falam sobre uma linguagem de padrões para projetar janelas em Smalltalk. A partir de então, muitos artigos, revistas e livros têm aparecido abordando padrões de software, que descrevem soluções para problemas que ocorrem freqüentemente no desenvolvimento de software e que podem ser reusadas por outros desenvolvedores (MALDONADO et. al).
Os padrões em software foram popularizados com o livro Design Patterns: Elements of Reusable Object-Oriented Software de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (GAMMA et. al, 1995), também conhecidos como Gang of Four ou GoF. Neste livro são descritos vinte e três padrões que podem ser utilizados em praticamente qualquer área de programação. Estes padrões se tornaram clássicos da orientação a objetos. Eles foram utilizados por muitos programadores muito antes do lançamento deste livro. Mas não tinham sido sistematicamente documentados e catalogados (GUIMARÃES, 2000).
Alexander define um padrão como a solução para um problema em um contexto (ALUR e CRUPI e MALKS, 2002).
Cada padrão descreve um problema no nosso ambiente e o núcleo da sua solução, de tal forma que você possa usar esta solução mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira .
- Christopher Alexander
Alexander amplia ainda mais sua definição e Richard Gabriel, conhecido por seu trabalho com padrões, discute essa definição com mais detalhes. Gabriel fornece sua própria versão da definição:
Cada padrão é uma regra de três partes, que expressa uma relação entre um certo contexto, um certo sistema de forças que ocorre repetidamente nesse contexto e uma certa configuração de software que permite que essas forças sejam resolvidas (Consulte a Timeless Way of Hacking).
Essa é uma definição razoavelmente rigorosa, mas também existem algumas mais flexíveis. Por exemplo, Martin Fowler oferece a seguinte definição em Analysis Patterns:
Um padrão é uma idéia que foi útil em um contexto prático e provavelmente será útil em outros .
- Martin Fowler
De acordo com as observações de Cristopher Alexander, um padrão é composto das seguintes partes (GAMMA, 1995):
O nome do padrão é uma referência que pode ser usada para descrever um problema de projeto, suas soluções e conseqüências em uma ou duas palavras. Dar nome a um padrão aumenta imediatamente o vocabulário de projeto. Isso permite projetar em um nível mais alto de abstração. Ter um vocabulário para padrões permite-nos conversar sobre eles com nossos colegas, em nossa documentação e até com nós mesmos. O nome torna mais fácil pensar sobre projetos e a comunicá-los, bem como os custos e benefícios envolvidos, a outras pessoas.
O problema descreve quando aplicar o padrão. Ele explica o problema e seu contexto. Pode descrever problemas de projetos específicos. Algumas vezes, o problema incluirá uma lista de condições que deve ser satisfeita para que faça sentido aplicar o padrão.
A solução descreve os elementos que compõem o projeto, seus relacionamentos, suas responsabilidades e colaborações. A solução não descreve um projeto concreto ou uma implementação em particular porque um padrão é como um gabarito que pode ser aplicado em muitas situações diferentes. Em vez disso, o padrão fornece uma descrição abstrata de um problema de projeto e de como um arranjo geral de elementos resolve o mesmo.
As conseqüências são os resultados e análises das vantagens e desvantagens da aplicação do padrão. Embora as conseqüências sejam raramente mencionadas quando se descreve decisões de projeto, elas são críticas para a avaliação de alternativas de projetos e para a compreensão dos custos e
benefícios da aplicação do padrão. As conseqüências para o software freqüentemente envolvem compromissos de espaço e tempo. Elas também podem abordar aspectos sobre linguagens e implementação.
Com esta visão, a definição e aplicação de um padrão de projeto se tornam mais fácil, assim como sua avaliação e aplicabilidade para o problema tratado neste projeto.
3.1.1
Classificação de Padrões
Os padrões representam soluções especiais para problemas recorrentes em um contexto e, dessa forma, foram capturados em muitos níveis de abstração e em inúmeros domínios (ALUR e CRUPI e MALKS, 2002). Padrões de projeto abrangem diferentes níveis de abstração, podendo portanto ser classificados em diversas categorias de modo a facilitar sua recuperação e uso. Porém, essa classificação não é rigorosa, podendo haver padrões que se encaixem em mais do que uma categoria. A seguir resumem-se algumas categorias importantes de padrões (MALDONADO et. al).
Padrões de processo: definem soluções para os problemas encontrados nos processos envolvidos na engenharia de software: desenvolvimento, controle de configuração, estes, etc.
Padrões arquiteturais: expressam o esquema ou organização estrutural fundamental de sistemas de software ou hardware.
Padrões de padrão (em inglês, patterns on patterns): são padrões descrevendo como um padrão deve ser escrito, ou seja, que padronizam a forma com que os padrões são apresentados aos seus usuários.
Padrões de análise: descrevem soluções para problemas de análise de sistemas, embutindo conhecimento sobre o domínio de aplicação específico.
Padrões de projeto: definem soluções para problemas de projeto de software. Padrões de interface: definem soluções para problemas comuns no projeto da interface de sistemas. É um caso particular dos padrões de projeto.
Padrões de programação: descrevem soluções de programação particulares de uma determinada linguagem ou regras gerais de estilo de programação.
Padrões de Persistência: descrevem soluções para problemas de armazenamento de informações em arquivos ou bancos de dados.
Padrões para Hipertexto: descrevem soluções para problemas encontrados no projeto de hipertextos.
Padrões para Hipermídia: descrevem soluções para problemas encontrados no desenvolvimento de aplicações hipermídia.
3.1.2
Anti-Padrões
Anti-padrões representam uma lição aprendida , ao contrário dos padrões, que representam a melhor prática (MALDONADO et. al). Os anti-padrões podem ser de dois tipos:
Aqueles que descrevem uma solução ruim para um problema que resultou em uma situação ruim
Aqueles que descrevem como escapar de uma situação ruim e como proceder para, a partir dela, atingir uma boa solução.
Os anti-padrões são necessários porque é tão importante ver e entender soluções ruins como soluções boas. Se por um lado é útil mostrar a presença de certos padrões em sistemas mal sucedidos, por outro lado é útil mostrar a ausência dos anti-padrões em sistemas bem sucedidos.
Segundo uma outra definição (XEXEO, 2000), um anti-padrão é:
um padrão que diz como ir de um problema para uma solução ruim ou um padrão que diz como ir de uma solução ruim para uma solução boa.
A primeira parece inútil, exceto se considerarmos o padrão como uma mensagem Não faça isso . O segundo é definitivamente um padrão positivo, no qual o problema é a solução ruim.
3.1.3
Padrões J2EE
Através de experiência coletiva de trabalho na plataforma J2EE com os clientes da Sun Java Center, alguns padrões foram criados para esta tecnologia, inicialmente com uma documentação informal, mas com o crescimento, surgiu a necessidade de uma documentação mais formal para capturar e comunicar esse conhecimento(ALUR e CRUPI e MALKS, 2002).
A arquitetura J2EE, por definição, já incorpora o padrão chamado MVC (Model View Controller), que define claramente uma separação entre camadas de visualização, controle e lógica de negócio. Desse modo, existe uma dependência das camadas superiores em relação às camadas inferiores, mas, as camadas inferiores não devem depender das superiores. Na figura 2 essa característica é transparente: a dependência desce e os dados sobem . Isso implica que se em alguma classe da camada Model houver um acesso a uma classe da camada Controller, o princípio da separação entre camadas será violado, dificultando a reutilização (GOMES, 2002).
Figura 2 Acoplamento entre camadas (GOMES, 2002)
Toda adoção de uma nova tecnologia pode colocar o programador e muitas armadilhas se não houver um estudo mais apurado da mesma. Nestas situações é bom ouvir a voz da experiência, de quem já conhece as armadilhas freqüentes e sabe como solucionar. Essas soluções são modeladas como padrões de projeto, que aumentam a
APRESENTAÇÃO CONTROLE PERSISTÊNCIA REDE NEGÓCIO Dependência Dados
qualidade do código, incrementa o desempenho da aplicação e provavelmente reduz o re-trabalho conseqüente de refactoring5 de projetos mal elaborados.
Os níveis de abstrações de padrões são enquadrados, basicamente, em três camadas na arquitetura J2EE (ALUR e CRUPI e MALKS, 2002):
Camada de apresentação: encapsula toda lógica de apresentação. Intercepta a requisição do cliente e direciona aos objetos de negócio. Após o processamento, retorna a resposta ao cliente.
Camada de negócio:contém a lógica do negócio, normalmente formada por Enterprise Beans.
Camada de integração: responsável pela comunicação com sistemas externos e principalmente acesso a dados, normalmente acoplada à camada de negócios.
Para a arquitetura J2EE, o gerenciamento de persistência é feito na camada de negócio. Esta camada encapsula vários padrões de projeto, que além de implementar a lógica de negócio, também permitem fazer o controle de concorrência entre clientes.
A figura 3 ilustra a estrutura de comunicação dos principais padrões criados para a plataforma J2EE (SUN, 2003).
Será feita apenas uma pequena abordagem dos principais padrões que serão utilizados neste trabalho. Esses padrões pertencem à camada de negócio.
3.1.3.1
Value Object
O Value Object, também conhecido como Detail Object, Data Transfer Object ou Replicate Object, é um dos mais importantes padrões desta arquitetura. As aplicações J2EE implementam componentes de negócios do lado servidor como beans de sessão e beans de entidade. Alguns métodos expostos pelos componentes de negócios retornam dados para o cliente. Freqüentemente, o cliente chama os métodos get de um objeto de negócios várias vezes até obter todos os valores dos atributos.
5
Refactoring é uma alteração do código com o propósito de melhorar a estrutura interna, sem afetar o ambiente externo.
Toda chamada de método feita para o objeto de serviço de negócios, seja ele um bean de entidade ou um bean de sessão, é potencialmente remota. Dessa maneira, em uma aplicação EJB tais chamadas remotas utilizam a camada de rede, independente da proximidade entre o cliente e o bean, criando uma sobrecarga na rede.
Para reduzir o número de chamadas remotas e evitar a sobrecarga de rede, os dados pode ser recuperados em uma única chamada que retorna um Value Object. Um Value Object encapsula os dados de negócio. Quando o cliente solicita ao enterprise bean os dados de negócios, o enterprise bean pode criar o objeto de dados, preenchê-lo com seus valores de atributos e passá-lo por valor para o cliente (ALUR e CRUPI e MALKS, 2002).
A figura 4 mostra um diagrama de classe que representa o padrão Value Object em sua forma mais simples. Como é mostrado nesse diagrama de classe, o objeto de dados é criado sob demanda pelo enterprise bean e retornado ao cliente remoto (SUN, 2003).
Figura 4 Diagrama de classe do padrão Value Object (SUN, 2003)
Adotar esta técnica pode acarretar em problemas de sincronização. Um cliente pode atualizar um objeto desatualizado. Uma maneira de solucionar este problema é adicionar ao Value Object um número de versão ou a data e hora da última modificação. Desta maneira, toda vez que os dados forem enviados a um serviço de negócios para serem salvos, antes é feito uma verificação para saber se os dados estão atualizados. A desatualização das informações resultará em um erro.
Porém, os clientes da aplicação freqüentemente precisam acessar dados que são compostos a partir de múltiplos objetos do modelo. O modelo da aplicação é uma abstração dos dados e da lógica de negócios implementada no servidor como componentes de negócios. Um modelo pode ser expresso como uma coleção de objetos reunidos de maneira estruturada (árvore ou gráfico). Em uma aplicação J2EE, o modelo é uma coleção distribuída de objetos como os beans de entidade, beans de sessão, e outros objetos. Para um cliente obter os dados do modelo, como os dados para exibir para o usuário ou para executar algum processamento, ele precisa acessar individualmente cada objeto distribuído que define o modelo.
Para o cliente acessar todos os objetos do modelo, e compor seu modelo de negócio, precisará executar múltiplos acessos remotos, degradando, assim, o desempenho da rede. Novamente a rede pode ser poupada através do uso de Value Object Assembler (ALUR e CRUPI e MALKS, 2002).
3.1.3.2
Value Object Assembler
O Value Object Assembler constrói um objeto de dados composto que representa os dados a partir de diferentes componentes de negócios. O objeto de dados carrega os dados do modelo para o cliente em uma única chamada de método. Visto que os dados do modelo podem ser complexos, é recomendável que esse objeto de dados seja imutável. Isto é, o cliente obtém esses objetos de dados com o único propósito de utilizá-los para apresentação e processamento em um modo somente leitura.
A figura 5 mostra o diagrama de classe representando os relacionamentos para o padrão Value Object Assembler (SUN, 2003).
