Jboss Seam 2.0.0 GA liberado

This message was edited 1 time. Last update was at 14/11/2007 11:26:15

jonataswingeter wrote:
1) O Seam não mata a idéia do EJB de ser uma aplicação distribuída?
Por exemplo, tenho uma arquitetura N-tier e estou precisando escalar o servidor de aplicação
pois houve um acréscimo alto do uso dos serviços. Se eu distribuir essa aplicação,
terei acoplado junto ao EJB o jboss seam, que por sua vez é acoplado ao JSF.
Eu precisaria então ter o tomcat e o jboss no mesmo server para escalar?

Não chequei a estudar a fundo isso pois a aplicação que estou fazendo nele não é para milhares de usuário, porém, como está baseado na consistente implementação do Jboss EJB 3, não vejo problema de escalar. Também não vejo muito ganho separar o Tomcat do Jboss para escalar. Bom, o Seam se posiciona no mercado como uma alternativa "Enterprise Level" de desenvolvimento rápido concorrendo com o Rails. Espero que eles tenham uma boa alternativa para clusterring.

jonataswingeter wrote:
2) Como eu posso pensar em POJO utilizando um serviço EJB sendo que meu EJB
representa as próprias ações do Presentatior Layer? Isto não me forçaria a pensar
de um modo procedural (Transaction Script) ?

Jonatas, estou usando o Seam e é o projeto web mais DDD que fiz até o momento. Lembre-se que é EJB3. O fato de você poder colocar um SFSB como camada de aplicação bindada direto na página não gera nada procedural. Estamos usando SFSB como Application Façade [Fowler], e neles, só ficam regras do objetivo do usuário, não necessariamente regras de view (essas ficam no xhtml). As regras de negócio ficam todas no Domain Model logo abaixo. Você viu algum exemplo? O que achou procedural ou TS neles?

jonataswingeter wrote:
3) Ex: Meu change request tem a necessidade de trocar o presentation layer
pois o cliente quer uma interface de usuário mais amigável (RIA), e precisarei
retirar o JSF. Precisarei refatorar a camada de aplicação inteira para desacoplar
o Seam (anotações, páginas de retorno, etc). Como seria isto?

Estou usando Facelets e MyFaces e minhas páginas são todas muito ricas e AJAX. O que você chama de RIA? Sei que existem exemplos de integração do Seam com Flex, mas no meu caso, a implementação JSF já me gera páginas ricas.

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

jonataswingeter wrote:1) O Seam não mata a idéia do EJB de ser uma aplicação distribuída?
Por exemplo, tenho uma arquitetura N-tier e estou precisando escalar o servidor de aplicação
pois houve um acréscimo alto do uso dos serviços. Se eu distribuir essa aplicação,
terei acoplado junto ao EJB o jboss seam, que por sua vez é acoplado ao JSF.
Eu precisaria então ter o tomcat e o jboss no mesmo server para escalar?

Não mata não. O Seam não força uma arquitetura, apesar de dar preferência a interfaces locais, ainda é possível usar o EJB que está em outra máquina, porém usando a anotação tradicional @EJB.
É preciso entender também que o Seam, assim como muitos framworks por aí, não é distribuído em um único JAR. Na aplicação final, haverá uns Jars na parte web, e outros Jars na parte EJB.
E uma última coisa, é muito difícil chegar a uma situação onde é necessário distribuir a aplicação, e nem sempre traz resultados efetivos.

jonataswingeter wrote:2) Como eu posso pensar em POJO utilizando um serviço EJB sendo que meu EJB
representa as próprias ações do Presentatior Layer? Isto não me forçaria a pensar
de um modo procedural (Transaction Script) ?

A partir do EJB 3.0, o bean que implementa as interfaces do EJB virou POJO. E só por isso, a sua colocação cai por terra.

jonataswingeter wrote:3) Ex: Meu change request tem a necessidade de trocar o presentation layer
pois o cliente quer uma interface de usuário mais amigável (RIA), e precisarei
retirar o JSF. Precisarei refatorar a camada de aplicação inteira para desacoplar
o Seam (anotações, páginas de retorno, etc). Como seria isto?

