Vocês usam ou não EJBs?

Eai Luca, Olá Guj’s!

Só deixe-me fazer uma pequena observação quanto ao comentário, antes q a galera meta o pitaco em mim!

A minha colocação infeliz foi no contexto de que não seria uma boa idéia aprender EJB nesta altura do campeonato, já que a pessoa que tinha dúvidas é um iniciante!

Desculpem-me por ter me expressado tão mal!

Luca, valeu por criar este post e por referir a minha péssima colocação!
Espero ter me retratado corretamente. Mas ainda sim quero dar um pitaco nos EJB’s!

Abraços!

Oi Luca,

já trabalhei em alguns projetos onde EJBs faziam parte da solução. E pelo pouco que pude ver, fiquei com a seguinte impressão:

• MDBs são muito bons para trabalhar com JMS. Achei bem simples de codificar e se você usa uma boa IDE então, fica mais fácil ainda. Tive uma experiência de precisar trabalhar com JMS sem MDBs e foi um caos por não ter a transação gerenciada automaticamente pelo container. Não consegui enxergar pontos ruins no MDBs e pelo que leio por ai, acho que apesar do pessoal cruxificar o EJB 2.x, até livram a cara dos MDBs!

• Acho que Session Beans são muito interessantes quando você precisa fazer aplicação distribuída. Codificá-los é um pé no saco, mas com uma boa IDE ou XDoclet, o problema se resolve facilmente. Codificar clientes para Session Beans é bem simples e você ganha de graça as transações, autenticação, etc.

Abraços,
Marco Campêlo

Ja trabalhei bastante com EJBs, o suficiente pra querer fugir deles como o diabo foge da cruz, por inumeras razoes, testabilidade e depurabilidade sendo as maiores delas, e ainda bem, parece que isso esta melhorando no EJB3, mesmo ainda nao terem resolvido o problema de se ficar amarrado a um fornecedor para as coisas que nao estao na spec.

De certa forma eu concordo com o Thiago - eh burrice usar EJBs hoje em dia, e pessoas bem-informadas o suficiente sabem quando se deparam com as raras excecoes que tem por aih. Entao, se vc adicionar um "Geralmente, " no comeco da frase dele, faz perfeito sentido.

Olá!

Quantos aos EJB’s a minha opinião é a seguinte. Utilize EJB quando não houver opção melhor. Essa minha afirmação só valerá até a versão 2.0.
Quando ao EJB 3.0 eu não sei. Vamos esperar para ver!

O problema principal dos EJB’s talvez nem seja os EJB’s propriamente dito, e sim como os desenvolvedores empregam mau o conceito de EJB em seus projetos. Eles simplesmente optam por esta tecnologia por ser uma tecnologia poderosa e que traz um certo status de certa forma. Também tem aqueles (eu por exemplo) que visa esta tecnologia para aprender e tirar suas curiosidades em projetos que não tem este perfil. O projeto é sério e o cara deixa de pesquisar uma boa solução e aplica EJB logo de cara, só para ver no que vai dar e preencher o currículo com conhecimentos e experiência em EJB!

Hoje o ciclo de vida no meu desenvolvimento de um sistema onde está aplicado EJB é assim:

• faço uma alteração para concertar um determinado erro;
• 35 minutos para compilar a aplicação;
• 2 minutos depois a máquina desliga sozinho,
• ligo a máquina;
• 5 minutos (em média) para iniciar o servidor e a aplicação.
• faço o bendito teste e encontre outro erro.

Minha máquina tem 512 de RAM, e utilizo produtos Borland que faz com que exiga mais ram ainda.
Já foi solicitado máquinas melhores, mas… isso já virou conto de fadas…

Se analisado com calma, este projeto não precisaria de EJB’s. Outras tecnologias seriam suficientes para resolver o problema, mas até aqui, tudo bém.

Conclusão: Independente se usamos EJB ou qualquer outra solução é necessário se ter um planejamento da arquitetura do projeto e quais são as tenologias que devem ser empregadas para resolver o problema, e não sair usando uma solução poderosa só pelo seu nome e pela força de empresas que lhe dão suporte!

