Engenharia de Componentes

2.7 Arquitetura Utilizada no Sistema Web.

Inicialmente a web era composta apenas por páginas estáticas, ou seja, não variava a cada solicitação conforme alguma mudança de parâmetros. Com o tempo, houve a necessidade de tornar o conteúdo das páginas dinâmico, que possibilitasse construir uma página conforme uma nova requisição, o que não era possível utilizando somente HTML (Hyper Text Markup Language). Para tanto o servidor web deveria processar os dados destas solicitações e retornar uma resposta personalizada. Surgiu então o CGI (Common Gateway Interface) (BRAZ, on-line).

O CGI possui limitações quanto a sua utilização em sistemas web de grande escala, pois a cada execução do programa um novo processo é criado, causando sobrecarga no servidor web. Ocorre também que os programas em CGI são capazes de tratar apenas uma solicitação, na qual um novo processo é criado, os dados são enviados, processados e a resposta é retornada para o navegador e o processo é finalizado. Com isso, não é possível o compartilhamento de recursos entre os CGIs. Este modelo apresenta problemas de performance se submetido a grande volume de acesso. Para amenizar estes problemas, foi adotado o uso de algumas linguagens de programação como o Perl, ASP, PHP, Java e etc.

Em Java, no ambiente JEE (Java Enterprise Edition), que é voltado para as aplicações web, encontra-se alternativas como Applets, Servlets, JSP (Java Server Pages), JSTL (Java Server Pages Standard Tag Library), EJB (Enterprise Java Beans), entre outros. Para facilitar o desenvolvimento das aplicações Java geralmente se faz o uso de design patterns também conhecido como padrões de projeto e algum framework, tais como o STRUS, JSF, Hibernate, entre outros.

2.7.1 Arquitetura Java EE e Design Patterns.

Um padrão de projeto é definido como uma solução desenvolvida utilizando boas práticas para um problema comum que ocorre várias vezes. Um padrão de projeto documenta e explana um problema importante que pode ocorrer no projeto ou implementação de uma aplicação e então discute a melhor solução prática para o problema (Marinescu, 2002).

Segundo a SUN, a plataforma J2EE (Java 2 Enterprise Edition) define um padrão para o desenvolvimento de aplicações multicamadas. Nesta arquitetura, a camada que contém as regras de negócio, normalmente implementada utilizando Enterprise JavaBeans, pode ficar concentrada no servidor de aplicações, sendo compartilhada com diversas aplicações clientes. As aplicações clientes não contêm a lógica do negócio, atendo-se somente à camada de apresentação. Na camada de apresentação normalmente são utilizadas as tecnologias de Servlets e JavaServer Pages.

Os Design Patterns buscam facilitar a reutilização de projetos e arquiteturas bem sucedidos. Eles auxiliam a escolher alternativas de projeto que tornam um sistema reutilizável e evitar alternativas que comprometam a reutilização.

Segundo Alur (2002) se destacam algumas vantagens de se usar cada um destes padrões, considerando que:

· Foram testados: refletem a experiência e conhecimento dos desenvolvedores que utilizaram estes padrões com sucesso em seu trabalho;

· São reutilizáveis: fornecem uma solução pronta que pode ser adaptada para diferentes problemas quando necessário;

· São expressivos: formam um vocabulário comum para expressar grandes soluções sucintamente;

· Facilitam o aprendizado: reduzem o tempo de aprendizado de uma determinada biblioteca de classes. Isto é fundamental para o aprendizado dos desenvolvedores novatos;

· Diminuem retrabalho: quanto mais cedo são usados, menor será o retrabalho em etapas mais avançadas do projeto.

A SUN disponibiliza um catálogo de 15 padrões J2EE, que fornece soluções para problemas tipicamente encontrados por arquitetos e designers de aplicações de software para a plataforma J2EE, conforme ilustra a Figura 3.

Descrição: 15

Figura 3: Core J2EE Patterns. Fonte: SUN.

