Enterprise
          JavaBeans 3.0
                            Parte 1: Introdução

                             Rafael
  ...
JavaBean
O que é um Enterprise JavaBean




                Os Enterprise JavaBeans foram criados em Março de 1998, na pri...
Vários requerimentos que um sistema robusto necessita estão listados abaixo junto com
o que os EJBs oferecem para suprir e...
para maximizar a eficiência de recursos. Componentes podem ser migrados para
      balancear carga sem um cluster de proce...
e entregarMaterial().        Invocando estes métodos, os
checarQuantidadeMaterial()
clientes remotos podem utilizar os ser...
Tipos de Enterprise Bean

       Existem três tipos de enterprise beans, os quais serão estudados aqui neste curso. Os
cap...
Uma arquitetura com Enterprise Java Beans


       A arquitetura EJB define um modelo de sistema distribuído, baseado em
c...
Figura 1-1: Arquitetura de um sistema com EJBs



        O container gerenciará muitos beans simultaneamente do mesmo mod...
alerta o bean de um diferente evento no seu ciclo de vida e o container invocará estes
métodos para notificar o Bean quand...
O Conteúdo de um enterprise bean

      Para desenvolver um enterprise bean, você deve fornecer os seguintes arquivos:

  ...
Empacotamento da aplicação


       Os componentes J2EE são empacotados separadamente e agrupados em uma
aplicação J2EE pa...
Benefícios da utilização de EJBs


        Por diversas razões, os EJBs simplificam o desenvolvimento de aplicações grande...
Quando usar EJBs

Você deve considerar o uso de EJBs se sua aplicação tiver alguns dos seguintes requisitos:

   1. A apli...
Tipos de EJBs

        Um componente EJB possui três tipos fundamentais: entity beans session beans e
                    ...
para
Convenções de nomes para EJB

      Em função dos enterprise beans serem compostos de múltiplas partes, é importante
...
Próximos SlideShares
Carregando em…5
×

Parte 1 Introducao

