Analistas veem a morte do Java EE em um mundo SOA

Assuntos Gerais Notícias
#1

Essa realmente é assustadora -> Analysts see Java EE dying in an SOA world :lol:

Não querendo tirar o mérito do(s) analista(s) lá, mas dizer que o uso de máquinas virtuais é coisa do passado, porque não importa aonde o código está rodando, mas o serviço que ele provê é simplesmente absurdo. Máquinas virtuais não servem apenas pra garantir portabilidade e eu acho que um "analista" de verdade provavelmente seria capaz de "entender" isso.

O melhor da notícia é que ele simplesmente só diz que o Java EE 5 vai morrer na praia e que "alguns desenvolvedores estão migrando pra Ruby" (o que pode indicar que ele só conhece Ruby de "ouvir falar", já que não se aprofundou mais no assunto).

#2

Olá

Quem fez a previsão que o artigo se baseou foi nada menos do que Richard Monson-Haefel.

[quote=Richard Monson-Haefel resumé]
Richard Monson-Haefel is a Sr. Analyst for Burton Group a technical analyst company. He has been consulting in enterprise Java since 1996.

Before working at Burton Group, Richard served on the JCP Executive Committee which oversees the JSRs (specifications) developed for the J2SE and J2EE platforms. He also served on the J2EE 1.4 (JSR-151) and EJB 2.1 (JSR-153) and EJB 3.0 (JSR 220) expert groups for the Java Community Process.

Richard was a founder of the Apache J2EE Application Server Project (Geronimo) and the OpenEJB project - an open source EJB container. Richard’s proudest achievement was instigating JSR-241, The Groovy Language Specification.

Richard. Monson-Haefel is the author of four best-selling editions of Enterprise JavaBeans (O’Reilly) J2EE Web Services (Addison-Wesley), and the coauthor of Java Message Service (O’Reilly). His books have won several awards.[/quote]

Ele é o responsável pela minha resistência aos EJBS desde a primeira versão. Quando estudei o livre dele Enterprise Java Beans 2nd Ed, achei tudo muito complicado.

Em julho de 2004 o The Server Side anunciava a saída dele da comunidade Java em http://www.theserverside.com/news/thread.tss?thread_id=27485

Atualmente ele não acredita mais em J2EE. Olhem o que está escrito no blog dele:

[quote=I, Analyst - Spitting-up the Hippo: Turning my back on J2EE]
Although I built my career in large part on EJB and J2EE, today I’m not much of an enthusiast for the technology. To be honest it gives me heartburn.

Eight years ago, everything started out O.K. There wasn’t that much information to take in and EJB seemed to pretty cool, especially for a survivor of the CORBA technology craze of the mid 1990’s. I mean it really was pretty cool.

Over the years however, EJB and its super set, J2EE, became increasingly complex until there was so much information it was difficult if not impossible to swallow. Today I’m a recovering J2EE developer; I’ve successfully regurgitated the massive J2EE bolus that slowed me down and made me mentally lethargic. [/quote]

O artigo do Richard Monson-Haefel citado pelo searchWebservices.com, “JEE5: The Beginning of the End of Java EE” tem acesso aos cadastrados em http://www.burtongroup.com/research_consulting/publicdoc.aspx?cid=70

[quote=resumo de JEE5: The Beginning of the End of Java EE]
Java Platform, Enterprise Edition version 5 (JEE5) was intended to simplify the incredibly complex Java Platform, Enterprise Edition (Java EE) but failed to deliver on that promise. The primary value proposition of Java EE—a common programming model for a complete enterprise platform—makes the platform susceptible to disruption by platforms that emphasize ease of development. In this overview, Senior Analyst Richard Monson-Haefel explains how JEE5 fails to save Java EE and why it’s a harbinger of the end of Java EE as the dominant enterprise platform.[/quote]

Realmente o que ele fala faz sentido e ninguém pode negar que J2EE tal como propõe a Sun é muito complexo. Se não fosse pelo que há por aí disponível fora do que a Sun acha ideal, talvez o J2EE nem demorasse mais 5 anos para virar coisa do passado.

