UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Modelagem do Catálogo e Autenticação do Direto utilizando J2EE e JAAS por FLÁVIO RODRIGUES MACIEL Projeto de Diplomação Prof. Cláudio Fernando Resin Geyer Orientador Porto Alegre, setembro de 2002.

2 2 Sumário Lista de Abreviaturas... 4 Lista de Figuras... 5 Lista de Tabelas... 6 Resumo... 7 Abstract Introdução O Direto Introdução Arquitetura Cliente web Servidor Web Servlets Java XML XSLT Módulos Java POP IMAP SMTP LDAP JDBC vcalendar Situação Atual Java 2 Platform, Enterprise Edition Arquitetura J2EE Server EJB Container Web Container Papéis Enterprise Java Beans Interfaces Visão Remota versus Visão Local Session Bean Message-Driven Bean Entity Bean Ciclo de Vida Descritor de instalação Tecnologias e Serviços Servlets Java Server Pages JavaMail Java API for XML Processing Java Database Connectivity... 28

3 Java Message Service - JMS Java Naming and Directory Interface JNDI J2EE Connector Architecture - JCA Segurança Transações Modelagem de Sistemas Modularidade Modelo Model-View-Controller Orientação a Objetos UML Modelagem do Catálogo do Direto Modelo Atual do Direto Autenticação Direto Módulos de Login Arquivo de Configuração de Login CallbackHandler Conclusão Módulo de Catálogo Casos de uso Enterprise Beans Camada Web Deploy Limitações Mono-usuário Alteração dos dados de usuário e grupo Considerações Finais Implementação do Protótipo Configuração do ambiente Protótipo Conclusão Trabalhos Futuros Catálogo Segurança JDBC JMS JNDI Avaliação de desempenho Bibliografia...70 Anexo I Diagrama de Classes do Catálogo... 72

4 4 Lista de Abreviaturas API Application Programming Interface EJB Enterprise Java Beans HTML HyperText Markup Language HTTP HyperText Transfer Protocol IMAP Interactive Mail Access Protocol IMAP4 Interactive Mail Access Protocol Version 4 J2EE Java 2 Enterprise Edition JAAS Java Authentication and Authorization Service JAXP Java API for XML Processing JCA Java Connector Architecture JDBC Java Database Connectivity JMS Java Message Service JNDI Java Naming and Directory Interface JSP JavaServer Pages JTA Java Transaction API JTS Java Transaction Service LDAP Lightweight Directory Access Protocol MVC Model View Controller POP Post Office Protocol POP3 Post Office Protocol Version 3 PROCERGS Companhia de Processamento de Dados do Estado do Rio Grande do Sul SMTP Simple Mail Transfer Protocol SQL Structured Query Language RMI Remote Method Invocation UFRGS Universidade Federal do Rio Grande do Sul UML Unified Modelling Language XML Extensible Markup Language XSL Extensible Stylesheet Language XSLT Extensible Stylesheet Language Transformations

5 5 Lista de Figuras Figura Arquitetura do Direto Figura Arquitetura da plataforma J2EE Figura Interfaces como visão do cliente Figura Ciclo de vida de um stateful session bean Figura Ciclo de vida de um stateless session bean Figura Ciclo de vida de um message-driven bean Figura Ciclo de vida de um entity bean Figura Modelo de autenticação do JAAS Figura Diagrama de classes do catálogo do Direto Figura Diagrama de seqüência do processo de autenticação Figura Casos de uso do catálogo pessoal Figura Bean de persistência Figura Direção do relacionamento Contato-GrupoContato Figura Geração do identificador Figura Diagrama de classes dos beans simplificado Figura Comunicação entre a camada de controle e a do modelo Figura Diagrama de navegação web Figura Tela de login Figura Tela inicial do catálogo Figura Tela de inserção de contato ao grupo... 67

6 6 Lista de Tabelas Tabela Classes das interfaces Tabela 5-1 Métodos necessários aos entity beans Tabela Mapeamento dos métodos de persistência de ContatoBean Tabela Mapeamento dos métodos de persistência de GrupoContatoBean... 55

7 7 Resumo Este trabalho trata da modelagem de um protótipo, baseado nas funções de catálogo e autenticação do software Direto, utilizando a plataforma J2EE, suas tecnologias e serviços. O Direto é um software de agenda, catálogo e correio corporativos desenvolvido pela PROCERGS e que possui licença de software livre. Tem como objetivo tornar-se ferramenta padrão de agenda, catálogo e correio para os órgãos do governo do Estado do Rio Grande do Sul. A plataforma J2EE é uma especificação para uma plataforma de desenvolvimento de aplicações corporativas, baseada na linguagem Java, da Sun Microsystems. A plataforma provê uma variedade de serviços de baixo nível, entre eles a API JAAS. Isto confere às aplicações que rodam na plataforma um alto nível de modularidade e escalabilidade por permitir o desenvolvimento de componentes de software reusáveis, denominados Enterprise Java beans, ou EJBs. A API JAAS define um modelo de segurança para aplicações Java que independe das características de segurança inerentes ao ambiente da aplicação. Neste trabalho, a tecnologia JAAS é aplicada ao processo de autenticação do Direto. Em seguida, um módulo de catálogo é desenvolvido utilizando a tecnologia EJB e integrado com a autenticação proposta. Ao longo deste estudo, são mostrados os diversos ganhos obtidos com a adoção deste modelo. Palavras-chaves: Direto, J2EE, JAAS, EJB

8 8 Abstract This work deals with the modeling of software prototype, based on the functions of catalogue and authentication of Direto software, using J2EE platform, its technologies and services. Direto is an enterprise scheduling, directory and mailing software developed by PROCERGS. As its objective, it pretends to become the standard scheduling, directory and mailing tool for the agencies of the government of the State of Rio Grande Do Sul. Platform J2EE is a specification for a platform that supports corporative applications development, based in the Java language of Sun Microsystems. The platform provides a variety of system-level services, like the JAAS API. It gives applications that run on the platform a high level of modularity and scalability by allowing the development of reusable software component, called enterprise Java beans, or EJBs. The JAAS API defines a security model for Java applications that does not depend on the inherent security characteristics of the application environment. In this work, the JAAS technology is applied to the authentication process of Direto. After that, a directory module is developed using EJB technology and it is integrated with the authentication proposal. During this study, the many advantages acquired with the adoption of this model are shown. Keywords: Direto, J2EE, JAAS, EJB

9 9 1. Introdução A utilização de ferramentas de agenda, catálogo e correio corporativos caracteriza-se como um fator fundamental para que as corporações agilizem e qualifiquem a comunicação interna da empresa. A adoção de sistemas proprietários, desenvolvidos por grandes fabricantes de software, implica geralmente custos elevados de licenciamento. Desenvolver uma solução própria de sistema de agenda, catálogo e correio corporativos é por um lado atrativo em relação a custos e flexibilidade que se pode obter da solução, mas por outro lado necessita know-how e atualização tecnológica de modo a obter um resultado de qualidade. O Direto é um software de agenda, catálogo e correio corporativos desenvolvido pela PROCERGS com o objetivo de atender os diversos órgãos do Estado do Rio Grande do Sul. O sistema peca na questão da modularidade, por não usar da melhor forma o paradigma orientado a objeto do qual tem poder com o uso da linguagem Java. Os componentes de software do Direto possuem um alto grau de acoplamento entre si, o que torna a sua manutenção difícil e o prejudica em relação à escalabilidade. O Java 2 Platform, Enterprise Edition (J2EE) é uma especificação para uma plataforma de desenvolvimento de aplicações corporativas, baseada na linguagem Java, da Sun Microsystems. Esta plataforma possibilita o desenvolvimento de aplicações com elevado grau de modularidade e escalabilidade. Isto se deve ao fato da plataforma prover à aplicação uma variedade de serviços de baixo nível, como o modelo de segurança JAAS. Estes serviços permitem o desenvolvimento de componentes de software reusáveis, focados apenas na lógica de negócio. Em conseqüência, ganha-se também em produtividade de desenvolvimento. Como parte do Projeto Direto, parceria da PROCERGS com diversas universidades gaúchas, entre elas a UFRGS, este trabalho propõe uma alternativa de modelagem à arquitetura de componentes do Direto, baseada na plataforma J2EE. O estudo resulta na prototipação de um sistema que reúne um subconjunto das funcionalidades presentes no módulo de catálogo do Direto integrado a um módulo de autenticação baseado na tecnologia JAAS. O principal objetivo é mostrar os diversos ganhos que uma aplicação do modelo do Direto pode obter com a adoção da plataforma J2EE. No capítulo 2, é apresentado o software Direto. Neste capítulo, mostramos seu histórico e suas metas iniciais e explicamos a sua arquitetura. Em seguida, são caracterizadas as dificuldades que o sistema enfrenta e as áreas de pesquisa envolvidas. No capítulo 3, é apresentada a plataforma J2EE. São detalhados todos os aspectos relevantes da plataforma, como tecnologias e a especificação EJB.

10 10 No capítulo 4, se introduzem brevemente alguns conceitos relativos à modelagem de sistemas, como modularidade e a linguagem UML, utilizados no capítulo seguinte. No capítulo 5, é proposta uma alternativa de modelagem do catálogo do Direto, incorporando as funções de autenticação. Para tanto, são explicados problemas do modelo atual do Direto e mostradas passo a passo as decisões tomadas para a modelagem tanto do módulo de autenticação quanto do módulo de catálogo. São também destacadas características do ambiente utilizado e limitações da modelagem. No capítulo 6, apresenta-se o protótipo desenvolvido com base na modelagem proposta. Explicam-se as configurações de ambiente necessárias à aplicação e o funcionamento do protótipo em si.

11 11 2. O Direto 2.1 Introdução O Direto é um sistema de agenda, catálogo e correio corporativos desenvolvido pela PROCERGS, Companhia de Processamento de Dados do Estado do Rio Grande do Sul. A PROCERGS é o órgão responsável pelo fornecimento de soluções de infraestrutura de tecnologia da informação para o governo do Rio Grande do Sul. Seu principal objetivo no desenvolvimento do Direto foi fornecer ao Estado uma alternativa de software de agenda, catálogo e correio corporativos financeiramente viável, capaz de servir os aproximadamente 200 mil servidores do Estado. Os diversos órgãos do governo até então contavam com duas soluções proprietárias distintas para o correio eletrônico: Lotus Notes, da Lotus, e Memo, da Eurosoft. Estes softwares não ofereciam todos os recursos necessários, além de contar com interfaces gráficas obsoletas. O Direto surgiu como uma alternativa barata para a padronização da ferramenta de correio dos servidores, essencial para melhor comunicação interna e externa, além de fornecer recursos de catálogo e agenda corporativos também essenciais ao Estado. O baixo custo do Direto justifica-se por possuir licença de software livre e basear-se totalmente em tecnologias como Java, Apache, Tomcat, OpenLDAP e PostgreSQL, baseadas na filosofia de software livre.. Quando do início da sua fabricação, em julho de 1999, os requisitos de desenvolvimento do Direto [BAL02] eram os seguintes:! Seguir protocolos padrão Internet.! Independência de plataforma no cliente e no servidor.! Prover independência de Gerenciador de Banco de Dados.! Prover independência de Servidor Web.! Ser modular, ou seja, permitir que novas funcionalidades pudessem ser adicionadas no futuro.! Possuir custo baixo. O Direto foi desenvolvido como um sistema web, contando com interface gráfica utilizável por qualquer navegador HTML, o que garantiu sua independência de plataforma no cliente. Além disso, baseando-se em Java, foi possível atingir diversos objetivos, como:! o uso de protocolos padrão da Internet, aos quais Java tem suporte a maioria;

12 12! independência de SGBD, garantido pelo JDBC, API Java de acesso a bancos de dados relacionais;! baixo custo, por Java ser gratuito e contar com ferramentas de desenvolvimento e servidores web que a suportem também gratuitos;! e a modularidade, pela semântica da linguagem induzir ao desenvolvimento de aplicações mais modulares. Este último ponto é discutível e é um dos pontos do trabalho. 2.2 Arquitetura A arquitetura do sistema é formada por diversos módulos, conforme mostra a figura abaixo. Figura Arquitetura do Direto fonte: [BAL02] Cliente web O cliente web é qualquer aplicativo capaz de visualizar páginas web. É por meio de um aplicativo deste tipo que o usuário utiliza o Direto, que possui sua interface totalmente em HTML.