1.928 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.928
No SlideShare
0
A partir de incorporações
0
Número de incorporações
41
Ações
Compartilhamentos
0
Downloads
68
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Parte 1 Introducao

  1. 1. Enterprise JavaBeans 3.0 Parte 1: Introdução Rafael Por: Rafael Zancan Frantz > < ATENÇÃO: Este material contém algumas imagens retirardas da docomentação oficial da SUN e adaptadas para este material. As mesmas podem ser encontradas no site www.sun.com. O objetivo deste material é recompilar uma série de informações existentes em diversas fontes e que possam ser utilizadas para o estudo da tecnologia EJB 3.0 pelo leitor. Ao final do material são apresentadas as bibliografias utilizadas para a elaboração do material. Sugere-se que as mesmas sejam utilizadas para aprofundar os conhecimentos nesta tecnologia. 1
  2. 2. JavaBean O que é um Enterprise JavaBean Os Enterprise JavaBeans foram criados em Março de 1998, na primeira especificação da Sun com o intuito de promover uma arquitetura de objetos distribuídos pela Internet. A definição da Sun Microsystems para Enterprise JavaBeans é: “The Enterprise JavaBeans architecture is a Component architecture for the development and deployment of component-based distributed business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These applications may be written once, and then deployed on any server plataform that supports the Enterprise JavaBeans specifications”. Fazendo parte de uma infra-estrutura de middleware em um modelo Web, os EJBs simplificam consideravelmente a criação da infra-estrutura, mas acrescenta outras dependências em uma implementação específica de um Application Server. A tecnologia Enterprise JavaBeans (EJB) de components, ou simplesmente quot;enterprise beansquot;, provê um ambiente para o gerenciamento de componentes. Eles podem simplificar o processo de desenvolver aplicações escaláveis, portáveis e reutilizáveis no seu ambiente de negócios. O uso de enterprise beans requer um investimento de tempo, codificação e treinamento. Em oposição a alguns que cultuavam, principalmente no começo da tecnologia, que no desenvolvimento de EJBs o programador precisava somente desenvolver a lógica de negócios os EJBs requerem muita experiência na administração e configuração dos serviços gerenciados pelo container e como são um pool de tecnologias é importante para o o coordenador do projeto ter “know how” de várias conceitos como de objetos distribuídos, RMI (Java Remote Method Invocation), conceitos de transações, conhecimento de mapeamento de dados Java com os de Bancos de dados pelo JDBC e outros. Para alguns, esta tecnologia parece complicada, mas eles podem simplificar o desenvolvimento de aplicações de negócio por resolver alguns requerimentos de serviços nos quais em um sistema robusto faz diferença. Até a versão 2.1 o desenvolvedor precisava configurar muitas coisas em arquivos XML, porém a partir da versão 3.0 muitas das configurações que eram feitas em XML agora podem ser feitas através de anotações. O uso de anotações simplificou muito a escrita de componentes EJB. 2
  3. 3. Vários requerimentos que um sistema robusto necessita estão listados abaixo junto com o que os EJBs oferecem para suprir estas demandas. A maioria destes requerimentos são aplicáveis na aplicação desde que tenham as seguintes necessidades. · Gerenciamento da Persistência Muitas aplicações empresariais manipulam os dados Persistência. persistentes. Um bean de entidade (um EJB que representa o dado persistente em um meio de armazenamento como um banco de dados relacional) é projetado para prover gerenciamento automático de dados persistentes, inclusive dados legados. Isto é feito a partir da versão 3.0 de EJB utilizando a API de persitência, Java Persitence API. · Acesso concorrente a dados Aplicações empresarias multi-usuárias devem prover dados. acesso concorrente a dados sem sacrificar a consistência. Enterprise beans são projetados para gerenciar acessos concorrentes e possuem automaticamente resursos multi-thread. · Acesso remoto a dados Aplicações empresariais tipicamente acessam dados a partir dados. de recursos remotos múltiplos. A tecnologia de EJB fornece interfaces remotas de negócio para esta transparência de localização, aumentando assim a disponibilidade da aplicação. · Modelo desenvolvido baseado em componentes Componentes de software podem componentes. prover reusabilidade, portabilidade e uma clara separação da interface com a implementação. Enterprise beans provê estes benefícios porque são verdadeiros componentes de software. · Portabilidade Uma aplicação que é portável através de múltiplas plataformas de Portabilidade dade. hardware e sistemas operacionais faz melhor uso de dos recursos da sua empresa, principalmente em se tratando de sistemas heterogêneos e provê uma futura flexibilidade de integração. A portabilidade diminui os riscos de uma aplicação tornar- se obsoleta quando sistemas operacionais são atualizados ou hardware são substituídos. A especificação das tecnologias J2EE, assegura que os serviços para sistemas empresariais estejam disponíveis através de vários fornecedores e plataformas. · Controle Transacional e de Segurança Dados empresariais devem ser atualizados Segurança. consistentemente e somente por aqueles que estiverem autorizados. Enterprise beans provê um controle declarativo das configurações de segurança e de transações, simplificando a customização e aumentando a flexibilidade. Enterprise beans podem também controlar as transações e a segurança programaticamente. · Alta dispobilidade. Sistemas de missão crítica necessitam estar disponíveis todo dispobilidade tempo. Implementações de Enterprise Beans podem prover controle a falhas automaticamente quando um servidor sai do ar por crash ou para manutenções, quando a rede está indisponível ou não confiável. Enterprise beans também gerencia uma religação de dados quando acontece uma falha de sistema. · Escalabilidade Aplicações normalmente crescem, aumentando o número de Escalabilidade. usuários e novos requisitos. Por terem um ciclo de vida gerenciado pelo container as instâncias dos beans que servem as requisições podem ser colocadas em um pool 3
  4. 4. para maximizar a eficiência de recursos. Componentes podem ser migrados para balancear carga sem um cluster de processadores. · Neutralidade do tipo de cliente. Algumas aplicações requerem acesso por muitos cliente. tipos de cliente. Objetos de negócios como enterprise beans provêm accesso para um modelo de aplicação para qualquer tipo de cliente. Clientes Java podem acessar os enterprise beans através das interfaces padrões (Home e Remote). Clientes não Java podem acessar enterprise beans usando CORBA (Common Object Request Broker Architeture) ou interfaces Web services. No passado as empresas construíram seu próprio Middleware com o intuito de se fazer uma solução que fosse adequada às realidades da empresa mas esbarraram nos seguintes inconvenientes: - Custo de manter uma equipe de desenvolvimento. - Um middleware de alto nível é estremamente complicado de construir e de manter uma equipe de manutenção para o código. - Pouca reusabilidade da solução, porque estes sistemas muitas vezes não eram adequados para a realidade WEB e desta forma o percentual de reconstrução era muito alto e principalmente quando era necessário a construção de pontes (bridges), porque as diferentes tecnologias não conversavam satisfatoriamente o custo aumentava ainda mais. - Caso fosse necessário conectar com um outro DBMS que não fosse o que foi feito no projeto original exigia uma reprogramação muito grande principalmente por que poucos sistemas eram três camadas com um foco orientado a MVC (Model-View- Controller). O conceito de Enterprise Java Beans não é recente, vêm dos monitores transacionais, os “TP monitors” que vieram de um ambiente Mainframe. Estas máquinas antigas, porém eficientes no papel que se dispuseram a fazer, trabalham com os monitores transacionais porém de uma forma monolítica e não uma forma distribuída. Partindo deste princípio formamos uma definição de EJB além da já apresentada e cunhada pela SUN. “Enterprise Java Beans é um padrão de modelo de componentes no lado servidor para aplicações de negócio distribuídas.” EJBs são os componentes J2EE que executam a tecnologia de Enterprise JavaBeans. Os EJBs funcionam no container EJB, um ambiente de runtime dentro de algum servidor J2EE. Embora transparente ao desenvolvedor de aplicação, o container de EJB fornece serviços a nível de sistema (como transações, por exemplo) a seus EJBs. Estes serviços permitem construir e disponibilizar rapidamente os EJBs, que dão forma ao núcleo de aplicações transacionais J2EE. Escrito na linguagem de programação de Java, um EJB é um componente server-side que encapsula a lógica do negócio de uma aplicação. A lógica do negócio é o código que cumpre a finalidade de uma aplicação. Em uma aplicação de controle de material didático, por exemplo, os EJBs podem executar a lógica do negócio nos métodos chamados 4
  5. 5. e entregarMaterial(). Invocando estes métodos, os checarQuantidadeMaterial() clientes remotos podem utilizar os serviços do controle de material fornecidos pela aplicação. 5
  6. 6. Tipos de Enterprise Bean Existem três tipos de enterprise beans, os quais serão estudados aqui neste curso. Os capítulos seguintes discutem estes tipos de beans mais detalhadamente. 1 – Session Beans: Executa uma tarefa para um cliente Bean eans 1.1 – Stateless: Sem informação de estado Stateless: 1.2 – Stateful: Com informação de estado Stateful: 2 – Message Driven Beans (MDB): Atua como um listener para a API Java Message Bean (MDB): eans Service (JMS), processando mensagens assincronamente. 3 – Entity Beans: Representa um objeto de entidade de negócios que existe no Beans eans: armazenamento persistente 6
  7. 7. Uma arquitetura com Enterprise Java Beans A arquitetura EJB define um modelo de sistema distribuído, baseado em componentes. O modelo de programação define um conjunto de perfis, através de um conjunto de contratos, que definem uma plataforma comum de desenvolvimento. O principal objetivo destes contratos é assegurar a portabilidade através dos vendedores de servidores de EJB ou de componentes, enquanto suportam um rico conjunto de funcionalidades. Container de EJB O conceito de Container na arquitetura J2EE define um conjuto de componentes que atendem uma especificação. Existem diversos tipos de container como Applet Container, WEB Container, EJB Container. Para um componente rodar nestes ambientes, o mesmo tem que atender as especificações descritas destes containers. Baseado na definição de EJB poderíamos definir um container acrescentando que os componentes rodam em um programa que define o funcionamento de runtime (tempo de execução) da especificação. Se o tipo de container define o padrão de objetos distribuídos então estaremos falando em EJB Container. Um Enterprise Bean não pode rodar fora de um container, porque o mesmo gerencia todo o aspecto de um enterprise bean em um ambiente de execução, por exemplo: o acesso remoto ao bean, segurança, persistência, transações, concorrência, acesso aos recursos de pool, etc. O container isola o enterprise bean a partir do acesso direto das aplicações clientes quando essas invocam uma chamada remota a um Enterprise Bean. Inicialmente, o container, intercepta a invocação para assegurar: persistência, transação e segurança pelas propriedades do Bean para toda a operação que o cliente executar. Como o container gerencia todos esses fatores automaticamente para o bean, então o desenvolvedor não precisa implementar este tipo de lógica no código do bean. O desenvolvedor pode focar nas as regras de negócio enquanto o container cuida dos serviços solicitados pelo bean, os quais são definidos em um arquivo chamado deployment descriptor. Veremos este arquivo mais adiante. 7
  8. 8. Figura 1-1: Arquitetura de um sistema com EJBs O container gerenciará muitos beans simultaneamente do mesmo modo que o Web Container gerencia muitos servlets. Para reduzir o consumo de memória e processamento, o pool de recursos do container gerencia os ciclos de vida de todos os beans com muito cuidado. Quando um bean não está sendo usado, o container colocará no pool o bean para ser reutilizado por outro cliente, ou possivelmente o eliminará da memória quando o container decidir que o bean não é necessário ficar no pool. Esta decisão pode ser de acordo com o número de acessos ao bean. Devido ao fato de que aplicações clientes não têm acesso direto aos beans, o container vive entre o cliente e o bean, portanto as aplicações cliente desconhecem completamente as atividades do container. Um bean que não está em uso, por exemplo, pode ser armazenado a partir da memória em algum outro mecanismo que varia entre tipos de EJB (Session , Entity e Message Driven Bean) no servidor, enquanto a referência remota fica intacta. Quando o cliente invoca um método na interface remota o container simplesmente revitaliza o bean para servir a requisição, deixando o processo totalmente transparente para a aplicação cliente. Um Enterprise Bean depende do container para qualquer serviço que necessite. Se um Enterprise Bean necessita acessar uma conexão com outro Bean tudo é feito da mesma forma que um cliente comum passando pelo container. Para isto o Enterprise Bean interage com o container através de três mecanismos: · Métodos de CallBack: Todo EJB implementa uma interface Enterprise Bean, sendo os métodos da interface chamados de métodos de callback. Cada método callback 8
  9. 9. alerta o bean de um diferente evento no seu ciclo de vida e o container invocará estes métodos para notificar o Bean quando os eventos acontecem (criação, remoção, persistência, etc.). Os métodos de callback dão chance ao bean de fazer algum processamento antes ou depois de algum evento gerado pelo container. Até a versão 2.1 os EJBs deveria seguir uma nomenclatura exata para métodos do seu ciclo de vida, porém com anotações os nomes dos métodos não mais são importantes e podem variar. A notação antes do nome do método é que irá dizer qual dos métodos do ciclo de vida que o mesmo representa. Por exemplo @javax.annotation.PostConstruct será utilizado para anotar um método como sendo o método a ser executado após a costrução de um Session Bean. · EJBContext Interface: Todo EJB obtém um objeto de contexto de EJB, o qual é uma referência direta para o container. A interface EJBContext provê métodos para interagir com o container tanto que o bean pode requisitar a informação sobre o seu ambiente como a identificação do cliente ou o status de uma transação ou pode obter referências remotas para ele mesmo. · JNDI (Java Naming and Directory Interface): JNDI é uma extensão da plataforma Interface): Java para acesso a sistemas como LDAP (Lightweight Directory Access Protocol), sistemas de arquivo, etc. Todo bean automaticamente tem acesso para um sistema especial chamado Enterprise Naming Context (ENC). O ENC é gerenciado pelo container e acessa os beans usando JNDI. O JNDI ENC permite um bean acessar recursos como conexões JDBC, outros enterprise beans, e propriedades específicas para aquele bean. Isto é feito internamente, porém como já dissemos a programação é a mesma que a de um cliente comum. 9
  10. 10. O Conteúdo de um enterprise bean Para desenvolver um enterprise bean, você deve fornecer os seguintes arquivos: 1) Descritor de implantação (deployment descriptor): Um arquivo XML que especifica as informações sobre o bean, como seu tipo de persistência e atributos de transação. Isto pode ser feito via anotações. Porém se o arquivo XML for fornecido as configurações postas no mesmo irão sobrescrever as anotações 2) Classe do enterprise bean (enterprise bean class): Implanta os métodos definidos nas interfaces local e/ou remota 3) Interfaces: A interface remota é necessária para o acesso remoto. Para acesso local, a interface local é necessária. Estas interfaces serão estudadas mais adiante. 4) Classes auxiliares (helper classes): Outras classes necessárias para a classe do enterprise bean, como classes de exceção e de utilitários. Você empacota os arquivos da lista anterior em um arquivo JAR EJB, o módulo que arqmazena o enterprise bean. Um arquivo JAR EJB é responsável e pode ser usado por diferentes aplicações. Para montar uma aplicação J2EE, você empacota um ou mais módulos – como arquivos JAR EJB – em um arquivo EAR que contém o arquivo JAR EJB do bean e outros arquivos, também implanta o enterprise bean no servidor J2EE. 10
  11. 11. Empacotamento da aplicação Os componentes J2EE são empacotados separadamente e agrupados em uma aplicação J2EE para implantação. Cada componente, seus arquivos relacionados com os arquivos GIF e HTML ou classes de utilitários do lado servidor, e um descritor de implantação são montador em um módulo e adicionados à aplicação J2EE. Uma aplicação J2EE é composta por módulos de componentes do cliente da aplicação, enterprise bean ou web. A solução empresarial final pode usar uma aplicação J2EE ou ser composta de duas ou mais aplicações J2EE, dependendo das exigências do projeto. Uma aplicação J2EE e cada um de seus módulos possuem seus próprios descritores de implantação. Um descritor de implantação é um documento XML com uma extensão .xml que descreve configurações de implantação de um componente. Um descritor de implantação do módulo do enterprise bean, por exemplo, declara atributos de transação e autorizações de segurança para um enterprise bean. Como as informações do descritor de implantação são declarativas, elas podem ser alteradas sem modificar o código-fonte do bean. No momento de execução, o servidor J2EE lê o descritor de implantação e age sobre o componente adequadamente. Uma aplicação J2EE com todos os seus módulos é entregue em um arquivo Enterprise ARchive (EAR). Um arquivo EAR é um arquivo Java Archive (JAR) padrão com uma extensão .ear. Dentro deste arquivo EAR normalmente você adiciona arquivos Web Archive (WAR) e JAR. - Cada arquivo JAR EJB contém um descritor de implantação, arquivos do enterprise beans e arquivos relacionados - Cada arquivo JAR do cliente da aplicação contém um descritor de implantação, os arquivos de classes para o cliente da aplicação e arquivos relacionados. - Cada arquivos WAR contém um descritor de implantação, arquivos do componente Web e recursos relacionados. A utilização de módulos e arquivos EAR possibilita a montagem de várias aplicações J2EE diferentes usando alguns dos mesmos componentes. Nenhuma codificação adicional é necesária; é apenas a questão de montar os vários módulos J2EE em arquivos EAR J2EE. 11
  12. 12. Benefícios da utilização de EJBs Por diversas razões, os EJBs simplificam o desenvolvimento de aplicações grandes e distribuídas. Em primeiro lugar porque o container EJB fornece serviços a nível de sistema aos EJBs, o desenvolvedor EJB pode se concentrar em resolver problemas de negócio. O container EJB -- não o desenvolvedor EJB -- é responsável por serviços a nível de sistema tais como a gerência de transação e a autorização de segurança. Em segundo lugar, porque os EJBs - e não os clientes - contêm a lógica do negócio da aplicação, o desenvolvedor do cliente pode focar na apresentação do cliente(User Interface, ou UI). O desenvolvedor do cliente não tem que codificar as rotinas que executam regras de negócio ou acesso a bases de dados. Em conseqüência, os clientes são mais finos, um benefício que é particularmente importante para os clientes que funcionam em dispositivos pequenos. Em terceiro lugar, porque os EJBs são componentes reutilizáveis, o integrador da aplicação pode construir aplicações novas com EJBs existentes. Estas aplicações podem funcionar em qualquer servidor J2EE compatível. Existem muitos servidores J2EE disponíveis hoje no mercado. Servidores estes gratuitos ou pagos. Iremos utilizar aqui um servidor J2EE gratuito chamado JBoss. Links interessantes: JBoss: http://www.jboss.org NetBeans: http://www.netbeans.org Sun: http://java.sun.com/javaee 12
  13. 13. Quando usar EJBs Você deve considerar o uso de EJBs se sua aplicação tiver alguns dos seguintes requisitos: 1. A aplicação deve ser escalável. Para acomodar o crescimento do número de usuários, você talvez precise distribuir os componentes de uma aplicação em múltiplas máquinas. Não somente podem os EJBs de uma aplicação funcionar em máquinas diferentes, mas suas localizações permanecerão transparentes para os clientes. 2. As transações são necessárias para assegurar a integridade dos dados. Os EJBs suportam transações, os mecanismos que controlam o acesso concorrente de objetos compartilhados. 3. A aplicação terá inúmeros clientes. Com apenas algumas linhas do código, os clientes remotos podem facilmente encontrar EJBs. Estes clientes podem ser magros (thin client), váriados e em grande número. 13
  14. 14. Tipos de EJBs Um componente EJB possui três tipos fundamentais: entity beans session beans e beans, message drive beans Como regra geral, na qual especificaremos estes tipos mais tarde, um beans. ENTITY BEAN modela conceitos de negócios que podem ser representados por nomes, como um comprador, um equipamento, um item de iventário. Em outras palavras entity beans modelam objetos do mundo real. SESSION BEANS são uma extensão da aplicação cliente e são responsáveis por modelar processos ou tarefas (ações) e MESSAGE DRIVE BEANS que são um tipo de bean que se assemelha ao Session Bean e que são acessados a partir de um sistema de mensagens pelo JMS (Java Message Service). Resumidamente abaixo os três tipos diferentes de EJBs. Os capítulos seguintes discutem cada tipo mais detalhadamente. 1. Session Beans: executa uma tarefa para um cliente. Pode representar um serviço Beans: (negócio). São divididos em Stateless Session Bean e Stateful Session Bean 2. Message Driven Beans: é um listener para a API Java Message Service (JMS), Beans: processando mensagens de modo assíncrono. 3. Entity Beans: representa um objeto de entidade de negócio que existe no armazenamento persistente. 14
  15. 15. para Convenções de nomes para EJB Em função dos enterprise beans serem compostos de múltiplas partes, é importante seguirmos uma convenção de nomes nas suas aplicações. A tabela abaixo mostra estas convenções. Item Sintaxe Exemplo Nome de um JAR para um EJB (DD) <nome>JAR CursoJAR Classe Enterprise Bean <nome>Bean CursoBean Interface Remote <nome>Remote CursoRemote Interface Local <nome>Local CursoLocal Tabela 1-1: Nomenclatura para EJBs OBS: DD significa que o item é um elemento “deployment descriptor” do bean. Bibliografia 1 - BURKE, Bill and MONSON-HAEFEL, Richard. quot;Enterprise JavaBeans 3.0quot;. O'Reilly. 5 ed. 2006. 760 p. 2 - JENDROCK, Eric et al. quot;The Java EE 5 Tutorialquot;. (http://java.sun.com/javaee/5/docs /tutorial/doc) Consultado em 16/04/2007. 3 - JBoss Web Site: http://labs.jboss.com/portal/jbossejb3. Consultado em 15/04/2007. 15

×