O que eu vi é que o Seam pode ser usado com Groovy ou GWT, ao invés de JSF. Mas eu não chegeui a testar isso. O que eu estranhei é que a "a interface de usuário mais amigável" (e você ainda colocou a sigla RIA, como se ambos fossem a mesma coisa) não significa trocar a tecnologia de apresentação. Dá muito bem pra pra fazer a interface de usuário mais amigável do mundo usando JSF, só não sei se é o mais adequado. Ainda por cima, é bom lembrar que o managed bean do JSF já é desacoplado das páginas de apresentação.

JavaBaby Membro desde: 20/11/2006 10:15:55 Mensagens: 90 Offline

rodrigoy wrote:

jonataswingeter wrote:
1) O Seam não mata a idéia do EJB de ser uma aplicação distribuída?
Por exemplo, tenho uma arquitetura N-tier e estou precisando escalar o servidor de aplicação
pois houve um acréscimo alto do uso dos serviços. Se eu distribuir essa aplicação,
terei acoplado junto ao EJB o jboss seam, que por sua vez é acoplado ao JSF.
Eu precisaria então ter o tomcat e o jboss no mesmo server para escalar?

Não chequei a estudar a fundo isso pois a aplicação que estou fazendo nele não é para milhares de usuário, porém, como está baseado na consistente implementação do Jboss EJB 3, não vejo problema de escalar. Também não vejo muito ganho separar o Tomcat do Jboss para escalar. Bom, o Seam se posiciona no mercado como uma alternativa "Enterprise Level" de desenvolvimento rápido concorrendo com o Rails. Espero que eles tenham uma boa alternativa para clusterring.

Opa Rodrigo..Então...gostaria de ver uma aplicação usando Seam ser escalável. Na verdade gostaria de ver isso na prática. Sobre a questão de desenvolvimento rápido...não julgo se é bom ou não....mas se me permite uma maleabilidade em termos de arquitetura.
O que me justificaria usar EJB, seria ter uma aplicação escalável e distribuída. Se vou ter o Presentation Layer e o Application Layer na mesma JVM, não vejo necessidade de ter EJB. Porque não Spring então??
O que eu queria saber mesmo, que não achei até agora...é se o Seam força o Tomcat estar na mesma JVM de um JBoss, por exemplo. É uma dúvida que tenho.

jonataswingeter wrote:
2) Como eu posso pensar em POJO utilizando um serviço EJB sendo que meu EJB
representa as próprias ações do Presentatior Layer? Isto não me forçaria a pensar
de um modo procedural (Transaction Script) ?

Jonatas, estou usando o Seam e é o projeto web mais DDD que fiz até o momento. Lembre-se que é EJB3. O fato de você poder colocar um SFSB como camada de aplicação bindada direto na página não gera nada procedural. Estamos usando SFSB como Application Façade [Fowler], e neles, só ficam regras do objetivo do usuário, não necessariamente regras de view (essas ficam no xhtml). As regras de negócio ficam todas no Domain Model logo abaixo. Você viu algum exemplo? O que achou procedural ou TS neles?

Na verdade, você tem razão. A minha questão é saber se o pessoal anda fazendo os EJBs como se fossem Actions da presentation Layer e se eu quiser mapear um EJB (Stateless SB, por exemplo) para um WebService,
terei algum problema. Não acho legal associar o EJB como uma ação do presentation Layer retornando a página de web (return "index.xhtml; "). Já vi uns exemplos assim e não achei legal.

jonataswingeter wrote:
3) Ex: Meu change request tem a necessidade de trocar o presentation layer
pois o cliente quer uma interface de usuário mais amigável (RIA), e precisarei
retirar o JSF. Precisarei refatorar a camada de aplicação inteira para desacoplar
o Seam (anotações, páginas de retorno, etc). Como seria isto?

Estou usando Facelets e MyFaces e minhas páginas são todas muito ricas e AJAX. O que você chama de RIA? Sei que existem exemplos de integração do Seam com Flex, mas no meu caso, a implementação JSF já me gera páginas ricas.