13 Servidor Web O servidor web é o responsável pela comunicação com os clientes web por meio do protocolo HTTP e envio das páginas HTML e outros arquivos que compõem a interface, como figuras e scripts. No servidor web que são executados os servlets Java do Direto, responsáveis por gerar as páginas dinâmicas que são enviadas ao navegador. Atualmente é usado o servidor web Apache integrado ao servidor Tomcat, responsável pelo suporte Java. É o Tomcat quem transfere as requisições do cliente para as Servlets da aplicação Servlets Java Camada de tratamento das requisições do cliente. Baseado em Java Servlets para geração de conteúdo dinâmico para a interface gráfica, os servlets fazem a comunicação com os módulos de negócio do Direto e geram a saída para o browser usando tecnologia XML e XSLT XML A Extended Markup Language é uma linguagem de marcação própria para a representação de dado estruturados e semi-estruturados. O XML é um padrão mundialmente aceito para representação de informações e intercâmbio de dados entre aplicações. No Direto ele é usado em conjunto com o XSLT para gerar a interface HTML. O Direto usa a API JAXP do Java para fazer processar documentos XML e fazer transformações XSLT XSLT A Extensible Stylesheet Language Transformation é uma tecnologia que permite aplicar regras a um documento de modo a gerar um segundo documento. As regras são contidas em um arquivo XSL (Extensible Stylesheet Language). No caso do Direto, os arquivos XSL contêm as informações sobre a interface e o XML contém os dados que serão mostrados. A transformação XSLT gera um documento HTML resultante da fusão dos dados com a interface contida por meio de regras no arquivo XSL. Desta forma atingese uma separação entre dados e apresentação Módulos Java Nos módulos Java que se encontram as classes que contém a lógica dos serviços de correio, agenda e catálogo do Direto. Nesta camada que é feita a comunicação com os

14 14 sistemas que dão suporte ao Direto, usando os respectivos protocolos específicos de cada serviço, e suportados por uma API Java correspondente POP3 POP3 (Post Office Protocol versão 3) é um protocolo padrão de acesso a mensagens de correio eletrônico. Por meio dele, programas clientes acessam servidores de mensagens onde estão armazenados os s. Seu funcionamento consiste basicamente na realização da conexão com o servidor e na requisição de cada mensagem armazenada. O Direto tem suporte a POP3, embora as versões em uso estejam dando preferência ao IMAP IMAP4 O IMAP4 (Internet Message Access Protocol versão 4) é um protocolo alternativo ao POP3. Ele possui algumas funcionalidades extras como atribuição de diversos atributos às mensagens e manipulação de pastas no servidor. O IMAP é o protocolo preferido nas versões instaladas do Direto hoje. No sistema, o servidor IMAP é integrado ao LDAP para efetuar a autenticação dos usuários. O acesso a mensagens no Direto, por parte dos módulos Java, é feito por uma API específica para IMAP e POP baseada no padrão JavaMail SMTP O Simple Message Transfer Protocol é um protocolo para envio de mensagens de correio eletrônico. Consiste na conexão por parte de um cliente do serviço a um servidor que implemente o protocolo, ao qual o cliente envia uma mensagem. O servidor é encarregado de remeter a mensagem eletrônica a todos os seus destinatários. No Direto, a comunicação com SMTP é realizada através de uma API específica baseada no JavaMail LDAP O LDAP (Lightweight Directory Access Protocol) é um protocolo de acesso a serviços de diretório. Baseia-se em um subconjunto de funcionalidades do DAP (Directory Access Protocol). Serviços de diretório baseiam-se na organização de informações de maneira hierárquica, onde é possível realizar consultas nos dados com base em seus atributos. Serviços de diretório são comumente otimizados para operações de consulta.

15 15 Pelo Java, o acesso ao LDAP é feito através da API JNDI, adiante explicada em mais detalhes. Versões instaladas do Direto atualmente costumam utilizar o OpenLDAP como servidor LDAP JDBC A Java Database Connectivity é a API padrão Java para acesso a gerenciadores de bancos de dados. Serve como uma interface de programação única para acesso a qualquer SGBD que implemente um driver JDBC. Esta API é usada pelo Direto para acesso ao banco de dados. Versões instaladas do Direto costumam usar o PostgreSQL, SGBD gratuito com licença de software livre vcalendar O vcalendar é uma especificação de formato de informações de agenda. O Direto tem suporte à importação e exportação de dados da agenda que obedecem este formato. 2.3 Situação Atual O Direto, hoje, ainda não foi capaz de atingir o objetivo inicial de atender 200 mil servidores do estado de maneira integrada. O sistema barra na questão de performance de características de sua arquitetura. Atualmente, para atender aproximadamente 5 mil servidores, são necessárias máquinas de última geração para hospedar o sistema. Claramente a questão da performance mostra-se hoje como uma das áreas de pesquisa vitais para o projeto. A principal causa destacada para o problema de performance situase no processamento XSLT da camada de apresentação, responsável por consumir muito processamento. Entretanto, o atendimento de 200 mil servidores é baseado em um modelo distribuído ainda não implantado no Direto. No contexto atual do sistema, as áreas de estudo mais importantes são as que envolvem aspectos de distribuição, como transações distribuídas e remodelagem da arquitetura do Direto. A área de segurança também se destaca entre áreas de pesquisa bastante ativas. Além disso, o Direto é carente em relação à sua documentação. Tanto o manual do usuário como a documentação de sua API são muito pobres. Enfim, hoje o sistema hoje se depara com algumas questões que o impedem de atingir suas metas iniciais, e para as quais este trabalho busca contribuir com soluções. Amparado pelo Projeto Direto, parceria da PROCERGS com diversas universidades gaúchas, o sistema é beneficiado pelo estabelecimento de várias frentes de pesquisa direcionadas às áreas mencionadas.

16 16 3. Java 2 Platform, Enterprise Edition O Java 2 Platform, Enterprise Edition (J2EE) é uma especificação para uma plataforma de desenvolvimento de aplicações corporativas, baseada na linguagem Java da Sun Microsystems. Esta plataforma provê para a aplicação uma variedade de serviços como , diretório, banco de dados, comunicação por mensagens, segurança, processamento XML e gerenciamento de transações, entre outras. O provimento destes serviços em conjunto com a tecnologia Enterprise Java Beans permite ao desenvolvedor de aplicações J2EE concentrar-se apenas na lógica do negócio, desenvolvendo aplicações distribuídas e multicamada. Esta característica desempenha a principal motivação no uso do J2EE: a facilidade de desenvolvimento de componentes de negócio reusáveis. Em conseqüência deste modelo, ganha-se em produtividade de desenvolvimento e escalabilidade das aplicações. Para entender J2EE, é necessário entender os conceitos de container envolvidos na tecnologia, os diversos papéis desempenhados em relação à plataforma, suas diversas tecnologias envolvidas e, principalmente, a tecnologia Enterprise Java Beans, elemento central do modelo. 3.1 Arquitetura Figura Arquitetura da plataforma J2EE

17 17 A plataforma J2EE é definida por três componentes fundamentais: o J2EE Server, o Web Container e o EJB Container J2EE Server O J2EE Server provê os seguintes serviços [SUN00]:! Nomeação e diretório: permite as aplicações localizarem serviços e componentes através da API JNDI;! Autenticação: reforça a segurança obrigando a autenticação dos usuários;! HTTP: permite a navegadores web acessarem componentes servlets e páginas JSP;! EJB: permite clientes fazerem acesso a métodos de componentes EJB EJB Container O EJB Container é responsável por encapsular os enterprise beans, provendo um ambiente de execução para os mesmos que oferece uma importante variedade de serviços. Desta forma, desenvolvedores de enterprise beans podem se concentrar na lógica de negócio dos componentes. O container dispõe os seguintes serviços:! gerenciamento de transações: o container gerencia transações ao nível da plataforma, permitindo o uso de transações distribuídas;! segurança: o container impõe controle de acesso ao nível dos métodos dos EJBs, certificando-se da identidade do cliente;! comunicação remota: o container gerencia a comunicação remota entre componentes, deixando transparente a sua localização na rede.! gerenciamento do ciclo de vida: o container coordena a transição entre os vários estados que um enterprise bean pode assumir;! pooling de conexões de banco de dados: o container gerencia o uso de conexões a banco de dados provendo o seu reaproveitamento, por uma conexão tratar-se de um recurso de alto custo Web Container O Web Container é o ambiente de execução para servlets e páginas JSP. As tecnologias Servlet e JSP são explicadas na seção 3.3.

18 Papéis Na plataforma J2EE são definidos papéis bem distintos desempenhados durante o clico de desenvolvimento de uma aplicação. Alguns papéis são facilmente identificáveis em outras plataformas, mas outros são peculiares ao J2EE. Embora se identifiquem muitos papéis distintos, nem sempre eles serão desempenhados por pessoas ou equipes diferentes Fornecedor de Produto J2EE Empresa que desenvolve um produto quem implemente as especificações da plataforma J2EE. São tipicamente empresas desenvolvedoras de sistemas operacionais, gerenciadores de bancos de dados, servidores web ou servidores de aplicações Fornecedor de Ferramenta J2EE É a pessoa ou empresa que desenvolve as ferramentas usadas pelos desenvolvedores de componentes, assemblers e deployers para desempenharem suas funções Desenvolvedor de Componente EJB O desenvolvedor de EJB é quem fornece enterprise bean documentados através de seus descritores e empacotados em arquivos JAR Desenvolvedor de Componente Web O desenvolvedor de componente web é responsável por fornecer componentes baseados em Servlet ou JSP, empacotados em arquivos WAR junto com um descritor que os documenta Desenvolvedor de Aplicação Cliente J2EE O desenvolvedor de aplicação cliente fornece uma aplicação cliente da plataforma empacotada em um arquivo JAR em conjunto com o seu arquivo descritor Compilador da Aplicação (Application Assembler) O Application Assembler é o responsável por empacotar todos os componentes que formam a aplicação, e configurá-la em relação às características especificas do ambiente operacional na qual será instalada e ao domínio do problema do qual a aplicação tratará Deployer e Administrador da Aplicação O deployer é o responsável por configurar, instalar e administrar a aplicação J2EE. É dele a responsabilidade por gerenciar a infra-estrutura que mantém a aplicação.

19 Enterprise Java Beans Enterprise Java Beans são componentes de aplicação focados na lógica do problema para o qual a aplicação se destina a resolver. Define-se esta lógica como lógica de negócio. Por esta razão, EJBs são chamados de componentes de negócio. Por serem providos pelo EJB Container de um ambiente de execução que fornece uma série de serviços de sistema essenciais, o código do componente torna-se muito mais ligado à lógica de negócio. Entre as características básicas de componentes de negócio, estão [SUN02]:! a necessidade de se manter um estado, seja persistente, ou que dure o tempo de uma conversação com um cliente;! o acesso a dados compartilhados, necessitando controle de acesso e níveis de isolamento entre componentes;! a participação em transações, onde diferentes componentes de negócio participam da realização de uma tarefa atômica;! o provimento de serviços a vários clientes simultâneos, necessitando um controle de instâncias do componente de modo a atender todos os clientes;! a disponibilidade, estando acessível ao cliente mesmo em casa de falhas no sistema;! permitir acesso remoto a suas funções, implicando existência de uma infraestrutura que suporte a comunicação;! controle de acesso, certificando-se da identidade do cliente e estabelecendo restrições de acesso com base nela;! ser reusável, provendo serviços a diferentes componentes da mesma aplicação ou de outras aplicações. A especificação da plataforma J2EE provê aos enterprise beans todas estas características Interfaces Como os enterprise beans são encapsulados e gerenciados pelo EJB Container, não é possível a clientes acessarem diretamente um EJB. A única forma de um cliente criar instâncias de um componente e acessar seus serviços é através de duas interfaces, chamadas interface home e interface do componente. Na classe de um enterprise bean é definida a sua lógica. No entanto, para um serviço estar disponível, ele deve ser definido na sua interface home ou de componente.