Em poucas palavras é possível descrever cada um destes padrões em suas respectivas camadas (Alur, 2002):

· Camada de apresentação: intercepting filter (Intercepta solicitações e respostas e aplica algum filtro); front controller (Fornece um controlador centralizado para manter a lógica de processamento que ocorre na camada de apresentação e que, erroneamente é colocado nas visões); view helper (Encapsula a lógica que não esteja relacionada à formatação da apresentação em componentes auxiliares);composite view (Cria uma visão através da composição de outras visões); service to worker (Combina um componente distribuidor com os padrões Front Controller e View Helper. Neste padrão a responsabilidade de recuperar o conteúdo para apresentar é do controlador); dispatcher view (Semelhante ao padrão Service to Worker, mas, neste padrão a recuperação do conteúdo é responsabilidade das visões).

· Camada de negócios: business delegate (Reduz o acoplamento entre o cliente e a camada de negócios); data transfer object (Facilita o intercâmbio de dados entre as camadas); data transfer object factory (Facilita e centraliza a criação de data transfer objects); session facade (Fornece uma interface unificada para um sistema distribuído); composite entity (Representa uma prática mais recomendada para criar entity beans de granulação grossa, agrupando os objetos dependentes em um único entity bean); value list handler (Gerencia o processamento e armazenamento em cache de consultas que retornam uma grande quantidade de informações); service locator (Encapsula a complexidade de localização e criação de serviços de negócio e localiza os objetos Home dos EJB).

· Camada de integração: data access object (Abstrai e encapsula o acesso aos dados); service activator ( Facilita o processamento assíncrono para Message-driven beans).

2.7.2 Componentização na camada de visualização com JSF

Segundo Gonçalvez (2007, p. 429) O JSF (Java Server Faces) é uma tecnologia do mundo JEE e é desenhado para simplificar o desenvolvimento de aplicações Web. JSF torna fácil o desenvolvimento através de componentes de interface de usuário (GUI) e conecta esses componentes a objetos de negócios. Também automatiza o processo de uso de Java Beans e navegação de páginas.

Java Server Faces disponibiliza o rápido desenvolvimento de interfaces para aplicações que rodam no servidor web. Permite aos desenvolvedores escrever aplicações com facilidade, sem se preocupar com as complexidades de lidar com navegadores e servidores Web. Também automatiza alguns procedimentos como o controle e o transporte do código entre formulários, a lógica de negócios, entre outros.

Java Server Faces realiza muito do trabalho pesado que geralmente precisam ser implementados em Servlets e JSP. Possui um conjunto de componentes que são essenciais para o desenvolvimento de aplicações em JSF.

Estes componentes funcionam em conjunto, ou seja, caso necessite de um determinado componente que não existe no projeto, ele pode ser inserido sem problemas. Hoje, existem diversos conjuntos de componentes, como por exemplo: JBoss RichFaces, MyFaces Tomahawk, Oracle ADF, ICEfaces, entre outros. Há também alguns fabricantes que desenvolveram suas próprias implementações de JSF, tais como: MyFaces (Apache), JSF RI ou Mojarra (Sun Microsystem) (Rafael Ponte,on-line).

De certa forma o JSF pode ser comparado ao framework Microsoft .net, pois possui um conjunto de componentes visuais, que permite o conhecido “arrastar e soltar”. Também por ser flexível na questão de criação de componentes próprios a partir de classes de componentes, e permitir que o desenvolvedor crie interfaces através de componentes fornecidos e manipule eventos do lado cliente com grande facilidade.

Vale destacar que no ano de 2009 foi lançada a versão 2 do framework JSF, que teve sua primeira versão lançada em 2003. Esta segunda versão veio para corrigir e facilitar o uso de diversos novos recursos tais como:

· Suporte nativo a Ajax, não disponível na primeira versão.

· Resolver problemas de incompatibilidade entre bibliotecas de componentes.

· Permitir configurações através de anotações, o que antes era feito somente via xml.

