mnemetica

Project Zero (ou WebSphere sMash) – Porquê, pra quê, o que, quando, e como? (E o que que é mesmo?)

maio 20th, 2009 | by Aldrin Leal |

Um bate-bola rápido sobre o ProjectZero, o meu ambiente favorito pra desenvolvimento atualmente.

A História da Web: Relembrar é Entender

Acompanhar a Web envolve um pouco da própria natureza da tecnologia: Novas demandas, novos desafios, e a constante necessidade de manter tudo alinhado com o que já existia, oferecendo recursos que originalmente sequer foram imaginados. Basicamente, as principais tecnologias que compõem a Web, entre 1990 a 2000, surgiram da necessidade de resolver os seguintes problemas:

Problema / Necessidade	Solução
Ambiente Hipermídia Cliente-Servidor	HTTP / HTML
Controle de Acesso	Autenticação HTTP
Preencher e Editar Campos, Interação com Bancos de Dados	Formulários HTML, CGI
Gerência de Sessão	Cookies
Segurança de Tráfego	SSL
Conteúdo Rico	Applets Java, ActiveX, JavaScript
Separação de Conteúdo e Apresentação	CSS
Integração entre Serviços	XMLRPC / SOAP

Agora repare esta tabela com um olhar crítico: Dentro da visão original da Web, ela buscava apenas ser um repositório online de documentos, o que basicamente envolve HTTP e HTML. Ou seja, apenas o primeiro item da lista.

Todas estas necessidades transformaram a mesma em um ambiente dinâmico de troca de informações. Os documentos não eram mais arquivos em uma pasta: Tornaram-se registros complexos em grandes bancos de dados, constantemente acessados e modificados.

A solução Java, àquiela época, eram os Servlets, que buscavam apenas a geração de conteúdo dinâmico. Ela se situa no tempo um pouco depois do conteúdo rico na linha do tempo. Era uma solução adequada? Bem, não muito, mas o Java Server Pages, em 1998, ajudou a aliviar e torná-la mais agradável.

Mas acompanhando esta corrida, perceba que surgiram requisitos implícitos: Bancos de Dados, Logs, Gerência de Concorrência, Pooling de Recursos. Performance e Elegância.

Complexidade

Esta complexidade minou inicialmente o poder do Java. As soluções saiam, mas jamais dentro de padrões aceitáveis de performance. A Lei de Moore ajudou e hoje Java está entre as plataformas mais adequadas em termos de performance, e relação custo-benefício adequadas a maioria das corporações.

Perceba a ressalva acima: Corporações. Ela ainda estava – e ainda está – inacessível a maioria dos desenvolvedores. Desenvolver em casa e publicar na web uma aplicação Java envolve um pouco de esforço em achar soluções de hospedagem, devido a natureza do negócio de hospedagem.

Em paralelo, ambientes como Perl e PHP trouxeram uma outra visão: Ambientes Interpretados, leves, com valores diferentes do que o público-alvo do java buscava. Isto gerou uma impedância entre os ambientes que até hoje persiste: A maioria dos ambientes de hospedagem é capaz de rodar Perl e PHP, mas não Java. Isto criou uma cultura e uma divisão: Programadores PHP acham Java Complexo demais, e Programadores Java consideram PHP inadequado para fazer aplicações dentro das necessidades da sua empresa.

AOP, IOC, DI e ORM: Abordando os Problemas sob outro Ponto de Vista

Estamos em 2004. Nesta época, as soluções Java já estavam sendo questionadas quanto a sua capacidade de manterem-se adequadas aos requisitos modernos. O AOP criou um novo paradigma de programação, mas o conceito de Injeção de Dependências e Inversão de Controle, popularizados pelo Spring, e o de Mapeamento Objeto-Relational (Hibernate) mostraram que desenvolver em Java era possível – apenas não estavam sendo feito de uma forma efetiva.

Em paralelo, o Struts tornava-se norma, enquanto buscava-se ao JSF a agilidade e leveza que o ASP.NET trazia.