Espero ter contribuído!
Abraços!
Thiago Senna

cv:

Ja trabalhei bastante com EJBs, o suficiente pra querer fugir deles como o diabo foge da cruz, por inumeras razoes, testabilidade e depurabilidade sendo as maiores delas, e ainda bem, parece que isso esta melhorando no EJB3, mesmo ainda nao terem resolvido o problema de se ficar amarrado a um fornecedor para as coisas que nao estao na spec.

E foge para onde:

• Quando você precisa trabalhar com JMS?
• Quando você precisa fazer chamadas remotas ao seu código? WebServices? HTTP? RMI?

Abraços,
Marco Campêlo

Mas isso é válido para qualquer tecnologia, não apenas para EJBs!

Além das 50 mil interfaces e dos 500 mil XMLs, o que mais vocês enxergam de tão ruim nos EJBs?

[]'s
Marco Campêlo

Opa…

Você esta falando de Spring?

Eu também já ouvi falar bém dos MDB’s. Mas hoje já temos o spring que oferece suporte para o JMS.

Daí pergunto: Para quê um EJB container para gerenciar Mensagens se você pode fazer isso usando POJO’s.

Não conheço este recurso em detalhes, mas os EJB’s neste caso não são mais a única solução.

Abraços!
Thiago

Ok, vamos lá.

Session Beans são úteis, mesmo. mas quando temos clientes distribuído sou rpecisamos de transações gerenciadas pelo Container ( nãoq ue seja obrigatório, mas é útil). Até hoje eu só trabalhei em um sistema que precisasse de fato de uns EJBs, o sistema é um grande two-phase commit, e algumas coisas acabam sendo muito complexas sem a ajuda do container.

Entity Beans acho que todos concordam a merda que são, sem meias palavras.

MDB eu sou usuário, nunca fiz nada que fosse rpeciso codificar um só uso os que estão prontos, mas parece bem legal.

O grande lance quando se utiliza EJB é separar os objetos de negócio do componente. A Sun com suas especificações, blueprint e documentação toda (bem como os fornecedores de AS) induzem as pessoas a pensar que os EJBs devem implementar seus objetos de negócio. Eles dão um ótimo Service Layer nos casos citados acima, não mais que isso.

Eu, sinceramente, acredito que de tudo que já li no GUJ, 99% das pessoas que postam dúvidas aqui não tem real necessidade de usar EJBs. De tudo que trabalhei até hoje, eu só vi um sistema que seria legal seu uso!

Spring?

Depende. Quem sao os clientes? Onde estao os clientes? O que os clientes vao fazer? A sua pergunta ja da uma ideia das possibilidades, mas existem muitas outras, e algumas se encaixam em certos casos bem melhor que EJBs, mas EJBs continuam sendo uma boa ideia pra transacoes distribuidas se, e somente se, voce realmente precisa de transacoes distribuidas.

Tirem para mim uma dúvida, por favor!

Você poderiam citar um exemplo que quando realmente se precisa de EJB, e que não há opções para substituí-lo!

Pergunte isso para que se um dia eu pensar em EJB, vou lembrar da resposta desta pergunta!

Abraços!
Thiago

Rolou uma discussão semelhante em:

http://www.portaljava.com.br/home/modules.php?name=Forums&file=viewtopic&t=14198&sid=4c6967e2e9bfc6e842292f28a4685b62

A pergunta que eu coloquei lá foi:

[color=red]O que temos em EJB que não conseguimos ter sem ele ???[/color]

Na minha cabeça é a APENAS clusterização/distribuição dos beans. Isso é legal e útil para um sistema que não pode parar de maneira nenhuma e não é muito fácil de se obter por fora de EJB.

O dia que eu tiver que fazer um projeto com EJB vou me matricular numa faculdade de direito e começar a considerar uma mudança de ramo.

