4 Razões Para Usar HTML5

Vejas 4 razões para começar usar HTML5. Boa semana a todos!

 “Porque Deus não nos chamou para a impureza, mas para a
santidade. 1 Tessalonicenses 4:7.

 

Java EE 7 e o Suporte a Cloud

O InfoQ.com ouviu Anil Gaur, vice-presidente de desenvolvimento da Oracle, sobre o suporte a cloud computing no Java EE 7, incluindo o cronograma geral do projeto, e novas APIs e ferramentas. A especificação do Java EE 7 (JSR 324) inclui suporte à computação em nuvem para apoiar o desenvolvedores de aplicações que sejam portáveis entre diferentes plataformas PaaS (plataforma como serviço) baseadas no Java EE. Serão fornecidas APIs para desenvolver aplicações baseadas em PaaS e dar suporte a múltiplos clientes (multi-tenancy). Outras características previstas são ajustes de capacidade sob demanda e o provisionamento automático de serviços. Vejam a entrevista completa.

“É necessário que ele cresça e que eu diminua.” João 3:30

 

Cache Distribuídos em Aplicativos JEE

JEE é a tecnologia escolhida para aplicações corporativas “high-end”. JEE tornou-se a plataforma referencia para o desenvolvimento de aplicações web de alto tráfego. Soluções JEE são dotadas de uma arquitetura que se adapta muito bem. Você pode lidar com mais e mais usuários simultâneos adicionando mais containers Web com balanceamento de carga. Conforme você tem uma quantidade crescente de carga e transação, basta ir adicionando mais e mais servidores. Dessa forma, você pode lidar com mais e mais transações usuários simultâneos.

No entanto, todas as coisas boas chegam ao fim, e neste caso o acesso aos informações da solução não são capazes de manter-se com o volume cada vez maior de transações. Portanto, armazenamento de dados e acesso a dados se tornam na verdade um gargalo nestas soluções.

Como você remove esses gargalos de escalabilidade? O objetivo é não só melhorar o desempenho, mas sim para melhorar a escalabilidade. Escalabilidade aqui é definida como a capacidade de manter o bom desempenho mesmo sobe carga de pico de transações. Com efeito, se você tiver cinco usuários, a solução será muito rápida. Se você tem 500.000 usuários, ela provavelmente vai não só diminuir, mas na verdade engasgar. Se você tem boa escalabilidade, o desempenho do usuário 500.000 seria muito semelhante a um desempenho de cincos usuários.

Veja o artigo completo falando sobre o uso de cache distribuído em aplicações web JEE.

“Ó Soberano, como prometeste, agora podes despedir em paz o teu servo. Pois os meus olhos já viram a tua salvação…” Lucas 2:29-30

 

Restrigindo Acesso da Solução com JLicense

JLicense ™ é uma biblioteca Java utilitário para a criação e validação de chaves de licença. Ele inclui uma ferramenta simples com interface gráfica para gerenciar os arquivos de licenças e um LicenseManager (que deve ser incorporado dentro do seu software Java) para validar a licença. Você também pode escrever sua própria classe, como um Servlet, para criar o arquivo de licença dinamicamente baseado na entradas de dados de um usuário final. É possível validar a licença com base nos recursos, como por exemplo, adicionar recursos como endereço IP, endereço MAC, o usuário número etc

A versão atual do JLicense é de 2,7. Você pode baixar binário toolkit JLicense e usá-lo gratuitamente. API JLicense também está disponível online.

Código fonte JLicense é para desenvolvedores Java que não querem gastar muitos dias escrevendo suas ferramenta própria de gerenciamento de licenças para suas soluções. O código fonte está disponível por US $ 50 e o pagamento pode se feito através do PayPal online.

E onde estão os deuses que você fabricou para si? Que eles venham, se puderem salvá-la na hora da adversidade! Porque os seus deuses são tão numerosos como as suas cidades, ó Judá! Jeremias 2:28

 

Nova Tendência de Aplicativos Web Mobile

As modernas aplicações web de hoje precisam estar devidamente preparadas para atender o publico em sua totalidade. Isso que dizer que a solução web precisa estar acessível para ser usada em navegadores de desktops e principalmente agora nos navegadores dos modernos dispositivos móveis conhecidos como smartphones e tablets que se infiltram cada dia mais no cenário das corporações.

O fator de complicação dessa nova tendência é que a filosofia de usabilidade de aplicações web nos navegadores móveis é completamente diferente da usabilidade de um navegador desktop. Mesmo os dispositivos móveis hoje tendo uma alta capacidade computacional, eles se diferem em dois aspectos chaves:

1. Monitores reduzidos
2. Estimulo de ação e digitação baseada em touchscreen.