Talvez não tenha colocado o termo da melhor forma. Vamos dizer que trabalho com desenvolvimento de framework e não acho que pelo fato do JSF poder ter um renderer diferente o mundo brilha e fica tudo bonito, atém porque os comportamentos podem ser diferentes se eu quiser desenvolver componentes com ExtJS, Flex, coocsdo, GWT, etc...Vi um tempo atrás um artigo do Gaving falando sobre a possível integração com outros frameworks, além de JSF. Mas até agora a única coisa que percebi que o Seam é realmente uma Emenda para resolver os problemas do JSF, como manter estado de conversação, IoC de ManagedBeans, abstração do HTTP, etc...Isso é minha visão, se eu estiver errado, por favor me corriga.

RIA é um conceito um tanto subjetivo e quando digo interface amigável, realmente me refiro a um modelo rico mesmo, estilo ExtJS ou Flex. Acho o JSF um pouco engessado, apesar de ser compatível com A4J, DWR...mas na prática existem diversos bugs que vão aparecendo...mas ainda sim é melhor que a maioria dos concorrentes.

Valeu, por enquanto é isso.

Jônatas

JavaBaby Membro desde: 20/11/2006 10:15:55 Mensagens: 90 Offline

Olá Leonardo, boa tarde.

A mensagem que respondi ao Rodrigo também serve a você.

Sobre a possibilidade do EJB3 ter POJO, isso não tira a possibilidade do programador de injetar regras de navegação do JSF no POJO, fazendo um acoplamento. Se eu quiser trabalhar com Binding dos componentes no JSF...vou colocar no EJB ou vou usar uma técnica diferente?

Percebe...pra cometer um erro é muito fácil. Já vi alguns exemplos na internet meio feio. Mas se vc tiver uma boa técnica coloca aí pra gente ver...pelo menos o conceito, não precisa do código, eheheheheheh

Att.,

Jônatas

Leonardo3001 wrote:

jonataswingeter wrote:1) O Seam não mata a idéia do EJB de ser uma aplicação distribuída?
Por exemplo, tenho uma arquitetura N-tier e estou precisando escalar o servidor de aplicação
pois houve um acréscimo alto do uso dos serviços. Se eu distribuir essa aplicação,
terei acoplado junto ao EJB o jboss seam, que por sua vez é acoplado ao JSF.
Eu precisaria então ter o tomcat e o jboss no mesmo server para escalar?

Não mata não. O Seam não força uma arquitetura, apesar de dar preferência a interfaces locais, ainda é possível usar o EJB que está em outra máquina, porém usando a anotação tradicional @EJB.
É preciso entender também que o Seam, assim como muitos framworks por aí, não é distribuído em um único JAR. Na aplicação final, haverá uns Jars na parte web, e outros Jars na parte EJB.
E uma última coisa, é muito difícil chegar a uma situação onde é necessário distribuir a aplicação, e nem sempre traz resultados efetivos.

jonataswingeter wrote:2) Como eu posso pensar em POJO utilizando um serviço EJB sendo que meu EJB
representa as próprias ações do Presentatior Layer? Isto não me forçaria a pensar
de um modo procedural (Transaction Script) ?

A partir do EJB 3.0, o bean que implementa as interfaces do EJB virou POJO. E só por isso, a sua colocação cai por terra.

jonataswingeter wrote:3) Ex: Meu change request tem a necessidade de trocar o presentation layer
pois o cliente quer uma interface de usuário mais amigável (RIA), e precisarei
retirar o JSF. Precisarei refatorar a camada de aplicação inteira para desacoplar
o Seam (anotações, páginas de retorno, etc). Como seria isto?

O que eu vi é que o Seam pode ser usado com Groovy ou GWT, ao invés de JSF. Mas eu não chegeui a testar isso. O que eu estranhei é que a "a interface de usuário mais amigável" (e você ainda colocou a sigla RIA, como se ambos fossem a mesma coisa) não significa trocar a tecnologia de apresentação. Dá muito bem pra pra fazer a interface de usuário mais amigável do mundo usando JSF, só não sei se é o mais adequado. Ainda por cima, é bom lembrar que o managed bean do JSF já é desacoplado das páginas de apresentação.

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