ja trabalhei em um sistema que usava ejb’s(2.0).
tinhamos entitys cmp na persistencia e session como facades na camada de negocio.
minha impressão:
so use ejb se sua app realmente precisar ser distribuida.
acho session beans validos na camada de negocio, mas mesmo com ant/xdoclet p/ ajudar na geração de interfaces/xml’s ainda assim é bem trabalhoso.
entitys, prefira cmp. gosto do controle de transacões dele e, a persistencia é bem tranquila, mas como os sessions, da muito trabalho de manter. e os recursos do ejb-ql ainda deixam muito a desejar, qq consulta mais complexa se torns impossivel, e vc acaba tendo que fazer muitas coisas na mão.
consultas muito pesadas tmb eram um problema, pois a app acaba ficando muito pesada.

[]'s

MDBs são legais de usar. Eu vejo session beans sendo uteis em alguns cenarios.

:arrow: Aplicação clusterizada, os containers J2EE fazem bem.
:arrow: Requisitos transacionais muito complexos, o Spring da conta do setup, mas caso envolva múltiplas fontes, legado ou 2PC, ainda sou mais usar EJB junto.
:arrow: JCA/Connectors/Legado, ainda é a melhor opção. Todas soluções que eu vi além de JCA+EJB são desastrosas.

Eu, atualmente, faço parte de um projeto que utiliza EJB´s( Entity Beans e SessionBeans), e sinceramente,
não tenho muito o que criticar em relação aos “mesmos”.
Vamos por partes:

Entity Beans: seja CMP ou BMP - é a pior merda que inventaram dentro dos EJB´s. IMHO nas versões menores que 2.1, nem deveriam existir. Sem comentários.Uso essa bosta e faço o Arquiteto que quis usar isso se arrepender até o ultimo fio de cabelo dela, por essa escolha mal feita. É um saco ter que ficar analizando as querys extremamente peeeeeeeeeeesadas que o maldito gera no IronTrack.

SessionBeans: relativamente faceis de se trabalhar, proveem muitos serviços uteis(Segurança, Transação, …), e que não são aquele absurdo de complicados de configurar.Com relação aos xml´s de configuração - são extremamente nojentos, asquerosos, ou qualquer adjetivo do genero…mas nunca tive que modificar uma virgula em um ejb-jar.xml, jboss.xml ou qualquer outro, já que o XDoclet(a ferramenta mais util que inventaram até hoje) :mrgreen: gera tudo que é necessário pra que a coisa funcione, então acho que ninguem tem muito que reclamar disso, a não ser que o cara goste de dar tiros no próprio pé e cria tudo na OOONHA, interfaces, xml´s.

MDB´s - nunca usei, mas já vi o quão uteis são e simples de se trabalhar.

Resumindo: IMHO EJB´s(Session Beans e Message Driven Beans) são bastante uteis SIM, [color=red]mas quando usados com sabedoria[/color], na hora, local e projeto que realmente requerem todos os serviçoes que eles disponibilizam.

Isso serve pra qualquer tipo de tecnologia. Provavelmente se neguinho teve problemas com EJB´s, é porque ele foi adotado em um projeto onde
provavelmente não deveria ser adotado, e o cara nunca tinha visto isso na vida e foi obrigado a usar e tinha que fazer pra ontem e não teve tempo de estudar.

Conselho: Estudem primeiro a tecnologia, depois use-a, e ai sim, tirem conclusões…é muito fácil botar a tecnologia(EJB) no tronco e lascar o chicote na coitada.

Luis,
vc tem razão, e quando falo que ejb’s so devem ser usados quando realmente necessarios, falo em relação a arquitetura e principalmente tecnicamente, pois é uma tecnologia complexa.
Em um outro post, ja tinha colocado que se a escolha for usar ejb, uma pessoa experiente na equipe vai poupar muita dor de cabeça.

[]'s

Ótimo ponto, Shoes.

Nunca estudei EJB a fundo ou li recomendações da Sun ou qualquer outro fornecedor para saber o que eles pensam do assunto, mas nos casos onde usei EJB não vi nenhum bom motivo para botar alguma (ou toda) regra de negócio em um Session ou MDB.

Um dos casos onde utilizamos EJB e eu acho que funcionava muito bem (precisávamos fazer a aplicação distribuída + cluster + load balance), o Session servia apenas como um layer para fornecer a interface remota. Toda regra de negócio estava distribuída em classes Java normais. Inclusive, facilitava muito em relação a testes, pois não era necessário testar o Session para verificar se uma funcionalidade estava OK ou não, podíamos rodar os testes direto nas classes de negócio.