Isso quer dizer uma mesma solução desenvolvida para ser utilizada no navegador do desktop pode ter seu uso totalmente impraticável em dispositivos móveis. É justamente o que tem acontecido na maioria das vezes. Temos dispositivos com alta capacidade computacional e conexão 3G, mas quando você entra em uma solução web, logo de inicio percebe que fica impraticável ficar gerenciando zoom nos monitores reduzidos e usando touch para disparar as ações. Quem ainda não passou por isso?

Problemas Básicos

Interface gráfica web para navegadores de dispositivos móveis não podem ser grandes, nem complexos e os componentes de ações devem ser maiores com espaçamento significativo entre eles. Tudo isso tem o com objetivo de gerar facilidade no momento de disparar as ações via touch. Outro fator é que estas interfaces devem ser resumidas, oferecendo objetividade no acesso e a leitura para as informações dentro do contexto da solução. Veja neste artigo os pontos problemáticos de usabilidade.

E é péssimo abrir algum Site que não esteja otimizado para mobile. Mesmo nos smartphones mais modernos com telas maiores que permitem abrir sites normais, não há dúvidas que um site não otimizado para mobile traz uma pior experiência para o usuário. E isso prejudica suas vendas, trata mal potenciais clientes e até afeta negativamente sua marca.

Como resolver?

O responsável por uma solução web hoje deve implicitamente considerar tal requisito e assim preparar sua solução para atender essa demanda de navegadores móveis. É justamente isso que eu hoje gostaria falar  hoje. No geral, temos duas abordagens parar resolver tal questão:

Abordagem 1 – Construir uma única camada de apresentação hibrida

Criar uma única camada de apresentação na solução para ambos os navegadores, fazendo as interfaces gráficas se comportarem especificamente quando forem acessadas por navegadores de dispositivos móveis. Quando um dispositivo móvel acessar as páginas da solução, será necessário tem certa “inteligência” que aplique algumas mudanças nas páginas como redução de layout, não envio de algumas imagens mais pesadas, maior separação entre os botões de ação e até troca de alguns componentes por outros mais intuitivos.

Pontos Positivos

• A solução terá uma única camada de apresentação.
• Atualização única para todos os usuários.

Pontos Negativos

• Aumento da complexidade na camada de visão nessa “inteligência hibrida”.
• Algumas páginas podem apresentar limitações que compliquem a customização justamente pelo próprio contexto do negocio ou usabilidade da solução.  Esses limitadores podem impedir alguma customização,  gerando desconforto para usuário final.

Como resolver isso arquiteturalmente?

Não existe segredo! A camada de visão necessitara ser “costurada” com decisões que gerem a mudanças adequadas que melhor customizem as páginas quando um navegador de dispositivo móvel estiver acessando.

Abordagem 2 – Criar duas camadas de apresentação

Nesta abordagem é criada uma camada de apresentação na solução exclusiva para cada um deles, uma para desktop e outra para os navegadores móveis. Quando o usuário acessar a pagina de entrada, a solução identificara o navegador corrente e redirecionara para a determinada camada A ou B. Essa é a abordagem mais usada hoje pelos grandes players do mercado.

Pontos Positivos

• Melhor experiência em usabilidade.
• Otimização de performance por menos latência de trafego HTTP com paginas 100% customizadas.

Pontos Negativos

• Duas versões diferentes de camada de apresentação na mesma solução.
• Manutenção duplicada.
• Novas funcionalidades devem ser projetadas, implementadas e testadas duplicamente nas duas camadas.

Como resolver isso arquiteturalmente?

Construa uma versão diferente de cada interface gráfica de todos os processos oferecidos pela solução:

• Uma para o navegador desktop sem limites e sem restrições.
• Uma para o navegador móvel com layout bem mais simples, com menos recursos, mais objetiva e com separação razoável entre os componentes visuais.

Reuso de Regras de Negócio

O objetivo é dar manutenção em duas interfaces gráficas diferentes, mas a regra de negócio de ambas é a mesma e dever ser totalmente reutilizável. Para alcançar isso, adicione uma camada lógica de serviço usando padrão Facade[GOF] entre as camadas de visões e a camada de negócio da solução, não permitindo dependência direta entre elas. Com esta camada de serviço, é possível centralizar os comportamentos em comuns das ambas camadas de apresentação, na interação com a camada de negócio. Isso que dizer que qualquer manutenção das regras e ou processo de negócios serão propagadas para ambas a camada de visão.

Reuso de Autenticação e Autorização

Mesmo tendo duas camadas de apresentação, as regras de autenticação e autorização também continuam a mesma. O mecanismo de autenticação e autorização da solução deve ser projetado de forma flexível para que possa reconhecer que ambas camadas de visão estão debaixo das mesma “regras de credencialidade”.

