Revista Do Linux
 


 
EDIÇÃO DO MÊS
 CD do Mês


 Mensagem ao Leitor
 Capa
 Entrevista
 Estudo de Caso 1
 Estudo de Caso 2
 Documentação
 Hardware
 Software
 Programação
 Redes
 Ferramenta
 Desenvolvimento
 Segurança
assinantes
 

Alternativa para o .NET

Saiba um pouco mais sobre a alternativa da Sun ao "vaporoso" sistema .NET da Microsoft, o Java 2 Enterprise Edition, que já conta com o apoio de grandes empresas do setor

O anúncio da plataforma .NET da Microsoft em 2000 criou uma grande turbulência no mercado de informática. Nada seria como antes, pois deixaríamos de desenvolver aplicações isoladas e de vender licenças de software, para desenvolver web services e vender aplicações por utilização, tal qual uma conta telefônica.

Assim como muitos outros anúncios da Microsoft, o .NET era mais vapor do que produto, e hoje em 2002 ainda não temos todos os componentes do .NET disponíveis. IBM, BEA e Oracle já oferecem servidores de aplicação e ferramentas de desenvolvimento para web services, enquanto que a Microsoft lança o Visual Studio.NET nesse início de ano. O resultado? Pesquisa recente do Giga Information Group mostrou que 78% dos CTOs acreditam que o Java seja a melhor opção para a implementação de web services.

Mas o poder da Microsoft de impor tecnologias com o seu monopólio do desktop preocupou também a comunidade de software livre, que lançou o Projeto DotGNU para criar uma alternativa livre compatível com o .NET.

Em especial, preocupa à comunidade e grupos de defesa da privacidade na Internet a vinculação do .NET ao serviço Passport, que fornece autenticação global para a Internet, mas tornando todos devedores e dependentes da Microsoft para colocar no ar seus web services. A reação veio como um consórcio liderado pela Sun, com o apoio de grandes empresas do setor financeiro (incluindo a Mastercard), chamado "Liberty Alliance". Infelizmente este consórcio ainda é tão vapor quanto o .NET, mas a tecnologia necessária está há muitos anos disponível como software livre: Kerberos, LDAP, SSL e XML.

O Enterprise Java x .NET

Pouco depois do lançamento do Java2, a Sun Microsystem criou o termo "Enterprise Java" como um guarda-chuva para várias tecnologias correlatas, muitas delas já disponíveis e testadas em versões anteriores do Java (como JDBC), outras totalmente novas (como os EJBs) e algumas mais antigas do que o próprio Java (como CORBA). Hoje existe o "Java2 Standard Edition", ou J2SE, e o "Java2 Enterprise Edition", ou J2EE.

Se você comparar as especificações do ainda incompleto .NET com o largamente utilizado J2EE, verá que tudo o que o .NET fornece está disponível no J2EE, com as vantagens da independência de plataforma.

Assim sendo, porquê ficar aguardando que o .NET esteja completo, e ficar ainda mais dependente de uma empresa que já deu provas de não ser um parceiro confiável? Até mesmo a integração com o .NET está prevista pelo J2EE, ao suportar bibliotecas para RPC-XML e para SOAP.

Alguns podem argumentar que o problema do J2EE é a sua dependência da linguagem Java. Isto pode ser na verdade uma vantagem, tanto que a Microsoft criou um clone do Java na linguagem C# para o .NET. Um clone piorado, pois no C# temos de volta os velhos problemas de ponteiros e "memory leaks", que haviam sido eliminados pelo Java.

Por outro lado, Perl, Python e PHP são capazes de interagir com classes Java, e o uso de CORBA ou de XML-RPC permite que qualquer sistema legado seja integrado a uma estrutura J2EE, de modo que você não está obrigado a utilizar exclusivamente Java.

J2EE x Software Livre

O J2EE marca mais um capítulo na tumultuada relação da Sun com a comunidade do software livre. Primeiro, ela ignorou por anos o Linux, para depois assumir os créditos de Blackdown.org ao lançar o Java2 para Linux. Depois, criou a sua "Licença Comunitária", que parece ser aberta, mas não é.

Agora a Sun estabeleceu um processo caro e burocrático de certificação para implementações do J2EE, que levou a Lutris Tecnologies a desistir de sua implementação aberta da tecnologia, chamada Enyhdra, alegando que a Sun não permitia que ela distribuísse o produto sob uma licença aberta, levantando dúvidas (felizmente infundadas) sobre a viabilidade do software livre para J2EE.

O mais estranho é que a Sun é a mesma empresa que criou e abriu o código do StarOffice, e que doou tecnologia para a Apache Foundation criar o Tomcat, que representa o estado-da-arte em Java Servlets e JSP.

Conheça o J2EE

Agora que você já sabe porquê o J2EE é importante, vamos conhecer um pouco mais sobre sua estrutura. A Figura 1 mostra um diagrama com os componentes básicos de uma aplicação J2EE, veja na Tabela 1.

Tabela 1
Aplicação Stand-Alone ou Applet Uma aplicação GUI típica, ou mesmo uma aplicação modo texto atuando na retaguarda, que utiliza os serviços de um ou mais EJBs armazenados no servidor de aplicações
Servlet ou Página JSP Uma aplicação Web típica, também usuária dos serviços de um ou mais EJBs armazenados no servidor de aplicações
Servidor de Aplicações Gerencia o ciclo de vida de vários EJBs e medeia a comunicação entre eles e seus clientes. O Servidor de Aplicações também pode fazer acesso ao banco de dados em lugar dos EJBs
Servidor de Dados Em geral é um banco de dados Relacional, mas pode ser um servidor de diretórios ou uma aplicação legada em um mainframe. Ele não é, na verdade, parte do J2EE, pois não executa classes Java, embora alguns bancos como o Oracle e o DB2 (em breve também o PostgreSQL) sejam capazes de rodar procedimentos armazenados e triggers escritos em Java. Neste caso, o código Java poderia ser cliente de algum EJB hospedado no servidor de aplicações.