· Diminuir a complexidade da criação de componentes visuais.

· Comunicação entre os componentes através de outros protocolos, pois na primeira versão era possível somente via GET, sendo esta uma de suas falhas mais criticadas.

2.7.3 Componentização na camada de negócios com EJB

Segundo Gonçalvez (2007, p. 544) O EJB ou Enterprise JavaBeans é um componente servidor que roda em um container para EJB do servidor de aplicação. Considerado como um dos principais componentes da plataforma JEE (Java Enterprise Edition), o EJB tem como principais objetivos da tecnologia fornecer rápido e simplificado desenvolvimento de aplicações Java baseadas em componentes, distribuídas, transacionais, seguras e portáveis.

Infelizmente essa não foi bem a realidade das versões anteriores as 3.0 da tecnologia EJB, especialmente os Entity Beans, que sempre foram acusados de baixa eficiência, alta complexidade e dificuldade de uso.

DEBU PANDA (2008, p.4) define Enterprise JavaBeans (EJB) como uma plataforma para construção de aplicações corporativas portátil, reutilizável e escalável, que utiliza a linguagem Java. Desde seu início, o EJB tem sido considerado um modelo de componente ou framework que permite que você construa aplicações corporativas Java sem ter que reinventar serviços necessários para a construção de uma aplicação, como as transações, seguranças, persistência automatizada e assim por diante.

DEBU PANDA (2008, p.5) descreve EJBs como componentes server-side que são utilizados para construir partes de uma aplicação, como a regra de negócios ou a camada de persistência. O desenvolvimento de componente geralmente é visto como algo extremamente complexo como o CORBA ou Microsoft COM+. O EJB3 mostra que um componente é o que deve ser: Encapsular com eficiência o comportamento de uma aplicação, dessa forma o usuário de um componente não precisa conhecer suas operações internas, tudo o que precisa saber é como ir e o que esperar de volta.

As principais vantagens do uso da tecnologia EJB, podem ser entendidas através dos seguintes pontos:

· Fácil de usar: Focado na facilidade de uso, os recursos que mais são realçados são a programação POJO, as anotações XML, o uso intenso dos padrões sensíveis e o JPA.

· Acúmulo de soluções integradas: O EJB oferece um conjunto de soluções para servidor, incluindo persistência, messaging, programas leves, remoting, serviços de web, injeção de dependência (DI) e interceptores. Isso significa que você não terá que perder tempo procurando ferramentas terceirizadas para integrar à sua aplicação.

· Padrão aberto Java EE: O EJB possui uma especificação API pública aberta, que as empresas utilizam para criar um container ou a implementação do fornecedor de persistência. O padrão EJB é desenvolvido pelo Java Community Process (JCP) proporcionando um suporte maior, sem precisar de uma solução proprietária.

· Suporte maior ao fornecedor: O EJB é suportado por uma grande variedade de empresas independentes. Incluindo as maiores empresas do ramo de tecnologia do mundo, muito respeitadas e financeiramente estabilizadas, como a Oracle e a IBM, assim como os grupos JBoss e Geronimo. O suporte amplo ao fornecedor se traduz em três vantagens importantes para você. Primeira, você não está à mercê dos altos e baixos de uma empresa particular ou grupo de pessoas. Segunda, muitas pessoas possuem interesses a longo prazo para manter a tecnologia o mais competitiva possível. Você pode ser capaz de levar vantagem das melhores tecnologias dentro ou fora do ambiente Java em um cronograma competitivo. Terceira, os fornecedores concorrem entre si para fornecer recursos não padronizados adicionados ao valor. Esses fatores ajudam a manter o EJB continuamente na linha de evolução.