20 Interface Home A interface home é a responsável por prover os serviços de criação e remoção de instâncias do componente. Estes serviços são definidos pelos métodos create e remove. É possível existir mais de um método create, cada um possuindo diferentes parâmetros de forma a garantir flexibilidade na criação de uma instância. Os métodos create e remove devem possuir uma implementação na classe do bean que se chame respectivamente ejbcreate e ejbremove. A interface home também é responsável por serviços de pesquisa e serviços que manipulam múltiplas instâncias do EJB. Estes últimos são chamados de métodos de negócio da interface home. Estes métodos são citados a seguir Métodos de consulta Os métodos de consulta, chamados finders, são responsáveis pela localização de uma instância ou um conjunto de instâncias com base em critérios de busca. Toda interface home deve definir ao menos o método findbyprimarykey, responsável por devolver uma instância dada a sua chave primária. É definido que todo método finder deve conter o prefixo find. Cada método finder presente na interface home deve possuir o mesmo método definido na classe do bean. Ou seja, se a interface home possui os métodos findbyprimarykey e findbyaddress, os mesmos métodos devem possuir uma implementação na classe deste bean Métodos de negócio Os métodos de negócio da interface home destinam-se à lógica do programa que não é específica a uma instância individual. Cada método de negócio na interface home deve possuir uma implementação na classe do bean Interface do Componente A interface do componente define a visão do cliente para uma instância do enterprise bean. É nela que se concentram os métodos de negócio aplicáveis a instâncias individuais. A exemplo da interface home, cada método definido na interface do componente deve possuir uma implementação na classe do bean. A diferença é que os métodos da interface do componente geralmente acessam diretamente os atributos do bean, que definem seu estado. Métodos da interface home não podem acessar os atributos do bean, porque não estão associados a nenhuma instância.

21 21 Figura Interfaces como visão do cliente Visão Remota versus Visão Local Quando especificada a interface de um componente, pode-se definir se os clientes terão uma visão remota ou uma visão local, ou ambas. Um componente tem sua visão definida como remota quando se pretende que seja usado em um sistema distribuído, onde componentes remotos na rede façam acesso a seus serviços. Como grande vantagem neste modelo está a transparência de localização dos componentes. Entretanto este modelo possui algumas limitações de performance por tratar de comunicação no ambiente de rede, mesmo que ambos o cliente e o bean estejam em uma mesma localização. A visão local tem como principal vantagem a redução de overhead em relação à visão remota e um conseqüente ganho de performance. Desta forma o cliente pode fazer acesso local direto aos métodos definidos nas interfaces do bean. Este modelo, no entanto, elimina a transparência de localização obtida com a visão remota. Clientes devem estar localizados na mesma máquina virtual que o bean e devem saber disso. Para a visão local, o componente define uma interface home local e a interface local do componente Para visão remota, ele deve definir a versão remota das interfaces. Um componente pode também implementar ambas as visões, permitindo acesso remoto e local. Para tanto, ele deverá definir a interface home local, interface home remota, interface local do componente e interface remota do componente A tabela abaixo identifica a qual classe deve pertencer cada tipo de interface.

22 22 Tabela Classes das interfaces Interface home local local home remota remota Classe javax.ejb.ejblocalhome javax.ejb.ejblocalobject javax.ejb.ejbhome javax.ejb.ejbobject Session Bean Session bean é uma categoria de enterprise bean que não representa dados persistentes e compartilhados na aplicação. O estado de um session bean reflete unicamente a conversação dele com um cliente. Adicionalmente session beans podem ser classificados entre stateful e stateless Stateful Um stateful session bean mantém um estado ao longo de toda a conversação com um cliente. Seu tempo de vida é tipicamente o tempo de vida de seu cliente [SUN02]. Como seus dados não são persistidos, o EJB Container é responsável por manter o estado de um stateful session bean durante o seu tempo de vida, o que, em alguns casos, pode ter reflexo na performance do sistema Stateless Stateless session beans não possuem estado. Seu estado basicamente se resume ao intervalo de execução de um serviço invocado pelo cliente. Por esta razão, stateless session beans são facilmente manipuláveis pelo EJB Container uma vez que podem ser criados e descartados após o uso Message-Driven Bean O message-driven bean foi introduzido apenas na especificação EJB 2.0. Este bean tem um comportamento diferente dos demais. Baseado na tecnologia Java Messaging Service para comunicação por mensagens, este bean se comporta como um consumidor assíncrono de mensagens. Message-driven beans não possuem interfaces que os tornem visíveis a outros clientes. Eles possuem apenas um método, onmessage, responsável por tratar qualquer tipo de mensagem que chegue ao bean.

23 Entity Bean Ao contrário de session beans, entity beans representam um dado persistente e compartilhado. Entity beans englobam dados na forma de objetos e permitem o acesso de múltiplos clientes simultâneos. Desta forma, os dados da organização são modelados de um modo reusável e independente da camada de persistência. Para desenvolvedores habituados com modelagem Entidade-Relacionamento, é comum o mapeamento de entidades para entity beans, já que uma entidade no modelo ER representa um dado persistente e manipulável da organização. A persistência de enterprise entity beans pode ser feita tanto de forma programática, implementada no código do componente, quanto de forma declarativa, gerenciada pelo EJB Container Bean-Managed Persistence Ao modelo de persistência implementado diretamente na classe do entity bean é dado o nome de bean-managed persistence. Neste modelo, o desenvolvedor se responsabiliza por escrever as rotinas de acesso a banco de dados ou a qualquer outro serviço de persistência. Bean-managed persistence requer uma modelagem cuidadosa, que tenha o objetivo de não tornar um entity bean dependente de sua camada de persistência. Por essa razão, muitas vezes são usadas classes auxiliares responsáveis apenas pelo acesso à camada de persistência do bean. Assim, alterações no serviço de persistência, como troca de SGBD, implicariam mudanças apenas na classe que implementa o acesso Container-Managed Persistence Container-managed persistence é o nome dado ao serviço de gerenciamento de persistência de entity beans provido pelo EJB Container. A opção de modelar um entity bean com container-managed persistence retira do desenvolvedor a responsabilidade de codificar o acesso à camada de persistência, simplificando significativamente o processo de desenvolvimento de entity beans. Esta é a razão pela qual este modelo é incentivado, em detrimento de bean-managed persistence, aconselhado apenas no caso de o desenvolvedor necessitar de maior controle sobre a persistência. Por este modelo, o desenvolvedor limita-se a indicar, através do descritor de instalação do bean, os atributos da classe que devem ser persistidos Sincronização Tanto para bean-managed quanto para container managed persistence, toda vez que o container necessita sincronizar os dados do bean com a camada persistente ele invoca

24 24 os métodos ejbload e ejbstore. No caso de bean-managed persistence, são nesses métodos que devem ser escritas as rotinas de acesso a camada persistente Ciclo de Vida Conhecer o ciclo de vida de um enterprise bean é fundamental para o seu desenvolvimento. Nesta seção explica-se rapidamente como o EJB Container controla o ciclo de vida de cada um dos tipos de beans [SUN02a] Stateful Session Bean Quando um cliente invoca o método create de um session bean, o EJB Container invoca os métodos setsessioncontext, que inicializa um contexto para o objeto, e o método ejbcreate. O session bean se encontra então no estágio pronto, onde pode ter seus métodos de negócio invocados. Figura Ciclo de vida de um stateful session bean fonte: [SUN02a] Enquanto se encontra no estágio pronto, o bean pode ser posto em modo passivo pelo container, caso precise liberar recursos. Imediatamente antes de o bean ser posto em modo passivo, seu método ejbpassivate é invocado.quando retirado do estágio passivo, seu método ejbactivate é invocado. Quando o cliente não necessitar mais do session bean, ele invoca o método remove. O container então invoca o método ejbremove do bean e ele é liberado para o serviço de garbage collection Stateless Session Bean Como um stateless session bean não possui um estado a ser mantido, seu ciclo de vida é muito mais simples. O container é responsável por criar e remover os componentes sem

25 25 que seja indicado pelo cliente. Do ponto de vista do cliente, entretanto, os métodos create e remove são invocados da mesma forma, mas não garantem que o container irá efetivamente criar nova instância ou remover a instância indicada. Figura Ciclo de vida de um stateless session bean fonte: [SUN02a] Message-Driven Bean Similarmente ao ciclo de vida do stateless session bean, um message-driven bean não possui estado e por isso nunca é movido para o estágio passivo. No início do ciclo de vida, o container associa um contexto a uma instância de message-driven bean, geralmente retirada de um pool de instâncias, e invoca os métodos setmessagedrivencontext e ejbcreate. O bean torna-se pronto para consumir mensagens, através do método onmessage. Figura Ciclo de vida de um message-driven bean fonte: [SUN02a]

26 26 O ciclo de vida termina quando o container invoca o método ejbremove e torna a instância disponível para o serviço de garbage collection Entity Bean O ciclo de vida de um entity bean começa quando o container cria uma instância e associa um contexto a ela, através do método setentitycontext. O bean é então movido para um pool de instâncias, onde nenhuma instância possui uma identidade. Quando o cliente invoca o método create, o container invoca os métodos ejbcreate e ejbpostcreate e move o bean para o estado pronto. Figura Ciclo de vida de um entity bean fonte: [SUN02a] No estado pronto o bean pode ter seus métodos de negócio invocados. O container pode movê-lo de volta ao pool de instâncias, invocando o método ejbpassivate, caso necessite liberar recursos. Caso o bean seja requerido, o container invoca seu método ejbactivate e o põe no estado pronto novamente. Quando o cliente invoca o método remove, o bean tem seu método ejbremove invocado pelo container é enviado de volta ao pool. No fim do ciclo de vida, o container invoca o método unsetentitycontext e libera a instância para o garbage collection.

27 Descritor de instalação Um enterprise bean não é formado somente pela sua classe e interfaces, mas também por um arquivo XML, chamado descritor de instalação (do inglês, deploy descriptor). Este descritor contém informações de configuração como outros EJBs ou recursos externos de que faz uso, aspectos de segurança, transação e parâmetros de ambiente. São informações dependentes do ambiente operacional que se localizam no descritor para garantir a portabilidade do componente. Por esta razão, o descritor é peça chave na instalação do componente. 3.3 Tecnologias e Serviços Para entender a plataforma J2EE, é necessário conhecer as tecnologias e os serviços nela presentes. Esta seção busca dar uma visão geral sobre as tecnologias e serviços presentes na arquitetura Servlets A tecnologia Java Servlet permite ao desenvolvedor criar classes específicas para comunicação HTTP. Servlets agem como servidores HTTP onde são acessadas por meio de um modelo requisição-resposta (request-response). Servlets são usadas tipicamente em sistemas web, onde há a presença de um servidor web Java Server Pages Java Server Pages, ou JSP, surgiu como uma forma de construir aplicações web que utilizam a tecnologia Java Servlet mais facilmente. Uma página JSP é um documento que contém trechos de código Java, dados estáticos em formato texto (tipicamente HTML), e elementos JSP. Elementos JSP são tags especiais, presentes no código, que determinam como a página vai ser construída. Estes elementos têm seu uso estimulado em substituição aos trechos de código Java, como meio de separar lógica e apresentação em documentos JSP. A exemplo de Servlet, documentos JSP ficam presentes em um servidor web. Quando requisitados por um cliente web, o documento JSP é transformado em uma classe Servlet, compilado e executado.