Quanto ao crescimento do SOA acredito que muito se deve a necessidade de aproveitar legados. Desde que surgiu a ideia, SOA parece ser muito atraente. Mas acho que só agora em 2006 vem sendo usado com mais intensidade. Jason Bloomberg, autor do livro “Service Orient or Be Doomed!” prevê que por volta de 2010 cerca de 70% do mercado de software empresarial será de aplicações orientadas a serviços.

Como atualmente trabalho em um legado em Fortran, não me asssuto muito com esta previsão do Richard porque sei que esta tonelada de código sendo desenvolvida atualmente virará um enorme legado com emprego para muita gente. Aliás isto ocorre atualmente com o legado do Cobol e do VB.

[]s
Luca

#3

Acredito que Java EE 5 deixou tudo muito mais simples… aumentando a produtividade em uns 500% e ransformando em realidade o que antes era “balela”

Alguem discorda ? prq ?

#4

Java 2 EE é mais complexo do que poderia ser mas isso não quer dizer que hajam concorretnes que concorram de maneira mais simples. Simplesmente existem coisas injustificávels em 2006 para a plataforma, como dependência em hierarquia de classes para recursos como segurança e transação, além da pilha de XML, mas não há até onde eu sei uma plataforma com as vantagens que java dá ao desenvolvimento de maneira mais simples.

O ponto é que não devia ser tão complexo.

Tudo vai depender do rumo que dermos à tecnologia. Realmente num ambiente SOA não existe nada além de operações e os serviços que as implementam mas alguém precisa implementar estes serviços. A parte onde SOA é independente é na interação entre estes, por dentro eles não são mais que componentes de granularidade grossa.

Então, se Java simplificar seu modelo coorporativo não há o que morrer, e tudo corre enste sentido. Eu aposto muito em Java para backend e uma linguagen dinâmica no front-end numaarquitetura SOA já hoje, na verdade estou trabalhando num sistema que disponibiliza cinco serviços inicialmente para quatro aplicações, mas um dos requisitos é que os serviços fiquem públicos na rede. Se não fosse por imposição do cliente eu facilmente buscaria algo mais dinâmico nas aplicações e faria os serviços em Java EE 5.0. Como eu conheço o histórico deste cliente (BTW, uma das maiores empresas brasileiras onde só o departamento que eu atendo possui um budget anual de TI de alguns milhões de reais) eu sei que em breve teremos essa liberdade.

Dizer que OO não combina com SOA é simplesmente ignorar o que é um paradigma de desenvolvimento. Em SOA não se trocam objetos, trocam-se mensagens (fundamentalmente diferente de um ambiente de componentes, como EJBs) mas a implementação dos serviços é exatamente como qualquer aplicação que já escrevemos, fora do controle do fluxo de mensagens não importa o que se usa.

Dizer que a escalabilidade de Java EE é focada em websites é mais uma prova que temos uma pessoa que não sabe nada de SOA ou arquitetura de aplicações em geral ou alguém sendo muito bem pago. A arquitetura em SOA é basicamente um modelo de Internet assíncrono, inclusive se baseando no odioso HTTP e dialetos de XML.

Baita FUD. Vamos ver a thread no TSS amanhã…

#5

Olá

Quem disse isto foi o Bloomberg. Tanto você na questão OO x SOA como o Maurício na questão das VMs, pinçaram frases isoladas e o entendimento do raciocínio dele ficou prejudicado.

[quote=Bloomberg]
“Fundamentally, the virtual machine approach to distributed computing is through the serialization of objects leading to remote method invocation, while SOA runs on the exchange of messages between services with contracted interfaces.”[/quote]

Lendo o trecho todo se percebe que ele acha que J2EE pode ser usado com SOA porém não foi feito para SOA. Isto é mais do que claro pois SOA é um conceito mais novo.

Nada do que está escrito lá me causa espanto. Se a gente pensar bem, são coisas mais ou menos óbvias. Atualmente temos um tópico enorme discutindo as mazelas do J2EE x RR. E me parece muito cedo para dizer que EJB 3.0 será a última Coca Cola do deserto.

