Desenvolvimento - Java
A Nova JSR 286 de Portlets Java
Aprovada recentemente, a nova especificação para desenvolvimento de portles Java, chega para cobrir lacunas e atualizar a primeira especificação, a JSR 168, de 2003.
por Eric C M OliveiraAprovada recentemente, a nova especificação para desenvolvimento de portles Java, chega para cobrir lacunas e atualizar a primeira especificação, a JSR 168, de 2003. Suas principais novas caracteristicas são um maior suporte a JEE4 e WSRP2. A introdução de Generics, do Java5, por exemplo animou a comunidade.
Como já vimos aqui no Linha de Codigo no artigo publicado em 2004 (http://www.linhadecodigo.com.br/Artigo.aspx?id=494), a JSR 168 foi um marco na padronização da especificação de portlets e portais Java. Desde 2003, data da JSR 168, houve a padronização da tecnologia de portais, trazendo ganhos para clientes, empresas de portais e a comunidade de desenvolvedores em geral. Entretanto surgiram lacunas, além da evolução natural da arquitetura Java, e uma nova JSR se fez necessária (JSR 286).
O conceito de um portal define uma plataforma que permite a usuários ter um ponto único de acesso baseado na web para entrega de aplicativos e/ou serviços. Essa arquitetura cresceu, primeiramente com implementações proprietárias e sem padronização, para trilhar um novo caminho de padronização com a JSR 168, e depois com crescimento de SOA e o aparecimento de tecnologias como AJAX e evolução de frameworks Java já amplamente utilizados, como Struts, JSF e Spring.
A nova especificação faz dos portlets como aplicações integradas em um portal, e não como uma coleção de pequenas janelas independentes. São novidades dessa nova JSR, suporte a eventos, que permite a comunicação entre portlets baseada no envio e recebimento desses eventos. Outra novidade é a capacidade de compartilhar ou não determinados parametros renderizados. Há também o portlet filtres, onde um portlet, on the fly, pode trasformar o conteudo de um request ou response de um outro portlet.
O uso de AJAX também foi lembrado e muito aprefeiçoado na nova JSR. Na JSR 168, se restringia a possibilidade de acessar um servelt adicional para usar como um fragmento AJAX, e que tinha problemas sérios de segurança. A unica maneira de dividir informações entre portlet com AJAX e o servlet era usando application – scope session ou via parametro com a URL que chamava o servlet. Na nova JSR, o uso é feito de forma direta via portlet, sem necessidade de um servlet, com troca do tradicional de XmlHttpRequests para o novo ResourceURLs. No lado servidor, acesso direto ao portlet context.
Vale lembrar que a nova espeficiação teve como objetivo manter a compatibilidade com a primeira JSR. Sendo assim há compatibilidade entre as APIs. Um portlet desenvolvido via JSR168, rodará normalmente no novo container sem modificações. O deployment descriptor também não sofreu modificações em seus parametros, apenas com a inclussão de novas entradas.
Referências:
http://jcp.org/en/jsr/detail?id=286
http://blogs.sun.com/portal/
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-4817&yr=2008&track=javaee
http://www.ibm.com/developerworks/websphere/
library/techarticles/0803_hepper/0803_hepper.html
Como já vimos aqui no Linha de Codigo no artigo publicado em 2004 (http://www.linhadecodigo.com.br/Artigo.aspx?id=494), a JSR 168 foi um marco na padronização da especificação de portlets e portais Java. Desde 2003, data da JSR 168, houve a padronização da tecnologia de portais, trazendo ganhos para clientes, empresas de portais e a comunidade de desenvolvedores em geral. Entretanto surgiram lacunas, além da evolução natural da arquitetura Java, e uma nova JSR se fez necessária (JSR 286).
O conceito de um portal define uma plataforma que permite a usuários ter um ponto único de acesso baseado na web para entrega de aplicativos e/ou serviços. Essa arquitetura cresceu, primeiramente com implementações proprietárias e sem padronização, para trilhar um novo caminho de padronização com a JSR 168, e depois com crescimento de SOA e o aparecimento de tecnologias como AJAX e evolução de frameworks Java já amplamente utilizados, como Struts, JSF e Spring.
A nova especificação faz dos portlets como aplicações integradas em um portal, e não como uma coleção de pequenas janelas independentes. São novidades dessa nova JSR, suporte a eventos, que permite a comunicação entre portlets baseada no envio e recebimento desses eventos. Outra novidade é a capacidade de compartilhar ou não determinados parametros renderizados. Há também o portlet filtres, onde um portlet, on the fly, pode trasformar o conteudo de um request ou response de um outro portlet.
O uso de AJAX também foi lembrado e muito aprefeiçoado na nova JSR. Na JSR 168, se restringia a possibilidade de acessar um servelt adicional para usar como um fragmento AJAX, e que tinha problemas sérios de segurança. A unica maneira de dividir informações entre portlet com AJAX e o servlet era usando application – scope session ou via parametro com a URL que chamava o servlet. Na nova JSR, o uso é feito de forma direta via portlet, sem necessidade de um servlet, com troca do tradicional de XmlHttpRequests para o novo ResourceURLs. No lado servidor, acesso direto ao portlet context.
Vale lembrar que a nova espeficiação teve como objetivo manter a compatibilidade com a primeira JSR. Sendo assim há compatibilidade entre as APIs. Um portlet desenvolvido via JSR168, rodará normalmente no novo container sem modificações. O deployment descriptor também não sofreu modificações em seus parametros, apenas com a inclussão de novas entradas.
Referências:
http://jcp.org/en/jsr/detail?id=286
http://blogs.sun.com/portal/
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-4817&yr=2008&track=javaee
http://www.ibm.com/developerworks/websphere/
library/techarticles/0803_hepper/0803_hepper.html