28 JavaMail JavaMail é a API para envio e recebimento de mensagens de correio eletrônico através de uma aplicação Java. Por meio dela é possível acessar servidores SMTP, POP3 e IMAP Java API for XML Processing O Java API for XML Processing, ou JAXP, define uma API Java para o uso das tecnologias DOM, SAX e XSLT para processamento XML. A tecnologia DOM (Document Object Model) define uma API que permite a navegação e manipulação de um documento XML na forma de árvore. Como documentos XML possuem uma estrutura hierárquica, este modelo é bastante intuitivo para manipulação de dados XML. SAX (Simple API for XML) define uma API para processamento XML baseada em eventos. Enquanto o documento XML é processado, são disparados eventos como início da tag, fim da tag, erro, etc. A aplicação pode então definir o comportamento do programa para cada tipo de evento. A tecnologia XSLT, como explicado no capítulo sobre o Direto, permite a aplicação de regras contidas em um documento XSL a qualquer tipo de entrada de texto, de modo a gerar um documento de saída. Para usar o JAXP, é necessário obter uma implementação, ou parser, para cada uma dessas tecnologias Java Database Connectivity JDBC é a API Java para conexão a bancos de dados relacionais. Seu principal objetivo é tornar transparente a aplicação o serviço interno que está sendo utilizado, neste caso, o gerenciador de banco de dados. Para a conexão a um banco de dados, é necessário obter um driver JDBC para o banco de dados em específico. É comum que o próprio fabricante do gerenciador de banco de dados forneça um driver JDBC junto com o produto. JDBC encontra-se hoje na versão 3.0. A partir de sua versão 2.0, foi especificado um suporte opcional a transações JTA (ver adiante) e a connection pooling, além de um novo objeto responsável pelo fornecimento de conexões: DataSource. Antes do objeto DataSource, a obtenção de conexões de banco de dados era feita através da classe DriverManager. Esta classe induzia a definição das configurações da conexão diretamente no código da aplicação. O DataSource soluciona este problema por

29 29 encapsular as configurações de conexão e centralizar o acesso ao banco. Sendo registrado em um serviço de diretório através da API JNDI, ele torna-se visível para todas aplicações. Por centralizar o acesso, se omite das aplicações alterações de configuração que se façam necessárias. A última versão do JDBC, 3.0, inclui suporte a pooling de consultas e uma especificação de migração da arquitetura JDBC para o Java Connector Architecture Java Message Service - JMS O JMS é uma API para comunicação por mensagens entre componentes de software para a plataforma Java. Comunicação por mensagens baseia-se em programas clientes que se conectam a um serviço de mensagens tornando possível o envio e o recebimento de mensagens entre os mesmos. Uma das principais vantagens deste tipo de comunicação é a de que para o envio de mensagens não é necessário tanto ao transmissor quanto ao receptor conhecer um ao outro. Isto permite um baixo acoplamento entre os componentes e uma conseqüente maior flexibilidade à aplicação, pois componentes podem ser substituídos sem grandes traumas. O JMS permite que aplicações Java utilizem diferentes sistemas de mensagens através de uma única API. Em conjunto com o JMS, na versão 1.3 do J2EE surgiu o Message-driven Bean, EJB capaz de consumir mensagens JMS assincronamente. Além disso, envios e recebimentos de mensagens podem também fazer parte de transações distribuídas no J2EE Java Naming and Directory Interface JNDI O JNDI é uma API para acesso a serviços de nomes e de diretório, independente da implementação do serviço Serviço de Nomes Serviço de nomes é um serviço essencial para qualquer sistema, por oferecer uma maneira de associar nomes a objetos. Isso torna possível a obtenção de qualquer objeto a partir do seu nome. Serviço de nomes é um conceito bastante genérico que se aplica a um vasto número de tecnologias hoje existentes. O serviço de , por exemplo, mapeia endereços a pessoas reais. Da mesma forma o DNS mapeia URLs a endereços IP. Um sistema de arquivos, da mesma forma, associa nomes a arquivos. Sistemas de nome normalmente se diferem em relação à convenção de nomes utilizada. Um nome em DNS é algo do tipo para um sistema de arquivos c:\windows\command.com e em LDAP o=comframe, c=us. As

30 30 operações básicas neste tipo de sistema são a associação de um objeto a um nome e a obtenção de um objeto com base no nome Serviço de Diretório Serviços de diretórios são extensões de serviços de nomes, permitindo a um objeto ter, além de um nome, outros atributos associados. Desta forma é possível obter atributos de um objeto e fazer a busca de objetos baseado nos seus atributos. Em um catálogo de biblioteca, por exemplo, buscando pelo nome de um livro obtemos uma referência ao local da biblioteca onde o livro se encontra, exemplo típico de um serviço de nomes. Mas através deste catálogo também é possível saber do livro qual o seu autor, ano de edição e editora, e fazer pesquisas com base nestes atributos. Esses recursos caracterizam um serviço de diretório. As operações básicas de um serviço de diretório consistem na adição, modificação e inserção de atributos de um objeto, além da busca baseada nos seus atributos O JNDI O JNDI é usado tanto como API padrão para acesso a serviços de diretórios existentes, como para localizador de objetos Java. Neste papel, o JNDI desempenha uma das funções centrais da plataforma J2EE, que torna possível a localização remota de componentes J2EE Connector Architecture - JCA O JCA, presente na versão 1.3 do J2EE, veio como solução para o problema de integração de sistemas de informação corporativos com a plataforma J2EE. Antes do JCA, era necessário implementar soluções específicas para a integração de servidores de aplicação J2EE com sistemas de informação existentes. Cada caso resultava em adaptações específicas a cada caso em ambos os produtos. O JCA faz parte do J2EE versão 1.3 O JCA define uma arquitetura padrão que permite ao fabricante de um sistema de informação corporativo desenvolver um adaptador para o seu sistema. Este adaptador faz a ligação entre o sistema de informação corporativo e qualquer servidor de aplicação que suporte o JCA. A arquitetura define um conjunto de contratos entre o servidor de aplicações e o sistema corporativo. O adaptador é a implementação da parte que cabe ao SIC dos contratos. Este conjunto de contratos busca deixar transparente as aplicações J2EE questões de segurança, transação e gerenciamento de conexões inerentes a cada SIC.

31 Segurança A plataforma J2EE provê duas metodologias de segurança: programática e declarativa. A programática é baseada na API JAAS descrita em seguida. A declarativa provê um meio definir a estrutura de segurança numa forma externa à aplicação. Características de segurança, como permissões de acesso, podem ser especificadas nos descritores dos componentes. A forma declarativa tem como grande vantagem a possibilidade de definir os atributos de segurança de componentes para cada ambiente em que for instalado. Um dado EJB, por exemplo, pode receber diferentes níveis de acesso a um banco de dados, bastando definir esta informação no seu descritor Java Authentication and Authorization Service Java Authentication and Authorization Service, o JAAS, define um modelo de segurança para aplicações Java que independe do ambiente em que a aplicação está sendo instalada. Isso se dá através da API do JAAS que omite da aplicação características de segurança peculiares a cada ambiente. Introduzido primeiramente no J2SDK v1.3 (Java 2 Software Development Kit) como pacote opcional e integrado ao J2SDK v1.4, ele é baseado no framework Pluggable Authentication Module (PAM) [SAM02]. O JAAS possui 2 propósitos básicos:! autenticação, obtendo a certificação de quem está usando a aplicação;! autorização, definindo as permissões de acesso aos diversos recursos da aplicação com base na identidade do usuário autenticado. Java 2 provia controle de acesso apenas ao nível do recurso e da entidade que certificava o recurso. O JAAS define um framework que refina o modelo tradicional de segurança do Java 2, introduzindo o aspecto de segurança baseado em quem está utilizando a aplicação Subject, Principal e credencial No JAAS existe a classe Subject, que é a representação de uma entidade autenticada no sistema. Esta entidade pode ser tanto um usuário final, quanto um processo ou um dispositivo. A classe Principal representa uma identidade que o Subject pode assumir. Um Subject pode possuir mais de um Principal associados em um mesmo momento. Como exemplo, um Subject pode conter um Principal que representa o nome de usuário dbadmin para acesso a um banco de dados, e um Principal representando o usuário guest para acesso a um servidor de FTP.

32 32 Credenciais são objetos que representam informações como senha, chave pública, nome ou CPF. São categorizadas como públicas e privadas, onde credenciais privadas são geralmente senhas e chaves privadas Módulos de Login A autenticação consiste em módulos plugáveis, responsáveis pela autenticação do usuário com base nos aspectos do ambiente da aplicação. Estes módulos são classes que implementam a interface LoginModule definida no JAAS. A aplicação responsabilizase apenas por realizar a interação com o usuário de forma a obter as informações de autenticação. O J2SE 1.4 vem com 4 módulos de login implementados para autenticação em ambiente NT, Unix, utilizando o protocolo Kerberos e utilizando um serviço de diretório através do JNDI. Figura Modelo de autenticação do JAAS fonte: [MUS02] Arquivo de Configuração de Login A autenticação baseia-se em um arquivo de configuração contendo as informações sobre os módulos de login. Este arquivo contém seções, identificadas por um nome,

33 33 geralmente o nome da aplicação. Cada seção possui uma lista de módulos de login. No momento da autenticação, a aplicação define qual das seções ela fará uso fornecendo a chave correspondente. admin { exemplo.modulo.database required debug=true; exemplo.modulo.impressaodigital required debug=true fingerprintdriver=com.someinc.fingerprint.driver; }; publico { exemplo.modulo.database required debug=true; }; Acima temos o exemplo de um trecho de arquivo de configuração de login. Vemos que na primeira seção, chamada admin, estão listados dois módulos de login. Os dois módulos têm o atributo required, significando que ambos são necessários para que a autenticação seja efetuada. Os demais atributos encontrados são parâmetros passados para os módulos de login. O atributo debug=true geralmente diz ao módulo que imprima informações de depuração na saída padrão CallbackHandler e Callbacks Quando a aplicação realizar a autenticação do usuário, ela fornece um objeto que implemente a interface CallbackHandler. Este objeto é responsável por realizar a interação com o usuário a fim de obter as informações de login. Estas informações podem ir desde nome de usuário e senha, até dados de biometria, por exemplo, caso o login envolva este tipo de certificação. O modelo não impõe restrições neste respeito. Como a interação com o usuário é de responsabilidade da aplicação, faz sentido que ela seja responsável por fornecer o CallbackHandler. Os módulos de login então o utilizam para obter os dados necessários. As informações de autenticação são encapsuladas em objetos Callback, fornecidos por cada módulo de login, e inicializados pelo CallbackHandler. O JAAS vem com um pequeno conjunto de Callbacks e CallbackHandlers já implementados Processo de autenticação Para realizar a autenticação, a aplicação faz uso do objeto LoginContext, ao qual indica uma seção do arquivo de configuração, e fornece o objeto CallbackHandler. O LoginContext cria, então, um novo Subject sem credenciais e Principals associados. Invocando-se o método login do objeto LoginContext, ele comunica-se com todos os módulos de login configurados para a seção escolhida. Cada módulo de login recebe uma referência ao objeto CallbackHandler e o utiliza para tentar autenticar o usuário.

34 34 Após todos os módulos de login tentarem efetuar autenticação, o LoginContext determina se o processo de autenticação como um todo foi bem sucedido. Para isso ele toma como base os atributos definidos para cada módulo de login no arquivo de configuração. Se todos os módulos são considerados requeridos (atributo required), é necessário que todos tenham conseguido realizar a autenticação individualmente para que o processo tenha sucesso. Se a autenticação como um todo foi bem sucedida, o LoginContext força os módulos de login a finalizarem o processo, associando os Principals e as credenciais devidas ao Subject criado. Do ponto de vista da aplicação, o login só é mal-sucedido se ocorrer algum erro no processo. Percebe-se desta forma que o modelo JAAS divide a autenticação em duas camadas claramente distintas:! a aplicação, que não conhece as tecnologias de segurança do ambiente em que se encontra, e necessita realizar a autenticação de seus usuários;! os módulos de login, que realizam a autenticação do usuário frente a serviço específico, próprio do ambiente onde a aplicação se encontra, como um banco de dados, servidor LDAP ou o próprio sistema operacional; Autorização A autorização no JAAS é baseada em permissões, que definem qual Principal pode acessar qual recurso, e o nível de acesso que lhe é dado direito. O nível de acesso é geralmente definido por uma lista de ações permitidas. Um exemplo do arquivo que contém estas permissões seria como abaixo. grant codebase "file:/c:/sample.jar", principal com.mybiz.myprincipal "admin" { permission java.net.socketpermission "*:8080", "accept, connect, listen, resolve"; Permission java.io.filepermission "${user.home}/-", "read, write, execute, delete"; }; Neste exemplo, ao principal admin, definido pela classe MyPrincipal, é permitido acesso total a todos os arquivos de seu diretório home e acesso total via socket a qualquer endereço pela porta A autorização no JAAS tem como base a arquitetura de segurança definida pelo Java, modelo onde já se permite controlar acesso a arquivos e sockets, como no exemplo. O modelo de autorização do JAAS traz diversos novos recursos à estrutura de segurança do Java, que não são abordados neste trabalho.