O retorno de um managed bean tradicional, de um session bean no Seam, ou de um action no Struts 2, não é a página pra onde se vai, mas uma mensagem indicando seu status, como por exemplo: success, loginOk, failed ou qualquer outra string. Haverá um xml de configuração que mapeia esses retornos para a próxima página. Por conta disso, não existe acoplamento na camada de apresentação.

Claro que o Seam passou a permitir algo que o JSF não tinha, que é colocar a próxima página a ser mostrada direto no Session Bean, mas não acho isso recomendável. Apesar disso, dá pra fazer no método que eu descrevi acima.

A palavra "escalável" é mais uma daquelas palavrinhas mágicas que os çábios da Sun usam pra enfiar goela abaixo o EJB. Não existe bala de prata. Achar que é só colocar um EJB numa outra máquina e "seus problemas acabaram" é idiotice.

JavaBaby Membro desde: 20/11/2006 10:15:55 Mensagens: 90 Offline

Fala Leonardo.

Penso como você. A sempre sempre tem alguma justificativa para usar o EJB.

Por isso quando vejo um projeto com EJB, já penso: Qual a necessidade disso?

Att.,

Peraí, vcs não estão confundindo com EJB 2.1?

É esse o raciocínio de vocês: se precisa ser distribuido usa EJB, se não precisa usa Spring?

Estou usando EJB 3 nesse meu projeto e pelo menos nesse momento (como já falei) a aplicação não necessitará escalar. Uso EJB 3 porque tem DI, Gerenciamento de Transação, Anotações, Remoting e facilidade de desenvolvimento. E também porque tenho nojo de XMLs (isso é pessoal)

No meu projeto grande parte da navegação está definida em retornos de métodos das minhas Actions/Façades que são SFSB. Por algumas razões também tem algumas façades que são SFSB que dependem de HtmlTree. Qual a opinião de vocês a respeito:

1. É pecado e você queimará no marmore do inferno
2. Você é um arquiteto cowboy, seu código é um lixo... vai programar em VB
3. Porque não faz em Asp.NET?
4. Sua aplicação tem uma restrição arquitetural que sua camada de aplicação só serve para páginas Web, e o impacto disso é......

Jonatas, tem um link aqui que pode te ajudar... pelo que entendí, se as conversas estão em cache não precisa mesmo separar o Tomcat do AppServer, mas não estudei a fundo... (é do release anterior)

http://docs.jboss.com/seam/1.2.1.GA/reference/en/html/cache.html

This message was edited 1 time. Last update was at 15/11/2007 15:46:06

rodrigoy wrote:
Lezinho, a sua aplicação manda mails usando Facelets como o manual diz?

Em servidores SMTP com autenticação segura (SSL ou TLS) as versões do Seam 1.2.1 e anteriores funcionam. Porém, para ambientes onde o protocolo não é seguro, existe um bug (se você especifica ssl = false ele tenta se conectar por TLS). Por esse problema eu já passei...
Felizmente tem um simples fix para isso na versão 2.0.0:
http://jira.jboss.com/jira/browse/JBSEAM-1795;jsessionid=F87B53058681F54E96E6F96F775F9CEC?page=all

Quanto ao problema que você relatou de ter componente JSF nas tags facelets gerando algum erro, aqui não tenho esse problema, funciona normalmente (minhas configurações do Seam são baseadas no Red Hat Developer Studio, não no seam-gen).

Aliás, saiu o RC1 do RHDS com suporte ao Seam 2

ddduran wrote:
Só uma pergunta de ignorante, independencia de JSF?
o Seam não vai ser mais uma implementação da especificação?

Na verdade ele nunca foi uma implementação da especificação. Sempre foi necessário você ter os jars da implementação jsf (r.i. ou myfaces) para trabalhar com o Seam. As características e funcionalidades do Seam não são as mesmas do JSF.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 718 Offline

jonataswingeter wrote:...Vi um tempo atrás um artigo do Gaving falando sobre a possível integração com outros frameworks, além de JSF. Mas até agora a única coisa que percebi que o Seam é realmente uma Emenda para resolver os problemas do JSF(...)