Ruby on Rails – Uma Nova Abordagem (e Valores)

O Ruby on Rails é um divisor de águas: Com um novo jogo de valores (YAGNI, DRI), ele buscou a simplicidade e jogou outro requisito na roda: Interatividade. Muitos (bons) programadores Java, Perl, Python e PHP foram para o Ruby on Rails.

Web 2.0

Em paralelo, cunhou-se o termo “Web 2.0”. Redes, Ajax, Mashups. Novos requisitos na roda.

Recomeçando

Neste ponto, haviam 3 grandes problemas:

• Haviam basicamente 2 tribos de desenvolvedores Web: Os programadores de Scripting (PHP/Perl/Python), com ambientes interpretados, dinâmicos e leves, e os programadores Java, compilados e exigindo mais memória;
• As soluções interpretadas forneciam aplicações com grande demanda (CMS), enquanto as Java eram orientadas ao ambiente enterprise. Porém, isso não impedia que soluções de CMS open source fossem viáveis para corporações, mas o temor natural de integrar uma aplicação PHP com uma base de dados manipulada por uma aplicação Java inibia a sua adoção, resultando em vários CMS Java de uso interno – causando diariamente a reinvenção da roda nas empresas;
• Haviam outras maneiras de se fazer as coisas, e mais atrativas que em Java;

No ambiente Java, criou-se um claro conflito de valores: Como produzir mais e ao mesmo tempo, integrar com o que eu tenho?

Esta proposta foi a premissa para a IBM inaugurar o Project Zero.

O Conceito:

O Project Zero busca trazer leveza, reuso, simplicidade e agilidade para o desenvolvimento web. As seguintes premissas foram adotadas:

• O Java permite o uso de linguagens Interpretadas;
• O Ambiente Servlet/JSP é complexo, e isto causa problemas;
• O conceito dos Archives J2EE – EAR, WAR, RAR não provê a reusabilidade necessária para as aplicações, trazendo retrabalho;
• O ambiente deve ser flexível, permitindo que vários meios sejam usados para desenvolver um website;
• O Open Source é uma realidade, e não pode ser ignorado;

Desta forma, a proposta do Zero procura englobar estes fatores em uma solução onde:

• O open source seja uma realidade, e que a equipe interaja com a comunidade buscando uma solução não apenas com massa crítica, mas focada em um objetivo comum;
• Linguagens como Groovy e PHP possam integrar-se com o Java;
• O reuso de aplicações Web seja uma coisa possível
• O desenvolvimento pode ser feito a partir de um runtime pequeno (2MB), podendo ser feito pela linha de comando, IDE (Eclipse), ou até pelo Browser (AppBuilder);
• As abstrações de acesso a dados (arquivos locais e remotos, e-mail, e Web) sejam vistos como recursos REST, abstraindo a complexidade de uma forma homogênea

O Zero possui um website, com blog, forum, issue tracking, área de desenvolvimento, downloads e documentação. Tudo rodando no runtime do Zero, e mantido pela equipe do Zero.

Aplicações:

O meu tcc foi feito no Zero. Ambora me arrependa de ter tido uma abordagem mais monolítica (evitando o PHP e Groovy), comparar a sua performance (Spring + Hibernate) contra um servidor J2EE equivalente demonstrou uma performance superior. Lembra quando falei de um runtime leve? Pois então.

Outro ponto forte é integração: Vamos supor que você possui na intranet um portal MediaWiki, e gostaria de integrar a sua autenticação com algum sistema proprietário da empresa. Ou o seu blog (em WordPress) necessita de alguma integração com o seu CMS Java? Pois – mesmo sendo PHP, o Zero integra com eles de uma forma genial.

E o sMash?

Ah sim, o sMash é a versão comercial do Zero, e é disponível pela IBM. Mas a mesma é baseada no Zero e na sua comunidade.

Concluindo

Então fica o convite: Veja os links acima e julgue se a Web não precisa de um curto-circuito. :)