35 Transações Transações dividem uma aplicação em unidades de trabalho atômicas. Sistemas que suportam transações garantem que tais unidades de trabalho completem sua tarefa sem interferência externa. Transações têm como característica:! serem atômicas, garantindo que a transação nunca é executada parcialmente;! serem consistentes, garantindo um estado consistente ao sistema após sua execução, tenha sido bem ou mal-sucedido;! serem isoladas, executando sem a interferência de outros processos;! serem duráveis, mantendo o seu estado interno até que a transação complete com sucesso. Este modelo que define transações é conhecido como ACID, iniciais de cada característica que define uma transação Java Transaction API O JTA é uma API para acesso ao Java Transaction Service (JTS), serviço de gerenciamento de transações do ambiente Java. Transações JTA funcionam independentes de outros gerenciadores de transações específicos, como é o caso em um SGBD. O JTS é um serviço provido pelo Java Transaction Manager, módulo da plataforma responsável pela coordenação de transações. O JTA tem como vantagem omitir da aplicação o gerenciador de transações específico de um banco de dados ou outro sistema que suporte transações. Entretanto, o principal ganho do JTA é a capacidade de gerenciar transações que envolvam bancos de dados heterogêneos e enterprise beans remotos. O JTA suporta tanto um modelo programático, onde a API é acessada diretamente pelo código da aplicação, quanto o modelo declarativo, que é integrado a tecnologia EJB Bean-Managed Transactions Para o modelo programático de transações é dado o nome de bean-managed transaction. Beans que implementam bean-managed transaction são responsáveis por explicitar os limites da transação, usando a API JTA ou JDBC. A menos que o driver JDBC não tenha suporte a JTA, deve-se dar preferência ao JTA por permitir a portabilidade entre diferentes bancos de dados, tenham ou não serviço nativo de transações.

36 Container-Managed Transactions Para o modelo declarativo é dado o nome de container-managed transactions. Transações container-managed podem ser usadas com qualquer tipo de enterprise bean. Para entity beans é obrigatório o seu uso. No descritor de instalação do bean são definidos quais os métodos que terão transação container-managed, e o atributo de escopo da transação. Os métodos serão, então, delimitados automaticamente pelo container. Apesar do modelo declarativo de transação ser definido no descritor do EJB, isto não deve ser tarefa do deployer, por haver necessidade de conhecer características internas ao componente

37 37 4. Modelagem de Sistemas Este breve capítulo tem por objetivo apresentar alguns conceitos de engenharia de software e modelagem de sistemas que fundamentam o estudo no capítulo Modularidade Modularidade é um conceito básico de engenharia de software, que define um bom software como altamente modular. Modularidade é relacionada à independência funcional existente entre os módulos de software de um mesmo sistema. Quanto maior a independência funcional dos módulos, maior é a modularidade do sistema como um todo. A modularidade de um sistema é medida com base em dois critérios: coesão e acoplamento Coesão A coesão é dada pela especificidade da função do módulo como um todo, ou o nível de similaridade entre as funções que o módulo exerce. Quanto mais bem definida é a função de um módulo, mais coeso ele é Acoplamento Acoplamento é definido pelo grau de dependência entre dois módulos. Quanto mais dados os módulos compartilharem, mais forte é a sua ligação e mais dependentes eles são entre si. Módulos com alto acoplamento são menos reaproveitáveis e menos modificáveis. 4.2 Modelo Model-View-Controller O modelo Model-View-Controller, ou apenas MVC, talvez seja o padrão de modelagem de sistemas mais disseminado. Baseia-se na identificação de três entidades básicas de um sistema:! Model: módulo que representa os dados e faz acesso a sistemas legados que interagem com a aplicação;! View: interface com o usuário final da aplicação. Trata apenas da apresentação e transfere requisições para o Controller;! Controller: módulo centralizador das requisições do usuário, responsável por delegar e coordenar as atividades dos demais módulos do sistema.

38 38 Componentes do sistema devem se enquadrar em um desses três papéis para garantir a modularidade do sistema. 4.3 Orientação a Objetos A orientação a objetos, neste trabalho, exemplificada pela linguagem Java, surgiu como um novo paradigma de programação que induz o desenvolvedor a produzir sistemas mais modulares. Isto acontece porque o foco no desenvolvimento passa a ser os dados, e não mais as funções, como em linguagens puramente procedurais. Orientação a objetos baseia-se no conceito de encapsulamento de dados. Objetos são entidades que têm um estado representado por um conjunto de dados encapsulados. Estes dados tornam-se visíveis a outros objetos por meio de operações que o objeto oferece. Estas operações permitem manipular os dados contidos no objeto, alterando o seu estado. Desta forma, objetos são componentes com funções bem definidas dentro de um sistema, já que suas funcionalidades claramente objetivam manipular um mesmo conjunto de informações encapsuladas pelo objeto. Caracterizada desta forma, orientação a objetos é claramente uma alternativa de paradigma para desenvolvimento de aplicações modulares. 4.4 UML A Unified Modeling Language é uma linguagem voltada para a modelagem de sistemas orientados a objeto. Baseiam-se no uso abundante de diagramas e documentações, chamadas de artefatos, para facilitar o desenvolvimento de sistemas. Entre seus vários diagramas, alguns dos mais conhecidos são:! o diagrama de casos de uso, responsável por identificar as principais atividades que o usuário final vai exercer sobre o sistema;! o diagrama de seqüência, responsável por detalhar todos os passos envolvidos na execução de um caso de uso, procurando identificar as interações entre os objetos do sistema;! o diagrama de classes, responsável por identificar as classes de objetos e os relacionamentos entre as mesmas. Mais detalhes sobre UML podem ser encontrados em [UML02] e [LAR00].

39 39 5. Modelagem do Catálogo do Direto Este capítulo propõe uma alternativa de modelagem ao catálogo e a autenticação do Direto. São explicados os problemas do modelo atual do Direto e mostradas passo a passo as decisões tomadas para a construção dos novos módulos de autenticação e de catálogo. 5.1 Modelo Atual do Direto Embora um dos objetivos do Direto fosse ser modular [BAL02], seu grau de modularidade é muito baixo. O sistema peca por não usar da melhor forma o paradigma orientado a objeto e a linguagem Java. Mesmo sendo possível identificar no Direto as funções típicas de um modelo MVC, essas funções não estão claramente distribuídas entre os componentes da aplicação. As classes e o código fonte do sistema evidenciam a dependência existente entre as camadas de apresentação, controle e modelo. Este alto acoplamento no Direto implica em componentes atuando como grandes bibliotecas de funções, sem responsabilidades claramente definidas, características presentes em um paradigma de programação procedural.

40 40 Figura Diagrama de classes do catálogo do Direto A figura 5.1 mostra um diagrama de classes contendo as classes do Direto responsáveis pela maior parte da lógica do módulo de catálogo. Nestas classes se verifica a presença de uma grande quantidade de parâmetros que se repetem entre os métodos de mesma classe, e um baixo número de métodos que retornam algum tipo de dado. Isto evidencia a idéia de uma modelagem orientada a procedimentos. Modelado desta forma, o Direto enfrenta sérios problemas para atingir suas diversas metas. Isto acontece porque, como existe uma alta interdependência entre os diversos componentes do sistema, o sistema torna-se difícil de manter e evoluir. Mudanças em um componente afetam os demais devido ao alto acoplamento. A baixa coesão agrava o problema, por induzir a atribuição de novas funções aos componentes errados, constituindo um círculo vicioso. Por esta razão, a tarefa de

41 41 definição de responsabilidades dos componentes é uma das tarefas fundamentais na modelagem orientada a objetos. Os problemas de modelagem constatados têm efeito em todas as áreas de pesquisa do Direto. Como exemplo:! Performance: o Direto hoje sofre com problema de falta de performance. Alternativas de mudança de componentes, tecnologia ou arquitetura afetam diversos módulos do sistema, o que implica custos mais altos para a sua solução.! Escalabilidade: além da escalabilidade ao nível de performance, a escalabilidade relativa às funcionalidades do sistema é dificultada da mesma forma. Adição de novas funções ao Direto tem reflexo em muitos componentes dentro do sistema.! Documentação: a baixa modularidade afeta diretamente a qualidade da documentação da API do sistema. Quanto mais confuso for o modelo, mais confusa será a documentação que o explica. Hoje, por exemplo, estuda-se o uso de JSP para substituir Servlets e a tecnologia XSLT na camada de apresentação, devido ao alto custo do processamento XSLT. Entretanto, a mudança na camada de apresentação do Direto afeta muito dos seus módulos, tanto os de controle quanto os de negócio, o que indica não ser uma adaptação trivial. Baseado nisto, este capítulo traz propostas de modelagem do Direto. As propostas levam em conta, além dos problemas descritos, a plataforma J2EE e as tecnologias que ela oferece. As mudanças visam atribuir ao Direto uma característica mais modular de sistema, utilizando um padrão bastante difundido que é o J2EE. Neste capítulo é realizada a modelagem de um protótipo, baseado no Direto, que incorpora as funções de autenticação e manipulação do catálogo pessoal. Parte do trabalho foi feita com o auxílio da ferramenta Together ControlCenter 6.0 [TOG02], ferramenta para modelagem UML e J2EE, desenvolvimento e instalação de aplicações, similar em funcionalidades ao conhecido Rational Rose [RAT02]. O software Together ControlCenter foi escolhido por ser uma ferramenta bastante completa nas suas funcionalidades, facilitando o processo de modelagem UML utilizando as tecnologias da plataforma J2EE. 5.2 Autenticação A primeira parte da modelagem do protótipo é a definição do modelo de autenticação. A autenticação do JAAS fornece um modelo abstrato o suficiente para garantir flexibilidade e padronização da autenticação para aplicações Java. O modelo aqui

42 42 proposto, terá como base o framework do JAAS aplicado ao Direto, e será posteriormente integrado ao protótipo proposto pelo trabalho Direto No Direto, encontramos a função de autenticação distribuída por diferentes componentes. Entretanto podemos simplificar o processo ao analisar apenas os componentes principais. Retirando componentes não ligados diretamente ao processo, podemos descrever a autenticação do Direto da seguinte forma: 1. O processo se dá início quando um usuário preenche as informações de login e submete ao sistema; 2. A servlet Direto recebe a requisição do usuário e verifica se o mesmo está autorizado para usar o sistema; 3. Como o usuário não está autorizado, instancia-se um objeto Autoriza; 4. A servlet Direto busca o id do usuário diretamente no módulo diretorio, que acessa o LDAP; 5. Invoca-se então o objeto Autoriza, passando o nome do usuário, senha e empresa; 6. O objeto Autoriza busca do objeto DiretoProperties a informação de qual é a base de autenticação configurada no sistema; 7. Com base nesta informação, o objeto tenta autenticar o usuário ou no servidor LDAP através do objeto diretorio, ou no banco de dados, ou no servidor IMAP, ou no servidor POP; 8. A servlet Direto recebe como retorno do Autoriza um valor inteiro indicando o resultado do login: LOGIN_OK, LOGIN_INVALIDO ou LOGIN_ERRO; Na figura 5.2 temos o diagrama de seqüência para o processo de autenticação no Direto, contendo o subconjunto de mensagens que interessa para o escopo deste trabalho.

43 43 Figura Diagrama de seqüência do processo de autenticação É possível identificar nesta modelo a presença de quatro alternativas de login diferentes no Direto. Nas próximas seções, será mostrado como este modelo do Direto pode ser baseado no JAAS.

