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...
