De que se trata o artigo:

Uma apresentação das tecnologias relacionadas a Portais, abordando uma visão geral de toda a terminologia por trás de Portais, como as JSR 168/286 para o desenvolvimento de portlets, WSRP e Portlet Bridges.


Para que serve:

Para auxiliar no desenvolvimento de portais que utilizam ou que sejam compatíveis com a especificação das JSRs 168/286 para portlets, e no desenvolvimento de web services para portlets com uso do WSRP. Além disso, mostra também como transformar uma aplicação JavaServer Faces em uma aplicação de portlet com uso da API JSF/Portlet Bridge.


Em que situação o tema é útil:

Para desenvolvedores envolvidos em projetos de Portais Intranet/Extranet, em projetos de integração ou projetos SOA, ou ainda, para todo desenvolvedor que quer oferecer através da Web, acesso a um ambiente único e simplificado às informações e serviços da empresa.

Portais Corporativos:

Quando pensamos em Portais Corporativos, imaginamos grandes sites (ou intranets) dentro de uma empresa que agrega vários tipos de conteúdo, meios de colaboração, conhecimentos, aplicativos transacionais e gráficos de toda sorte, todos concentrados em uma única interface.

Para atender a demanda de desenvolvimento para este tipo de portal, o JCP disponibilizou as especificações das JSRs 168/286 que definem o desenvolvimento de portlets.

Portlets são os componentes principais de um Portal, são componentes web reutilizáveis que fornecem uma visão a um sistema de informação ou uma aplicação, através de fragmentos de marcação (geralmente HTML) que podem ser agregados ou plugados em qualquer página de portal, desde que seja compatível com a especificação.

Para a execução dos Portlets, o servidor de aplicação precisa dispor de um ambiente de execução, chamado Contêiner de Portlets. Diversas empresas fornecem soluções para execução de portlets compatíveis com as JSRs, entre elas podemos destacar a Oracle, IBM, Sun e Apache.

É possível também desenvolver portlets utilizando o framework JavaServer Faces, porém, para o seu funcionamento em um ambiente de portal, é preciso utilizar uma biblioteca chamada JSF/Portlet Bridge, que faz uma ponte ou um proxy entre a aplicação JSF e o contêiner de Portlets.

Autores: Wagner Roberto dos Santos e Marcelo Augusto Zanatto

Neste artigo vamos demonstrar na teoria e na prática os fundamentos do desenvolvimento de portlets em portais corporativos e a importância de Portais no contexto de SOA (veja o quadro “SOA”). Vamos entender a fundo as tecnologias envolvidas na construção de um grande portal, como as JSRs 168/286, que contemplam a criação e o ciclo de vida de um portlet. Veremos também como definir WSRPs, que são os web services para portlets remotos, e como converter uma aplicação JSF para um portlet com o uso do Portlet Bridge.

SOA

Quando entramos em uma discussão sobre SOA, sempre vemos os assuntos: Integrações com ESB, execuções com BPEL, monitoração com BAM e modelagem de processos de negócio com BPMN. É incrível que muitos não conseguem imaginar como serão apresentadas as interfaces de interação com o usuário, principalmente as tarefas “Human Task” que existem dentro de um fluxo de processo.

Grandes suítes do mercado de SOA têm a apresentação de formulários de entrada de dados e apresentação dos resultados através de portlets, que serão registrados e utilizados nas ferramentas de portal.

Com isso a ferramenta de portal acaba sendo indispensável em uma arquitetura orientada a serviços que tem processos com interação dos usuários finais, conforme a Figura Q1.

Figura Q1. Portal em um ambiente SOA (Autor Desconhecido)

Por fim, demonstraremos no NetBeans como montar e configurar um ambiente para o desenvolvimento de portlets utilizando o Contêiner de Portlets, o pacote WSRP, e a biblioteca JSF/Portlet Bridge do projeto livre OpenPortal junto ao servidor de aplicações Glassfish V2.

Portal

Se buscarmos a definição de Portal no dicionário, na maioria delas veremos que ele é definido como “uma porta, portão ou entrada”. Quando falamos em Portais web, estamos nos referindo a sites especiais da web ou intranet, que são designados a agir como um gateway de acesso a outros sites.

Um portal agrega informações de múltiplas fontes e torna estas informações disponíveis para diversos usuários. Além de disponibilizar diversas fontes de informações, eles fornecem um guia de serviços que auxiliam os usuários a se direcionarem no meio de tantas informações na internet.

Mais especificamente, um portal não deve ser visto somente como gateway para outros sites, mas para todos os recursos acessíveis na rede, que envolve intranets, extranets ou a própria Internet. Em outras palavras, um portal oferece acesso centralizado para aplicações e todo conteúdo relevante para a empresa/usuários finais. Na Figura 1 apresentamos a arquitetura de um portal, formado por um servidor web, um contêiner de Servlets/Portlets e as aplicações (portlets) para o portal, conforme veremos em detalhes no decorrer do artigo.

Figura 1. Arquitetura de um portal

Durante muito tempo as ferramentas de portal foram ignoradas e até mesmo discriminadas por muitos programadores que achavam que elas eram de uso exclusivo para web designers. Mas com o surgimento da arquitetura orientada a serviços e a busca frenética das empresas em disponibilizar soluções mais baratas e produtivas, com o intuito de reduzir o Time-to-Marketing, esse tipo de ferramenta voltou com toda a força para fazer o que sempre fez: facilitar a vida de todos. A partir desta análise, mostraremos nesse artigo as vantagens do uso de uma ferramenta de portal, e qual o papel do programador neste contexto.

