Ok, Sérgio, eu te conheço e sei que você é turrão mas é inteligente o suficiente para ir direto ao ponto. Se você tivesse respondido minha proposta acima adicionando código de transação ao código que eu escrevi você iria estar misturando conceitos.
Transação dificilmente faŕa parte do domínio de negócios, por isso é muito bom ter alguém, seja um EJB, o Spring ou o que for, delimitando isso de maneira transparente, por configuração, metadados ou o que for.
Sobre o tópico em si: eu já tive alguns casos onde usar EJB fazia sentido mas na maioria deles não. Geralmente chamadas remotas são um belo caso de uso para EJB, muito mais simples que gerenciar tudo via RMI.
Outro casod e uso é uma arquitetura CBD. Acontece que quase ninguém sabe o que é CBD, muito menos saber arquiteturar algo assim.
Quanto ao EJB 3.0 eu acho um ótimo trabalho mas só posso ter certeza após algum trabalho sério. Ah, e a falta de Criteria API é simplesmente ridicula e resultante da pressa.
[quote=louds]Sérgio, você pediu um exemplo de sistema que seria bom usar EJB 3.0, eu dei, agora só porque esse é um exemplo ruim para você malhar não vale?
Sinceramente, EJB hoje é útil e recomendável em qualquer sistema que use hibernate. Simples assim. Ou seja, se você vai ter muita manipulação de dados ou precisa de independencia de banco, é uma boa escolha.[/quote]
Achei o seu exemplo um pouco vago. Se possível mostra um problema e apresenta a soluçao com EJB, para eu ver se consigo sugerir outra sem EJB.
Tem razão, Phillip. Modelo de negócio trabalhando com transação parece ruim mesmo, e eu estava pensando em fazer isso.
Mas digamos que o meu modelo de negócio tem uma função que realiza duas operações que precisam ser atomicas.
Então eu faria essas duas operacoes sem se preocupar com transação e depois daria um jeito de abraçar isso com uma transação, certo?
No caso de um projeto web, acredito que 95% das situações vc vai resolver fazendo a requisicao ficar atomica, com um filtro de transação para abraçar qualquer coisa que ela venha a fazer.
Seria diferente quando por algum motivo, na mesma requisiçao vc estivesse disposto a fazer 2 transações independentes. Se o modelo de negócio não deve se preocupar com as transaçoes, então alguma outra coisa teria que delimitar isso. A action poderia fazer na mão, abrindo as transaçoes e chamando o modelo, ou algum outro esquema de demarcação que eu não conheço.
O que me falta e um exemplo clássico de situação onde EJB vai resolver o teu problema de maneira que justifique o seu uso. Esse tal de controle transacional, parece que as situações que ele resolve são raríssimas, como 2PC.
PS: Phillip, tu sabes que tenho consideração pela sua pessoa e pela sua capacidade técnica, meu amigo. Um dia ainda vamos fazer umas brincadeiras aí no Rio. 
Você quer um exemplo que nunca vai existir… nada é insubstituivel… ainda mais em java… voce faz a mesma coisa de 20 formas diferentes… acredito que voce está magoado com EJB 1.x e 2.x e tá querendo procurar pêlo em ovo… se voce quer deixar um filtro servlet cuidar da sua transacao… é uma opcao sua… eu não delegaria essa funcionalidade a um framework web… usaria um EJB ou Spring ou diabo que o parta… acho que cada coisa deve ser usada para um fim especifico… senao… daqui a pouco o webwork vai fazer tela swing tmb… hehe
Sergio, quer um bom exemplo? Uma plataforma de bilhetagem e cobrança.
Os requisitos são bem simples:
:arrow: As regras do negócio devem ser concentradas em um único sistema.
:arrow: Este sistema deve ser acessivel por todos demais sistemas da corporação atraves de uma interface publicada e bem definida.
:arrow: O sistema deve permitir escalabilidade de deployment, isto é, uma alteração nas regras de negocio não deve exigir fazer um deployment de todos sistemas que se utilizam dele.
:arrow: O sistema deve possui ciclo de vida independente dos demais que se utilizam deles.
Ou seja, os requisitos são, a grosso modo, para desenvolver o sistema utilizando SOA e para isto, um framework web é a última coisa no planeta que vc vai querer.
Valeu pelo exemplo. Esse está um pouco mais claro.
Sem necessidade de EJB para isso.
Esse sistema deve prover uma interface de comunicacão para que qualquer sistema possa interagir com ele, certo. Por que não usar HTTP/HTTPS? Qual a necessidade desse sistema que justifique mensagens assíncronas (JMS) ? Por que usar chamadas remotas via EJB, RMI, RPC, SOAP, e essas coisas?
A não ser que vc mude a interface de comunicaçao com o mundo exterior, as regras de negócio poderão ser alteradas sem problemas. Não há necessidade de EJB para obter isso.
Claro, quando o servidor do gmail sai do ar, a sua vida não para.
Tudo depende do protocolo de comunicação que vc quer usar, certo? Há várias opções:
:arrow: HTTP puro
:arrow: XML em cima de HTTP
:arrow: Objeto serializado em cima de HTTP (pode ser binário via post ou hex via get mesmo)
Http só não é muito indicado para um sistema que exiga mensagens assíncronas em real-time, o que não parece ser um requisito desse seu sistema. E mesmo quando precisamos de mensagens assíncronas, na maioria dos casos pooling resolve. E escala sim! Quantas requisiçoes por segundo um tomcat aguenta? Sem contar que vc pode fazer load balance tb para as mensagens assíncronas, sem muita dificuldade.
Sérgio, como nós discutimos.
EJB é um meio de fazer isso
Com EJB 3 você vai na sua classe e coloca:
@Stateless
pronto! Sua classe agora pode ser disponibilizada como serviço, funciona em cluster, tem controle transacional, pode ter acesso a serviços de persistência e segurança e ainda ganha de brinde inversão de controle 
(e mais coisas ainda)
Ta, não é só isso, tem que ter uma ou outra configuração do AS para certos serviços como cluster. Mas é isso aí, acredito que não seja mais complexo que outras alternativas.
Na verdade HTTP não é muito indicado para qualquer coisa que fuja do seu escopo original: transferir documentos.
Neste momento um dos meus projetos é transformar uma interface HTTP para uma orientada a conexão de modo que seja armazenável em um pool. Abrir e fechar conexões está saindo mais caro do que criar e processar a mensagem.
[quote=pcalcado]Na verdade HTTP não é muito indicado para qualquer coisa que fuja do seu escopo original: transferir documentos.
Neste momento um dos meus projetos é transformar uma interface HTTP para uma orientada a conexão de modo que seja armazenável em um pool. Abrir e fechar conexões está saindo mais caro do que criar e processar a mensagem.[/quote]
Fazer pooling de conexões, ou usar KeepAlive com HTTP, é uma otimização importante, mas só quando você não tem milhares de clientes simultâneos tentando fazer isso e causar um DDOS no teu sistema.
A conexão é interna de um sistema com outro e já faz literalmente milhares de requisições por segundo, mas este não é o ponto, o ponto é substituir HTTP por algo que já foi criado para ser mantido conectado e que não tenha um milhões de headers para parsear quando na verdade o que se passa é uma string de até 10 letras.
[quote=saoj]Valeu pelo exemplo. Esse está um pouco mais claro.
…
Esse sistema deve prover uma interface de comunicacão para que qualquer sistema possa interagir com ele, certo. Por que não usar HTTP/HTTPS? Qual a necessidade desse sistema que justifique mensagens assíncronas (JMS) ? Por que usar chamadas remotas via EJB, RMI, RPC, SOAP, e essas coisas?
[/quote]
Não falei nada sobre a tecnologia a ser usada, muito menos o wire protocol. Mas sim que a aplicação deve expor sua funcionalidade de forma bem definida. Ou seja, ser acessivel de forma fácil por outros sistemas. Este é um bom caso para usar EJBs ou Web Services, dependendo da possibilidade de existirem clientes não Java.
O ponto aqui é que a solução criada não pode ser uma biblioteca, pois se assim for, quando alterar alguma regra, todas aplicações que usarem ela, vão precisar de um deploy.
Ciclo de vida do projeto! Não falei em uptime! Conhece aquele papo de ciclo de vide de um software? Então, é isso. Este é um requisito muito comum e importante, já que você não quer atrelar manutenções de um sistema com o de outro. Isso é para ter escalabilidade de recursos (desenvolvedores) e gerência.
Qual o ponto de ficar reinventando a roda se você pode usar um negócio já pronto e que funciona? É a mesma coisa que dizer que é melhor usar servlets puro pra um sistema web em vez de usar o framework MVC adequado. Comunicação remota e sistemas distribuídos baseados em RPC são muito mais faceis de fazer com EJB 3.
saoj, entendo seus contra argumentos até ao EJB 2.1. Eu mesmo sempre fui reticente à adoção de EJBs. Mas conhecendo EJB 3.0 estou seguro de adotar esta tecnologia. È tão simples quanto não usar EJB e você ainda ganha um monte de brindes grátis (JTA, JPA, JMS, etc).
Até ontem fiz sistemas sem EJB e só usei quando era requisito do cliente. Hoje eu aconselho usar, simplesmente por dois fatores: a perfumaria gratuita e ser o padrão de mercado.
Aos olhos do cliente o TCO é menor.
Gostaria de saber como usar o JBOSS sem o EJB e não posso usar o Tomcat… Como devo proceder?
Obrigado
[quote=Jonasg]Gostaria de saber como usar o JBOSS sem o EJB e não posso usar o Tomcat… Como devo proceder?
Obrigado
[/quote]
Se sua aplicação não tiver EJBs (ou fizer acesso a eles), o JBoss não irá criá-los do nada. Faça o deploy do seu WAR e vc. não estará “usando EJBs” só pq está rodando no JBoss (isto vale para qq AppServer).
vou ser curto e grosso:
framework é re-invenção da roda.
mano!! nao para mais essa onda filha da #$%! de framework, #$%! merda, daqui a pouco vao criar um framework q programa pra vc…
parem de procurar alternativas, atalhos ou qqr porra que for pra reduzir a quantidade de linhas à ser digitada, pq daqui a pouco vc vai tar digitando:
C:>please do my job today -verbose -xvf
(AHUhAuhAuAHuAHuAHuAHuAhAUhAUhaUhaUhAUhAUAHuAuAH)
um exemplo lindo e perfeito de que isso ja ta acontecendo:
Iterator??? ITERATOR??? q mane iterator, eh FOR INT I = 0; pana nan pana nan e tal…
e ainda digo mais, vou dar exemplo pratico pra vermos que porra de vantagem tem em usar um ITERATOR(hauhau):
===============================================
List list = new ArrayList();
list.add("programador de apis 1 hauahu");
list.add("programador de apis 2 hauahu");
list.add("programador de apis 3 hauahu");
Iterator it = list.iterator();
List list = new ArrayList();
list.add("programador de apis 1 hauahu");
list.add("programador de apis 2 hauahu");
list.add("programador de apis 3 hauahu");
que coisa…a versão do for, tem menos linhas aHUAHuAHA ridiculo…
OBS: ta eu sei q iterator nao tem nada a ver com framework, mas eh uma reinvencao da roda SIM, e um otimo exemplo disso tbm!
na minha opiniao java é legal, mas emburrece um programador…e cada dia ta emburrecendo mais ainda…daqui a pouco seu chefe cola em vc e fala:
"olha sr. fulano x, aqui nao pode usar essas merdas de iterator e tal pq dificulta o entendimento da logica na hora da manutencao, arrume uma forma alternativa"
"mas sr, eu sou programador frameworkeiro(), e nao sei fazer um loop FOR pra ler um arraylist =("
"bom mas html vc sabe ne? pode me ajudar aqui nesta jsp?"
"é em taglib??? =("
"AHUAHAUhAUhAUhaUhaUahuAHuaHUAH cara, vai pastar vai, c nao sabe nem html pq ja comecou nessas de taglib, aqui eh uma EMPRESA ROOTS, raizes, feita de programadores com base… nao de xucros que acham q tao abafando pq tem sempre uma api q faz tudo por um idiota que nem vc hauhauhauha"
"ai a voz da sabedoria(junto com a do capeta rindo de vc pq vc vai perder o emprego): kakakakakakk mas javeiro é um bicho que nao sabe de nada mesmo, acha q ta abafando com aquele framework porco novo q saiu agora feito no fundo do quintal… vai programar c++ rapá! quero ver vc se fudendo nos malloc() da vida hauHAuAHuAHuAH"
assume sua funcao: VC EH UM PROGRAMADOR E NAO UM USUARIO FINAL, PORTANTO VC TEM Q SABER PROGRAMAR E NAO FICAR USANDO FERRAMENTINHA RALÉ PRA PROGRAMAR SEM DIFICULDADES, PQ O MERITO VAI PRO CARA QUE FEZ O FRAMEWORK E NAO PRA VC, IMBECIL.
agora o que isso tem a ver com ejb?? ejb eh uma reinvencao de RMI…e bem mal feita por sinal hauhauah…
sem mais.
Cara, acho que nunca vi tanta bobagem em um lugar só.
Ex.
framework é re-invenção da roda;
RMI = EJB;
Iterator = “for(int i”;
E outra, tenha mais respeito com os comparsas.
Ou volta pro buraco que tu saiu.
hauhauha beleza…
me fala qual a diferenca entre iterator e for? hahahuah o nome e o jeito de fazer eh diferente…e dai? hauhauha
onde que eu falei q RMI É EJB??? onde??
eu disse q EJB usa principios RMI e eh praticamente baseado nisso…como uma aplicacao distribuida se comunica com seus fragmentos? via RMI…atraves de um lookup no container ejb via jndi…ou seja ejb eh um nome bonitinho pra rmi…com alguns lances de regras de negocios…
[color=red][size=24]Restante do post apagado [/size]
Mensagens com mesmo tom de desreispeito serão deliberadamente apagadas sem mais avisos[/color]
Bom.
Sobre o iterator http://web.cs.wpi.edu/~gpollice/cs509-s04/Patterns/IteratorPattern.html
Você dizer
é bem diferente de
E o motivo de qualquer framework existir é exatamente para não reinventarmos a roda.
Pois aquele código que tínhamos que programar em todos os projetos (o mesmo código), agora é colocado em um framework e reusado em todos(logo não reinventamos a roda);
E outra, não seja mal educado por que ninguém aqui é bixo pra falar dessa maneira.
Exponha suas idéias e diga que são suas, não saia chingando o que não conhece só por que acabou de conhecer uma tecnologia diferente que achou melhor.
e nao quer dizer a mesma coisa??? ahUHAUhAUhAUahuaHuaHuahAUhAUha OMG…
(to falando de rmi e ejb)
voltando aos frameworks:
framework é sinonimo de lazy programmer detected(hauhAUHA), blz agora falando serio. é uma reinvencao da roda sim pq framework eh uma incrementacao tosca pra uma determinada sessao da linguagem java ou seja frameworks vieram depois que java foi lancado…logo o que vc ta me falando LOGICAMENTe nao prossegue…
quer reciclar objetos? velho, ce quer ser lixeiro ou programar java? hAUHAU com essa onda de framework, tá parecendo aquele brinquedo de montar: LEGO…vc pega os tecos do codigo, ctrl + c, ctrl + v, e ja era, ai da pau e o animal nem sabe porque, de tanta camada que tem em cima da aplicacao java dele…virou uma salada de frameworks hauha UAUU que POWER-ADVANCED…pra mim javeiro nao sabe de nada e quer só complicar os codigos com essas palavras bonitas, elegantes e grandes, pra poder valorizar seu trabalho(como o q ocorreu no EJB 1.1 kakakakk q todos viram q era uma grande merda)
ahh! li seu artigo do iterator e nao vi nenhuma vantagem em utiliza-lo ainda hauha, obrigado de qualquer forma(sem ironia), qualquer conhecimento é bem vindo, mas prefiro meu FOR.
pense comigo: o tempo que vc perde aprendendo uma porra de um framework novo, vc pode usar criando sua propria estrutura e dps utiliza-la inumeras vezes…a concepcao do struts por exemplo, é legal, mas vc nao precisa usar o struts pra usar o modelo MVC de aplicacoes web…
sem mais por enqto