O Seam 2 é independente do webframework em seu core. A equipe do Seam faz a prova do conceito com sua integração totalmente independente do JSF com o GWT, em seu tutorial.

http://in.relation.to/Bloggers/WhatsNewInSeam2 (Removing the JSF dependency)

Escopo de conversação, manter estado entre popups e abas de web browsers, gerenciar comportamento quando o usuário utiliza o "back" do navegador e tantos outros recursos não são meramente "emendas" para o JSF, mas sim soluções para qualquer framework web.

jonataswingeter wrote:
Sobre a possibilidade do EJB3 ter POJO, isso não tira a possibilidade do programador de injetar regras de navegação do JSF no POJO, fazendo um acoplamento. Se eu quiser trabalhar com Binding dos componentes no JSF...vou colocar no EJB ou vou usar uma técnica diferente?

Você não precisa colocar regras de navegação em classes java. No arquivo pages.xml do Seam você pode colocar regras que associam um determinado método da classe Java com seu sucesso de execução ou não. Se o método foi executado com sucesso você é redirecionado para uma página, caso ocorra uma "determinada" exceção você decide no xml qual fluxo seguir. Mas vc tbm pode como JSF, retornar uma String contendo um alias.

Um método de Services retornar uma String não é acoplamento algum, mas se você não deseja isso para sua arquitetura você pode optar por não utilizar EJB no primeiro nível de componentes Seam, e isso tbm responde sua questão sobre fazer bindigs de componentes. O Seam não obriga você usar EJB, um componente Seam é um POJO, que pode ou não ser Remote. Você pode ter um POJO normal atuando para bindings e utilizar uma Façade injetada pelo próprio Seam para isolar sua lógica se você assim preferir.

JavaBaby Membro desde: 20/11/2006 10:15:55 Mensagens: 90 Offline

rodrigoy wrote:Peraí, vcs não estão confundindo com EJB 2.1?

É esse o raciocínio de vocês: se precisa ser distribuido usa EJB, se não precisa usa Spring?

Estou usando EJB 3 nesse meu projeto e pelo menos nesse momento (como já falei) a aplicação não necessitará escalar. Uso EJB 3 porque tem DI, Gerenciamento de Transação, Anotações, Remoting e facilidade de desenvolvimento. E também porque tenho nojo de XMLs (isso é pessoal)

No meu projeto grande parte da navegação está definida em retornos de métodos das minhas Actions/Façades que são SFSB. Por algumas razões também tem algumas façades que são SFSB que dependem de HtmlTree. Qual a opinião de vocês a respeito:

1. É pecado e você queimará no marmore do inferno
2. Você é um arquiteto cowboy, seu código é um lixo... vai programar em VB
3. Porque não faz em Asp.NET?
4. Sua aplicação tem uma restrição arquitetural que sua camada de aplicação só serve para páginas Web, e o impacto disso é......

Jonatas, tem um link aqui que pode te ajudar... pelo que entendí, se as conversas estão em cache não precisa mesmo separar o Tomcat do AppServer, mas não estudei a fundo... (é do release anterior)

http://docs.jboss.com/seam/1.2.1.GA/reference/en/html/cache.html

Oi Rodrigo.

Acho que fico com a resposta 4.

Particulamente faria o que vc está fazendo...sem problemas...mas sem o EJB e pensando em termos de presentation layer.

Quanto ao cache, pela doc que vc passou, a princípio parece que o cache dele pode ser distribuido.
Seria interessante ver uma aplicação deste tipo rodando...

Infelizmente os frameworks, em suma, não possuem POC (Prove of Concept). Não estou dizendo exemplos de como codificar e usar o Seam, mas situações reais para fins específicos. Se isto fosse feito, a maioria dos bugs e problemas seriam previamente solucionados e haveria maior adesão ao produto.

Aí o arquiteto de software faz um POC para um Seam, por exemplo, e nas primeiras situações diversos problemas são encontrados. O que ele faz? desiste do produto. Mas o pior não é isso....
Pior ainda é ele não fazer POC e aderir ao produto porque tem alguma informação no ChangeLog ou doc que diz suporte a alguma coisa. O kra coloca o framework no projeto e depois de alguns meses começa a se deparar com diversos problemas, e na maioria bugs...e ferra o projeto dele.

