Ta aí a duvida pessoal, quando realmente preciso de EJB´s ? Como abstraio isso?
Obrigado!
Tem gente que vai responder: nunca!
Penso que quando o ambiente vai nascer pensando em alta disponibilidade e com distribuição de componentes/serviços em mais de um servidor…
E aí entra o Spring na parada, mas eu não conheço, então nem comento.
O Spring faz praticamente o que o EJB faz. Agora com anotações na versão 2.5 do Spring, nem se fala. A questão maior é que, se realmente precisar usar EJB 3 (num recomendo abaixo, seria uma ótima). Ele realmente é fácil, embora sua melhor utilização, é quando precisa de alta disponibilidade da aplicação, como o colega acima já citou, em um ambiente clusterizado (mas dá pra fazer isso com Spring tb).
Boa sorte
Sinceramente, eu nunca vi um sistema que usou EJB e realmente precisava dele.
Precisar mesmo você realmente não precisa. Você pode fazer na mão o controle transacional, load-balance, remoting, pool de conexões, serviço de mensageria e um monte de outras coisas que ele faz por você.
Claro que você pode usar Spring+Servlet Container para isso. É uma outra opção.
Acho que o EJB 3 trouxe muita facilidade para o desenvolvimento EJB, com certeza é algo a ser considerado.
[quote=Rubem Azenha]Precisar mesmo você realmente não precisa. Você pode fazer na mão o controle transacional, load-balance, remoting, pool de conexões, serviço de mensageria e um monte de outras coisas que ele faz por você.
[/quote]
Sou preguiçoso…
Na verdade, não fazia mto sentido em apps EJB 1.x ou 2.x, devido principalmente à complexidade no desenvolvimento. Com EJB3 a coisa muda um pouco de figura…
Cara, a tua pergunta é simples e direta e passa pelo conceito de EJB:
“A arquitetura Enterprise JavaBeans é uma arquitetura de componentes para o desenvolvimento e implantação de aplicativos de negócio distribuidos baseados em componentes. Aplicativos escritos utilizando a arquitetura Enterprise JavaBeans são ESCALONÁVEIS, TRANSACIONAIS e SEGUROS com MULTIUSUÁRIOS. Esses aplicativos podem ser escritos uma vez e então implantados em qualquer plataforma de servidor que suporta a especificação Enterprise JavaBeans.”
Não vou nem perder tempo com o pessoal que diz que “nunca viu um sistema que usou EJB e realmente precisava dele”.
Resumidamente, você pode usar EJB quando quiser ter um sistema DISTRIBUIDO que precisa ser ESCALAVEL, TRANSACIONAL e SEGURO.
Vc nao precisa necessariamente de EJBs para implantar uma arquitetura Escalavel, Transacional e Segura.
Quanto a distribuir objetos, acho melhor dar uma olhada nessa velha dica do tio Fowler:
“First Law of Distributed Object Design: Don?t distribute your objects!”
PS: Desculpe pela acentuacao… teclado formato Americano.
[quote=aaarodrigo]“A arquitetura Enterprise JavaBeans é uma arquitetura de componentes para o desenvolvimento e implantação de aplicativos de negócio distribuidos baseados em componentes. Aplicativos escritos utilizando a arquitetura Enterprise JavaBeans são ESCALONÁVEIS, TRANSACIONAIS e SEGUROS com MULTIUSUÁRIOS. Esses aplicativos podem ser escritos uma vez e então implantados em qualquer plataforma de servidor que suporta a especificação Enterprise JavaBeans.”
Não vou nem perder tempo com o pessoal que diz que “nunca viu um sistema que usou EJB e realmente precisava dele”.
Resumidamente, você pode usar EJB quando quiser ter um sistema DISTRIBUIDO que precisa ser ESCALAVEL, TRANSACIONAL e SEGURO.[/quote]
Rodrigo, de onde você obteve essa citação?
Se você reparar bem, a citação está dizendo escaLONÁvel, não escaLÁvel, como você disse depois. Deve ser por isso que o pessoal que gosta de EJB vive dizendo que EJB é escalável; leu errado a descrição porque não nunca ouviu falar em escalonador!
A maioria de quem usa EJB, usa Session Bean, que não é escalável. A razão é que é utilizado chamadas síncronas e é exigido que a thread que envia a mensagem seja a mesma que receba o retorno, obrigando que recursos da máquina, tanto do lado cliente quanto do lado servidor, sejam consumidos para que a comunicação ocorra.
Voltando à pergunta básica…
Você NÃO precisa de EJB 2.x pra baixo, NUNCA! Qualquer benefício será inferior ao pé-no-saco que é pra utilizá-lo. Você PODE precisar de, EJB 3 ou Spring, quando precisar de recursos de infraestrutura, sem muito trabalho. Exemplo: transação, chamadas remotas, pooling… A diferença de Spring e EJB 3 é mais filosófica. O primeiro é melhor pra fazer objetos de domínios ricos, aspectos e deploy em único arquivo war. O segundo é melhor para uma arquitetura tradicional, que realmente precise de distribuição.
Acho que esse assunto já virou algo religioso… Não vai ter fim essa discussão!
A citação é do Enterprise JavaBeans 3.0 em PORTUGUES, no entanto a tradução está errada, segue o trecho em inglês:
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 platform that supports the Enterprise JavaBeans specification.
É escalável mesmo.
Escalabilidade é uma característica desejável em todo o sistema, em uma rede ou em um processo, que indica sua habilidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar preparado para o crescimento do mesmo. Por exemplo, isto pode se referir à capacidade de um sistema em suportar um aumento carga total quando os recursos (normalmente do hardware) são requeridos. Um significado análogo está relacionado quando a palavra é usada em termos comerciais, onde a escalabilidade de uma empresa implica em um modelo de negócio que oferece potencial de crescimento econômico dentro da empresa.[1]
Escalonável, em português, é aquilo que é passível de ser colocado em níveis, etapas, escalões, degraus.[2]
Com certeza foi um problema de tradução.
Quanto ao EJB em si ser escalável segue outra citação:
EJB and scalability EJB is scalable because it can run in cluster environment. What is there in EJB specification and in Application Server that supports this feature?
Capability is the current processing capability of an application. Like the No. of requests an application can handle with fair/good performance.
Scalability is the rate at which the Capability of an application can be increased without any degradation of the current processing capabilities.
For example, if an application was developed to handle 100 concurrent users with a performance of x. After sometime, the number of users/customers get doubled. In this case, we have to increase the current processing capability of the application with no degradation of the performance. We increase the number of application server instances and cluster them.
Clustering is not part of EJB or J2EE specification. It is the feature provided by Application Server vendors. Through clustering feature, an app. server would support Load Balancing, High Avaialbility and Scalability. Multiple server instances are created in the Application Server and client requests are distributed among all the server instances. By doing this, we are making sure that a particular server is not overloaded with too many requests and also in case of a server instance going down, other server instances will take over the failed server instance’s requests.
Neste ponto vemos que escalabilidade em parte é responsabilidade do application server atraves de clusterização para poder suportar operações de balanceamento de carga e etc.
No entanto existem algumas facilidades:
The scalability of the EJB is does not only depend upon the clustering feature provided by the Application Server Vendor. EJBs are inherently scalable, meaning there are certain features in the J2EE specs which makes the EJB scalable. For example, at the server startup you can specify the max and min number of beans in the pool. The App Server does not create the max number of bean immediately but min number of beans and as the number of requests grow it goes on adding the number of beans till the max pool size is reached.[3]
Para fechar o tema, concordando em partes com o amigo que diz que SessionBean não é escalável:
To many people, EJB is synonymous with scalability. I am here to tell you that they are wrong! There is nothing about EJB that is inherently more scalable then any other technology. The real secret to scalability is that good software scales well and bad software scales poorly. This is universally true regardless of the technology that is used. An EJB Container can achieve scalability based on its ability to be clustered and load balanced. However, the same is true of most standard Servlet/JSP Containers and most other web technologies (Perl, PHP, and ASP) as well. Therefore, once again, EJB offers nothing in terms of scalability that cannot be achieved with a simpler solution. In fact, it is my experience that simpler solutions such as Servlet/JSP applications are much easier and cheaper to scale than full blown EJB applications. Remember, scalability is never free; you pay for it in the cost of designing good software. [4]
Resumindo a história:
Escalabilidade tem seu preço, geralmente envolve hardware (afinal aumentando a largura de banda, memória, processando conseguimos aumentar o numero de clientes atendidos) e está diretamente relacionada a como o conteiner gerencia o ciclo de vida dos objetos e também a como o application server faz o balanceamento da carga.
[1] Wikipedia
[2] Wordreference
[3] JGuru
[4] Javaranch
Agora concordo com você. Não tenho nada contra EJB 3 ou Spring (só com EJB 2.x), mas sempre me preocupa as pessoas dizendo que “com EJB, você ganha escalabilidade”, como se dissessem “escalabilidade sem exigir atividade cerebral”.
O que eu já vi de aplicações EJB me mostra que se deve tomar cuidado ao se criar aplicações distribuídas. Uma é não criar método fino como “boolean isNomeUsuarioBranco(String nome)”. Outra é não sobrecarregar a comunicação entre nós com uma chamada do tipo “List meTragaTudo()”. Esse tipo de coisa, obviamente compromete o desempenho e a escalabilidade, seja o EJB ou qualquer outro serviço distribuído.
Na dúvida, deixem os beans como local mesmo, sem qualquer tratamento para, “futuramente”, deixá-los remotos.
Sua aplicação DEVERÁ ser acessada por outras aplicações? Então você precisa de middleware aka EJB
Eu não acho que ela necessariamente precisa de um “middleware aka EJB”, ela precisa de um forma qualquer que permita que outras aplicações a acessem.
Esse acesso tem que ser real-time? Qual o volume de acessos? Os acessos vão gerar muita carga no sistema? O sistema deverá ter um “ponto de acesso” público (worldwide) ou apenas para outras aplicações internas? O que é exatamente esse “DEVERÁ ser acessada”? Todas as aplicações envolvidas são aplicações Java? O acesso deverá ser via TCP\IP, passando por um firewall coorporativo chato?
Existem N complicações, e para cada complicação existem N ténicas para fazer aplicações diferentes se acessarem, desde transferência arquivos textos á webservices SOAP, passando por EJB, RMI simples, Plain Old XML (POX), Sockets, webservices REST, ESB e mais um monte de outras siglas. Não acho que EJB cobre todos os casos nem acho que EJB foi feito exatamente para isso.