Aplicações MulticamadasAgosto, 2008

Oscar A. Konno Sampaio

As aplicações empresariais geralmente são implementadas utilizando a arquitetura multicamadas. Cada camada é composta de vários componentes de software que possuem uma interface bem definida para se comunicar com outros componentes ou com serviços oferecidos pelo middleware.

Arquitetura Multicamadas – é uma arquitetura de software em que o aplicativo é dividido em várias camadas, onde cada camada é responsável por um determinado aspecto ou funcionalidade como apresentação, lógica de negócio, persistência, etc.

Middleware – é um sistema de software que faz a mediação entre outros softwares. É utilizado para mover informações entre programas ocultando do programador diferenças de protocolos de comunicação, plataformas e dependências do sistema operacional. É geralmente constituído por módulos dotados de APIs de alto nível que proporcionam a sua integração com as aplicações e interfaces de baixo nível que permitem a sua independência relativamente ao dispositivo. Seu objetivo é mascarar a heterogeneidade e fornecer um modelo de programação mais produtivo para os programadores de aplicativos. É composto por um conjunto de processos ou objetos em um grupo de computadores, que interagem entre si de forma a implementar comunicação e oferecer suporte para compartilhamento de recursos a aplicativos distribuídos.

Porque utilizar a arquitetura multicamadas

DesacoplamentoNas aplicações monolíticas, a lógica de negócios, apresentação e controle estão normalmente interligadas, apresentando um alto acoplamento. Isto normalmente se torna um problema desde que alterações em um componente impactam em muitos outros, necessitando que sejam feitas validações de grandes partes do sistema mesmo para pequenas alterações. Outro efeito desse alto acoplamento é a dificuldade de se reutilizar o código.

Nas aplicações implementadas em camadas, os diferentes aspectos são implementados separadamente, forçando o desacoplamento e permitindo a reusabilidade dos vários componentes.

Distribuição do processamentoAs aplicações empresariais normalmente necessitam ter seu processamento distribuído entre vários hardwares, seja por necessidade de escalonar o processamento ou pela distribuição geográfica.

No entanto o processamento distribuído introduz complexidade no desenvolvimento de sistemas. Os middlewares permitem que os sistemas sejam desenvolvidos sem que o

desenvolvedor necessite se preocupar com os detalhes como localização e sincronização do acesso aos recursos, comunicação, protocolos envolvidos, etc.

ComponentizaçãoO desenvolvimento em multicamadas é feito pela construção de componentes de software.

Um componente consiste de uma porção de software com uma interface (forma de se comunicar com o mesmo) bem definida, e com funcionalidade pre definida.

Componentes podem ser utilizados para compor componentes maiores. São como peças que podem ser combinadas para formar componentes maiores. Essas peças podem ser reutilizadas ou substituídas por outras equivalentes conforme a necessidade de desenvolvimento.

Camadas De uma forma geral podemos dividir um aplicativo em 6 camadas:

Camada de apresentação – clienteFornece uma interface para o usuário final. O cliente pode ser ‘magro’ (browser por exemplo – IE, Firefox, Opera, etc.), gordo (um aplicativo rodando na máquina do usuário) ou algo entre os dois extremos.

Camada de apresentação – servidorFornece para a camada de apresentação no cliente os dados, tais como páginas HTML, necessários para gerar a interface com o usuário.

Camada de lógica de negócios – servidorInclui os métodos de negócio por trás da aplicação. Consiste das ações que governam a dinâmica do negócio (workflow). Pode ser visto como os verbos de uma aplicação.

Ex.: cadastrar clientes, efetuar compra, enviar mercadoria, confirmar pedido, etc.

Camada de modelo de domínioConsiste do modelo de dados utilizado para representar os diferentes atores e entidades envolvidos no negócio. P.ex. clientes, fornecedores, pedido, produto, etc. São utilizados pela camada de lógica de negócios. Podem ser vistos como os ‘substantivos’ de uma aplicação.

Camada de persistênciaResponsável por persistir os dados do aplicativo, ou seja, os dados (modelo) manipulados pela camada de lógica de negócios necessitam ser salvos em um meio físico como um banco de dados. A responsável por isso é a camada de persistência.