· Agrupamento, balanceamento de carga e failover: Os recursos historicamente adicionados por muitos fornecedores de servidores de aplicações são suportes robustos para o agrupamento, balanço de carga e failover. Os servidores de aplicação EJB possuem um registro de trilha provado para suportar alguns dos ambientes de servidores ativados por computação (HPC) de alto desempenho. Mais importante que isso, você pode alavancar tal suporte sem alterar o código, sem interação de ferramenta terceirizada e com configuração relativamente simples (além do trabalho inerente em configurar um agrupamento de hardware). Isto significa que você pode confiar no agrupamento de hardware para medir sua aplicação com o EJB 3, caso precise.

Os beans são os componentes EJB e são classificados conforme sua utilidade, sendo eles: Session Beans, Message Driven Beans, Entity Beans. Cada tipo de bean tem um propósito e pode utilizar um subconjunto específico de serviços EJB. O propósito real dos tipos de beans é proteger as possíveis sobrecargas contra os serviços que surgem.

Os sesseion beans e os Message Driven Beand são usados para construir lógica de negócios e residem em um container, que gerencia esses beans e fornece serviço a eles. Já os Entity Beans são usadas para modelar a persistência de uma aplicação.

Segundo DEBU PANDA (2008, p.14), um dos recursos mais atraentes do EJB 3 é o modo com que ele controla a persistência. Persistência é a habilidade de ter os dados contidos nos objetos Java automaticamente armazenados em um banco de dados relacional como o Postgres SQL. A persistência em EJB 3 é gerenciada pelo JPA. Ela persiste automaticamente aos objetos Java usando uma técnica chamada mapeamento objeto-relacional (ORM). O ORM é essencialmente o processo de mapeamento de dados contidos nos objetos Java das tabelas de banco de dados usando configuração. Ele desobriga o desenvolvedor da tarefa de escrever o código JDBC de baixo nível para manter os objetos em um banco de dados.

Os frameworks que fornecem capacidade ORM para realizar persistência automatizada são conhecidos como frameworks ORM. Como o nome já diz, um framework ORM executa persistência transparente usando metadados do mapeamento objeto-relacional que define como os objetos são mapeados nas tabelas de banco de dados. ORM não é um novo conceito e já está presente por algum tempo. Oracle TopLink é provavelmente o framework ORM mais antigo no mercado; o framework de fonte aberta JBoss Hibernate popularizou os conceitos ORM entre a comunidade do desenvolvedor atual.

REFERÊNCIAS BIBLIOGRÁFICAS

ALECRIM, Emerson. JSE, JEE e JME: uma breve explicação. Info Wester. São Paulo - SP. 02 out. 2007. Disponível em: <http://www.infowester.com/versoesjava.php>. Acesso em 02 abr. 2009.

ALUR, Deepak; CRUPI, John; MALKS, Dan. Core j2ee patterns: as melhores práticas e estratégias de design. Rio de Janeiro: Campus, 2002.

BRAZ, Christian Cleber Masdeval. Introdução ao Java Server Pages. Disponível em: <http://www.tudodownloads.com.br/download/2552/Apostila_-_Introducao_ao_JSP_Java_Server_Pages.html>. Acesso 23 mar. 2008

CONALLEN, Jim. Building Web Application With UML. 2. ed. 2002.

COULOURIS, George F.; DOLLIMORE, Jean; KINDBERG, Tim. Distributed systems:concepts and design. 4th ed. 2005.

DESMOND D"Sousa. Objects, Components, and Frameworks with UML: The Catalysis Approach.1998.

Friedrich Ludwig Bauer. NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO (1969) 231p.

GONÇALVES, Edson. Desenvolvendo aplicações web com jsp, servlets, javaserver faces, hibernate, ejb3 persistence e AJAX. Editora Ciência Moderna: Rio de Janeiro, 2007.

IEEE, Institute. IEEE Std 830-1998. Recommended Practice for Software Requirements Specifications. Institute of Electrical and Eletronic Engineers.

JANDL JUNIOR, Peter. Java Guia do Programador. Novatec Editora. 2007. Disponível em: <http://www.novatec.com.br/livros/javaguia/capitulo9788575221099.pdf> Acesso em 02 abr. 2008.

