Tomcat, Jboss, Glassfish... Por que tantos?

Ok. Agora considere o seguinte, se deve haver uma concorrência sadia no mercado de IDEs, porque não haveria no mercado de servidores de aplicação? Afinal, o que você consegue fazer com uma IDE você faz com outra (ok, talvez com um pouco mais ou menos de trabalho, mas consegue). Imagine então nos servidores de aplicação onde dependendo da aplicação que esteja rodando sobre ele, a falta de compatibilidade com algum recurso qualquer pode acarretar uma perda muito grande.

Agora na boa… OC4J não rola, se não me engano ele ia até morrer (que deus o tenha)! :evil:

Certo, mas as IDEs são diferentes umas das outras (olha o netbeans e o eclipse, até a disposição dos botõezinhos muda).

Mas QUAIS as coisas que estão implementadas em um (e que SÃO USADAS para que) e não estão em outro?

CintiaDR:

Existe alguma razão histórica que eu desconheço? Estou pensando aqui com meus botões se existe outras versões da JRE além da SUN e da antiga da Microsoft…

Sim existe.

Como quase tudo (se não tudo) no Java é regido pelas especificações, vc pode implementar o que você quiser e submeter p/ verificarem se o que você fez está de acordo com a especificação. Já ouviu falar do Harmony? Seria a implementação do Java pela Apache, mas a Sun andou colocando areia no negócio… Não sei como anda esse processo.

davidbuzatto:

Sim existe.

Como quase tudo (se não tudo) no Java é regido pelas especificações, vc pode implementar o que você quiser e submeter p/ verificarem se o que você fez está de acordo com a especificação. Já ouviu falar do Harmony? Seria a implementação do Java pela Apache, mas a Sun andou colocando areia no negócio… Não sei como anda esse processo.

Não conhecia a lenda, não… Mas até entendo que o Apache tinha e tem feito várias implementações do Java, até porque antes era tudo código fechado.

CintiaDR:

Eu andei pesquisando pelo Google e pelo GUJ e até achei alguns comparativos entre os servidores Tomcat, Glassfish e Jboss. Mas não apareceu NADA muito gritante, além do EJB (que aparentemente não é utilizado dado os frameworks MVC - a não ser em aplicações distribuídas)

Vc acha EJB pouco? Eu não acho, já tentou fazer uma aplicação distribuída usando C++ e CORBA, eu não acho pouco.

Absolutamente não acho pouco, não. 8)

Só é POUCO utilizado. Pouco no sentido de a maior parte das aplicações java não são distribuídas, e sim cliente-servidor. (corrigindo - a maior parte que EU vejo, e provavelmente a maior parte do que eu programarei)

Por isso, a dupla Tomcat-Jboss eu até ENTENDO a diferença, até o da Sun posso aceitar, mas os demais é uma incognita para mim.

Há uma boa diferença em servidores de aplicação.

Primeiramente, existem servidores de aplicação e container jsp… por exemplo, vc pode usar EJB no JBoss (appserver), mas não pode usar no Tomcat (container), mesmo com o Tomcat existindo “dentro” JBoss…

Ai, começa aquele papo de especificação e implementação de referencia. Há, sim, diferenças gritantes entre os appservers, exemplificando: o suporte a trace de erro, segurança, escalabilidade, etc. do WebLogic é diferente do mesmo suporte do Jboss… uns são mais robustos e aceitam conectividades externas, como é o caso do WebSphere com o MQSeries… e assim por diante.

Resumindo: cada um tem seus prós e contras… todos são diferentes executando a mesma coisa…
Acho q ai vc tem que levar em consideração duas coisas: pagar ou não pagar e o tamanho do seu core de negocio… não adianta colocar um WebSphere, que é caro pra caramba pra hospedar aplicações de controle de cafezinho…

Só um parenteses: EJB e MVC são coisas totalmente diferentes… Vc pode ter MVC com ou sem EJB e vice-versa! E sobre aplicações distribuidas, não necessariamente, pra ser EJB tem que ser distribuida!

Certo… Eu até já sabia disso, mas acho que me confundi ao explicar.

Aaaaaaaaaaaaaaaaah entendiiiiiiiiiiiiiii agora. Faz sentido! Muito obrigada!

rodrigoallemand:

Só um parenteses: EJB e MVC são coisas totalmente diferentes… Vc pode ter MVC com ou sem EJB e vice-versa! E sobre aplicações distribuidas, não necessariamente, pra ser EJB tem que ser distribuida!

Vixe, que salada que eu fiz aqui. Pera, eu nem sei o quanto eu entendi de EJB. O que eu li (putz, não vou achar fácil agora) em algum link é que como nós acabamos usando os frameworks MVC tipo JSF, temos algumas das vantagens que teríamos usando EJB. Por isso, EJB acaba não sendo utilizado normalmente.

Procede?

A JRE foi implementada por diversas companhias. As que me lembro de cabeça são:

• Sun (implementação de referência)
• IBM (usada no WebSphere e no Eclipse)
• BEA (JRockIt, usada no BEA WebLogic)
• Oracle (até algum tempo atrás)
• Apple (para o MacOSX)
• Microsoft (até a versão 1.1 do Java)
• Symantec (até a versão 1.1 se não me engano)

e por alguns projetos Open-Source.