O coração do J2EE são os Enterprise Java Beans ou EJBs. Um Java Bean é um componente Java reutilizável, preparado para uso dentro de IDEs visuais. Um EJB é um Java Bean preparado para ser hospedado de forma transparente por um Servidor de Aplicações.

A idéia é que a lógica das aplicações seja implementada como um conjunto de EJBs. Eles poderão ser hospedados na máquina mais adequada em termos de performance e segurança, ou mesmo em várias máquinas separadas para distribuição de carga e tolerância a falhas.

A interface com o usuário é fornecida por aplicações GUI ou páginas HTML contendo Servlets/JSP que delegam trabalho para EJBs. Como um EJB também é um Java Bean, ele pode ser facilmente manipulado por um IDE visual. Ou então, a camada de apresentação pode ser uma aplicação PHP, Perl ou Python, que são capazes de criar instâncias e trocar mensagens com EJBs. Com um pouco mais de trabalho, esta camada também pode ser formada por aplicativos C ou Pascal, utilizando JNI (Java Native Interface).

O Servidor de Aplicações é responsável pela distribuição e tolerância à falhas, para que o desenvolvedor do Bean se preocupe apenas com o código da aplicação. Ele também é responsável por fornecer acesso ao EJB como uma interface COBRA, e podemos facilmente criar Servlets para fornecer o acesso via SOAP.

Além disso, uma série de APIs fornece aos EJBs capacidades adicionais (Tabela 2):

Tabela 2
JDBC Acesso a bancos de dados relacionais
JavaMail Envio e recepção de e-mail
Java Transaction API Coordenação de transações distribuídas
JMS Troca de mensagens e eventos assíncronos
JAXP, JAXM Manipulação e troca de documentos XML
JNDI Acesso a serviços diretórios como NIS ou LDAP

Tipos de EJBs

Um EJB pode ser de três tipos:

  • Um Session Bean é um EJB cujo tempo de vida se limita à duração da sessão com um cliente, e serve apenas àquele cliente. Por exemplo, uma cesta de compras de um site de vendas on-line seria um Session Bean.
  • Um Entity Bean é um EJB cujo tempo de vida vai além de uma sessão e que pode ser compartilhado por vários clientes. Por exemplo, um item no catálogo de produtos de um site de vendas on-line seria um Entity Bean, informando coisas como o preço do item, sua descrição e a disponibilidade (ou não) do item em estoque.
  • Um Message Bean (ou message-driven bean) é um bean cujo tempo de vida vai além de uma sessão de um cliente, mas que serve apenas àquele cliente. Ele é utilizado em operações assíncronas via JMS. Por exemplo, o pagamento via cartão de crédito seria um Message Bean, contendo os dados para a autorização junto à operadora do cartão, que pode não ser imediata. O site não deixará de registrar a compra se não conseguir autorizar imediatamente o pagamento. É por isso que recebemos mensagens de e-mail confirmando a compra, mesmo que o site não diga nada sobre a compra estar "aguardando aprovação".

Normalmente, os Session Beans e os Message Beans atuam como clientes de um ou mais Entity Beans para desempenhar as suas funções. Os EJBs de uma aplicação freqüentemente requisitam os serviços de EJBs escritos para outras aplicações, e esse é um dos benefícios de se utilizar uma arquitetura de objetos distribuídos.

Imagine: em vez de exportar os dados do sistema de estoque para o sistema de comércio eletrônico e depois importar de volta as mudanças, que tal os beans do sistema de comércio eletrônico se comunicarem diretamente com os beans de estoque, evitando atrasos e possibilidades de erros?

O canhão e a mosca

O J2EE é uma infra-estrutura madura e testada para o desenvolvimento de grandes aplicações (ao contrário do .NET), atendendo às necessidades de segurança, performance e extensibilidade da era da Internet. Mas ele não é uma panacéia, nenhuma tecnologia o é.

Antes de utilizar EJBs (ou DotGNU, ou .NET) pense se realmente sua aplicação necessita desses recursos, e se o esforço extra para sua utilização é realmente compensado pelos benefícios. Se não precisar hoje, não se prepare para um amanhã que pode não vir.

Não estou com isso dizendo para escrever código descartável. Um projeto consciente, utilizando as técnicas consagradas da orientação a objetos, será facilmente adaptável a um ambiente J2EE, se isto se mostrar necessário. Mas um projeto ruim não será melhorado por um ambiente J2EE.

Uma das grandes causas do sucesso do software livre, da sua superioridade em performance, confiabilidade e segurança, vem da eliminação de overhead desnecessário. O mesmo princípio pode e deve ser aplicado às aplicações desenvolvidas por você.

Para Saber Mais

Software Livre para J2E
  • EJBCreator
    Gerador de EJBs, com suporte a JUnit (eXtrmme Programing) e ao Jakarta-Ant, além de bancos relacionais
  • EJBCA
    Autoridade Certificadora escrita em Java
  • JBoss
    Implementação completa do J2EE em Java, integrado ao Tomcat para suporte a Servlets/ JSP
  • JOnAS
    Outro servidor de aplicações J2EE
  • NetBeans
    IDE RAD com suporte a J2EE
  • Jakarta e Apache XML
    Conjunto de projetos da Apache Foundation relacionados com Java e XML, incluindo o popular Tomcat

A Revista do Linux é editada pela Conectiva S/A
Todos os Direitos Reservados.

Política de Privacidade
Anuncie na Revista do Linux