O JSF é um exemplo disso (RI da Sun e MyFaces)...um framework bom, componentizável, mas cheio de bugs.

Bom, por enquanto é isso.

Att.,

This message was edited 1 time. Last update was at 16/11/2007 10:18:12

Beleza Jonatas... he he he...

Minha colocação foi meio dura porque fico meio fulo quando vejo esses programadores "puritanistas" que confundem restrição arquitetural, code smell, débito técnico.

[adicionado] (encontrei com um desses que falou que na empresa dele "era pecado" colocar um HtmlTree na fachada, e por conta disso, criaram uma camada a mais na aplicação só por conta disso. [/adicionado]

Abraços

JavaBaby Membro desde: 20/11/2006 10:15:55 Mensagens: 90 Offline

Lezinho wrote:
O Seam 2 é independente do webframework em seu core. A equipe do Seam faz a prova do conceito com sua integração totalmente independente do JSF com o GWT, em seu tutorial.

http://in.relation.to/Bloggers/WhatsNewInSeam2 (Removing the JSF dependency)

Escopo de conversação, manter estado entre popups e abas de web browsers, gerenciar comportamento quando o usuário utiliza o "back" do navegador e tantos outros recursos não são meramente "emendas" para o JSF, mas sim soluções para qualquer framework web.

Olá, boa tarde.

Bem, então Removing the JSF dependency é uma contradição em relação a versão 1.0.
Olhei o código e aquilo nada mais que é tentar englobar o mundo.
Pode ter certeza que o Seam não vai conseguir englobar TODOS os frameworks sem precisar de alguma modificação. É só olhar o JIRA com a lista de bugs. Imagine qualquer framework ser integrável com Seam...aquela lista vai crescer exponencialmente. Não diga que se usar uma arquitetura agnóstica com JSON, XML, etc...vai funcionar, pois os frameworks web tem diferentes técnicas e comportamentos em seu core.
E ao contrário do que você disse, continuo achando que o Seam é uma emenda (do próprio inglês) pro JSF.

Este framework nasceu através de um conjunto de idéias da JSR 299 (Web Beans). Obviamente ele não é a
implementação desta própria JSR, mas a idéia dele era desenvolver uma solução baseada no Web Beans e numa fase posterior, a versão do Web Beans poderia ser totalmente implementada.

A própria JSR 299 está altamente acoplada aos comportamentos do JSF e agora o Seam 2 vem dizer que quer desacoplar dependências JSF....

Além de contraditório, isto só é marketing para ganhar o concorrente.

E a propósito: Viu quem é o leader desta JSR??

Lezinho wrote:
Você não precisa colocar regras de navegação em classes java. No arquivo pages.xml do Seam você pode colocar regras que associam um determinado método da classe Java com seu sucesso de execução ou não. Se o método foi executado com sucesso você é redirecionado para uma página, caso ocorra uma "determinada" exceção você decide no xml qual fluxo seguir. Mas vc tbm pode como JSF, retornar uma String contendo um alias.

Um método de Services retornar uma String não é acoplamento algum, mas se você não deseja isso para sua arquitetura você pode optar por não utilizar EJB no primeiro nível de componentes Seam, e isso tbm responde sua questão sobre fazer bindigs de componentes. O Seam não obriga você usar EJB, um componente Seam é um POJO, que pode ou não ser Remote. Você pode ter um POJO normal atuando para bindings e utilizar uma Façade injetada pelo próprio Seam para isolar sua lógica se você assim preferir.

Isto que vc falou é legal...Não necessariamente deve ter regras de navegação. No entanto, existe um acoplamento lógico.

Se você está retornando "sucesso", "falha", obviamente você está pensando em presentation layer. É ou não é???

Se eu tenho um WebService que utiliza SLSB e este retorna qualquer coisa que não seja pertinente, já é uma quebra de conceito.

Quanto a injeção de lógica e deixar a classe utilizando a Façade....achei interessante. Já é algo legal para se pensar.

por enquanto é isso.

Att.,

JavaBaby Membro desde: 20/11/2006 10:15:55 Mensagens: 90 Offline

rodrigoy wrote:Beleza Jonatas... he he he...

Minha colocação foi meio dura porque fico meio fulo quando vejo esses programadores "puritanistas" confundem restrição arquitetural, code smell, débito técnico.

Abraços

Opa!

Que é isso Rodrigo, fica frio.

Estas discussões servem para nos enriquecer mesmo! ehehehehehe

Abraço!

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

rodrigoy wrote:Peraí, vcs não estão confundindo com EJB 2.1?

É esse o raciocínio de vocês: se precisa ser distribuido usa EJB, se não precisa usa Spring?

Estou usando EJB 3 nesse meu projeto e pelo menos nesse momento (como já falei) a aplicação não necessitará escalar. Uso EJB 3 porque tem DI, Gerenciamento de Transação, Anotações, Remoting e facilidade de desenvolvimento. E também porque tenho nojo de XMLs (isso é pessoal)

No meu projeto grande parte da navegação está definida em retornos de métodos das minhas Actions/Façades que são SFSB. Por algumas razões também tem algumas façades que são SFSB que dependem de HtmlTree. Qual a opinião de vocês a respeito:

1. É pecado e você queimará no marmore do inferno
2. Você é um arquiteto cowboy, seu código é um lixo... vai programar em VB
3. Porque não faz em Asp.NET?
4. Sua aplicação tem uma restrição arquitetural que sua camada de aplicação só serve para páginas Web, e o impacto disso é......

Jonatas, tem um link aqui que pode te ajudar... pelo que entendí, se as conversas estão em cache não precisa mesmo separar o Tomcat do AppServer, mas não estudei a fundo... (é do release anterior)

http://docs.jboss.com/seam/1.2.1.GA/reference/en/html/cache.html

Eu não sei se tem muito a ver com a sua indagação. Mas desconfio que os Session Beans não são muito eficazes quando se busca escalabilidade (reparem que estou dizendo "desconfio", não precisa ficar nervosinho se discordar de mim). A razão disso é que as invocações são síncronas (ou seja, quando é chamada a invocação remota, o cliente fica ali parado retendo memória e outros recursos) e seqüênciais (ou seja, se o cliente precisar chamar dois EJB, o segundo não será chamado enquando o primeiro não terminar), quando deveria ser assíncronas e paralelas, como se fosse um esquema de fork/join, que, infelizmente, não existe um jeito fácil de se fazer em Java.

Mas o EJB, a partir da versão 3, deixou de ser ruim, e está valendo a pena utilizá-lo, mesmo pra quem quer somente o recurso de gerenciamento de transação. O Seam seria muito pior se contasse com o EJB 2.1.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 718 Offline

Na pratica Jonatas, para o desenvolvedor tanto faz se ele é uma emenda para o JSF ou não, o que vemos é a praticidade, facilidade e elegância do código ao se desenvolver com o Seam. O próprio JSF ja foi uma ótima sacada da Sun, não vejo mal na sua utilização.

Eu não sou pretensioso em afirmar que o Seam NUNCA vai ser totalmente independente do JSF (na verdade ele ja é)... ou que cada vez vai ser mais bugado e etc. Pra mim o que interessa é ele resolver os meus problemas e dos clientes do software final, o que ele faz perfeitamente.

jonatasw wrote:No entanto, existe um acoplamento lógico.
Se você está retornando "sucesso", "falha", obviamente você está pensando em presentation layer

Você nao precisa retornar String alguma, como ja disse no post anterior. Você decide o fluxo através de um flow xml, facinho.

jonatasw wrote: Se eu tenho um WebService que utiliza SLSB e este retorna qualquer coisa que não seja pertinente, já é uma quebra de conceito.

WebServices no Seam sao Componentes que utilizam Façades de outros componentes (podendo ser EJB ou não). Nao possui nada de lógica da camada de aplicação.

Notícias, artigos e o maior fórum brasileiro sobre Java