Camada de integraçãoPermite conectar a aplicação a outros sistemas. Ela permite a integração com sistemas legados, banco de dados, outros sistemas que necessitam participar da lógica de negócios, ou mesmo com partes do aplicativo separados por grandes distâncias geográficas.

Plataforma JEEA plataforma Java Enterprise Edition é a plataforma Java para o desenvolvimento de aplicações empresariais utilizando a arquitetura de multicamadas. O JEE corresponde ao JSE para aplicações empresariais.

1Em JEE um aplicativo consiste de componentes que interagem entre si e são gerenciados por um servidor de aplicativo.

O servidor de aplicativos é o núcleo da plataforma JEE, é ele que fornece a infra-estrutura básica para o desenvolvimento e execução de um aplicativo empresarial. Consiste de um software onde são hospedados os componentes responsáveis por implementarem as diversas camadas do aplicativo – lógica de negócios, componentes web (apresentação) - e fornece serviços que permitem a persistência e interação com outros aplicativos.

Os componentes devem implementar uma interface padronizada para que o container (outro nome dado ao servidor de aplicativo) possa se comunicar com o mesmo e gerenciar o seu ciclo de vida. Da mesma forma, os serviços fornecidos pelo container, são utilizados pelos aplicativos hospedados no servidor através de uma interface bem definida.

1 O JSE (Java Standard Edition) é a plataforma para desenvolvimento de aplicativos em Java no desktop, os aplicativos desenvolvidos em JSE são normalmente auto-suficientes e não dependem de uma infra-estrutura externa para que seja executado. O JSE fornece funcionalidades como acesso a disco, entrada/saída, bibliotecas básicas, acesso a banco de dados, funções matemáticas e interface gráfica.

Camada de Apresentação ClienteA camada de apresentação no cliente pode ser de três tipos: clientes web, applets e aplicativos clientes.

Clientes WebUm cliente web é composto de duas partes:

1 ) Páginas web dinamicamente geradas codificadas por uma linguagem de marcação (XML, HTML, etc). Estas páginas são normalmente geradas por componentes na camada de apresentação no servidor.

2) Um browser que monta visualmente a página recebida do servidor.

Os clientes web são também chamados de cliente magro. Normalmente não acessam banco de dados, não executam lógica de negócios nem se comunicam com outros aplicativos (exceto o servidor). Todo o trabalho é efetuado no lado servidor, ficando o cliente responsável apenas por apresentar os dados.

Atualmente com a utilização cada vez maior de tecnologias como Ajax e Flex, muito da lógica de controle está migrando do servidor para o cliente, mas a lógica de negócios e interação com outros aplicativos ainda são rodados no servidor.

AppletsUma pagina recebida do servidor pode incluir um applet encapsulado. Um applet consiste de um pequeno aplicativo Java que é executado na maquina virtual Java do browser web. Um applet está sujeito a normas de segurança para impedir que efetue operações indevidas na máquina cliente.

Aplicativo clienteUm aplicativo cliente roda em uma máquina cliente e fornece uma interface para o usuário interagir com o sistema. A interface pode ser desde interfaces gráficas (GUI) sofisticadas até interfaces em linhas de comando.

O aplicativo cliente normalmente acessa diretamente a camada de negócios do aplicativo e são muitas vezes chamados de clientes gordos – por implementarem toda a lógica de interação com o usuário.

Camada de Apresentação ServidorNa camada de apresentação no servidor, os componentes que implementam o aplicativo são desenvolvidos na forma de páginas JSP (incluindo JSF) e servlets. Estes componentes são hospedados por um container WEB, que é responsável por receber as requisições do cliente WEB e repassar para processamento pelos componentes do aplicativo. Estes componentes, a partir da interação com outras camadas, obtém ou alteram dados, e geram páginas em uma linguagem de marcação (HTML ou XML) que é enviada para o cliente.

Além das páginas JSP e servlets, o container web pode fornecer páginas, imagens e outros recursos estáticos, que não são considerados componentes web.

Observar que a comunicação entre as camadas da web e lógica de negócios é feita pela passagem de objetos Java Beans2.