Sem contar as implementações acadêmicas, etc.

CintiaDR:

Vixe, que salada que eu fiz aqui. Pera, eu nem sei o quanto eu entendi de EJB. O que eu li (putz, não vou achar fácil agora) em algum link é que como nós acabamos usando os frameworks MVC tipo JSF, temos algumas das vantagens que teríamos usando EJB. Por isso, EJB acaba não sendo utilizado normalmente.

Procede?

Pode até ser…
EJB é dividido em 3 grupos:
SessionBeans, que são para implementação da sua cama de negocio; estes ainda podem ser com estado (Stateful) e sem estado (Stateles)
EntityBeans, que são para persistencia
MessageBeans, que são para processamento via JMS, assincrono ou sincrono

Como a especificação até 2.1 do EJB não fez muito sucesso (era trabalhosa, tediante e coisas mais) o pessoal começou a encontrar os caminhos para utilizar o mesmo conceito sem ter que penar com o EJB. Com isso surgiram diversos frameworks… o que espelha melhor isso é o Hibernate para a parte de persistencia. Como fazer um EntityBean era muito trabalhoso, o pessoal inventou uma maneira de mapear as tabelas para objetos do Java. Com isso surgiu o conceito de ORM (Mapeamento Objeto-relacional). Foi tão bem aceito na comunidade que, na nova especificação do EJB (EJB 3) colocaram um suporte muito parecido para essas vias, nomeado de JPA - Java Persistence API…

Portanto, confere o que vc falou, que os EJBs foram substituidos pelos diversos frameworks… cada um para o seu conceito…

Até!

Tudo muito explicativo!

Obrigada, pessoas!

Na minha opinião, a questão é mesmo econômica/comercial: os Application Servers “comerciais” existem porque as empresas viram que isto ajudava a vender mais produtos ou “fidelizar” o cliente (o Oracle AS é bem isto). As fundações/consórcios/empresas criaram seus próprios Application Servers Open Source, pois isto ajudaria a manter/ampliar o portfolio de produtos que elas mantém/oferecem e ajuda a projetar a “marca” delas.

Veja também o mercado de banco de dados. Neste caso a história é ao contrário: primeiro só existiam banco de dados proprietários. Depois é que surgiram os banco de dados Open Source.

Só para por mais lenha na fogueira: você esqueceu de citar o Jonas e eu trocaria o Tomcat pelo Geronimo para a lista ficar mais coerente (tem que tirar o Jetty também).

CintiaDR:

Mas até o JSF tem várias implementações:
JSF:
* Sun JSF
* MyFaces
* Facelets JSF
* Seam

Que eu saiba o Seam e Facelets não são implementações de JSF.
Acho que ter várias implementações é “saudável”: cada implementação pode ter features/componentes que sejam melhor para cada um dos projetos. Por exemplo, usamos o IceFaces que adequou-se bem aos nossos projetos, por conter vários componentes já “prontos”.

Hum… Desenha o porquê pra mim? O Tomcat e o Jetty são apenas Container JSP, isso?

Não sei, copiei na cara dura da documentação do richfaces, conforme o PS da minha primeira mensagem

Ok, poderiam haver muuuuuitas “bibliotecas” de componentes (como o tomahawk é, por exemplo) e apenas uma ou duas implementações JSF.

CintiaDR:

oyama:

Só para por mais lenha na fogueira: você esqueceu de citar o Jonas e eu trocaria o Tomcat pelo Geronimo para a lista ficar mais coerente (tem que tirar o Jetty também).

Hum… Desenha o porquê pra mim? O Tomcat e o Jetty são apenas Container JSP, isso?

Exatamente!!! Eu prefiro chamá-los de Servlet Containers.
O Tomcat e o Jetty também são bons exemplos que vale a pena ter mais de um servidor/implementação de uma especificação: apesar do Tomcat ser bem aceito (é a implementação de referencia) o Jetty tem features que o tornam bem atraente (“leve”, “rápido”).

CintiaDR:

oyama:

Que eu saiba o Seam e Facelets não são implementações de JSF.

Não sei, copiei na cara dura da documentação do richfaces, conforme o PS da minha primeira mensagem

Desculpe, mas não tinha lido o conteúdo do link. Acho que ali o contexto é um pouco diferente: o Richfaces suporta as seguintes tecnologias/implementações relacionadas a JSF. Mas tudo bem, o texto do link não está legal mesmo.

CintiaDR:

oyama:

Acho que ter várias implementações é “saudável”: cada implementação pode ter features/componentes que sejam melhor para cada um dos projetos. Por exemplo, usamos o IceFaces que adequou-se bem aos nossos projetos, por conter vários componentes já “prontos”.

Ok, poderiam haver muuuuuitas “bibliotecas” de componentes (como o tomahawk é, por exemplo) e apenas uma ou duas implementações JSF.

Concordo com você que com relação a componentes, somente bibliotecas de componentes resolveriam, mas existiam features que não tinham no MyFaces que outras implementações tinham (suporte a AJAX é um exemplo).

Bem, moral da história: a idéia quando se cria uma especificação, é que ela possa ser implementada por qualquer um. São as pessoas/empresas que acabam criando várias implementações. Na maioria das vezes isto é saudável, pois ajuda a criar produtos melhores.