44 Módulos de Login A definição do modelo de autenticação do Direto baseada no JAAS começa por identificar os módulos de login necessários para a aplicação. Para o Direto, a autenticação requer 4 módulos de login diferentes, para as seguintes tecnologias:! LDAP;! POP;! IMAP;! JDBC. É possível procurar por implementações de módulos de login para estas tecnologias, ou implementar o próprio módulo de login. O próprio pacote JAAS vem com módulos de login implementados, como ressaltado na seção Para tomar esta decisão, deve ser levado em conta:! se o fornecedor do módulo de login é confiável, já que o componente trata de informações sigilosas;! se o módulo de login possui os parâmetros necessários para customizá-lo com base nas características específicas do seu ambiente. Por questão de simplicidade, optou-se por usar apenas dois módulos de login para o Direto: um que faça autenticação no servidor LDAP e outro que faça autenticação via JDBC em um banco de dados. Ao analisar a documentação do com.sun.security.auth.module.jndiloginmodule [SUN02c], que vem junto com o JAAS no J2SDK 1.4, percebe-se que não é possível de usá-lo para o Direto. Isso se dá pelo fato de o componente não ser configurável para realizar buscas em subníveis do serviço de diretório. No entanto este parâmetro é necessário ao Direto, cuja estrutura de dados de usuário no LDAP obriga a procura em subníveis. Sendo assim, resolveu-se por implementar um módulo próprio de login via JNDI para o caso do Direto, que têm como vantagem constituir-se numa experiência de modelagem e desenvolvimento de um módulo de login. Por conseqüência resolveu-se por implementar o módulo de login para JDBC ao invés de buscar algum pronto. Os módulos criados possuem os seguintes parâmetros, que são passados através do arquivo de configuração de login (ver seção ): Módulo JDBCLoginModule:! datasourcecontext: contexto do objeto DataSource usado para a conexão com o banco;

45 45! tablename: nome da tabela que contém os dados de autenticação;! usernamefield: campo da tabela que contém o nome de usuário;! passwordfield: campo da tabela que contém a senha (não criptografada). Módulo LDAPLoginModule! environmentcontext: contexto de um objeto HashTable que contém os dados para conexão com o LDAP;! searchfilter: filtro para a busca. Deve ser um filtro que obedeça a especificação de filtros de pesquisa para LDAP [IET97]. Ele será concatenado ao filtro montado pelo módulo que procura pelo nome de usuário obtido com o CallbackHandler. Apesar de serem desenvolvidos especificamente para o Direto, os módulos tem a intenção de serem independentes e reusáveis. Isso justifica a escolha de parâmetros genéricos, independentes do Direto. Uma opção intuitiva para o LDAPLoginModule seria acessar diretamente a classe DiretoProperties, classe que no Direto concentra todas as configurações de ambiente do sistema. Entretanto desta forma haveria um acoplamento desnecessário entre o módulo de login e o DiretoProperties Arquivo de Configuração de Login O arquivo de configuração de login deverá conter uma seção para cada módulo de login diferente, já que os módulos são exclusivos. Isto é, no caso do Direto os módulos de login nunca participarão em conjunto de um processo de autenticação. Como se optou por utilizar apenas dois módulos de login, LDAPLoginModule e JDBCLoginModule, o arquivo de configuração ficou da seguinte forma: ldap { nullinc.diretoj2ee.auth.ldaploginmodule required debug=true environmentcontext=env/ldapenvironment searchfilter=(objectclass=diretoperson); }; jdbc { nullinc.diretoj2ee.auth.jdbcloginmodule required debug=true datasourcecontext=jdbc/diretods tablename=usuario usernamefield=nomeusuario passwordfield=senhausuario; }; Como se vê pelo arquivo de configuração, o módulo LDAPLoginModule necessita de uma HashTable contendo as informações de conexão registrada sob o

46 46 contexto env/ldapenvironment. Para o JDBCLoginModule, é necessária a presença de um DataSource registrado no contexto jdbc/diretods, e que forneça conexões a um banco de dados que contenha a tabela usuario com os campos nomeusuario e senhausuario. O filtro especificado como argumento para o LDAPLoginModule (parâmetro searchfilter) é o mesmo filtro usado na autenticação do Direto. Todos estes parâmetros podem ser mudados de acordo com o ambiente da aplicação. A configuração do ambiente é detalhada na seção CallbackHandler CallbackHandlers têm a função de interagir com o usuário para obter as informações de login. Entretanto, o paradigma de uma aplicação web baseado em requisições e respostas, impede que o CallbackHandler interaja com o usuário enquanto o login é realizado. A solução é criar um CallbackHandler que tenha a função de simplesmente encapsular os dados de autenticação, ao invés de interagir com o usuário. A interação com o usuário continuará com a camada de apresentação através da interface web do sistema. A classe Autoriza é um exemplo da tendência no Direto de se modelar funções ao invés de modelar dados, o mais coerente para o paradigma orientado a objetos. Como as responsabilidades dela são basicamente formadas pelos métodos de autenticação, há duas alternativas para o seu destino no modelo:! eliminá-la, já que boa parte de suas funções será substituída com o JAAS;! mantê-la, preservando sua compatibilidade com a servlet Direto. Optando-se pela segunda alternativa, o objeto Autoriza seria o responsável por interagir com o LoginContext. Desta forma, o componente Direto não precisará se adaptar, já que a interface do Autoriza não sofrerá mudanças. Entretanto, para o caso do protótipo que está sendo modelado, aproveitar a classe Autoriza implica aproveitar diversas outras classes que estão acopladas ao Autoriza. Para que a implementação contenha apenas classes que importam ao escopo do trabalho e também por questão de simplicidade, a classe Autoriza não será aproveitada. Como a função do CallbackHandler no paradigma web é puramente o encapsulamento dos Callbacks, foi criada uma classe que incorpora o mínimo necessário para tal finalidade. package nullinc.diretoj2ee.auth; import javax.security.auth.callback.*; import java.io.ioexception; public class DiretoCallbackHandler implements CallbackHandler {

47 47 } private String password; private String user; public DiretoCallbackHandler(String user, String password) { this.password = password; this.user = user; } public void handle(callback[] callbacks) throws IOException, UnsupportedCallbackException { for (int i=0; i<callbacks.length; i++) { if (callbacks[i] instanceof NameCallback) { ((NameCallback)callbacks[i]).setName(this.user); } else if (callbacks[i] instanceof PasswordCallback) { ((PasswordCallback)callbacks[i]).setPassword(this.password.toCharArray()); } } } O método handle é invocado pelos módulos de login para interagir com o usuário e preencher com dados de autenticação os callbacks fornecidos como parâmetro. Note-se como o DiretoCallbackHandler apenas inicializa os callbacks com as informações de usuário e senha encapsuladas. Nenhuma interação com o usuário é realmente necessária Conclusão Tendo modelado os principais elementos definidos pelo JAAS, o módulo de autenticação está concluído. O próximo passo é realizar a modelagem do catálogo, e integrar a autenticação ao modelo de catálogo proposto. 5.3 Módulo de Catálogo Esta seção objetiva modelar o módulo de catálogo, utilizando os recursos da plataforma J2EE, de modo a solucionar os problemas de modularidade apresentados, destacando também os ganhos adicionais que esta solução oferece Casos de uso Para modelarmos o catálogo, inicialmente identificaremos quais são os casos de uso envolvidos neste módulo. Escolheu-se um subconjunto dos casos de uso do catálogo, que envolvem apenas a manipulação do catálogo pessoal do usuário.

48 48 Figura Casos de uso do catálogo pessoal Analisando estes casos de uso, é possível encontrar três entidades distintas:! contato, que pode estar associado a vários grupos;! grupo, que pode conter vários contatos;! catálogo pessoal, que contém os grupos e os contatos Enterprise Beans Tendo identificado estas entidades e a relação entre elas, devemos analisar como a modelagem EJB se daria neste caso. Ao identificar quais são as entidades que modelam os dados que serão persistidos, concluímos que grupo e contato representam tais entidades. O catálogo nos provê o meio pelo qual manipulamos estes dados. A modelagem dos dados da aplicação é feita com o uso de entity beans, assim torna-se intuitivo criar um entity bean para grupo e outro para contato. Session beans geralmente tem a função de apresentar uma interface unificada a clientes fora do EJB container para a manipulação de um conjunto de entity beans. Para este tipo de função é dado o nome de façade, por omitir de seu cliente o uso de entity beans internos. Tendo isto como base, a modelagem da entidade catálogo como um session bean torna-se bastante adequada. Um outro ponto a favor desta opção é notar que os casos de uso descrevem a interação do usuário com o sistema sempre através do catálogo. Tendo feita esta opção, mapearemos agora cada caso de uso para um método de negócio do session bean catálogo, chamado de CatalogoBean:! getcontatos(): devolve todos contatos do catálogo pessoal;! getcontatos(grupopk): devolve todos contatos do grupo;

49 49! getgrupos(): devolve todos grupos do catálogo pessoal;! addcontato(nome, ): adiciona contato ao catálogo pessoal;! removecontato(pk): remove contato do catálogo pessoal;! addgrupo(nome, descricao): adiciona grupo ao catálogo pessoal;! removegrupo(pk): remove grupo do catálogo pessoal;! addcontato(contatopk, grupopk): adiciona contato a um grupo;! removecontato(contatopk, grupopk): remove contato de um grupo; Agora faremos uma análise dos serviços que o CatalogoBean necessita por parte de ContatoBean e GrupoContatoBean para a realização dos casos de uso. Tabela 5-1 Métodos necessários aos entity beans CatalogoBean getcontatos() getcontatos(grupopk) getgrupos() addcontato(nome, ) removecontato(contatopk) addgrupo(nome,descricao) removegrupo(grupopk) addcontato(contatopk,grupopk) removecontato(contatopk,grupopk) ContatoBean / GrupoContatoBean ContatoBean.findAll() ContatoBean.findByGrupoContato(grupopk) GrupoContatoBean.findAll() ContatoBean.create(nome, ) ContatoBean.remove(contatopk) GrupoContatoBean.create(nome,descricao) GrupoContatoBean.remove(grupopk) GrupoContatoBean.findByPrimaryKey(grupopk) GrupoContatoBean.addContato(contatopk) GrupoContatoBean.findByPrimaryKey(grupopk) GrupoContatoBean.removeContato(contatopk) Como os métodos create e remove são de implementação obrigatória para um EJB, e o método findbyprimarykey obrigatório para entity beans em especifíco, a necessidade de implementação destes métodos já está implícita. Logo, com exceção destes casos, constatamos que é necessário implementar para o ContatoBean os métodos:! findall(): busca todos os contatos do catálogo;! findbygrupocontato(grupo): busca todos os contatos de um determinado grupo;

50 50 Para o GrupoContatoBean são necessários os seguintes métodos adicionais:! findall(): busca todos os grupos do catálogo;! addcontato(contatopk): adiciona contato ao grupo;! removecontato(contatopk): remove contato do grupo. A opção pelos métodos addcontato e removecontato no GrupoContatoBean será detalhada mais adiante Chaves Primárias A escolha de como modelar a chave primária para um entity bean é uma decisão importante. A chave primária na especificação EJB é elemento que identifica uma única instância de um entity bean. Essa é a razão pela obrigatoriedade do método findbyprimarykey na implementação de um entity bean. Chaves primárias podem ser modeladas tanto pelo tipo primitivo de dado que elas representam, como string ou int, como por um objeto que a represente. Modelar como um objeto é necessário para o caso de a chave primária ser composta. Neste caso, o objeto encapsularia os atributos que compõem a chave primária. Modelar chave primária usando um tipo pré-definido como string ou int possui o contraponto de que, caso seja necessária a mudança da chave primária para refletir a composição de mais de um campo, ou mesmo para mudar o tipo de dado, isto terá reflexo em todos os componentes que utilizam o entity bean. De modo a diminuir o acoplamento entre os componentes, optou-se por criar um objeto responsável por encapsular a chave primária do ContatoBean e do GrupoBean. Assim, foi criada classe ContatoPK e GrupoContatoPK. Ambas têm a função de transportar o atributo id de seu entity bean relacionado Objetos de Transferência Para este modelo foi feita a opção de os entity beans não implementarem interfaces remotas. O motivo é que entity beans devem preferencialmente se comunicar com session beans localmente, por questão de performance. A comunicação entre entity beans e session beans que interagem muito não deve possuir gargalos. Assim, ambos o entity bean e o session bean que formam um par, devem ficar em um mesmo nodo da rede. Entretanto, session beans devem implementar interface remota para que a camada web e a camada EJB possam ser balanceadas em máquinas diferentes. Assim, não é possível para o session bean que está sendo acessado pela camada web passar uma referência para os entity beans, porque a referência é local. Também não é aconselhável que a camada web possa interagir diretamente com os entity beans.