Abraços,
Marco Campêlo

cv:

Depende. Quem sao os clientes? Onde estao os clientes? O que os clientes vao fazer? A sua pergunta ja da uma ideia das possibilidades, mas existem muitas outras, e algumas se encaixam em certos casos bem melhor que EJBs, mas EJBs continuam sendo uma boa ideia pra transacoes distribuidas se, e somente se, voce realmente precisa de transacoes distribuidas. ;)

Que existem outras possibilidades, eu entendo e concordo.

Mas nesse caso em especial (chamadas remotas), qual vantagem vocês enxergam em utilizar qualquer uma das opções mencionadas (WebServices, RMI, HTTP) ao invés de EJB? Queria vantagens reais (dizer que configurar XML e implementar interface é chato, não vale, porque isso as IDEs já resolvem) …

Abraços,
Marco Campêlo

Aqui utilizei MDB e Session Bean no último projeto que desenvolví e me foram bastante úteis.

O meu cenário era o seguinte: uma aplicação que precisava executar processos assíncronos, como atualizações e geração de arquivos. Esses processos deveriam ser requisitados por sistemas diversos.

O que fiz foi criar um sistema que gerenciava esses processos. E MDB com JMS foi como uma luva de veludo no frio de Vladvostok.

Os sistemas “clientes” apenas fazem uma chamada HTTP ou via uma interface Java / JNDI que criei (única dependência nos clientes). E o gerenciador dos processos assíncronos executam os EJB Session Bean que cada sistema disponibiliza.

Nesse caso foi uma ótima solução usar EJB. Nunca mais usei eles.

Não levem a mau! É brincadeira!! Só para descontrair!!

Para eu ser Evangelist, teria que entender muito bem do assunto, como não é o meu caso!

Apenas não sou fundamentalista como um monte de gente que vejo por aí, que não gosta de EJB (ou qualquer outra tecnologia que esteja na moda ser malhada) simplesmente porque não gosta!

Meu objetivo aqui é aprender e é por isso que eu questiono certas coisas.

Respostas como “Existem várias tecnologias que fazem o mesmo que EJB faz” não me dizem muita coisa, pois eu quero entender porque são melhores ou piores e não apenas saber que existem.

Abraços,
Marco Campêlo

Olá

Eu deveria ter me dado ao trabalho de distribuir 5 estrelas para todos que escreveram neste tópico. Acho que as respostas até aqui foram de nível altíssimo e bem aquilo que eu estava precisando ler. Ainda espero aprender mais.

saoj:

Rolou uma discussão semelhante em:
http://www.portaljava.com.br/home/modules.php?name=Forums&file=viewtopic&t=14198&sid=4c6967e2e9bfc6e842292f28a4685b62

Dei 5 estrelas para o Sérgio pelo favor de incluir este fantástico link com a brilhante disputa Shoes x Murai. Muito bom mesmo!

Detalhe: A discussão do Portal Java começou na véspera do Carnaval e e passou do desfile das campeãs. Carnaval de nerd é discutir EJBs!

[]s
Luca

O Murai trabalha comigo, mas em outros projetos! Ele tem experiência como Java. Foi o primeiro no estado a tirar SCJP e tbm tem SCEA. Ele acabou de implantar um sistemas usando muitos EJBs e muito requisitado (users/dia).

Eu que acabei indicando aquele post e outros links do GUJ sobre discussão de EJB e Struts, principalmente, já que ele adora estas duas tecnologias.

De forma resumida, o que tenho a dizer sobre EJBs é: MDBs são muito úteis e Session Beans também. Uma das arquiteturas do genesis inclusive usa um Session Bean de forma invisível ajudando a tirar proveito das características de seu servidor de aplicação.

Atualmente estou num projeto que usa Hibernate para persistência, com uma camada de Stateless Session Beans com Container-Managed Transactions acima disso. Funciona bem, e, com XDoclet fica relativamente fácil de trabalhar. Mas isso seria facilmente resolvido pelo Spring.

