EJB em desuso ... em detrimento dos Pojos? ainda não entendi!

O Core J2EE Patterns eh um livro antigasso, da epoca em que a comunidade Java achava bonito ser complicado.

Se quiser estudar alguma coisa util daqui pra frente, faca uma cerimoniazinha pra queimar o seu Core J2EE Patterns, e aprenda Hibernate e JPA.

CV …

Hibernate eu já aprendi… legal demais… mas o que é JPA?

+1

A pergunta é porque vc precisa de EJB? Provavelmente não precisa… No passado, porque algumas empresas queriam vender application servers de milhares de dólares por processador e consultorias que queriam vender projetos de milhares de dólares é que ele foi enfiado goela abaixo da comunidade Java. Lamentável…

ah…

Também li neste feriado de carnaval … o DDD em inglês… muito bom… mas pena que não tinha exemplos

em códigos para exemplificar

exemplos para exemplificar… que redundância meu Deus

Pois é … e tem um pessoal aqui no fórum que

Está recomendando o livro sobre Enterprise JavaBeans 3

aqui neste tópico
http://www.guj.com.br/posts/list/81185.java#431868

O que acham?

sandeco, quando for acrescentar algo a sua resposta e ela foi a ultima do post, edite ela. Evite o flood.

Att,

Renan

Mas EJB continua sendo desnecessário na maioria dos casos.

E se vc quer chamadas remotas, use web services via HTTP = REST, ou xFire ou até mesmo SOAP.

Application server é um contra-senso, na minha opinião. Mas tem gente que acha que eles são fundamentais e “abstraem” complexidade.

A complexidade que eles abstraem não é mais complexidade a um par de anos e a maneira com que eles abstraem é péssima.

Minha opinião pessoal, ok?

Alguém me corrija se há outras opções, mas eu só usaria EJB para mensagens assíncronas. Não porque eu acho bom, mas porque a complexidade de desenvolver o seu próprio queue de mensagens é realmente grande!

Eu pensava assim até EJB 2.1 Com a versão 3.0 e agora 3.1 eu uso e recomendo.

Fora que hoje, com a nova especificação, EJB são “praticamente” POJOS. Facilita.

Eu acho que o conceito EJB em si é desnecessário! O que vc ganha com ele?

Só consigo imaginar duas coisas: cluster (vide Terracota e JGroups) e mensagens assíncronas (vide ???)

São poucos os sistemas que justitifcam o uso de chamadas remotas (sistemas distribuídos) e ainda mais raros os sistemas que justificam o uso mensagens assíncronas. Existem mas são a exceção e não a regra!

Hoje estou em um grande projeto onde sem EJB seria “praticamente impossível”.

Hoje estou em um grande projeto onde sem EJB seria “praticamente impossível”.

Deve ser um projeto especial (exceção e não a regra).

Mas por curiosidade, o que vc utiliza nele que não poderia ter sem EJB ? Mensagens assíncronas? Cluster? Chamadas remotas?

Tirando o cluster, porque vc precisa de mensagens assincronas e chamadas remotas? Deve ser um sistemas realmente distribuído e que precisa realmente ser distribuído. Então se vc estiver utilizando mensagens assíncronas tudo bem. Cluster, talvez. Chamadas remotas não sei…

Sistema distribuído. Hoje (ainda não implantamos em produção) estamos com apenas uma instância rodando os sistemas, mas há previsão de distribuir por nós/clusters.

Fora que o modelo de desenvolvimento fez com quem EJB fosse uma solução viável. São 5 empresas fazendo partes do mesmo sistema. Não faria sentido nenhuma usar WebServices para comunicar um pedaço com outro.

Demorei algum tempo para entender o que é realmente um sistema distribuído. Acredito que um sistema distribuído é um sistema onde vários módulos independentes (ou outros sistemas) estão distribuídos em máquinas diferentes e precisam conversar entre si. Vc pode fazer essa conversa com mensagens assínconras ou chamadas remotas.

É esse o seu caso?

Quando vc falou do cluster, eu entendi que vc quer colocar o seu sistema (apenas um) em cluster com fail-over.