51 51 Este problema é resolvido com a idéia do transfer object, ou objeto de transferência. Esse tipo de objeto é usado para encapsular os dados de um entity bean. Para o caso do catálogo, teremos um objeto de transferência para grupo e outro para contato. Quando for requisitado ao CatalogoBean os contatos do catálogo pessoal, o CatalogoBean obtém as referências a todos os contatos, encapsula os dados de todos estes objetos em objetos de transferência ContatoTO, e os envia para o cliente. Desta forma, criamos duas novas classes: ContatoTO e GrupoContatoTO, responsáveis por encapsular os dados de uma instância de contato e uma instância de grupo, respectivamente. Para que seja possível ao CatalogoBean encapsular os dados dos entity beans, ContatoBean e GrupoContatoBean devem prover acesso aos seus dados. Assim, são necessários mais os seguintes métodos:! para ContatoBean:! getnome(): devolve o nome do contato;! get (): devolve o do contato.! para GrupoContatoBean:! getnome(): devolve o nome do grupo;! getdescricao(): devolve a descrição do grupo Interfaces Agora que já se tem conhecimento de todos os métodos necessários aos beans, podemos definir as interfaces local e home local para cada um dos entity beans public interface ContatoLocal extends EJBLocalObject { String getnome() throws EJBException ; } String get () throws EJBException ; public interface ContatoLocalHome extends EJBLocalHome { ContatoLocal create(string nome, String ) throws CreateException, SQLException, EJBException, PersistenceException; ContatoLocal findbyprimarykey(contatopk pk) throws FinderException, EJBException ; Collection findbygrupocontato(grupocontatopk pk) throws FinderException, EJBException ; } Collection findall() throws EJBException, FinderException; public interface GrupoContatoLocal extends EJBLocalObject { String getnome() throws EJBException; String getdescricao() throws EJBException;

52 52 void addcontato(contatopk pk) throws EJBException; } void removecontato(contatopk pk) throws EJBException; public interface GrupoContatoLocalHome extends EJBLocalHome { GrupoContatoLocal create(string nome, String descricao) throws CreateException, EJBException, SQLException, PersistenceException ; GrupoContatoLocal findbyprimarykey(grupocontatopk pk) throws FinderException, EJBException ; } Collection findall() throws EJBException, FinderException; Já para o CatalogoBean, são definidas as seguintes interfaces remota e home: public interface Catalogo extends EJBObject { Collection getcontatos() throws RemoteException, EJBException, CatalogoException; Collection getcontatos(grupocontatopk pk) throws RemoteException, EJBException, CatalogoException; Collection getgrupos() throws RemoteException, EJBException, CatalogoException; ContatoPK addcontato(contatoto contato) throws RemoteException, EJBException, CatalogoException; GrupoContatoPK addgrupo(grupocontatoto grupo) throws RemoteException, EJBException, CatalogoException; void addcontato(contatopk contatopk, GrupoContatoPK grupopk) throws RemoteException, EJBException, CatalogoException; void removecontato(contatopk pk) throws RemoteException, EJBException, CatalogoException; void removegrupo(grupocontatopk pk) throws RemoteException, EJBException, CatalogoException; } void removecontato(contatopk contatopk, GrupoContatoPK grupopk) throws RemoteException, EJBException, CatalogoException; public interface CatalogoHome extends EJBHome { Catalogo create() throws CreateException, EJBException, RemoteException; } Referências Para que enterprise beans se comuniquem, é necessário estabelecer referências entre eles. Para o caso do catálogo, o CatalogoBean precisa obter uma referência para ContatoBean e GrupoContatoBean. No código do CatalogoBean, ele obtém uma referência para a interface home local de contato e grupo da seguinte forma: Context initial = new InitialContext(); this.contatohome =

53 53 (ContatoLocalHome) initial.lookup("java:comp/env/ejb/contato"); this.grupocontatohome = (GrupoContatoLocalHome) initial.lookup("java:comp/env/ejb/grupocontato"); CatalogoBean procura pelos outros beans por JNDI, acessando os contextos java:comp/env/ejb/contato e java:comp/env/ejb/grupocontato. No entanto, ambos os contextos precisam ser mapeados no descritor do CatalogoBean para os respectivos entity beans. Estas referências ficam no descritor do CatalogoBean da seguinte forma: <ejb-local-ref> <ejb-ref-name>ejb/contato</ejb-ref-name> <ejb-ref-type>entity</ejb-ref-type> <local-home> nullinc.diretoj2ee.businesstier.catalogo.contatolocalhome </local-home> <local>nullinc.diretoj2ee.businesstier.catalogo.contatolocal</local> <ejb-link>contatobean</ejb-link> </ejb-local-ref> <ejb-local-ref> <ejb-ref-name>ejb/grupocontato</ejb-ref-name> <ejb-ref-type>entity</ejb-ref-type> <local-home> nullinc.diretoj2ee.businesstier.catalogo.grupocontatolocalhome </local-home> <local>nullinc.diretoj2ee.businesstier.catalogo.grupocontatolocal</local> <ejb-link>grupocontatobean</ejb-link> </ejb-local-ref> A entrada ejb-ref-name indica o contexto pelo qual o Catalogo vai procurar o bean referenciado. Este contexto é sempre relativo a java:comp/env, que representa o contexto local do bean. A entrada ejb-link, que indica onde está o EJB referenciado, contém o nome dado ao bean dentro da aplicação. O nome do bean também é um atributo definido no seu descritor. Apenas este atributo é definido pelo instalador no momento da instalação. Os demais atributos são sempre definidos pelo desenvolvedor do componente Persistência Uma vez definida a interação entre os componentes da aplicação através da definição de suas interfaces, é hora de definir como será gerenciada a persistência dos entity beans. A persistência do catálogo no Direto é feita em um servidor LDAP. Como o J2EE dá suporte a persistência container-managed apenas para bancos de dados relacionais, e a intenção deste protótipo é reproduzir o catálogo do Direto sobre J2EE, a persistência de grupo e contato será bean-managed utilizando o LDAP. Criou-se, então, dois stateless session beans auxiliares, sem acesso remoto, responsáveis por gerenciar a persistência de ContatoBean e GrupoContatoBean.

54 54 Chamam-se ContatoPersistenceBean e GrupoPersistenceBean. Esses beans possuem os seguintes métodos de negócio, acessíveis pelas suas interface locais:! ContatoPersistenceBean:! delete(contatolocal);! insert(contatolocal);! update(contatolocal);! load(contatolocal);! selectbyprimarykey(contatolocal);! selectbygrupocontato(grupocontatopk, ContatoLocal);! selectall(contatolocal);! GrupoPersistenceBean:! delete(grupocontatolocal);! insert(grupocontatolocal);! update(grupocontatolocal);! load(grupocontatolocal);! selectbyprimarykey(grupocontatolocal);! selectall(grupocontatolocal); Nota-se que foram criados métodos para remoção, inserção, atualização e carga para grupo e contato. Além disso, foi criado um método select equivalente a cada método finder do entity bean respectivo. Todos os métodos recebem como parâmetro a referência para o bean que quer ter seu estado persistido. Assim evita-se que o componente de persistência armazene uma referência do cliente, justificando ele ser stateless. Figura Bean de persistência A exemplo do CatalogoBean em relação a ContatoBean e GrupoContatoBean, para que estes dois últimos tenham acesso a seus session beans de persistência, ContatoPersistenceBean e GrupoPersistenceBean, é necessário obter uma referência a eles por JNDI no código do componente e fazer o devido mapeamento em seus descritores.

55 55 Cada vez que o CatalogoBean ou GrupoContatoBean precisa fazer acesso a camada de persistência, eles o farão através do bean de persistência. A comunicação entre o entity bean e seu session bean de persistência ocorre segundo a tabela abaixo: Tabela Mapeamento dos métodos de persistência de ContatoBean ContatoBean ejbcreate() ejbremove() ejbload() ejbstore() ejbfindbyprimarykey() ejbfindbygrupo() ejbfindall() ContatoPersistenceBean insert() delete() load() update() selectbyprimarykey() selectbygrupo() selectall() Tabela Mapeamento dos métodos de persistência de GrupoContatoBean GrupoContatoBean ejbcreate() ejbremove() ejbload() ejbstore() ejbfindbyprimarykey() ejbfindall() GrupoPersistenceBean insert() delete() load() update() selectbyprimarykey() selectall() Cada vez que o método da primeira coluna for invocado, o método de seu respectivo bean de persistência, identificado na segunda coluna, será invocado. Adicionalmente, todos estes métodos da camada de persistência lançam a recém criada exceção PersistenceException. A função desta exceção é indicar erros na camada de persistência relativos ao acesso ao LDAP, banco de dados ou qualquer outro serviço usado pela camada para persistência dos dados.

56 Relacionamento Um ponto que deve ser levado em conta no modelo ainda é o relacionamento entre grupo e contato. Como sabemos, um grupo pode conter vários contatos e um contato pode estar associado a vários grupos. Identificamos desta forma um relacionamento do tipo muitos-para-muitos. Em um projeto de banco de dados, isso se dá geralmente na forma de uma tabela intermediária representando o relacionamento. Em modelagem orientada a objetos, isto também faz sentido para alguns casos. Pode-se também optar por não modelar uma entidade intermediária. Assim, deve-se decidir qual a direção do relacionamento, ou seja, qual entidade possui a referência para outra. O relacionamento pode ser unidirecional ou bidirecional. Não existe um modelo certo ou errado para este caso. Por questão de simplicidade de raciocínio e modelagem, optamos por modelar um relacionamento unidirecional em que o grupo contém as referências para os contatos. a decisão foi tomada com base nos casos de uso do sistema. Não existe, por exemplo, um caso de uso do tipo remove grupo do contato ou lista grupos do contato. Embora o caso de uso remove contato do grupo seja de certa forma equivalente ao primeiro, neste último caso a idéia é de subordinação do contato em relação ao grupo. Nada impediria o relacionamento entre GrupoContatoBean e ContatoBean de ser bidirecional, no entanto isto implicaria ambos os lados manterem suas referências atualizadas. Se um contato fosse retirado de um grupo, ambos os objetos deveriam ser atualizados. Pela idéia implícita de subordinação e por questão de simplicidade, o relacionamento entre grupo e contato foi modelado de forma unidirecional do grupo para o contato. Isto implica a adição de uma referência ao ContatoBean no código e no descritor do GrupoContatoBean. Figura Direção do relacionamento Contato-GrupoContato Se for prestada atenção no modelo produzido até agora, não existe um método de negócio no GrupoContatoBean do tipo getcontatos() para trazer todos os contatos do grupo. A razão é que não há necessidade, já que é equivalente acessar o ContatoBean e buscar todas as instâncias que pertencem a um grupo por meio do finder findbygrupocontato(). Caso um outro componente tivesse acesso apenas ao