Segurança

A etapa mais cansativa e torturante para um desenvolvedor é ter que gastar seu tempo desenvolvendo módulos de segurança de uma aplicação, sendo que esses módulos geralmente são constituídos por telas de autenticação, tratamentos de usuários e grupos de usuário, utilização de repositórios LDAP, e em algumas vezes a integração com um autenticador para desfrutar do tão desejável Single Sign On.

Além de ter todas essas características, muitas vezes é necessário desenvolver soluções “self-service”, para que o administrador do ambiente de Portal tenha autonomia para gerenciar o repositório de usuários e dar permissões de uso para as funcionalidades da ferramenta.

Praticamente todas as soluções de portal possuem todo esse mecanismo pronto, possibilitando ao programador se dedicar somente no desenvolvimento das aplicações de automatização do negócio.

Conteúdo

No desenvolvimento completo de uma solução como uma “Intranet”, é comum ver que todo o tempo de desenvolvimento é gasto na criação de aplicações para gerenciamento de conteúdo, como funcionalidades de notícias, biblioteca de documentos, áreas institucionais e qualquer outra seção que necessita de um gerenciamento de informações por parte do usuário do sistema. Em um projeto deste tipo, também é comum que todas essas funcionalidades passem por uma governança editorial, e que inevitavelmente necessitem de um mecanismo de workflow. Essas são funcionalidades típicas nas ferramentas de portal, o que fez com que todos achassem que esse tipo de ferramenta só proporcionava esse benefício.

Há empresas que buscam outras soluções que vão além de um simples gerenciamento de conteúdo, indicando que elas devem ser mais robustas e possuir módulos de digitalização, transformação e busca de conteúdo. Esses sistemas, chamados ECM (Enterprise Content Management), muitas vezes dependem de uma ferramenta de portal para disponibilizar o conteúdo trabalhado. Este é só um exemplo de ferramenta que necessita de um portal como camada de visão. E a forma com a qual esse e outros tipos de ferramentas mostram suas funcionalidades é através dos chamados portlets.

Portlet

A internet fornece um conjunto de informações quase que ilimitado para diversos tipos de dispositivos. Com o advento da web foi criado um universo de padrões e protocolos de comunicação, recursos, e uma linguagem de marcação utilizada para apresentação (HTML). Mas a web e seus protocolos foram projetados para atender ao conceito de uma página como um pedaço estático único de informação, apresentado em um navegador, como uma entidade completa e inalterável. Para visualizar outra página, o usuário tem que chamar outra página.

Até o momento, diversos esforços têm sido feitos para superar esta limitação com o uso extensivo de código, como JavaScript/Ajax, ou alguma solução DHTML para trazer ao usuário uma experiência similar e até mesmo superior ao uso de uma aplicação desktop.

Portlet é uma maneira de superar a natureza “tudo ou nada” de uma página HTML. Para defini-los podemos dizer que os portlets são o núcleo dos serviços de um portal, onde uma ferramenta de portal utiliza os portlets como uma interface de apresentação plugável, ou seja, aplicações que podem ser adicionadas em qualquer página em um ambiente de portal, com o objetivo de fornecer qualquer tipo de informação na camada de apresentação.

O conteúdo gerado por um portlet é chamado de fragmento, que na verdade é um pedaço de marcação (ex: HTML, XHTML, etc.) aderente a certas regras, de forma que possamos agregar pedaços de vários fragmentos para gerar um documento.

A página de um portal é composta por um ou mais portlets, que são normalmente agregados com o conteúdo de outros portlets para formar uma página. O ciclo de vida de um portlet é gerenciado pelo contêiner de portlet, conforme veremos logo a seguir. Na Figura 2 apresentamos uma página de exemplo do portal open source Liferay, com a disposição de vários portlets.

Figura 2. Exemplo de uma página de portal

Se olharmos atentamente o conteúdo do navegador na Figura 2, veremos que a página é formada por diferentes janelas. Temos uma janela para um dicionário, outra para um RSS, uma terceira para um calendário, e por último uma para o Google Maps. Cada uma destas janelas representa um portlet. Ao analisarmos o detalhe de cada janela, vamos perceber que cada uma delas contém uma barra de título e alguns botões, incluindo os botões de maximizar e minimizar.

Na verdade, estas janelas são aplicações diferentes, desenvolvidas independentemente uma das outras. O programador desenvolve o portlet como uma aplicação web e empacota em um arquivo .war, e o administrador do portal efetua o deploy deste arquivo .war no servidor de portal e adiciona o portlet recém instalado em uma ou mais páginas do portal.

Pelo fato de você poder colocar o portlet em qualquer página, faz com que você possa reutilizá-lo a todo o momento no portal, até mesmo em uma mesma página. No caso da Figura 3, apresentamos uma página com várias instâncias de um mesmo portlet (Locadora).

Figura 3. Várias instâncias do mesmo portlet em uma página

Repare nesta figura que temos um mesmo portlet na página, mas com instâncias diferentes. A ferramenta de portal tem a responsabilidade de garantir sessões independentes da aplicação, mesmo estando todos na mesma página.

...
Quer ler esse conteúdo completo? Tenha acesso completo