Essas “partes” do sistema vão rodar independentemente em máquinas diferentes e precisarão se comunicar entre si? Caso positivo então vc tem verdadeiramente um sistema distribuído.

A questão, interessante pelo menos pra mim, é que algumas vezes um sistema possui várias partes independentes, mas ele não precisa ser necessariamente distribuído. Eu só penso em distribuído quando eu penso assim: “Quero esse sistema rodando, separadamente e independentemente desse outro aqui.”

saoj:

A questão, interessante pelo menos pra mim, é que algumas vezes um sistema possui várias partes independentes, mas ele não precisa ser necessariamente distribuído. Eu só penso em distribuído quando eu penso assim: “Quero esse sistema rodando, separadamente e independentemente desse outro aqui.”

Adolfo Rodrigues:

saoj:

A questão, interessante pelo menos pra mim, é que algumas vezes um sistema possui várias partes independentes, mas ele não precisa ser necessariamente distribuído. Eu só penso em distribuído quando eu penso assim: “Quero esse sistema rodando, separadamente e independentemente desse outro aqui.”

Sérgio, eu já trabalhei num projeto em que a camada de apresentação e a camada de negócios de um mesmo sistema rodavam em máquinas separadas. Tinha esse requisito (acho que por questões de segurança da empresa), eram dois pacotes diferentes, rodando em máquinas diferentes. Acredito que seja mais um caso em que chamadas remotas se fazem uma boa opção.

Verdade, mas vc usou EJB só pra isso? Eu acharia melhor usar RMI. Ou não?

saoj:

Adolfo Rodrigues:

saoj:

A questão, interessante pelo menos pra mim, é que algumas vezes um sistema possui várias partes independentes, mas ele não precisa ser necessariamente distribuído. Eu só penso em distribuído quando eu penso assim: “Quero esse sistema rodando, separadamente e independentemente desse outro aqui.”

Sérgio, eu já trabalhei num projeto em que a camada de apresentação e a camada de negócios de um mesmo sistema rodavam em máquinas separadas. Tinha esse requisito (acho que por questões de segurança da empresa), eram dois pacotes diferentes, rodando em máquinas diferentes. Acredito que seja mais um caso em que chamadas remotas se fazem uma boa opção.

Verdade, mas vc usou EJB só pra isso? Eu acharia melhor usar RMI. Ou não?

Sim. Exatamente!

Existe, obviamente, uma interdependência entre cada componente, mas existem componentes independentes (camadas mais baixas) e as camadas adjacentes usam estes componentes e assim segue até a view.

Hoje, como eu disse, estão todos no mesmo balaio (app server/container/jvm), mas logo devem se espalhar fisicamente e não precisaremos mudar uma linha de código sequer.

E sobre RMI em detrimento ao EJB. Porque vou escreve algo já feito? Padrões! Ajudam muito na hora de trocar o pessoal (turn over) e continuar a manutenção no “mesmo ritmo”.

Olha o TCO (Total Cosf of Ownership) ai.

Só adicionando uma informação. Cada grupo de funcionalidade do meu sistema, eu chamei de serviço. Então tenho uma arquitetura “SOA”, feita com EJBs.

WebServices seriam inapropriados demais, então optamos por EJB mesmo. Fora a questão de controle transacional etc.

Alguém sabe dizer se o livro

POJOs in action da mannig é bom?
http://www.linuxmall.com.br/index.php?product_id=4525

Alguem tem o PDF dele?

… Ou alguém pode indicar alguma literatura sobre o assunto?

Sanderson

você não precisa de ejb para usar jms:
http://openjms.sourceforge.net/

Destro,

Que tal manter tudo como chamada local e quando migrar para distribuida voce muda? (supndo EJB 2.x)

pcalcado:

Destro,

Que tal manter tudo como chamada local e quando migrar para distribuida voce muda? (supndo EJB 2.x)

Porque este QUANDO é muito próximo. Os sistemas ainda nem foram homologados. E o nosso QUANDO deve ocorrer quando entrar em produção ( aka 2008 ).

http://www.guj.com.br/posts/list/81830.java

Vamos lá, mas o que é um EJB.

Descrição sucinta:

Os antigos EJB 2.0 realmente acrescentavam uma complexidade, na maioria das vezes desncesárias para projetos, porém agora com a nova especificação EJB 3.0 os próprios ejb’s agora são POJOs; veja os exemplos.

EJB 2.1

public interface BankingService extends EJBObject {
        
    public void deposit(int accountId, float amount) throws RemoteException;
        
    public void withdraw(int accountId, float amount)throws RemoteException;
        
    public float getBalance(int accountId) throws RemoteException;


    public void doServiceLogout() throws RemoteException;
 
}


public interface BankingServiceHome extends EJBHome {
    public BankingService create() throws CreateException, RemoteException;
}


public class BankingServiceEJB implements SessionBean {


    public void deposit(int accountId, float amount) throws RemoteException {
    //Business logic to deposit the specified amount and update the balance
    }


    public void withdraw(int accountId, float amount)throws RemoteException {
    //Business logic to withdraw the desired amount and update the balance
    }


    public float getBalance(int accountId) throws RemoteException {
    //Business logic to get the current balance
    }


    public void doServiceLogout() throws RemoteException {
    //Service completion and logout logic
    }


    public void ejbCreate(){}
    public void ejbActivate(){}
    public void ejbPassivate(){}
    public void ejbRemove(){}
    public void setSessionContext(SessionContext context){}


}

EJB 3.0 (POJO)

@Remote
public interface BankingService {
    public void deposit(int accountId, float amount);
    public void withdraw(int accountId, float amount);
    public float getBalance(int accountId);
    publlic void doServiceLogout();


}





@Stateful
public class BankingServiceBean implements BankingService {


    public void deposit(int accountId, float amount) {
    //Business logic to deposit the specified amount and update the balance
    }


    public void withdraw(int accountId, float amount) {
    //Business logic to withdraw the desired amount and update the balance
    }


    public float getBalance(int accountId) {
    //Business logic to get the current balance
    }


    @Remove
    public void doServiceLogout () {
    //Service completion and logout logic
    }


}

Você pode notar que não é mais necessário estender ou implementar nenhuma classe e/ou inteface, vc precisa somente utilizar as devidas anotações;

Algumas vantagens do uso de EJB.

Veja mais aqui

http://rfiume.blogspot.com/2007/03/sobre-ejb-30.html

http://dev2dev.bea.com/pub/a/2006/01/ejb-3.html

http://dev2dev.bea.com/pub/e/841

Um artigo interessante

POJO Application Frameworks: Spring Vs. EJB 3.0

Se quiser mais é so googlar um pouquinho.

Eu pensava assim até EJB 2.1 Com a versão 3.0 e agora 3.1 eu uso e recomendo.

Fora que hoje, com a nova especificação, EJB são “praticamente” POJOS. Facilita.

++

E ainda vai melhorar, pois estão previstas novas mudanças para EE 6, como por exemplo:

Não será preciso mais nem mesmo uma interface;

A possibilidade de distribuir EJB’s dentro do próprio WAR;

Entre outras;

Eu tb recomendo, especialmente EJB 3 + JPA; Mistura “explosiva”; hehehehehehe

E que tal SEAM + EJB3 + JPA!!!

As coisas melhoraram muito, só acho uma pena que JEE 5 ainda seja pouco utilizado pelas empresas a meu ver.

Hoje estou em um grande projeto onde sem EJB seria “praticamente impossível”.

Deve ser um projeto especial (exceção e não a regra).

Mas por curiosidade, o que vc utiliza nele que não poderia ter sem EJB ? Mensagens assíncronas? Cluster? Chamadas remotas?

Tirando o cluster, porque vc precisa de mensagens assincronas e chamadas remotas? Deve ser um sistemas realmente distribuído e que precisa realmente ser distribuído. Então se vc estiver utilizando mensagens assíncronas tudo bem. Cluster, talvez. Chamadas remotas não sei…

Depende, eu hoje, mesmo que não seja preciso trabalhar em um ambiente distribuido, ou com serviços de messageria mas for necessário um controle robusto de transações, segurança (declarativa) usaria EJB 3; principalmente pela facilidade e por ser uma especifcação.

IMO.