Além disso, a gente usa MDBs pra fazer processamento paralelo dentro do Container. E também funciona bem. Não sei como seria a solução pra esse tipo de problema sem usar MDBs. Alguém?

Enfim, acho que EJB tem seus usos. Mas como todo mundo já disse, 99% dos casos, hoje em dia, não precisam.

[]'s

As IDEs resolvem mas mesmo assim vc programa sem entender nada, pois quem está programando é IDE.

Bom, eu nunca fiz um projeto prático usando EJB, pois sempre fujo deles, mas eu realmente acho chato demais ficar configurando um milhão de xmls e escrevendo um milhão de classes e interfaces para modelar uma entidade. Contraste isso com a simplicidade do Hibernate, onde um objeto persistente é como um JavaBean puro.

A complexidade de EJB, a quantidade massiva de configurações XML, a complexidade dos Applications Servers, me fazem continuar com o bom e velho Servlet Engine.

Tá certo que com servlet vc vai ter que implementar algumas coisas na mão, ou ser safo para achar essas coisas já implementadas por aí (Hibernate, Taglibs, JTA, etc.), mas será bem mais divertido e no final vc terá a sensação de que vc está no controle e não um application server maluco.

Olá…

Achei este material no TheServerSide:
É uma crítica quanto ao EJB 3.0!

Abraços!

Estou com preguiça de ler as postagens anteriores, mas me interessei pelo assunto.
Gostaria de saber quem já utilizou o padrão EJB Session Façade em um projeto para distribuição de módulos, persistindo os dados com Entity’s Bean na versão 2.1, utilizando JDeveloper, BD Oracle 10g e Oracle 10g AS?!?

A ressureição…

Não sou defensor do uso de EJB em todas as soluções, mas essa é pra quem gosta de malhar sem conhecer…

Kameron McKenzie at JavaRanch:

Let us establish one undeniable fact: enterprise programming is hard.

Sure, Servlets are superb at handling client requests, and Java Server Pages are fabulous at generating markup for a client, but request-response programming is not where Java developers earn their salt.

Java developers earn their salt by implementing some seriously complicated business logic. Fiddling with a Servlet’s request and response objects all day long won’t impress anybody.

Enterprise programming is hard, but EJBs make some of the toughest parts of enterprise programming just a little bit easier.

What are the common challenges enterprise developers encounter?

Enterprise programming is hard. In an enterprise environment, there are a number of mission critical challenges that must be addressed and implemented properly, otherwise applications will fail.

Some of the typical challenges that enterprise developers encounter include:
Database Access:

How do we ensure that that data in our application is completely, totally, 100% in sync with what is in the database? This is a requirement of almost every enterprise application, but without an intimate knowledge of how a database works, implementing database synchronization properly is a significant challenge.
Transactional Updates:

If I’m updating three different databases in an ‘all or nothing’ type of scenario, and one of those database writes fails, how do I roll back writes to the other two databases?

What if one of those databases is in Kalamazoo and two of them are in Tuktoyaktuk? How do you maintain the transactional integrity of your updates?
Distributed Programming:

I’m in Gun Barrel, Texas, but I want users in Antigonish, Nova Scotia to remotely invoke the methods in my Java components. How do I make a local component accessible to remote applications?
Multithreading:

Multithreading remotely accessible components that must handle a gargantuan load is a difficult and onerous task. How are you going to do it?
Secure Access:

You only want Double Agents to call one method of your JavaBean, and only Secret Agents can call the other method. How ya gonna do it? With a typical Java application, it’s almost impossible.

How do EJBs Make Life Easier?

Database concurrency, distributed transactions, multithreading, distributed programming and secure accesses are all issues our enterprise applications must deal with.

If we have to deal with these issues alone, we’re going to be in an ugly world of hurt. The good news is that EJBs deal with these issues, and by dealing with them, they make enterprise programming much, much easier.

I hope that sheds some light on ejbs. More here:

http://www.technicalfacilitation.com/get.php?link=usingejbs

O conteúdo original está aqui…

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=11&t=012333

Bom senhores, vou contribuir com a experiência que possuo sobre o assunto:

Como muitos disseram, um dos principais motivos da adoção EJB é quando sua aplicação possui necessidade de estar 99,9999% no ar. Logo se projeta uma arquitetura de Cluster com diversos nós.

Alguns applications servers como Websphere, adotam a estratégia de cluster da sessão, ligados a um banco de dados.

Um dos motivos de eu gostar do GlassFlish é o HADB- High Avaible Data Base, uma tecnologia da Clustra - empresa que a Sun adquiriu no passado e integrou ao seu produto na versão 7.1.

Com tal tecnologia, você serializa os objetos e compartilha por uma estratégia Round-Robin de escalonamento.

Nesse cenário utilizar um Session Bean Stateful, para armaezenar algumas informações que você não pode correr o risco de perder pode ser uma grande vantagem.

A especificação te dá essa opção e um bom produto que faça bom proveito da mesma, pode reduzir bastante seu TCO com hardwares de cluster, utilizando somente Application Server para a questão.

Vivi esse cenário num projeto da OESP, cliente da Sun Microsystems (empresa que representei como consultor).

JMS todos aqui mencionaram como se ganha poder ao utilizar MDB´s e simplicidade. Existem muitos patterns de desacoplar todo o tratamento de excessões usando JMS de forma assíncrona, principalmente quando se precisa dar continuidade ao processo e logar a informação ou dar seu devido tratamento de forma isolada.

Também estou acompanhando alguns Patterns mais novos sobre Ajax + JMS - http://www.trajano.net/2006/04/ajax-queue.html

Claro que você pode utilizar o Spring para controlar desde o MVC ao JMS, sei que muitos vão falar disso e tb prefiro a solução.

Mas em projetos de integração, quando você opta por utilizar uma estratégia baseada em JMS, ter um monitor ( serviço do application Server) entre outras features de controle, te faz olhar EJB com outros olhos.

Realmente a parte de persistência (Entity Beans) não me agrada. Para cenários complexos você pode ter muita dor de cabeça e hoje você tem muitas alternativas, como várias implementações JDO, Hibernate - que agora está seguindo EJB3.

Mas para findar, acredito que deve-se estar ciente do que sua aplicação necessita de infra-esturutra, quais são as premissas do negócio.

EJB na minha ótica provisiona uma ótima relação custo x benefício para ambientes clusterizados, vide hardwares para tal operação são muitas vezes ineficientes e bastante custosos.

Aproveitando o tópico, clientes swing acessando as regras de negócio no app. server teria outra opção além de uma camada de Session Beans fazendo a ligação entre eles? Não sou simpático em utilizar chamadas http no cliente swing e estou começando um sistema com a abordagem que citei acima…

Olá

Então empatamos pois eu sou favorável a utilizar chamadas Http síncronas ou assíncronas no cliente Swing.

Mas em alguns raros casos concordo que se pode fazer do modo como você falou.

Se quer uma outra opção sem usar Http seria necessário que você desse mais dados da sua aplicação dizendo se ela está confinada em uma rede local que aceita RMI, se está na Internet por trás de firewalls, se será baseada em serviços ou eventos, etc…

[]s
Luca

Em principio está na intranet, mas no futuro deverá ter acesso via internet atrás de um firewall. Será baseado em serviços.

mutano:

Aproveitando o tópico, clientes swing acessando as regras de negócio no app. server teria outra opção além de uma camada de Session Beans fazendo a ligação entre eles? Não sou simpático em utilizar chamadas http no cliente swing e estou começando um sistema com a abordagem que citei acima…

Existem algumas opcoes de remoting para essa situacao, mas nao importa o que voce escolha, nao faca chamadas “na unha”. Diversos frameworks sao capazes de invocar interfaces remotas via HTTP e existe tambem RMI/HTTP(S), o que permite acessar EJBs atraves da porta 80.

Com o genesis, costumamos usar Session Beans mesmo e jah usei RMI/HTTPS algumas vezes.

Pessoal,
Acompanhei as dicussões sobre utilizar ou não EJB. Eu não preciso, afinal não é um sistema distribuído e tal… mas estou precisando utilizar MDB, já que não é adequado utilizar thread em aplicação J2EE.
E agora?
Existe alguma solução que não seja MDB para processamento paralelo nesta situação?
Caso não exista, como fica a arquitetura de um projeto que utiliza somente “parte” de EJB, no caso, somente MDB (Eu não conheço muito de EJB)?