Paradigma das Páginas para Dispositivos Móveis

Temos hoje duas vertentes diferentes de paradigmas para a filosofia de construção das paginas web para dispositivos móveis.

Páginas Otimizadas

As paginas são construídas para os dispositivos móveis iguais a uma pagina HMLT padrão. O único diferencial é que elas são otimizadas, simples, com menos código, layouts, poucas ou sem imagens, css simples e com javascripts básicos.

Páginas Look Feel Nativas

As paginas são construídas aparentando serem interfaces gráficas desktop da própria plataforma móvel. Ou seja, as páginas aparentam ser aplicações nativas, utilizando todos os componentes específicos e a forma de usabilidade totalmente voltada para as monitores otimizados. Provedores de componentes JSF 2.0 já identificaram essa nova abordagem de solução é já estão fornecendo componentes 100% automáticos. Veja alguns exemplos:

RichFaces Mobile

• Projeto - https://community.jboss.org/wiki/GettingStartedWithMobileRichFaces
• Execute em um navegador de dispositivo móvel  - http://showcase.richfaces.org/phoneHome.jsf#home

PrimeFaces Mobile

• http://www.primefaces.org/showcase-labs/mobile/index.jsf
• Execute em um navegador de dispositivo móvel - http://www.primefaces.org/showcase-labs/mobile/showcase.jsf?javax.faces.RenderKitId=PRIMEFACES_MOBILE

JQuery Mobile

• Framework JavaScript  - http://jquerymobile.com/
• Execute em um navegador de dispositivo móvel http://jquerymobile.com/demos/1.1.0-rc.1/

Da mesma forma ja existem vários frameworks javascript oferecendo também componentes prontos para criar aplicações web mobile. Segue os destaques:

Sencha Touch

• http://www.sencha.com/learn/touch/

Dojo Mobile

• http://dojotoolkit.org/features/mobile

Na verdade todas elas são simples páginas HTML puras com algumas imagens, css e javascript que “simulam” as funcionalidades equivalentes a aplicações nativas instaladas no próprio aparelho móvel. Dessa forma é possível entregar uma solução web com aparência e a usabilidade de uma aplicação nativa.

“Feliz é o homem que persevera na provação, porque depois de aprovado receberá a coroa da vida, que Deus prometeu aos que o amam.” Tiago 1:12

 

Migrando de Spring para JEE 6 Web Profile

Como foi previsto por mim e muitos outros, a nova especificação do JEE 6 realmente conseguiu reduzir a carga pesada que vinha colocando no modelo EJB. Fato é que nós realmente tentávamos a todo custo evitar usar um container JEE FULL optando por um container web, adicionado manualmente os serviços extras como gerenciamento de transação, timers, JPA etc. Nesse cenário, o framework Spring disparou no mercado Java, sendo um dos ‘lightware container” mais usados para controlar esses serviços. Com o objetivo de fechar a idéia do assunto, a dica de hoje é apresentar alguns artigos que apresentam vantagens e como migrar uma aplicação desse modelo Spring para o novo modelo Web Profile:

1. Spring to Java EE Migration, Part 1 
2. Spring to Java EE Migration, Part 2
3. Spring to Java EE Migration, Part 3
4. ttp://www.oracle.com/technetwork/articles/java/unlocking-1540042.html
5. https://blogs.oracle.com/arungupta/entry/why_java_ee_6_is

Bom final de semana para todos!

“Pois desde a criação do mundo os atributos invisíveis de Deus, seu eterno poder e sua natureza divina, têm sido vistos claramente, sendo compreendidos por meio das coisas criadas, de forma que tais homens são indesculpáveis…” Romanos 1:20

 

Sequestro de Sessão – Invadindo o javaranch.com

Um dos ataques mais comuns a sistemas web na atualidade é o sequestro de sessão ou mais conhecido como “Session Hijacking”. Hoje eu gostaria de falar um pouco sobre o assunto, apresentando uma aplicação prática de como roubar uma sessão, invadir um site e acessar a conta da vítima.

HTTP é Stateless

A facilidade de se roubar uma sessão se da pelo justo fato do HTTP ser um protocolo de comunicação sem estado e por isso necessitar que um número de identificação trafegue dentro de todas as interações que um navegador de internet fizer para se comunicar com a solução web.

Como isso funciona?

