[quote=Rafael Nunes]Para aplicações distribuídas, com a facilidade que o EJB3 trouxe e junto alguns bons mecanismos(DI, por exemplo), eu optaria por ele.
[/quote]
Spring FrameWork você não vai precisar de Application Service (Containers EJB), todavia a arquitetura vai lhe obrigar a compatibilizar o tende ser mais vantageoso em termos de manutenabilidade.
Uma decisão a se pensar, ao design da arquitetura a ser projetada em vista de todo um processo.
Com SpringRemoting, um RMI não resolveria? e também não sei como é no EJB3, mas no 2.1 tenho que implementar n interfaces para ser remoto!
com Spring apenas denoto e em execução se torna Remote.
Só não sei como ficaria a transação com SpringRemoting.
Ps: Por que você precisa colocar uma(ou várias) imagem gigantesca em toda mensagem sua?
[quote=rpffoz]
Com SpringRemoting, um RMI não resolveria? e também não sei como é no EJB3, mas no 2.1 tenho que implementar n interfaces para ser remoto!
com Spring apenas denoto e em execução se torna Remote. [/quote]
Sim, resolveria, mas como disse, a facilidade que tenho com EJB3 não sei se compensaria(nunca utilizei o Spring pra fazer comunicação remota). E ao contrário do EJB2, o EJB3 você só precisa de uma interface comum(que será sua interface remota) e uma classe(que será seu EJB) com duas anotações.
[quote=rpffoz]
Só não sei como ficaria a transação com SpringRemoting.[/quote]
Com EJB eu deixo isso a cargo do container. E como nunca tive que fazer nada muito complexo em relação a transações, tem me atendido perfeitamente.
Se sua aplicação vai ser realment distribuida, eu fico com EJB3.
Eu tinha em trauma com EJB por causa de um projeto em 2004 suando a versão 2.1, e nem podia ouvir falr nessa palavra.
Mas a um tempo atras resolvi dar uma estudada e usei em um projetinho p/ ver como era. Muito facil de usar.
Pontos que destaco nessa versao:
1 - Não depende mais explicitamente da API de RMI, vc usa classes e interfaces java normais.
2 - Suporte a DI direto pelo container.
3 - Controle de transações transparente.
4 - Facil de escalar se for necessario.
5 - “Independencia” de container.
IMHO, hoje se eu precisasse desenvolver um sistema distribuido eu escolheria EJB3.
Hun… realmente hoje não vou distribuir meus objetos, logo o Spring me atende muito bem.
Mas taí, se houver a necessidade de distribuir objetos em outra aplicação, eu darei uma pesquisada.
Quanto as vantagens, acredito que fica pau a pau com o Spring atualmente, só me encucou um detalhe, o que você quis dizer com:
Hun… realmente hoje não vou distribuir meus objetos, logo o Spring me atende muito bem.
Mas taí, se houver a necessidade de distribuir objetos em outra aplicação, eu darei uma pesquisada.
Quanto as vantagens, acredito que fica pau a pau com o Spring atualmente, só me encucou um detalhe, o que você quis dizer com:
!?!?[/quote]
Teoricamente, se vc pegar sua aplicação usando EJB3, gerar um EAR dela, vc pode fazer deploy em qualquer container EJB que implemente a especificação.
Coloquei entre aspas pq ainda não testei isso, e nos sabemos que entre a teoria e a pratica tem um grande distancia… hehe
na verdade você precisa apenas de uma interface para distribuir… esse e a implementação do lado servidor… apenas a interface ITesteServiceBean precisa ser de fato distribuida…
mais para distribuir eu tbm vou de EJB… a não ser que vc use spring na sua aplicação delegando as transações para o container EJB e usar EJB de fachada…
Acredito que isso vai depender do contexto (conhecimento do arquiteto, tempo, atributos de qualidade, requisitos do sistema) da tua arquitetura.
Agora as vantagens e desvantagens de cada um em contextos conhecidos:
Gerenciamento de transação:
Acho muito interessante porder definir um TransactionManager utilizando aspectos, e de “esquecer” um pouco disso e ainda ter flexibilidade sem alterar código depois.
EJB3 tem os interceptors, mas acho mais flexível os tipos de definições disponíveis no Spring (regExp, pointcut, annotation) além de ser menos intrusivos e você ainda pode definir o escopo dos objetos, etc.
Distribuição:
Existem várias estratégias de distribuição e o motivo de porque você implementá-las. Se for por performance, temos que ver onde está o gargalho, pois temos várias soluções desde de optimização de selects lentos, load balance, até virtualização, e em último caso alteração de código. A maioria dos problemas que já vi em relação a sistemas bem desenvolvidos foi por causa de I/O ou lock em algum objeto/dado, que são problemas de sobrecarga e concorrência, ou seja, arquitetura.
Como EJB3 é uma API, os comparativos vão depender de qual servidor de aplicação está sendo usado e qual tipo de sistema temos. O mesmo acontece com o Spring, pois essas estratégias são plugáveis dentro do contexto do Spring, que vão desde de barramento de serviços de dados, clusterização (Terracotta), SpringRemote, etc. (Não esqueçam do SCA que deve estabilizar em breve, plugável também no Spring)
Acesso a dados:
JPA é uma padronização já esperada, mas que ainda falta alguns itens como Criteria e StoredProcedure mais robusta, infelizmente ainda vou continuar com os meus DAOs, ainda não dá para injetar um EntityManager e usar ele para tudo.
Extensibilidade
Agora com o Spring 2.5, podemos definir schemas e usá-los dentro do contexto do Spring. As especificações e as novas funcionalidades da plataforma Java tente a ser mais demoras e nem por isso, como vimos, vão ser melhores que as da comunidade.
Padrão de mercado
Acredito que a grande maioria dos projetos começam com a célebre frase, “o sistema é somente alguns processos e uns cadastros simples”. Com o Spring consigo crescer sem muitos problemas de refactore de forma simples, e com o EJB já tenho que está dentro de certos padrões, isso não ruim, mas para fazer um pequeno sistema é chato. JBoss Seam está melhorando essa integração da plataforma Java, mas ele ainda não faz parte de nenhuma JSR, ah faz sim, WebBeans, ou seja, vai demorar, é promessa.
Deployment
Para EJB3 isso é bem legal, criar um EAR e fazer um deploy “no sangue”. Isso depende muito de como foi projetado o sistema, ja tive problemas com sistemas que tinham singletons, mas isso deve se amenizado em breve com os frameworks a nível de bytecode (asm, cglib).
Aqui a plataforma entrou na frente, porque só existe Spring Dynamic Modules, mas ainda tá verde.
Teste
Ah, isso não dá para comparar, pois a plataforma por ela mesmo, não tem facilidades ou API para testes. O Spring, é igual a chiclete que gruda em tudo, JUnit e uma API já estão disponíveis.
E ainda existe uma outra possibilidade, Spring com EJB3, já pensou nisso ? Ter o melhor dos dois em um projeto. Segundo o Spring Reference, dá sem problemas!
Vejo a plataforma JEE como um corredor em segundo lugar sempre atrás do primeiro, pegando o vácuo e vendo os buracos que não deve pisar. Isso é muito bom.
A comunidade cria, testa e vira API.
A gente começa a usar e vê oportunidades de soluções, implementa, virá padrão de mercado;
Torna-se API.!
Ciclo de aprimoramento da plataforma Java. Não sei se DotNet tem isso, mas vou descobrir, até me cadastrei no The Journal Architecture. (Calma, eu não sou “traíra”, só quero ver o tem do outro lado do rio.)
Veja que mais e mais o trabalho de um arquiteto, que tem conhecimento dessas vantagens e desvantagens, está sendo valorizado porque essas respostas dependem de muitas variáveis a analisar.
Me clareou algumas coisas e me mostrou algumas, não conhecho SCA, mas nada como uma Googlada não resolva.
Quanto ao seu ponto de vista, realmente um arquiteto tem que estar o máximo preparado com tais tecnologias,
como disse, minha formação é EJB 2.1, mas nas horas vagas estou me atualizando! +)