Resolvi me dar ao trabalho de olhar as mensagens todas, e apesar do bom nível técnico das discussão, parece-me que a maioria dos posts abordou a questão do ponto de vista do mérito/demérito dos EJBs para o código, ou seja, uma visão do que é bom/ruim para o desenvolvedor.

Convenhamos, uma vez a aplicação feita (e funcionando), ela vai ser entregue para uma área de produção que não está nem aí se vc. usou Struts ou Mentaway ou Spring para implementar MVC - ou mesmo se vc. usou ou não MVC.

Esta área quer é um conjunto de artefatos para fazer deploy, junto com a especificação dos requisitos estáticos (datasources) e dinâmicos (tamanho dos pools, pex) a sereme configurados.

Uma vez no ar, a produção tem que responder perguntas do tipo: Quantos acessos a página tal tem por dia ? Qual o tempo de resposta ? Qual a evolução no número de usuários nos últimos 6 meses ?

Para responder a estas questões, a aplicação precisa ser constantemente monitorada. Neste momento, o que a produção precisa é uma visão clara dos módulos do sistema e, em caso de problemas, ser capaz de alterar parâmetros em tempo de execução, preferencialmente sem afetar outras aplicações.

Nesta hora, os EJBs (Session, ok ? Acho que todos concordam que Entity Beans foram uma bola fora) apresentam algumas vantagens:

• Um EJB pode ser utilizado como ponto de controle de fluxo, manipulando-de o tamanho do pool de instâncias.

• EJBs podem ser atualizados de forma independente uns dos outros e dos clientes (wars e clientes RMI). Em um ambiente de produção esta flexibilidade pode ser interessante, uma vez que o maior motivo de parada de um aplicativo é para atualização de versões.

• Os containers instrumentam os EJBs (e servlets) de forma a ser possível monitorar os tempos gastos nas sua execução.

Vc. pode fazer isto tudo sem EJBs ? É claro que sim ! Mas será código da aplicação. Mesmo que todas as aplicações usassem o mesmo framework, mesmas versões de bibliotecas - o que não acontece na prática - ainda assim, do ponto de vista da produção, tal solução seria inadequada, e provavelmente criaria problemas operacionais relacionados à dificuldade em operar aplicações com formas distintas de operar.

Com EJBs, ao menos a separação das camadas principais fica exposta de uma forma padronizada, permitindo um ponto de observação/controle/diagnóstico que é independente das bibliotecas utilizadas.

Olá

Beleza, sevestre. Levou 5 estrelas com louvor.

ferstring:

Existe alguma solução que não seja MDB para processamento paralelo nesta situação?
Caso não exista, como fica a arquitetura de um projeto que utiliza somente “parte” de EJB, no caso, somente MDB (Eu não conheço muito de EJB)?

MDBs são ótimos. Como também você poderia fazer tudo sem MDBs usando JMS na raça que nãoé tão difícil assim.

O maior problema que eu vejo não é na tecnologia e sim no fato de você ter dito que não conhece bem. Acho que o conselho mais honesto seria para você procurar aprender o máximo sobre arquiteturas baseadas em mensagens, os conceitos de tópicos e filas, porque a arquitetura de mensagens baseada em MDBs/JMS é boa dentro da empresa e manca na Internet, etc. Um bom livro é o Java Messaging do Eric Bruno.

Desenvolver um software baseado em mensagens assíncronas é o modo mais fácil de ter escalabilidade sem precisar gastar rios de dinheiro com soluções de hardware e rede.

[]s
Luca

gente hoje eu não vou fazer grandes debates, vou apenas fazer perguntas e dar infos…

o que acham de spring em cluster?
www.terracottatech.com/pdf/Spring.pdf

HTTP Invoker para acesso remoto?
vcs sabiam que esta solução esta disponivel? (beta ainda).
se sabiam o que muda? alguma consideração?

acho que EJB e complicado mesmo… não uso mais…