Todas as vezes que você acessa uma aplicação web, o sistema te envia um numero único que será usado para identificar que você é você durante o uso da aplicação ao longo do tempo. Ou seja, todas as vezes que você entrar no site após abrir o navegador de internet, o sistema vai te enviar um número como por exemplo: 123ABC que será seu identificador único.  O navegador de internet foi programado para  armazenar esse número e envia-lo de volta todas as vezes que você interagir com o sistema, clicando (link, botão, aba, menu etc) na página, fazendo a solução web processar seu pedido e saber que você é você. A questão é que esse identificador fica disponível e visível para ser roubado por qualquer pessoa que tenha conhecimentos mínimos de manipulação de rede e ou protocolo HTTP.

Como roubar o identificador?

O identificador pode ser facilmente roubado de varias maneiras. Segue alguma delas:

1. Trafego HTTP – qualquer pessoa que tenha conhecimentos básicos de rede pode facilmente usar uma ferramenta chamada de “Sniffer” para interceptar todos os pedidos de internet trafegados em uma rede, visualizando todo o conteúdo do protocolo e assim localizar esse identificador.

2. No Navegador – o identificar pode ser acessado via javascript usando o comando “documento.cookie”. Isso abre varias possibilidades:

• Qualquer pessoa que saiba escrever código javascript pode executar esse comando no navegador e obter o identificador.
• Pode existir vírus instalados na estação do usuário sem o seu consentimento que também pode obter o identificador manipulando o navegador.

3. Link Malisioso - O usuário pode ser induzido a entrar em um link originário de algum e-mail falso ou de outro site dizendo “depois de logar no seu internet bank, click aqui para atualizar seu cadastro”. O link ou o site falso pode ser programado para ter comandos javascript que extraia esse identificador.

4. Adivinhação – Algumas soluções web tem a geração do número identificar seguindo uma lógica no qual pode ser facilmente adivinhado. Por exemplo, se o último identificador gerado foi ABC123 o próximo poderia ABC1234.

De qualquer forma que o identificador seje sequestrado, o atacante de posse desse número pode então acessar e usar a solução web fazendo o sistema pensar que o atacante é o próprio usuário autenticado.

Exemplo

Você entra no seu site de comercio eletrônico preferido, colocando seu login e senha. A partir disso começa a navegar nos livros, procurando algum do seu interesse. Nesse tempo seu identificador de sessão é roubado por uma pessoa que esta visualizando todo o trafego HTTP da rede e o atacante assim faz comunicação com essa aplicação web de comercio eletrônico fazendo a solução pensar que ele é você usando o sistema. Diante disse, o atacante pode então executar qualquer ação maliciosa que prejudique você e a solução como por exemplo, visualizar e ou alterar suas informações pessoais como endereço, cartão de credito, trocar seu cadastro, gastar seus cupons de vale-desconto ou colocar um endereço de entrega falso, ficando com sua última compra. Tudo depende do cenário da aplicação.

Prática

Vamos para a brincadeira. Hoje vamos invadir o site do Java Ranch muito conhecido pela comunidade Java mundial. O endereço do site é http://www.coderanch.com/forums/user/login e da acesso para a pagina de autenticação:

Vou colocar meu usuário e senha, me autenticando na aplicação.

Veja que eu entro no link “My Profile” e vejo minhas informações pessoais:

Para simular o sequestro de sessão, vou executar um simples javascript no navegador que acessa o número. Eu digito na barra de endereço “javascript:alert(document.cookie)” e obtenho o número da minha sessão estabelecido após me autenticar:

Veja que esse roubo pode ser feito no tráfego, por vírus, spam de e-mail ou qualquer outra coisa que maliciosamente pegue esse número. Repare que o identificar de sessão neste site esta declarado como JSESSIONID=4AD7D9322052B800F6BF03D2811AA895;

Com esse número em mãos, o atacante pode usar qualquer ferramenta HTTP para trocar requisições no site do fórum anexando o ID da sessão roubado. Com isso, o site do javaranch vai responder achando que na verdade é o próprio usuário apenas fazendo mais uma requisição. Para mostrar isso, eu escrevi uma simples aplicação Java que envia um pedido HTTP para o qualquer endereço na internet, no qual eu possa mecanicamente adicionar um número da sessão e com isso simular o cenário. Segue a abaixo o fonte do sistema:

Esse sistema apenas envia uma requisição HTTP para um endereço configurado, anexando qualquer ID de sessão e como resultado imprime no console a página de resposta retornada pela aplicação. Ao executá-lo passando o valor da sessão roubada, o site do javaranch me envia a página de resposta do meu usuário, mostrando todos as minhas informações. Ou seja, o atacante agora pode então acessar o fórum fazendo a aplicação pensar que as requisições originarias da ferramenta de ataque são do próprio usuário logado. A partir dai é muito fácil manipular a ferramenta para gerar requisições que manipulem todos os processos disponibilizados pelo sistema. Caso alguem se interesse nessa ferramenta é só postar um comentário no artigo requisitando que eu prazer em compartilhar.

