Olá a todos,
segue uma matéria sobre a batalha J2EE x .NET
__| J2EE x .NET: A Batalha de 2002 Está Apenas Começando |__
O colega Joel de Sousa Ribeiro de Melo - [EMAIL PROTECTED], nos
envia o excelente texto abaixo, da Developers' Magazine, Número 66 -
FEVEREIRO/2002, que por motivo de tamanho sera' dividido e, duas
partes.
O último ano não foi muito excitante para os desenvolvedores de
software. Novos produtos e tecnologias estrearam no mercado; novos
horizontes (especialmente wireless) continuam se abrindo; mas não
tivemos nenhuma novidade de grande impacto.
Isso pode mudar em 2002, quando a plataforma.NET da Microsoft deve
finalmente sair do forno. Quem gosta de debates terá um prato cheio,
pois a .NET vem de encontro à plataforma J2EE (Java2 Enterprise
Edition), de sucesso já consolidado e adotada por milhares de
desenvolvedores. Se os fãs do Java vêem o .NET com certo desdém, com
certeza a nova plataforma é um tremendo evento para quem ainda
desenvolve aplicações específicas para as plataformas da Microsoft e
tem resistido ao Java. Mesmo para quem prefere se manter independente
da plataforma Windows, a força da Microsoft não pode ser ignorada.
Os efeitos da competição. A competição entre J2EE e .NET será acirrada
e, mesmo para quem não pretende "mudar de time", essa competição pode
ter um impacto importante. Se a plataforma.NET tiver algumas
características claramente superiores à J2EE, não há dúvida que a Sun
e os vendedores de J2EE responderão à pressão. Já
pudemos ver isso com os Web services: a Microsoft saiu na frente, mas
o mundo Java já está finalizando o suporte a tecnologias como SOAP,
WSDL e UDDI, inclusive em IDEs. Por outro lado, o adepto do Java pode
argumentar que a .NET é, em grande parte, um clone da J2EE. Isso dá a
entender que a J2EE é tão superior à totalidade das ofertas anteriores
da Microsoft (todos SDKs, linguagens e ferramentas pré-.NET) que a
Microsoft não teve saída senão abandonar sua antiga plataforma em
troca de algo quase igual à J2EE, o que legitimiza a plataforma Java
de uma forma que nenhum marketing da Sun faria.
Semelhanças e diferenças. Vamos encontrar no .NET os mesmos princípios
da plataforma Java: máquina virtual; memória automática (Garbage
Collection); bytecode portável; linguagens dinâmicas e reflexivas (C#
e outras); um framework OO unificado e extremamente abrangente;
suporte a um sem-número de necessidades como distribuição, segurança,
acesso a dados, ou desenvolvimento para Web.
Várias diferenças vêm da opção da Microsoft por uma plataforma
amarrada ao Windows. Muitas bibliotecas do .NET são finas cascas sobre
APIs existentes do Windows. Quem conhece as funções da Win32, classes
da MFC e similares, já tem alguma familiaridade com a .NET. A
desvantagem? O porte para outros sistemas operacionais (SO) é possível
em tese, mas seria muito difícil e o resultado ineficiente. As APIs
Java são explicitamente projetadas para poderem ser implementadas em
qualquer S.O., por isso são mais abstratas, flexíveis e neutras em
relação a detalhes importantes que variam fortemente de um S.O. para
outro (exemplo: threads). Considerando que a Microsoft não tem planos
de disponibilizar o .NET para SOs concorrentes, essa desvantagem é
significativa apenas para quem pretende clonar o .NET (o projeto Mono,
que tenta criar um ambiente compatível com a .NER para o Linux e
outros Sos suportados pelo Gnome, será compatível primariamente no
baixo nível: VM e linguagens. O Mono terá bibliotecas próprias, como a
Gtk#, e a maioria das aplicações do Mono serão amarrados pelo Gnome).
Se quiséssemos fazer uma checklist de ambas plataformas, veríamos que
as diferenças funcionais, que são as mais importantes, existem, mas
também em pequeno número. A favor da Microsoft, existe o novo modelo
de programação do ASP.NET. É uma vantagem importante, mas que irá
durar pouco tempo. Assim como já ocorreu com os Web services, o
release final da .NET demorou tanto, que permitiu à competição correr
atrás - no caso do ASP.NET, a maior vantagem atual é devida ao Visual
Studio.NET, pois já existe suporte ao modelo MVC com o projeto Struts
(Apache). A resposta definitiva da Sun é a JSF (Java Server Faces),
que estará disponível meses antes da data de lançamento prevista do
Windows.NET Server (em meados de 2002).
Em contrapartida, o J2EE fica isolado com alguns recursos do modelo
EJB, especialmente nos Entity Beans. A Microsoft não oferece nada
similar, nem tem planos de oferecer; o problema é que a MS não
acredita no modelo EJB. Assim, seus desenvolvedores precisam continuar
utilizando APIs de baixo nível, ou então Wizards que entopem seus
programas de código ilegível, para tarefas fundamentais como
persistência de objetos. O mais provável é que muitos programas
continuem sendo feitos num modelo 2-tier indevidamente (Não há pecado
em usar duas camadas para uma aplicação em que isso faça sentido; o
problema é quando evitamos três camadas somente porque nossas
ferramentas não suportam este modelo de forma adequada).
Outras explicações são a necessidade de suportar múltiplas linguagens,
o que seria bem difícil para CMP (persistência automática), e a
estratégia da Microsoft de favorecer o SQLServer (não há nada melhor
para se amarrar a um SGBD do que programar em duas camadas e com APIs
de baixo nível expondo código SQL).
Marketing, benchmarks e padrões. A escolha entre estas plataformas
pode ser dificultada pela propaganda de ambos os lados. Os vendedores
de J2EE já se ocupam brigando entre si, num mercado talvez já saturado
por um excesso de implementações. A entrada da Microsoft, com sua
poderosa máquina de marketing, aumentará a diversão ainda mais. O
problema é que as plataformas J2EE e .NET não possuem compatibilidade
nem mesmo de código-fonte, portanto um mesmo programa não pode ser
testado em ambas, nem mesmo após uma recompilação. É necessário fazer
um porte de programas J2EE para .NET, ou vice-versa, mas é difícil
evitar alterações não triviais, jogando os princípios do benchmarking
científico pelo ralo. A Microsoft deu a primeira cartada rescrevendo a
aplicação Java Pet Store (JPS, um tutorial de J2EE da Sun) para .NET,
"provando" que sua tecnologia tem desempenho até 28 vezes superior ao
da J2EE. Esse porte foi criticado por ser extraordinariamente
diferente do original, não preservando sequer princípios básicos de
arquitetura (por exemplo, o JPS é escrito em três camadas com EJB,
enquanto a versão .NET usa até stored procedures).
Continua...