57 57 GrupoContatoBean e necessitasse desta informação, o método getcontatos() seria então necessário a este bean. Em função da direção deste relacionamento, GrupoPersistenceBean torna-se responsável também por fazer a persistência deste relacionamento. Entretanto, não é necessário ao GrupoPersistenceBean, no método load(), buscar as referências aos contatos. Para tanto, basta o próprio GrupoContatoBean invocar o método findbygrupocontato de ContatoBean para obter todos os seus contatos Geração da Chave Primária Outro ponto a ser ressaltado é a geração da chave primária. Como foi visto até agora, em nenhum momento se altera a chave primária de uma instância ou se cria uma instância fornecendo a chave primária. A decisão para este modelo foi de se usar geração automática de chave primária usando um session bean de um terceiro. Este bean chama-se SequenceSessionBean, e faz a interface para um entity bean responsável por gerar chaves primárias e guardar essas informações em uma base de dados. Como o componente está pronto, desenvolvido por [ROS02], importa para o nosso modelo detalhar como ele será usado. O SequenceSessionBean possui apenas um método, generateid(), que recebe como parâmetro uma String identificando o nome da seqüência para a qual deseja-se obter um identificador único. Figura Geração do identificador Como ContatoBean e GrupoContatoBean farão uso do SequenceSessionBean, é necessário criar uma referência para este último em ambos os beans. Assim, quando for criada uma instância de ContatoBean e GrupoContatoBean, através do método ejbcreate, serão respectivamente enviadas as seguintes mensagens para o SequenceSessionBean:! sequence.generateid("contato")! sequence.generateid("grupocontato") Componentes EJB Finalmente temos a camada EJB finalizada. Pelo diagrama abaixo podemos verificar os relacionamentos entre os componentes desenvolvidos.

58 58 Figura Diagrama de classes dos beans simplificado Transações Todos os beans criados tiveram seu atributo de transação definido como Required, como exceção dos beans de persistência que tiveram transação definida como Not Supported. Isto se explica por os beans fazerem acesso ao OpenLDAP, que não suporta transações. Atribuir Required aos demais beans justifica-se por este atributo funcionar para a maior parte das situações de transação, sendo aconselhável usá-lo como valor padrão [SUN02] Camada Web Esta camada é a responsável pela interface com o usuário final e pela interação com os EJBs. A ela pertencem os objetos com a função de apresentação e controle do modelo MVC, que serão identificados nesta seção. O componente controlador, neste modelo, será desempenhado por uma versão simplificada do módulo que tem esta mesma função no Direto, a servlet Direto. A servlet Direto concentra para si todas as requisições vindas da internet, executa tarefas de controle e delega as funções de correio, catálogo e agenda para os componentes

59 59 responsáveis. Caracteriza-se como um típico controller. A nossa versão do componente, também implementado como servlet, será chamada de CatalogoController. Nele, está concentrada a função de autenticação, modelada anteriormente, e a comunicação com o CatalogoBean. O funcionamento básico do CatalogoController é o seguinte:! todas as requisições web são direcionadas para ele;! se o usuário não está autenticado, o controlador o direciona para a tela de login. Na próxima requisição ele tenta autenticar o usuário usando o modelo proposto. Uma vez autenticado, ele é direcionado para a página principal.! caso o usuário já esteja autenticado, o controlador interage com o CatalogoBean para realizar a operação desejada pelo usuário. Após a interação com o CatalogoBean, a requisição é transferida para a página JSP respectiva para apresentar o resultado na tela. Para o processo de autenticação, o CatalogoController recebe como parâmetro da requisição o tipo de autenticação a ser realizada: ldap ou jdbc. Com base nisso, ao instanciar o objeto LoginContext, o CatalogoController indica qual seção do arquivo de configuração ira usar. Figura Comunicação entre a camada de controle e a do modelo A função de apresentação no modelo fica então a cargo das páginas JSP. Para tanto, foram construídos 6 documentos JSP diferentes. São eles:! login.jsp: apresenta a tela de login, com campos de nome de usuário e senha e escolha da base para autenticação: LDAP ou JDBC;

60 60! catalogo.jsp: tela principal do catálogo pessoal, atingida após a autenticação, onde se visualiza todos os grupos e contatos;! catalogo_grupo.jsp: apresenta todos os contatos de um determinado grupo;! add_contatogrupo.jsp: a partir de catalogo_grupo.jsp, pode-se chegar nesta tela onde se escolhe contatos para adicionar ao grupo;! add_contato.jsp: tela para entrada de dados de um novo contato, atingida a partir de catalogo.jsp! add_grupo.jsp: tela para entrada de dados de um novo grupo, atingida a partir de catalogo.jsp; Figura Diagrama de navegação web O diagrama da figura 5.9 mostra como é a navegação entre as páginas JSP da camada de apresentação Deploy Finalmente modelado o sistema, a próxima tarefa é a de instalação ou deploy, a qual é bastante facilitada pelas ferramentas Together e deploytool, esta última presente no pacote do J2EE. Nesta fase, os beans devem ser configurados em relação a parâmetros específicos do servidor de aplicações onde serão instalados. São pequenas configurações não especificadas na plataforma J2EE, particulares a cada implementação. O Together tem incluído na sua instalação o Sun EE Reference Implementation, implementação da Sun para a plataforma J2EE, disponível no site da empresa [SUN02b]. Contando com o módulo de deploy do Together, são identificadas automaticamente as alterações necessárias nos descritores dos beans, além de possíveis problemas com os beans relativos à própria especificação J2EE. Realizadas as modificações necessárias, é feito automaticamente o empacotamento de todos os componentes. O empacotamento consiste em criar arquivos JAR, contendo os beans e demais classes Java, e WAR, contendo os componentes web. Em seguida todos estes arquivos são empacotados em um arquivo EAR, representando a aplicação a ser instalada.

61 61 Após esta fase, é necessário iniciar o banco de dados Cloudscape que vem com servidor de aplicações da Sun, necessário para o uso do componente SequenceSessionBean. Em seguida deve-se iniciar o próprio servidor de aplicações. Para a instalação da aplicação, existe a ferramenta deploytool, presente no pacote J2EE. Esta ferramenta fornece uma interface visual para a instalação dos componentes no servidor de aplicações. Basta abrir o arquivo EAR da aplicação, e a ferramenta permite alterações nos descritores e configurações gerais do ambiente. Depois basta acionar a função deploy e a aplicação é instalada. 5.5 Limitações Mono-usuário O catálogo modelado é mono-usuário, no sentido de que não há um catálogo pessoal de cada usuário do sistema. Entretanto, o modelo pode ser facilmente melhorado. Basta que, no momento da criação do CatalogoBean, seja identificado o usuário ao qual o catalogo pessoal pertence. Para tanto, o método de criação do catálogo deve ser modificado para:! ejbcreate(usuario) Desta forma não será mais permitido criar um catálogo sem identificação de usuário. Adicionalmente, seria acrescentado o seguinte método de negócio aos beans grupo e contato:! findbyusuario(usuario) O que permitirá que o catálogo forneça ao usuário apenas os grupos e contatos associados a ele. Desta forma, notamos como é fácil, usando o paradigma de desenvolvimento da plataforma J2EE, expandir a funcionalidade do catálogo de mono-usuário para multiusuário Alteração dos dados de usuário e grupo Não foram modelados também os casos de uso de alteração dos dados de um contato ou grupo. Tal modelagem resultaria em mais alguns serviços em CatalogoBean, ContatoBean e GrupoContatoBean do tipo setnome(), set (), setdescricao(), etc.

62 Considerações Finais Neste capítulo foi realizada a modelagem do mecanismo de autenticação presente no Direto utilizando a API JAAS. Também foi construído um modelo de catálogo, baseado em um subconjunto dos casos de uso presentes no catálogo do Direto, utilizando a tecnologia EJB. O modelo de ambos os módulos mostrou-se bastante reusável, por representar basicamente a lógica de negócio do catálogo e da autenticação do Direto.

63 63 6. Implementação do Protótipo Neste breve capítulo, é mostrado o protótipo resultante da modelagem do catálogo analisada no capítulo anterior. Este protótipo tem o objetivo básico de mostrar o catálogo, detalhadamente modelado na seção anterior, do ponto de vista do usuário e dos casos de uso implementados. 6.1 Configuração do ambiente Antes de poder usar o protótipo, é necessário configurar o ambiente e os recursos que serão utilizados. Para a autenticação e o próprio catálogo, baseados no LDAP, foi instalado o servidor OpenLDAP [OPE02]. O OpenLDAP é um software livre que fornece serviço de diretório baseado na tecnologia LDAP. Uma vez configurado e populado com uma amostra de dados do catálogo do Direto, ele está pronto para ser acessado pelo protótipo. Para que se usar os módulos de login, são necessárias mais algumas configurações em função dos parâmetros destes módulos. Para o caso do LDAPLoginModule, registrou-se no contexto env/ldapenvironment através da API JNDI um objeto HashTable que contém os dados para acesso ao OpenLDAP, já que o módulo recebe o nome do contexto como parâmetro. A inicialização do objeto e seu registro são realizados com a execução do trecho de código abaixo. HashTable env = new HashTable(); env.put(context.initial_context_factory,?); env.put(context.provider_url, "ideagate"); env.put(context.security_authentication, "simple"); env.put("java.naming.batchsize", "100"); env.put("java.naming.ldap.version", "3"); env.put(context.security_principal, "admin"); env.put(context.security_credentials, "1234"); env.put("java.naming.ldap.attributes.binary", "usercertificate"); Context ctx = new InitialContext(); ctx.bind("env/ldapenvironment", env); Para o JDBCLoginModule foi criado um banco de dados MySQL [MYS02], contendo a tabela usuario e os campos nomeusuario e senhausuario. Esta tabela representa um modelo típico para informações de login. Criou-se, então, um objeto DataSource, o qual foi registrado no JNDI para poder ser acessado pelo módulo de login. Para tanto foi necessário obter um driver JDBC atualizado, que implementasse o objeto DataSource. Tal driver foi conseguido diretamente no site do MySQL. com.mysql.jdbc.jdbc2.optional.mysqldatasource ds =

64 64 new com.mysql.jdbc.jdbc2.optional.mysqldatasource (); ds.setservername("ideagate"); ds.setdatabasename("direto"); ds.setdescription("banco de dados do DiretoGNU"); Depois de criado o arquivo de configuração, registrou-se uma referência para ele no arquivo java.security. É a partir deste arquivo que o ambiente Java carrega as informações dos arquivos de configuração. 6.2 Protótipo O protótipo é todo baseado na web, a exemplo do próprio Direto. Como já mencionado, foi usada a tecnologia JSP para a geração da interface HTML dinâmica. Note-se que a interface do protótipo é toda baseada na interface atual do Direto, sofrendo algumas adaptações para melhor exemplificar os casos de uso. O sistema conta com uma tela inicial para o login do usuário. A autenticação é baseada em um conjunto de usuários previamente cadastrados no servidor LDAP e no banco de dados. Esta autenticação se dará, como já descrito anteriormente, através de um módulo de login específico para a base de autenticação escolhida.

65 65 Figura Tela de login Depois de realizada a autenticação do usuário, temos a tela inicial do catálogo pessoal. Nesta tela, são mostrados todos os grupos e contatos presentes no catálogo, todos cadastrados manualmente pelo usuário através da interface do protótipo. Neste momento, os casos de uso Lista contatos do catálogo pessoal e Lista grupos do catálogo pessoal foram cumpridos. Para facilitar o entendimento do funcionamento interno do protótipo, vale relembrar as responsabilidades dos componentes. Toda ação do usuário no sistema é direcionada para a servlet CatalogoController. Ela por sua vez fará contato com o CatalogoBean, invocando a ação desejada sobre o catálogo. Ele, por sua vez, fará as interações necessárias com os beans de contato e grupo para realizar a tarefa. Uma vez completa a tarefa, o CatalogoController chama a página JSP responsável por montar a interface ao usuário. Para a adição de um novo grupo ou um novo contato, basta acionar o botão correspondente, que então será solicitada a inserção dos dados Para se remover um determinado grupo ou contato, basta clicar no botão excluir correspondente. Assim, mais quatro casos de uso pretendidos pela modelagem são atendidos.

66 66 Figura Tela inicial do catálogo Clicando-se em um grupo, obtém-se a lista de todos os contatos deste determinado grupo. Nesta nova tela torna-se possível adicionar ou remover contatos do grupo corrente. Assim podemos verificar que todas as funcionalidades previstas para este protótipo estão ao alcance do usuário através da interface.