Como impedir os ataques?

Os responsáveis pelas soluções web devem estar cientes das possíveis vulnerabilidades existentes nas “entrelinhas” tecnológicas da atualidade, juntamente com as questões e situações que envolvem os “ciclos de desenvolvimento” e assim devem implementar contra-medidas que venham inibir cada vulnerabilidade que possam gerar problemas dentro do contexto da negocio da solução.
O sequestro de sessão é apenas um caso de brecha das muitas dezenas existentes hoje no qual eu percebo que maioria dos responsáveis estão na verdade mal preparados e completamente a margem da situação. Para os interessados no assunto segue as minhas dicas de leituras.

Eu me coloco a disposição para qualquer eventual dúvida sobre o assunto. Até a próxima pessoal !

“Aquele que supre a semente ao que semeia e o pão ao que come, também lhes suprirá e multiplicará a semente e fará crescer os frutos da sua justiça.” 2 Coríntios 9:10

 

Gerenciamento de Vulnerabilidades 2012

Uma solução segura é aquela que identifica todas as suas possíveis vulnerabilidades, implementando mecanismos que tenham o objetivo de reduzir qualquer tipo de danos caso ela seja vítima de um ataque. As vulnerabilidades estão espalhadas em todas as camadas da solução – Física, Rede, Servidores e Aplicação.

Qualquer fraqueza em qualquer ponto da solução pode ser explorada por um atacante. Dentro desse assunto, hoje eu gostaria de publicar meu plano de Gerenciamento de  Vulnerabilidades para aplicações web em nível de aplicação. Ou seja, é o levantamento resumido da maioria das possíveis vulnerabilidades que os arquitetos, projetistas e programadores devem estar cientes no momento de construir suas aplicações. As camadas física, rede e servidores são de responsabilidade de infra, ficando assim fora do escopo deste artigo.

Cada vulnerabilidades de aplicação esta classificada de acordo sua aplicabilidade, no qual eu apresento uma breve descrição e as possíveis soluções adotadas. Para um melhor entendimento eu retirei qualquer detalhe de tecnologia/framework, fazendo com que o leitor possa facilmente entender e assim tomar medidas cabíveis dentro do seu próprio projeto. O objetivo desse plano é ser usado como um “pente fino” para que os responsáveis de soluções possam sistematicamente refinar sua solução antes de coloca-la em produção. Vale lembrar que é muito mais barato, fácil e robusto as práticas serem adotadas dentro do planejamento arquitetural, antes da solução ser desenvolvida.

Para aqueles que desejam um dia ter as minimas condições de entregar um solução web segura, segue indicações de leitura obrigatória:

1. Livro sobre desenvolvimento de aplicações web JEE seguras - Secure Java: For Web Application Development.
2. Guia para desenvolvimento de aplicações web .NET - Hack-Resilient
3. Organização Internacional com objetivo de catalogar e documentar questões de segurança em sistemas - https://www.owasp.org/
4. Documentação das TOP 10 vulnerabilidades cadastradas no OWASP do ano de 2010- Top Ten OWASP

“Eu sou o Alfa e o Ômega, diz o Senhor Deus, o que é, o que era e o que há de vir, o Todo-poderoso. Alguém Semelhante a um Filho de Homem.”  Apocalipse 1:8

 

Novos Serviços JEE 7

Arun Grupta acabou de publicar os possíveis novos serviços que serão incluidos no JEE 7. Segue abaixo:

Java EE 7 (JSR 342)

• The main theme is to easily run applications on private or public clouds
• The platform will define application metadata descriptor to describe PaaS execution environment such as multi-tenancy, resources sharing, quality-of-service, and dependencies between applications
• Embrace latest standards like HTML5, WebSocket, JSON and have a standards-based API for each one of them
• Remove inconsistencies between Managed Beans, EJB, Servlets, JSF, CDI, and JAX-RS
• Possible inclusion of JAX-RS 2.0 in the Web Profile, revised JMS 2.0 API
• Technology Refresh for several existing technologies (more on this below) and possible inclusion of Concurrency Utilities for Java EE (JSR 236) and JCache (JSR 107)

JPA 2.1 (JSR 338)

• Support for multi-tenancy
• Support for stored procedures and vendor function
• Update and Delete Critieria queries
• Support for schema generation
• Persistence Context synchronization
• CDI injection into listeners
• Status
• Approved by the JCP
• Spec lead: Linda DeMichiel (Oracle)
• Project: jpa-spec.java.net
• Mailing Lists Archive: jsr338-experts@jpa-spec.java.net, users@jpa-sepc.java.net.

JAX-RS 2.0 (JSR 339)