Mantenho minha opinião, se a gente dependesse só da Sun como a turma do outro lado depende só da Microsoft, a gente estava roubado. O que nos salva e nos dá vantagem é justamente a contribuição que vem de fora da Sun. Da Sun jamais sairia um XFire para Web Services.

De qualquer modo SOA também não nada simplizinho como estes artigos SOArentos tentam mostrar. Vou repetir aqui o que disse o Carlos Perez:

[]s
Luca

#6

Eu sei que foi ele e não estou falando de fulano ou beltrano, mas do artigo como um todo.

E veja o trecho original que fala de OO x SOA:

Acho que se alguém cortou uma frase não fui eu. Não tenho acesso ao material original então fica difícil comentar algo além do que esta lá.

Basicamente isso é uma frase onde não se verifica conhecimento sobre como um software é implementado. É como dizer que Assembly morreu por causa de OOP ou que bytecodes o fizeram por causa de Java.

O que eu entendi é que há um FUD federal em dizer que VMs fazem chamadas remotas baseadas em troca de objetos. VMs não tem nada a ver com isso, esse é o modelo de RPC adotado para RMI, nada impede que se adote outro, como se faz o tempo todo.

Como falei, a diferença básica é que em RPC se trocam objetos enquanto em SOA se processam mensagens. Nada impede que Java (ou .Net, ou Ruby, ou Python) faça ambos.

E SOA não é quase nada novo, pra variar é apenas um conjunto de tecnologias que está se organizando, ganhando padrões e nomes pomposos.

Não importa se você usa EJB 3.0, Spring+Hibernate ou o que for. O que importa é que o modelo está se simplificando e por dentro um serviço é apenas um sistema normal, como estamos cansados de ver. O papel de Java é implementar este serviço, se Java não for adequado para outros componentes (especialmente Application Front-Ends), não há problema, que se utilize outra plataforma onde for necessário.

O difícil é apontar uma plataforma tão eficiente para implementação de serviços hoje.

SOA é complexo demais, muito mais que EJB 2.1. E assim como EJB 2.1 não é necessário para todos, e mesmo quando é não precisa implementar tudo (WS-Policy? OMFZ!). E como EJB 2.1 o que mais tem é gente usando sem saber porque.

Só que este não é o ponto. Assim como EJBs SOA está sendo empurrado guela abaixo dos CTOs e dizer que Java morre num ambiente SOA sem qualquer argumento é FUD.

#7

Dizer que OO não combina com SOA é realmente um exagero. Mas também não dá para dizer que tem impacto zero na implementação dos serviços. Uma arquitetura tipo pipes and filters programada em estilo funcional (sem estado explicito além da stack) me parece bem atraente. Por outro lado, muito da importância de SOA é em EAI, e nesse caso uma fachada de serviço em cima de um modelo de objetos pré-existente seria ideal.

Qual o problema do HTTP?

#8

Nenhum, se você está transportando hipertexto numa conexão sem estado.

#9

Olá

Só para deixar bem claro. Também acho que a questão das VMs foi mal colocado, mais parece executivo que ouviu cantar o galo tentando falar de modo técnico. A única diferença é que acho que consegui captar o principal do recado dele sem estacionar em uma frase isolada. Eu entendi que ele diz o mesmo que você: SOA troca mensagens. Foi a conclusão dele que transcrevi.

Tanto o artigo como o Richard, não dizem que Java morre em ambiente SOA. O que eles dizem é que J2EE não foi feito para isto. De minha parte acho que isto não tem muita importância pois nada do que existe hoje foi feito para SOA. Tudo está se adaptando. Não creio que haja necessidade de algo novo só porque alguma ferramenta foi concebida antes da existência de algum conceito novo.

Sobre outras plataformas apenas por curiosidade dei uma googlada para ver como a Microsoft está reagindo a SOA, ESB e afins (sem usar BPEL). Achei o seguinte em um relatório de junho/2006 da AMR:

“Microsoft’s different approach to this market makes it difficult for customers to evaluate its value proposition for service-oriented architecture (SOA).”

Phillip, seu sistema troca serviços com .NET?

[]s
Luca

#10

Como falei ele vai ser disponibilizado na rede, como é um sistema bem crítico apra o segmento de negócios ele deve trocar mensagens com todo o zoológico de uma grande empresa.

O problema do SOA neste cenário é que tem especificações (não lembro se a própria WS-Policy é um exemplo mas creo que WS-ReliableMessage seja) que tem duas versões, uma patrocinada pela MSFT outra pela IBM. Isso está tornando SOA algo muito difícil de dar certo.

Olhando a pilha de especificações, demos e promessas se vê que SAO é muito parecido com EJB em sua complexidade e questionável features ‘importantíssimas’, alémd a dependência de ferramentas que ainda estão sendo criadas, com um belo Design by Comitee.

Atualmente eu consumo serviços exportados por DCOM via um ESB. Sim, temg ente investindo em novos sistemas feitos com DCOM. Não, não entendo também, só obedeço.

#11

Olá

Realmente há uma salada de especificações mas a principal culpada é a Dona Microsoft que recusa a aceitar o que já está sendo feito por outros.

DCOM para mim é apenas RPC mas o lado de lá acha que é SOA. Fui googlar e encontrei em um monte de lugares textos de gente que usa tecnologias Microsoft com este papo de que com SOA não precisa de OO, de com DCOM não precisa de web services e que SOA com DCOM é mais do que suficiente. Na linguagem Microsoft, DCOM também serve para mensagens entre serviços com interfaces contratadas.

Para se afastar mais ainda da Microsoft, agora a Oracle aparece com EDA e seu Oracle Event Driven Architecture Suite dizendo que EDA é o componente chave do SOA 2.0, expandindo além do modelo de interação de serviços do SOA para gerenciar interações baseadas em eventos em tempo real. De um jeito ou de outro a Microsoft é capaz de dizer que já faz isto desde 1999 pois ela não acredita em nada deste mundo que não tenha sido inventado (ou apenas patenteado) por ela.

[]s
Luca

#12

Bom, você pode ter SOA com WebServices ou sem eles, apesar da maioria das specs serem específicas paraSOA (é o que o Erl chama -e eu odeio o termo- de conteporary SOA) mas o ponto é que … DCOM?! Que tal .Net logo?

Mas não conhecia esse treco da Oracle, vou dar uma olhada.

#13

Gente, só para clarear um pouco…

SOA != WebService / BPM != BPEL

WebServices só é recomendado quando se consome serviços de terceiros (o que tende a mudar com o advento dos ESB) ou entre tecnologias que não falam uma lingua comum. WebServices são 10x mais lentos que uma chamada RMI, e eu estou falando de testes feitos com o XFire.

Nesse contexto entra o ESB, que (entre um monte de outras coisas) expõe servicos em diversos meios de acesso. Assim você teria o serviço, por exemplo, buscaCEP, disponivel como WebService, EJB, file transfer e REST…

Abraços,
Jose Peleteiro

#14

Pessoal,

to meio por fora de SOA, só vi falar em alguns lugares, e tal, li a respeito alguns artigos mais conceituais falando dos benefícios e sobre o que tange essa nova arquitetura, mas alguém poderia me dizer o que existe hoje em dia na plataforma java pra provê a utilização dessa arquitetura ? Algum implementação … ? Desculpe se eu fiz alguma pergunta tola :roll:

#15

[quote=Fabrício Cozer Martins]Pessoal,

to meio por fora de SOA, só vi falar em alguns lugares, e tal, li a respeito alguns artigos mais conceituais falando dos benefícios e sobre o que tange essa nova arquitetura, mas alguém poderia me dizer o que existe hoje em dia na plataforma java pra provê a utilização dessa arquitetura ? Algum implementação … ? Desculpe se eu fiz alguma pergunta tola :roll: [/quote]