KOCH, Nora. A UML-based Methodology for Hypermedia Design. England. Out 2000.

LAMPORT, Time. Clocks and the Ordering of Events. CACM. Jul 1978, p 558-565.

HORSTMANN, Cay S. Core Java 2 – Vol.1:Fundamentos.Editora Makron Books: São Paulo SP, 2000.

MANGIONE, Carmine. Performance tests show Java as fast as C++. Java World. 02 jan. 1998. Disponível em: <http://www.javaworld.com/jw-02-1998/jw-02-jperf.html>. Acesso em 01 jun. 2008.

MARINESCU, Floyd. EJB design patterns: advanced patterns, processes, and idioms. New York: John Wiley & Sons, 2002.

MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.0: do conceitual à implementação – 2.ed. Brasport. Rio de Janeiro, 2004.

MURUGESAN, S. Leverage global software development and distribution using the internet and web. Cutter IT Journal. Mar 1999

NEWMAN, Alexander. Usando Java. Editora Campus: Rio de Janeiro, 1996.

OLIVEIRA, José Palazzo Moreira de. Conceitos sobre Sistemas Distribuídos. UFRGS. Disponível em: <http://palazzo.pro.br/sd/distr-dados.htm>. Acesso em 16 set 2010.

DEBU PANDA, REZA RAHMAN, DEREK LANE. EJB3 em ação. Alta Books, 2008.

PRESSMAN, ROGER S. Engenharia de Software. 5ª Ed. Rio de Janeiro: McGraw- Hill, 2002.

Rafael Ponte. Anatomia do JSF - JavaServer Faces. Rafael Pontes. Ceará. 27 out. 2007. Disponível em: <http://www.rponte.com.br/wp-content/uploads/2007/10/anatomia-jsf-javaserver-faces-cct.pdf>. Acesso em 20 mar.2010.

RUBIRA, Cecília Mary Fischer. Desenvolvimento Baseado em Componentes e o Processo UML Components. Unicamp. 2008. Disponível em: <http://tolstenko.net/dados/Unicamp/2009.2/mc436/2009.2/Material de Apoio/Slides/11_dbcUMLComp.pdf>. Acesso em 07 set. 2010.

SILBERSCHATZ, Abraham; Korth, Henry F e Sudarshan, S. Sistema de Banco de Dados. Makron Books, 1999. p. 1.

SWEBOK. Disponível em: <http://www.computer.org/portal/web/swebok>. Acesso em 01 jun. 2008.

SUN, Sun Microsystems. Designing enterprise applications with the j2ee platform enterprise edition. Disponível em: <http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/index.html>. Acesso em: 28 out. 2010.

TANENBAUM, Andrew S. Distributed Operating Systems. New Jersey: Prentice Hall, 1995.

WIKIPEDIA. Sistema de Gerenciamento de Banco de Dados. Disponível em: <http://pt.wikipedia.org/wiki/Sistema_de_gerenciamento_de_banco_de_dados>. Acesso em: 10 dez. 2009.

WIKIPEDIA. PostgreSQL. Disponível em: <http://pt.wikipedia.org/wiki/PostgreSQL>. Acesso em: 10 dez. 2009.

WIKIPEDIA. Engenharia de software. Disponível em: <http://pt.wikipedia.org/wiki/Engenharia_de_software >. Acesso em: 10 dez. 2009.

WIKIPEDIA. Engenharia de software baseada em componentes. Disponível em:<http://pt.wikipedia.org/wiki/Engenharia_de_software_baseada_em_componentes>. Acesso em: 10 dez. 2009.

WIKIPEDIA. Processo Unificado. Disponível em: <http://pt.wikipedia.org/wiki/Processo_Unificado>. Acesso em 10 dez. 2009.

WIKIPEDIA. IBM Rational Unified Process Disponível em: <http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process>. Acesso em: 10 dez. 2009

Desenvolvimento - Java

Leia também