Arquivo da tag: java ee

JavaOne 2011 e os próximos grandes passos para Java EE, SE e ME

A próxima versão Java EE vai suportar computação em nuvem, com multi-tenancy e maior capacidade de caching e elasticidade. Adam Messinger, Hasan Rizvi e Cameron Purdy, da Oracle, apresentaram os planos para as edições Micro (ME), Standard (SE) e Enterprise (EE) da plataforma Java na conferência JavaOne 2011, realizada nesta semana.

Cameron Purdy falou sobre as novas funcionalidades planejadas para a plataforma Java EE, que incluem o suporte a cloud computing. Segundo Purdy, hoje todas as aplicações de cloud são proprietárias e não existe padrão, e precisamos de um padrão de plataforma como serviço (PaaS) baseado em soluções para nuvem. O multi-tenancy (o suporte a múltiplos clientes com isolamento de tráfego, aplicações e configurações) será implementado na própria máquina virtual Java, de modo a permitir monitoramento, medição e controle dos diferentes clientes, utilizando a JVM para otimização no uso de recursos.

Assim como o Contexts and Dependency Injection (CDI) gerencia as dependências entre os componentes em aplicações em uma VM, o Java EE 7 fará o mesmo para aplicações corporativas. As anotações do JPA terão capacidade de mapear objetos Java nas tabelas de banco de dados utilizando controle dos usuários. Também está sendo desenvolvido um trabalho para que o caching em Java se torne um padrão e também seja implementado na versão Java EE 7.

Com relação ao Java SE, a Oracle anunciou o lançamento de um preview do JDK 7 para Mac OS X, com versão final a ser lançada em 2012. Além disso, o Java SE 8 vai suportar modularidade e o gerenciamento do ambiente de execução utilizando funcionalidades dinâmicas de compilação.

Haverá ainda melhorias para JavaScript na JVM, o que inclui o Nashorn, a próxima geração de engine JavaScript otimizada para a JVM; e a interoperabilidade nativa Java/JavaScript para comunicação entre objetos Java e JavaScript.

A Oracle também anunciou sua intenção de submeter a plataforma JavaFX como um projeto open source dentro do OpenJDK. A Oracle pretende inicialmente contribuir com os controles JavaFX UI e suas bibliotecas; outros componentes JavaFX serão liberados em fases subsequentes. E a próxima geração do cliente Java, o Java FX 3.0, está planejado para lançamento em 2013 e incluído no JDK 8.

Os planos para o Java ME incluem a sincronização entre os releases do CDLC e do JDK, além da convergência do CDC com a API Java SE Embedded. O suporte para recursos mais recentes em dispositivos, como multitouch, também será disponibilizado. Outras mudanças incluem a liberação do OJWC 1.1, com importantes atualizações para a base de código do CDC, e a integração com serviços mobile.

Fonte: Srini Penchikala/Mário Henrique Trentim/InfoQ

A importância do ASA (Application Server Admin)

Todo mundo que estuda um pouquinho do funcionamento de um Application Server repara logo que existe a necessidade de pessoas para zelarem pelo seu funcionamento e responderem pela sua administração. O Servidor de Aplicação está para o ASA (App. Server Admin), assim como o Banco de Dados está para o DBA. A diferença é que no modelo de desenvolvimento Cliente-Servidor ainda não existia a necessidade do ASA, já que não havia a existência do Servidor de Aplicação.

Acho um assunto muito interessante, e pesquisando sobre isso, verifiquei que já existiam artigos tão bons e que tratam o tema de maneira tão completa que dispensa a criação de outro artigo sobre o mesmo assunto.

Repasso para que vocês possam ler a matéria completa.

O ‘Deployer’ ou Administrador é a pessoa (ou empresa) responsável por configurar e realizar o deploy de aplicações Java EE, administrar a infraestrutura de computação e rede onde aplicações Java são executados, e monitora o ambiente de execução. Entre suas atribuições, está o ajuste dos controles transicionais e atributos de segurança, além de especificar conexões de Banco de Dados.