• Client API – low level using builder pattern and possibly a higher level on top of that
• Hypermedia – easily create and process links associated with resources
• Form or Query parameter validation using Bean Validation
• Closer integration with @Inject, etc
• Server-side asynchronous request processing
• Server-side content negotiation using “qs”
• Status
• Approved by the JCP, Early Draft Available, Draft Javadocs
• Spec lead: Santiago Pericas-Geersten, Marek Potociar (Oracle)
• Project: jaxrs-spec.java.net
• Mailing List Archive: jsr339-experts@jax-rs-spec.java.net, users@jax-rs-spec.java.net

Servlets 3.1 (JSR 340)

• Optimize the PaaS model for Web applications
• Multi tenancy for security, session, resources, etc.
• Asynchronous IO based on NIO2
• Simplfiied asynchronous Servlets
• Utilize Java EE concurrency utilities
• Enable support for WebSockets
• Status:
• Approved by the JCP
• Spec lead: Shing-Wai Chan, Rajiv Mordani (Oracle)
• Project: servlet-spec.java.net
• Mailing List Archive: jsr340-experts@servlet-spec.java.net, users@servlet-spec.java.net

Expression Language 3.0 (JSR 341)

• Separate ELContext into parsing and evaluation contexts
• Customizable EL coercion rules
• Reference static methods and members directly in EL expressions
• Adding operators like equality, string concatenation, and sizeof etc.
• Integration with CDI such as generating events before/during/after the expressions are evaluated
• Status
• Approved by the JCP
• Spec lead: Kin-man Chung (Oracle)
• Project: el-spec.java.net
• Mailing List Archive: jsr-341-experts@el-spec.java.net, users@el-spec.java.net

Java Message Server 2.0 (JSR 343)

• Ease of development – changes to the JMS programming model to make the application development simpler and easier
• Remove/Clarify ambiguities in the existing specification
• Integration with CDI
• Clarification of the relationship between JMS and other Java EE specs
• A new mandatory API to allow any JMS provider to be integrated with any Java EE container
• Multi-tenancy and other cloud-related features from the platform
• Status
• Approved by the JCP
• Spec lead: Nigel Deakin (Oracle)
• Project: jms-spec.java.net
• Mailing List Archive: jsr-343-experts@jms-spec.java.net, users@jms-spec.java.net

Java Server Faces 2.2 (JSR 344)

• Ease of Development – making configuration options dynamic, make cc:interface in composite components optional, shorthand URLs for Facelet tag libraries, integration with CDI, OSGi support for JSF artifacts
• Support implementation of Portlet Bridge 2.0 (JSR 329)
• Support for HTML5 features like HTML5 Forms, Metadata, Heading and Section content model
• Flow management, Listener for page navigation events, and new components like FileUpload and BackButton
• Status
• Approved by the JCP, Early Draft Available
• Spec lead: Ed Burns (Oracle)
• Project: javaserverfaces-spec-public.java.net
• Mailing List Archive: jsr344-experts@javaserverfaces-spec-public.java.net, users@javaserverfaces-spec-public.java.net

EJB 3.2 (JSR 345)

• Enhancements to the EJB architecture to enable PaaS, such as multi-tenancy
• Factorization of container-managed transactions to use outside EJB
• Further use of annotations
• Alilgnment and integration with other specifications in the platform
• Status
• Approved by the JCP
• Spec lead: Marina Vatkina (Oracle)
• Project: ejb-spec.java.net
• Mailing List Archive: jsr-345-experts@ejb-spec.java.net, users@ejb-spec.java.net

CDI 1.1 (JSR 346, more details)

• Global ordering of interceptors and decorators
• API for managing built-in contexts
• Embedded mode to allow startup outside Java EE container
• Declarative control over which packages/beans are scanned in an archive
• Injection for static members such as loggers
• Send Servlet events as CDI event
• Status
• Approved by the JCP, Early Draft Available
• Spec lead: Pete Muir (RedHat)
• Project: CDI 1.1 Development
• Mailing List Archive: cdi-dev, @jsr346

Bean Validation 1.1 (JSR 349)

• Integration with other Java EE specs
  • JAX-RS: Validate parameters and return values on HTTP calls
  • JAXB: Convert constraints into XML schema descriptor
• Method level validation
• Apply constraints on group collection
• Extend the model to support AND and OR style composition
• Status
• Approved by the JCP
• Spec lead: Emmanuel Bernard (RedHat)
• Project: beanvalidation.org
• Mailing List Archive: beanvalidation-dev

JCache (JSR 107)

• API and semantics for temporary, in-memory caching of Java objects, including object creation, shared access, spooling, invalidation, and consistency across JVMs
• Package: javax.cache
• Status
• Approved by the JCP
• Spec lead: Yannis Cosmadopoulos, Cameron Purdy (Oracle) and Gregory Luck (Software AG)
• Project page: jsr107spec
• Mailing List Archive: jsr107@googlegroups.com