Lógica de NegóciosA lógica de negócios em uma aplicação JEE é implementada em componentes EJB. EJB’s são componentes de softwares gerenciados pelo container EJB. Fisicamente, os EJB’s podem estar no mesmo servidor em que se encontra o container web, em outro servidor ou distribuidos em vários servidores. O container EJB se encarrega da comunicação entre os vários EJBs e o desenvolvedor não precisa se preocupar com os detalhes de como se dá a comunicação entre eles ou da localização dos mesmos.

Modelo de Negócio O modelo do negócio é implementado em classes Java Beans chamadas entities. Estas classes são persistidas (camada de persistência) através de uma API de persistência, o JPA, que se encarrega de efetuar as operações (insert, update, delete) no banco de dados. Para isso estas classes são anotadas com informações sobre como elas devem ser mapeadas no banco de dados.

Containers JEEUma aplicação multicamadas é normalmente extremamente difícil de escrever, principalmente se tivermos de nos preocupar com os detalhes de baixo nível como: controle transacional, gerenciamento de estado, multithread , processamento concorrente, controle de acesso aos recursos, etc. Na plataforma Java, o container JEE cuida de todos estes detalhes, deixando para o desenvolvedor apenas o trabalho de implementar a lógica de negócios e apresentação através dos componentes que serão hospedados nele.

2 Java Beans são objetos Java que possuem 2 caracteristicas: possuem um construtor padrão (sem argumentos) e as propriedades são acessados através de métodos getters e setters.

Todos os componentes que formam os aplicativos JEE “vivem” dentro de um container. Para que eles possam ser executados necessitam ser montados em um módulo JEE e hospedados no container. A este processo de instalação do módulo no container chamados de deploy.

O processo de montagem do módulo JEE inclui também a configuração do mesmo de forma a informar como o container deve tratar aquele módulo no que se refere a aspectos como segurança, gerenciamento de transações, localização (como encontrar os componentes do módulo), acesso a recursos como banco de dados, mecanismos de comunicação etc.

Tipos de Containers JEE

Servidor de Aplicativos JEEÉ o aplicativo servidor de uma plataforma JEE. Ele contem containers EJB e WEB. Exemplos de servidores de aplicativos JEE são o JBoss, Glassfish, etc.

Container Enterprise JavaBean (EJB) Gerencia a execução de componentes EJB de uma aplicação JEE. O container EJB roda dentro de um servidor de aplicativo JEE.

Container WEBGerencia a execução de páginas JSP e servlets de uma aplicação JEE. Os contêiner Web rodam dentro de um servidor JEE.

Montagem e deploy de aplicações JEEOs aplicativos JEE são empacotados em unidades padronizadas para instalação em um servidor JEE. Cada unidade deve conter:

Componentes (EJBs, JSP, Servlets, Applets, etc) – consistem de classes Java (EJB, Servlets) devidamente anotadas e que implementam as interfaces exigidas para o tipo de componente. Os páginas JSP são páginas que utilizam tags JSP ou JSF que são compiladas em classes Java para depois serem executadas.

Recursos como páginas html, imagens, etc.

Descritores de instalação que descreve o seu conteúdo (opcional)

Os componentes, recursos e descritores devem ser distribuídos em uma estrutura de arquivos definida pela especificação JEE. Para fazer o deploy, esta estrutura de arquivo deve ser empacotada (jar) em um arquivo que será colocado dentro do servidor de aplicativo.

No caso de um módulo WEB, o arquivo deve ser nomeado com a extensão WAR (Web archive) e no caso de um módulo EJB em um arquivo EAR

JEE API e ServiçosA plataforma JEE disponibiliza vários serviços que podem ser utilizados pelos componentes de uma aplicação. Estes serviços são acessíveis via uma interface de aplicativo (API) padrão.

Serviço de Diretorios - JNDI – Java Naming and Directory Interface, fornece a base para a localização de recursos em um ambiente JEE. Os recursos (banco de dados, componentes, outros serviços, etc.) são registrados no JNDI utilizando um nome. Este nome é utilizado como uma chave para localizar o recurso quando necessário.

Segurança – JAAS – Java Authentication and Authorization Service , o modelo de segurança do JEE permite configurar o acesso aos componente web, ejbs ou recursos do sistema.

Controle Transação – JTA - Java Transaction API, o modelo transacional do JEE permite especificar relações entre os métodos de forma a fazê-los participarem de transações (ACID). É possível utilizar tanto a abordagem via configuração como programável.

