UNIVERSIDADE NOVE DE JULHO

USO DO INTERPRISE JAVA BEANS PARA DESENVOLVIMENTO DE COMPONENTES DE SOFTWARE

MARCIO PEREIRA DE SOUSA

SO PAULO 2012

SUMARIO

ENTERPRISE JAVA BEANS UM MODELO DE APLICAO

ENTERPRISE JAVA BEANS

O to conhecido Enterprise Java Beans pode ser considerado uns dos principais componentes da plataforma J2EE (Java 2 Enterprise Edition). Ele um componente do tipo servidor que executa no container do servidor de aplicao. Enterprise Java Edition j passou por varias modificaes e adaptaes de melhoria, fazendo com que o mesmo tenha varias verses diferentes, cada uma delas com uma melhoria ou funcionalidade em especial. Entre as verses 2.1 e a verso 3.0 a introduo de anotaes em Java, anotaes essas que facilitam o desenvolvimento diminuindo a quantidade de cdigo e o uso de determinados tipos de arquivos de configurao XML. A plataforma J2EE tambm providencia algumas facilidades dedicadas camada lgica de negcio e para o acesso ao banco de dados. Outro ponto que vale a pena lembrar, que no inicio dos anos 90, a arquitetura das aplicaes comeou a evoluir de cliente servidor para modelos de aplicativos em varias camadas, com o objetivo de separar 3 aspectos: uma delas era a lgica do negcio, outra a interface com o usurio e por ultimo as particularidades de cada servidor. Consequentemente isso levou ao desenvolvimento de arquiteturas de middleware que incluam monitores de transao, middleware orientado a mensagens e servidores de aplicativos. Um outro fator muito importante que acelerou ainda mais o desenvolvimento desse tipo de tecnologias era a necessidade de enfrentar uma nova realidade, que era a Internet. Essa rede mundial de computadores que comeava a ter outra dimenso planetria, permitindo fornecer novos servios ao consumidor levando as empresas a terem que repensar a sua organizao e todos os seus sistemas de informao. Essas arquiteturas multicamadas permitem simplificar muito o desenho, o desenvolvimento e a manuteno desses novos sistemas de informao, alm de permitir que se desenvolva uma lgica de negocio no se preocupando tento com os pormenores da infra-estrutura tecnolgica que os suporta. Pensando pelo lado negativo, um grande problema que surgiu, foi o de que cada fornecedor comeou a criar a sua prpria middleware para suportar este tipo de arquitetura usando uma abordagem isolada, e ainda por cima no havia um esforo na indstria de software para uniformizar estes servios, e foi nesse contexto que acabaram surgindo os EJBs, num esforo desenfreado de o modelo de componentes, e alguns servios associados a eles. Atravs do EJB o programador utiliza a infra-estrutura do servidor de aplicao voltada para o desenvolvimento de aplicaes de misso mais critica que so de alta importncia para a empresa e de aplicaes empresariais em geral.

UM MODELO DE APLICAO

No podemos levar muito a srio esse nome, pois ao contrrio do que o nome indica, o Enterprise Java Beans tem pouco em comum com a outra tecnologia da Sun: O Java Beans. Enquanto os Java Beans definem convenes para que cada instncia possa ser customizada com alguma ferramentas visuais, ligando quase todos os objetos por eventos, os Enterprise Java Beans so desenhados para implementar servidores com suporte a transao para vrios usurios, e a nica idia em comum o conceito de componente, ou seja, entidades portteis e independentes que podem ser reutilizadas. Os EJBs j mencionados acima, possuem 02 tipos fundamentais que so os Entity Beans e os Session Beans. Para acessar qualquer um dos EJBs necessrio definir as suas intefaces de acesso que so: Interface Local, Interface Remota ou Ambas. Os dois tipos de componentes tm muito em comum e so bem complementares, pois cada Bean definido por quatro partes que so empacotadas formando um s EJB. As quatro partes so: - Um arquivo em XML de definio de atributos; - Uma interface que sempre estende o EJBHome, esta interface define os mtodos para gerir o ciclo de vida do Bean, e para o cliente criar um Bean; - Uma interface que estende a EJBObject, definindo os mtodos de negocio especficos a cada componente; - Uma classe que implementa SessionBean ou EntityBean, ambas estendem Enterprise Bean, que por sua vez estende Serializable. esta classe que implementa os mtodos definidos nas duas interfaces acima citadas. importante notar que esta classe no declara que implementa nenhuma das interfaces, e existe apenas uma conveno de nomes usada para interligar esta classe com as duas intefaces. O arquivo de definio em XML nos permite definir vrios atributos de aplicao. Podemos ate mesmo indicar se algum mtodo precisar especificamente ser executado em modo de transao, e o container, ao ler o arquivo de definio, coloca externamente s fronteiras da transao nesse mtodo e gere as transaes necessrias, e pode-se ainda por cima, definir quais requisitos de segurana se deseja utilizar. Existem ainda algumas restries em modo geral que os Beans tm de cumprir, como por exemplo, a de no utilizar threads, arquivos atravs da java.io, no utilizar AWT para ler o teclado ou para escrever a tela, no usar socketes, no fazer o loading de bibliotecas j nativas, os mtodos precisam sempre ser Public e no pode se Abstract nem final e no se pode definir o finalize.

DETALHES NA IMPLEMENTAO DE EJBs

No memento de realizar a implementao das EJBs preciso verificar alguns pontos importantes, como por exemplo, o de que a Interface Home estende a EJBHome e define mtodos comuns a todos os Beans, que so usados para criar, encontrar e remover um Bean. O Container usa ento estes mtodos para gerir o ciclo de vida do Bean, o cliente e o prprio Bean, que no tem controle sobre esse ciclo de vida. A Interface de Home no estendida pela classe, visto existir uma conveno de nomes entre as duas. Esta conveno aplica-se especialmente aos mtodos de criao e de procura, isto porque a assinatura destes depende do tipo de Bean, logo no podero ser definidos em EJBHome, s na interface, como por exemplo, os mtodos para criar objeto precisam ter o nome create, devolver um objeto que implemente a interface remota deste Bean podendo ter qualquer assinatura. A classe que implementa estas mtodos tm de ter o nome ejbCreate, a mesma assinatura, mas devolver void, onde a ligao entre a interface e a implementao feita pelo container. Outro ponto importante que devemos o saber que a Remote Interface estende o EJBObject e define os mtodos especficos de negcio do Bean em questo, que podem ter o nome desde que no entre em conflito com os da Home Interface. Na criao de um Bean, o create invocado obtendo-se um objeto que implementa esta interface. Podemos reparar que a classe tambm no estende esta interface, mas tm que implementar os mtodos definidos aqui, com o mesmo nome da assinatura, mas claro que no podem ter, por exemplo, mtodos com o nome ejbCreate, pois so palavras reservadas. A Classe, tal como na Home Interface, no declara que implementa esta interface, a conveno de nomes aqui se resume a implementar mtodos com o mesmo nome e valor de retorno. Por fim, tem-se que implementar o Bean em si, o que feito numa classe Java, que implementa ou a Interface SessionBean ou a EntityBean, dependendo do tipo de Bean que se quer. Alm disso, tambm ser de suma importncia implementar todos os mtodos na Home e da Remote Interface de acordo com as convenes descritas acima.

SESSIONBEANS EJBs

ENTITYBEANS EJBs

http://www-usr.inf.ufsm.br/~fabian/Download/Trabalhos/artigo.html