State Management (JSR 350)

• API that can be used by applications and Java EE containers to offload the responsibility of statement management into third party providers with different QoS characteristics
• Java SE-based callers can access the state data by querying the state providers
• Providers with different QoS can be added and API callers can query to meet their criteria
• Package: javax.state and javax.state.provider
• Status
• Approved by the JCP
• Spec lead: Mitch Upton (Oracle)
• Project page: java-state-management.java.net
• Mailing List Archive: jsr-350-experts@java-state-management.java.net, jsr-350-users@java-state-management.java.net

Batch Application for the Java Platform (JSR 352)

• Programming model for batch applications and a runtime for scheduling and executing jobs
• Defines Batch Job, Batch Job Step, Batch Application, Batch Executor, and Batch Job Manager for the standard programming model
• Package: javax.batch
• Status
• Approved by the JCP
• Spec lead: Chris Vignola (IBM)
• Project page: jbatch.java.net
• Mailing List Archive: issues@jbatch.java.net

Concurrency Utilities for Java EE (JSR 236)

• Provides a clean, simple, independent API by building on JSR 166, making it appropriate for use within any Java EE contianer.
• Package: javax.util.concurrent
• Status
• Approved by the JCP
• Spec lead: Anthony Lai, Naresh Revanuru (Oracle)
• Project page:
• Mailing List Archive:

Java API for JSON Processing (JSR 353)

• Produce and consume JSON text in a streaming fashion(similar to StAX API for XML)
• Build a Java object model for JSON text using API classes(similar to DOM API for XML)
• Status
• Under JCP Review
• Spec lead: Jitendra Kotamraju
• Project Page: json-processing-spec
• Mailing List Archive: jsr353-experts@json-processing-spec.java.net, users@json-processing-spec.java.ne

Para o Java e o além!!

“Por essa razão era necessário que ele se tornasse semelhante a seus irmãos em todos os aspectos, para se tornar sumo sacerdote misericordioso e fiel com relação a Deus, e fazer propiciação pelos pecados do povo.” Hebreus 2:17

 

A Famosa Falta de Memória OutOfMemoryError

Hoje eu gostaria de divertidamente abordar o famoso erro de falta de memória frequente das soluções Java. Os dois sabores mais comuns deste delicioso erro são: java.lang.OutOfMemoryError: Java heap space e java.lang.OutOfMemoryError: PermGen. Com isso, vamos nos divertir no assunto:

Gerenciamento de memória em soluções Java é como uma brincadeira de criança. Todo aplicativo Java é executado um cima da JVM que por sua vez esta instalada em cima do S.O. Todo sistema operacional disponibiliza um espaço determinado fixo de memória RAM total da estação para a uso da JVM. Em outras palavras seria afirmar que um programa Java tem disponível para gastar memoria um copo vazio, de tamanho previamente determinado no qual poderíamos exemplificar como um de 300 ml.

Cada vez que o programa Java executando aloca uma variável ou objeto, seria como se ele estivesse gastando espaço nesse copo, adicionado uma gota de água la dentro. Vale lembrar que existem muitas outras coisas dentro de um programa Java que também gasta memória. Nesse sentido, o programa vai sendo usado e o nosso copinho de água vai se enchendo.

Agora vamos para o detalhe mais importante, quando a água ultrapassa a media de 70% do total disponível da memória, a JVM tem um camarada que se chama “Coletor de Lixo” que é avisado para limpar essa memória. Esse coletor de lixo então se prepara e a qualquer momento a partir disso, ele acaba passando para fazer seu trabalho. Voltando para nossa brincadeira, o coletor de lixo é o cara que tem a responsabilidade de esvaziar a água do copo.

Continuando nossa linha de raciocínio, o coletor de lixo no momento sublime e único da solução é executado e assim consegue esvaziar um tanto de memória, reiniciando então o ciclo de gastos. Na visão da nossa brincadeira, o coletor de lixo derramaria então um tanto de água, esvaziando parcialmente o nosso copinho. Esse é ciclo que eu chamo de “marawonderfull”! A aplicação vai sendo executada, gastando memória (adicionado gotinhas de água no copo de 300 ml) e o coletor de lixo vai de tempos em tempos esvaziando uma parte da água. Seria o cenário ideal de uma solução Java.

Como tudo da vida não é perfeito, vamos ao terror! Imagine na sua cabeça agora o que aconteceria se o coletor, dentro dos ciclos de sua passagem não conseguisse esvaziar nada de água? A aplicação vai gastando, gastando, adicionando água e quando você menos espera bummmmm, acontece o “java.lang.OutOfMemoryError” que significa nada mais simples que:

“não é possível continuar executando esse programa Java porque ele ta precisando gastar memória e o copo já esta totalmente preenchido.”

A partir desse ponto de visão é muito mais fácil entender quais são os motivos da falta de memória:

1. A solução esta gastando memória desenfreadamente

O que eu mais vejo nas consultorias e fóruns são os desenvolvedores despreparados, que mesmo bem tensionados acabam escrevendo código que resulte em gastos de memória totalmente desenfreados, sem nenhum critério, preocupação ou um padrão arquitetural previamente estabelecido.

Como corrigir ?

1.1 Alterar o código da aplicação, aplicando sistematicamente melhores práticas diante de cada situação ou elaborar e estabelecer uma arquitetura padrão que contemple práticas de otimização. Que tipos de praticas? Segue algumas:

• Liberar objetos obsoletos logo após o uso atribuindo null.
• Reuse um objeto, resetando seu estado, ao invés de recria-lo.
• Não faça operações matemáticas com wrappers correlativos ao tipos primitivos, uma vez que o auto/unbox vai gerar um novo objeto para cada operação.
• Identifique e aplique singleton para os objetos únicos da solução ao invés recria-los desnecessariamente para cada processo.
• Identifique e reuse objetos imutáveis sem identidade da solução ao invés recria-los desnecessariamente para cada processo.
• Identifique e aumente corretamente o escopo de vida de objetos ao invés recria-los desnecessariamente para cada processo.
• Identifique e reduza corretamente  o escopo de vida de objetos, disponibilizando mais rapidamente para a  coletor de lixo GC.
• Usar StringBuffer ou StringBuilder quando manipular algo volume de string.
• Use a abordagem de paginação ao invés de criar um alto volume de objetos resultando de interações com banco de dados, arquivos txt, xml etc.
• Use a abordagem de cache para objetos com perfil ao invés de ficar gastando memória desnecessária com repetitivas iterações remotas para recursos externos – SGDB, LDAP, EJB, FILE, etc.

1.2 Elaborar e estabelecer uma arquitetura padrão para a solução que previamente contemple todas as práticas de otimização envolvidas dentro do contexto. Aqui já é necessária a contratação de consultor ou alguma empresa que faça o papel de um arquiteto.

2. A solução já esta otimizada, mas ainda não é suficiente. O que fazer?

Caso a solução já esta 100% otimizada, entenda que a única coisa que pode ser feito é aumento da memória. Ou seja, se a solução esta gastando o mínimo possível e ainda assim esta precisando de mais memória, a unica resposta lógica e cabível é que o copo de 300 ml não é suficiente para executar essa determinada solução. Isso não é o fim do mundo, muito pelo contrario, é algo totalmente corriqueira e normal. Situação muito comum em aplicativos Java para Web no qual o número de usuários simultâneos é gradativamente crescente no tempo de vida de existência da solução.

Como corrigir?

A situação complicada de se aumentar o espaço de memória para a JVM é devido a complexidade do seu funcionamento, no qual o desenvolver precisa ter o conhecimento básico de seu funcionamento, regiões e responsabilidades para assim ter autonomia de parametrização. Para aqueles interessados segue alguns artigos que cobrem esses tópicos:

• Melhor e mais claro artigo que eu já li sobre o assunto é o escrito pelo Rodrigo de Azevedo na revista Mundo Java (Agora MundoJ) edição 35 pg 15. Vale a pena comprar a revista só para ter acesso a esse artigo.
• http://www.slideshare.net/claudius/gerenciamento-de-memria-pela-jvm-1937149
• http://blog.corujadeti.com.br/wp-content/uploads/2010/12/java-5-mem-2.pdf
• http://java.sun.com/developer/technicalArticles/J2SE/monitoring/
• http://www.infoq.com/articles/java-profiling-with-open-source

Em aplicações de pequeno/médio porte, a configuração de 2 parâmetros já são suficiente para estabilizar uma solução em produção:

• Use o -Xms<>m -Xmx<>m para declara espaço área ”HEAP” da JVM – lugar aonde os objetos da aplicação criados pela solução são alocados.
• Use o -XX:PermSize=<>m -XX:MaxPermSize=<>m para declarar o espaço da área ”PERMANENT GENERATION” da JVM – lugar aonde as todas as classes existente da solução são carregadas para execução.

Em soluções de larga escala, muitos parâmetros podem ser alterados, inclusive selecionar e customizar diferentes tipos de coletores de lixo.

“Nós, que somos fortes, devemos suportar as fraquezas dos fracos, e não agradar a nós mesmos.” Romanos 15:1