Essa é a definição oficial da Sun para o perfil “Application Deployer and Administrator“, segundo o Tutorial Java EE.

Desde quando comecei a trabalhar com o Java EE na sua versão 1.3, toda a equipe ganhou “de brinde” uma nova atribuição: Administrar o servidor de aplicações! Claro que no ínicio tudo não passava de alguns deploys e restarts. Com o amadurecimento foi inevitável o crescimento da quantidade de componentes, bibliotecas, datasources, filas JMS e também do “parque” de servidores de aplicação; esta nova atribuição já tomava um tempo considerável da equipe. Foi assim que resolvemos seguir a “sugestão” da Sun e contratar um perfil específico para esta função.

É comum as pessoas que tem seu primeiro contato com o Java EE, enxergarem o Servidor de Aplicações como uma espécie de Web Server estando ele para o Java, como o mod_php/Apache está para o PHP ou como o IIS está para o ASP. Na verdade, como diz Bruno Souza (o Javaman), o Java EE é uma especificação! É um documento que pode ser obtido na página da JSR 244! O Servidor de aplicação nada mais é que a implementação do que foi especificado. Não vou entrar no mérito da compatibilidade do Servidor com sua especificação mas sim deixar claro que o Servidor de Aplicações é muito mais que um Web Container Java e entre os serviços providos pelo Servidor de Aplicação estão: e-Mail (Java Mail), Transação (JTA), Filas (JMS), Conectores (JCA), Segurança (JAAS), Monitoramento (JMX), Pool (Conexão e EJBs), Registro de nomes (JNDI), além dos conteiners de EJBs (Entity Beans, Session Beans e Message Driven Beans); WEB (JSP, Servlets, JSTL e JSF) entre outros.

Cada um desses serviços possui suas próprias configurações como números de Threads, número máximo e mínimo dos Pools, sem contar o próprio tunning da JVM (Não deixem de ver a palestra do Cláudio Miranda – Performance em Aplicações Java). Fora essas atribuições, o ASA (Application Server Admin) também é responsável por: Realizar o deploy da aplicação Java EE, Configurar a aplicação Java (modificando os descritores) para se adequar ao ambiente operacional, Verificar o conteúdo da aplicação e garantir que o arquivo está de acordo com a especificação Java EE e também que as dependências de bibliotecas de terceiros estão corretas (e não quebram a compatibilidade com a API de outras aplicações no servidor).

Como é possível ver, para praticamente todas as atividades citadas, é necessário um conhecimento específico da plataforma JAVA. Entretanto, o que muito se vê nas corporações é a administração do Servidor de Aplicações sendo realizada pela “equipe da rede”, na qual muitas vezes a instalação do Servidor é feita através do apt-get, descompactação do ZIP ou “Next, Next, Finish”. O resultado é que muitas vezes o servidor é executado com uma configuração padrão para a JVM (o que é insuficiente na maioria dos casos), nível de Logging e segurança: Basta ver a quantidade de servidores JBoss na internet que possuem o JMX console aberto (permitindo total controle da instância).

Não é nenhum exagero dizer que hoje, assim como todos os Bancos de Dados sérios e críticos precisam de um excelente DBA, também todos os Servidores de Aplicações sérios e críticos precisam de um ASA. É perceptível o nível de profissionalismo que uma empresa atinge quando o profissional implanta servidores de aplicações com alta disponibilidade; sistemas de monitoramento que notificam o Administrador quando o Servidor está indisponível ou próximo do limite de Threads e Pools e ainda é capaz de rastrear data, hora e versão da aplicação disponibilizada em produção.

Não deixem de considerar esse perfil se quiserem aumentar o profissionalismo das aplicações/ambiente Java EE!

Fonte: Lúcio Camilo/IMaster