Cara eu escrevi um artigo mais de alto nível, por causa do público - http://webinsider.uol.com.br/vernoticia.php/Web_2_0__Ajax_e_SOA__uma_nova_perspectiva/id/2659

Na verdade desacoplar e dividir em serviços é uma visão puramente de arquitetura e OOP não tem nenhuma relação direta. Como você vai implementar o serviço é problema seu, poderia ser o paradigma procedural, desde que encapsule o serviço o publique para consumo.

O Bloomberg falou uma grande besteira, prova que não conhece nada de programação.

Voltando ao ponto de SOA, você como arquiteto vai definir quais “módulos” estarão encapsulados num serviço. Alguns applications servers implementam o bus service, para lookup do serviço.

Por isso descordo completamente do artigo. Java pode sim ser utilizado para implementar a estratégia SOA, pois possui uma estrutura ( espeficiação JEE) que contempla suporte à WebServices, possui execelentes Frameworks para tal e soluções de diversos players para bus services.

Talvez formas de se criar essas layers de maneira mais simples, como XFire integrado à uma estratégia Spring por exemplo, possam facilitar o desenvolvimento, mas não tem haver diretamente com a linguagem.

#16

Olá

Para os anais…

Opinião do Tim Bray, diretor de Tecnologias Web da Sun ao ser perguntado sobre SOA:

:arrow: “What do you think we should do about SOA?”

[quote=Tim Bray]
“Don’t do anything. ‘SOA’ may have meant something once but it’s just vendor bullshit now.” Looking back, what happened was, certain software architects were uncomfortable with the framing that goes with the words “Web Services”; maybe because people think anything with “Web” in the name should be simple and lightweight and easy to set up. Thus SOA, which is so much more Enterprisey. Me, I want to go the other way. The crucial point is that Web-like things should be simple and lightweight and easy to set up; so I think the “Web” part of “Web Services” is more important than the “Services” part. SOA isn’t the future, Web style is. [/quote]

Fonte: Tim Bray no Canada on Rails

[]s
Luca jogando mais lenha na fogueira

#17

E cito o Martin Fowler, no post Service Oriented Ambiguity:

[quote] * For some SOA is about exposing software through web services. This crowd further sub-divides into those that expect the various WS-* standards and those that will accept any form of XML over http (and maybe not even XML).
* For some SOA implies an architecture where applications disappear. Instead you have core services that supply business functionality and data separated by UI aggregators that apply presentations that aggregate together the stuff that core services provide.
* For some SOA is about allowing systems to communicate over some form of standard structure (usually XML based) with other applications. In it’s worse form this is “CORBA with angle brackets”. In more sophisticated forms this involves coming up with some form of standard backbone for an organization and getting applications to work with this. This backbone may or may not involve http.
* For some SOA is all about using (mostly) asynchronous messaging to transfer documents between different systems. Essentially this is EAI without all the expensive EAI vendors locking you in.[/quote]

O Tim Bray é um defensor de web services estilo REST, que é uma alternativa muito legal especialmente para serviços públicos (vejam o APP). Por algum motivo eu não vejo muita discussão sobre REST na comunidade Java.

#18

Oi, tive uma aula péssima de Java na faculdade, e fiquei com tanta raiva do “negócio” que tô até querendo que este “troço” morra, e olha que eu adoro a área de desenvolvimento.

#19

O livro desse cara é o mais complicado que eu já li na minha vida.

Não porque o cara é um mal autor, mas sim porque EJB e J2EE é a coisa mais bizarra que já inventaram.

#20

E se falar assim:
“Windows 2000 vai morrer em 5 anos num mundo de interfaces 3D”.

Não cola né!? Novas tecnologias surgem e evoluem. Obviamente o Java EE vai melhorar. Nem por isso o Java EE 5 vai ser jogado fora, sem mais nem menos. ASP.net está ai há quanto tempo!? Será que ASP já morreu “nesse mundo com .NET” !? Acho que o cara fez um comentário muito Ogro!

É só acompanhar a evolução da Apache Foundation, dos fabricantes de midleware e depois dar uma opinião razoável sobre o futuro do Java EE.

[]'s
Rodrigo