Comunicação – o JEE implementa por baixo dos panos a conectividade entre os vários componentes participantes do aplicativo corporativo, escondendo as complexidades inerentes a distribuição do processamento.

Enterprise Java BeansOs EJBs são os componentes fundamentais para a implementação da lógica de negócios em uma aplicação JEE.

Um EJB possui como características:

Pode ser acessível remotamente (processamento distribuído)

É gerenciado pelo container que controla a sua criação, utilização e deleção. O container pode utilizar um pool3 de ejbs para atender as solicitações dos diversos clientes.

Gerenciamento de transações – o container EJB suporta o controle declarativo de transações que permite implementar o comportamento transacional por configuração ao invés de se codificar.

Segurança – o container EJB pode cuidar dos detalhes de autenticação e autorização de acesso aos recursos de forma declarativa (por configuração) , liberando o desenvolvedor dos detalhes ou da implementação do mecanismo de segurança.

Tipos de Enterprise Java Beans

Session EJBUm session bean é requisitado por um cliente com o propósito de executar uma operação da lógica de negócios. O nome session (sessão) se refere ao fato da instancia do bean ficar disponível durante uma sessão e não sobrevive a uma queda ou desligamento do servidor. Um session bean pode ser utilizado para modelar qualquer funcionalidade da lógica de negócios da aplicação.

Existem 2 tipos de session beans:

Statefull session bean – o container salva o estado do bean (propriedades do mesmo) entre requisições do cliente. Um exemplo típico de statefull EJB é um carrinho de compras em um aplicativo de loja web.

Stateless session bean – não mantém registro do estado de solicitações anteriores. Ele pode ser utilizado para efetuar operações atômicas como criar um pedido por exemplo.

Os session beans podem ser requisitados tanto localmente quanto remotamente via Java RMI (o desenvolvedor não precisa se preocupar com os detalhes desse acesso remoto, ele trabalha como se estivesse utilizando um objeto local). Um session bean do tipo stateless também pode ser acessado via web service.

Message Drive Beans (MDB)Como os session beans, o MDB processa operações da lógica de negócios. Entretanto, o Message Beans diferem dos Session Beans na forma como é feita sua requisição. Em um MDB as requisições não são feitas diretamente o bean, ao invés disso, as requisições são enviadas

3 Um pool consiste de uma técnica de gerenciamento de recurso. Os recursos disponíveis em uma aplicação gerencial (banco de dados, ejbs, servlets, etc.) são compartilhados por vários clientes que utilizam estes recursos. Para otimizar a utilização dos mesmos, ao invés de criar um recurso para cada solicitação – o que leva tempo, pois para isso é necessário alocar e inicializar o mesmo – o container cria um conjunto (pool) de recursos e vai utilizando conforme a demanda. Depois de utilizado o recurso volta ao pool e pode ser reutilizado novamente por outro cliente. Caso o numero de solicitações exceda o numero de objetos disponíveis no pool o container aloca novos objetos para suprir a demanda.

como mensagens para um servidor de mensagens (daí o nome Message Drive Beans). Este servidor se encarrega de entregar a mensagem ao bean para que este a processe.

A execução da requisição ocorre de forma assíncrona, ou seja, o cliente não precisa esperar para que a requisição seja processada. Caso o bean a qual se destina a mensagem esteja inacessível no momento em que o cliente enviou a requisição, o servidor de mensagem armazena a solicitação e a envia quando o bean estiver disponível novamente.

BibliografiaThe Java EE 5 Tutorial – Sun Microsystem, 2006.

Panda, Debu; Rahman, Reza; Lane, Derek. EJB 3 in Action. Manning, 2007.

Sriganesh, Rima; Brose, Gerald; Silverman, Micah. Mastering Enterprise JavaBeans 3.0. Wiley, 2006.

Schincariol, Merrick; Keith, Mike. Pro EJB 3 – Java Persistence API. Apress, 2006.

Crawford, Willian; Kaplan, Jonathan. J2EE Design Patterns. O’Reilly, 2003.

Alur, Deepak; Crupi, John; Malks, Dan. Core J2EE Patterns: Best Practices and Design Strategies. 2nd Edition. Prentice Hall, 2003.