Construindo portlets para IBM WebSphere Portal – Parte 1

Construindo Portlets para IBM
WebSphere Portal – Parte 1
Rodrigo Reis
IT Specialist & Application Architect
IBM Collaboration Solutions

© 2013 IBM Corporation

Agenda
Introdução
Parte 1: Portal & Portlets
Parte 2: Construindo Portlets para IBM WebSphere Portal
Parte 3: Especificação JSR 286
Parte 4: Ambiente de Desenvolvimento

2


Introdução
●

●

●

3

Este workshop não é de introdução a Java ou IBM WebSphere
Portal
Necessário conhecimento básico de Programação Java para
Web (JSP, HTML, XML, JavaScript, Frameworks)
O objetivo do workshop é introduzir ao desenvolvimento de
portlets


Parte 1: Portal & Portlets

1878A
4


Definições
O que é um Portlet?
"Um portlet é um aplicativo que fornece um conteúdo
especifico (informação ou serviço) para ser incluido como parte
de uma página de Portal."
O que é Portal?
"Um portal é um container que executa portlets e os
disponibiliza com o ambiente de execução requerido."

5


Definições - Portal
Para entender o que é um portlet, primeiro é necessário entender o
que é um portal:
Portal é uma aplicação web que oferece personalização e
agregação de conteúdos de diferentes fontes, aglomerando e
distribuindo estas informações de forma direcionada a um publico
alvo
Um portal possui 3 funcionalidades básicas:
●

●

Agregador de Conteúdo

●

6

Portlet Container
Serviços Comuns


Definições
Portlet Container: o portlet container é responsável por controlar o
ciclo de vida de um portlet
Agregador de Conteúdo: uma das principais tarefas de um portal é
agregar conteúdo gerado por aplicações de diversos portlet
Serviços Comuns: Um dos principais pontos fortes de um servidor
de portal é o conjunto de serviços comuns que ela proporciona.
Alguns serviços comuns que você pode encontrar na maioria das
implementações de portais são:
●

●

7

Logon único: Permite ter acesso a todas as outras aplicações
uma vez que você entrar no servidor do portal
Personalização: Permitir ao usuário personalizar sua página,
alterando cores, layout e decidindo quais portlets incluir na página

Definições
●

●

●

8

No passado, com o surgimento de um número crescente de
portais corporativos, vários fabricantes criaram diferentes APIs
para componentes do portal
Esta variedade de interfaces incompatíveis geraram problemas
para os fornecedores de aplicações
Para solucionar estes problemas, foi criada a JSR (Java
Specification Request) 168, uma especificação de Portlets, que
nasceu para oferecer interoperabilidade entre portlets e portais


Definições
O propósito da JSR 168 era:
●

Definir o ambiente de execução, ou portlet container, para portlets

●

Definir a API entre o portlet container e portlets

●

●

Fornecer mecanismos para armazenar dados temporários e
persistentes para portlets
Fornecer um mecanismo que permite incluir servlets e JSP
(JavaServer Pages) nos portlets

●

Definir um pacote de portlets para permitir uma implantação fácil

●

Permitir a portabilidade entre os portlets do portal

●

9

Executar portlets JSR 168 como portlets remotos usando o Web
Services for Remote Portlets (WSRP) protocolo

Definições
●

Java Portlet 1.0 Specification (JSR 168)
Liberada em: 27 de Outubro de 2003

●

Java Portlet 2.0 Specification (JSR 286)
Liberada em: 03 de Março de 2008

●

Java Portlet Specification 3.0 (JSR 362)
Em desenvolvimento
Lider: Martin Scott Nicklous, IBM

10


Checkpoint
NÃO é um dos propósitos da especificação JSR168:
A – Definir um pacote de portlets para permitir uma
implantação fácil
B – Permitir a portabilidade entre os portlets do portal
C – Definir o modelo de segurança do portlet container
D – Definir a API entre o portlet container e portlets
E – Definir o ambiente de execução, ou portlet
container, para portlets

11


Parte 2: Contruindo Portlets para IBM
WebSphere Portal

1878A
12


Arquitetura do WebSphere Portal
A arquitetura do ambiente de execução do WebSphere Portal
possui as seguintes caracteristicas:
●

●

●

É executado dentro de
um web container do
WebSphere Application
Server chamado de
WebSphere_Portal
Possui seu próprio
componente de
transporte HTTP
Possui 6 banco de dados
de apoio que por padrão
é instalado em Derby

13


Banco de dados do WebSphere Portal:
●

●

●

●

●

●

14

Release – Armazena configurações do WebSphere Portal
Customization – Contém dados associados com cada usuário do
portal, como por exemplo, preferências de portlet
Community – Contém recursos que são modifcados em
produção
JCR – Armazena todo conteúdo do Web Content Management e
Personalization
Feedback – Armazena logs de utilização do site
LikeMinds – Contém classificassões e dados sugestão para
personalização

Principais serviços do WebSphere Portal:
●

●

●

●

●

15

Model SPI – Fornece acesso leitura para todos WebSphere Portal
Data Model
PUMA – Gerência associação e atributos de usuários
Credential Vault – Prover acesso seguro as credencias de
usuário
Tagging e Ratting – Novidade no Portal 8, fornece serviços de
classificação e marcação de conteúdos
Personalization – Disponibiliza mecanismos para personalização
de conteúdos para usuários


Visão Geral
Web Experience Suite

Browser / Systems

Out of the box features
Theme / Portlets

Custom Portlets

Client Engine
Markup (HTML)

Custom Development

REST SPI

(Client Side)

Model SPI
WebDAV SPI

Third Party

IBM products

Data (ATOM,binary…)

Custom Development
(Server Side – Theme, Extensions)

16


Portlets e Servlets
●

Portlets e Servlets são parecidos em alguns aspectos, mas sem
nenhuma conexão direta

●

Portlets são executados em um Portlet Container

●

Portlet Container é uma extensão de um Servlet Container

●

Portlet Application é uma extensão de uma Web Application
web.xml + portlet.xml são os Deployment Descriptors

●

Podemos ter Portlets e Servlets dentro da mesma aplicação web

17


Portlet Modes
●

O Portal monitora o modo do portlet

●

Um portlet pode conter 3 modos padrões:
●

●

Edit – Usuário personaliza o portlet

●

●

View – Modo de exibição padrão
Help – Exibe janela de ajuda

Portais podem conter modos adicionais (muitos são sugeridos na
especificação), o WebSphere Portal contem:
●

●

18

Edit Shared Settings – Configurações comuns a todos
usuários
Configure – Configurações administrativas

Portlet Modes
●

Portlets podem modificar seu próprio modo de operação

●

O acesso a cada modo depente das permissões do usuário
●

●

Por exemplo, um usuário do tipo Privileged User tem acesso ao
modo Edit mas não ao Edit Shared Settings

O desenvolvedor deve implementar os Portlet Modes. As
configurações ficam armazenadas no arquivo portlet.xml
<supports>
<mimetype>text/html</mimetype>
<portletmode>view</portletmode>
<portletmode>edit</portletmode>
<portletmode>help</portletmode>
</supports>

19


Portlet States
●

Diferente de aplicações web tradicionais, portlets utilizam apenas
uma fração da página

●

O estado da janela de cada portlet é controlado individualmente

●

Os seguintes estados de janela estão disponiveis:
●

●

Maximize – exibe apenas o portlet na janela

●

20

Minimize – exibe apenas o titulo da janela
Restore – exibe o portlet no modo padrão


Checkpoint
Quais são os Portlets Modes suportados pelo WebSphere
Portal?
A – View, Edit, Configure
B – View, Edit, Help, Configure
C – View, Edit, Help, Personalize
D – View, Edit, Help, Configure, Edit Shared Settings

21


Checkpoint
Qual das alternativas a seguir é FALSA?
A – Portlets podem modificar seu próprio modo de operação
B – O desenvolvedor deve informar os modos de operação
do portlet dentro do arquivo web.xml
C – O desenvolvedor pode implementar novos Portlet States
D – O desenvolvedor pode implementar novos
Portlet Modes

22


public class HelloWorld extends GenericPortlet {

Criando um Portlet

public void init (PortletConfig portletConfig) throws UnavailableException,
PortletException
{
super.init(portletConfig);
}

Desenvolvendo
●

public void doView(RenderRequest request, RenderResponse response) throws
PortletException, IOException

Parte 1: Código do Portlet

{

response.setContentType("text/html");
response.getWriter().println("Hello Portal World!</p>");
}
}
<?xml version="1.0" encoding="UTF-8"?>

+

<portlet-app ...>
<portlet>
<portlet-name>HelloWorld portlet name</portlet-name>
<display-name>Hello World portlet (JSR)</display-name>
●

<display-name xml:lang="en">Hello World portlet (JSR)</display-name>

Part 2: Portlet descriptor

<portlet-class>HelloWorld</portlet-class>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
</supports>
<supported-locale>en</supported-locale>
</portlet>
</portlet-app>

Empacotando & Publicando

23

WAR


Criando um Portlet
●

Estrutura de um Portlet (arquivo WAR)
●

●

Arquivos de classe Java

●

Arquivos JSP

●

O deployment descriptor, portlet.xml

●

Arquivos JAR contendo qualquer biblioteca usada pelo porltet

●

●

Arquivos WAR contém os seguintes artefatos:

Arquivos Web (HTML, XML, XHTML, JavaScript, CSS, …)

Um aplicativo de portlet pode conter um ou mais portlets

24


Laboratório 1: Criando o primeito Portlet
●

Criar um projeto de Portlet

●

Implementar a lógica de negócios

●

Fazer Deploy do portlet

25


Parte 3: Especificação JSR 286

1878A
26


Introdução ao JSR 286
●

●

●

O IBM WebSphere Portal inclui um ambiente de execução que
suporta Portlets desenvolvidos seguindo as especificações JSR
168 e JSR 286
A API JSR 168 define a maior parte dos objetos, sendo a base do
JSR 286, que resolve limitações da especificação anterior
Principais recursos da JSR 286:
●

●

Portlet events
Portlet filters que permitem adicionar mais lógica de negócio
antes de processar as fases do ciclo de vida do portlet, como:
render(), processAction(), processEvent(), serveResource()

●

●

27

Public Render parameters
Resource Serving portlets

Portlet

Diagrama do Java Portlet Specification, Version 2.0
28


Ciclo de vida de um portlet
Portal Iniciado
Portlet init()
Usuário solicita página

ProcessAction(), render()
[doView(), doEdit(), ...]

Portal
Retorno da página

Portal Terminado

29

Portlet
Portlet marckup

Portlet destroy()


Interface Portlet
Cada portlet deve implementar a interface de portlet, ou estender de
uma classe que implementa essa interface. A interface de portlet é
composta dos seguintes métodos:
●

●

init(PortletConfig config) - para inicializar o portlet.
- Este método é chamado apenas uma vez após instancia-lo.
- Pode ser usado para criar objetos / recursos utilizados por ele.
ProcessAction(ActionRequest request, ActionResponse response) para notificar o portlet que o usuário executou uma ação sobre este
portlet.
- Apenas uma ação por solicitação do cliente é disparada.
- Em uma ação, um portlet pode emitir um redirecionamento,
alterar seu modo de portlet ou estado da janela, alterar o seu
estado persistente, ou os parâmetros de render.

30


Interface Portlet
●

●

render(RenderRequest request, RenderResponse response) para gerar a marcação. Para cada portlet na página atual, o
método de renderização é chamado, e o portlet pode produzir
marcação que pode depender do modo de portlet ou estado da
janela, os parâmetros de renderização, atributos pedido, estado
persistente, os dados da sessão, ou dados de back-end.
destroy() - para indicar o fim do ciclo de vida do portlet. Este
método permite liberar recursos e atualizar os dados persistentes
que pertencem a este portlet.

31


Relacionamento entre classes JSR286

32


Classe PortletConfig
●

A classe PortletConfig funciona de maneira similar a classe
ServletConfig que utiliza os seguintes metódos comuns para
conceder acesso a configuração do portlet:
- getInitParameter()
- getPortletName()
- getResourceBundle()
- getSupportedLocales()

●

Exemplo de uso PortletConfig que carrega o ResourceBundle para
a localidade atual do usuário:
ResourceBundle portletBundle = null;
portletBundle =
getPortletConfig().getResourceBundle(request.getLocale());

33


Classe PortletContext
●

●

●

A classe PortletContext também funciona de maneira similar a
classe ServletContext e fornece acesso a informações do portlet
container
Existe um contexto por aplicativo de portlet e instância do servidor
de portal
Atributos armazenados no contexto são globais para todos
usuários e componentes do aplicativo de portlet
setAttribute() e getAttribute()

●

Exemplo usando getRequestDispatcher() para iniciar um JSP
PortletRequestDispatcher rd =
getPortletContext().getRequestDispatcher("/jsp/UserForm.jsp");
rd.include(request, response);

34


Classe PortletRequest
A classe PortletRequest usa as seguintes subinterfaces
●

●

●

●

ActionRequest – passada dentro do método processAction()
RenderRequest – passada dentro dos métodos doView() e
doEdit()
EventRequest – passada dentro do método processEvent() para
portlets que utilizam eventos
ResourceRequest – passada dentro do método serveResource()
para portelts que fornecem recursos

35


Classe PortletRequest
Dicas sobre a utilização da classe ActionRequest:
●

Por padrão atributos na ActionRequest não são repassados para
para RenderRequest
●

Quando a opção ActionScopedRequestAttributes está
definida como true, atributos em ActionRequest são
repassados para RenderRequest
<containerruntimeoption>
<name>javax.portlet.actionScopedRequestAttributes</name>
<value>true</value>
</containerruntimeoption>

●

Coloque atributos que necessitam estar disponiveis em mais que
um simples request na Session

36


Classe PortletResponse
●

Cada fase do cliclo de vida de um portlet possui uma implementação
da classe PortletResponse
ActionReponse, RenderResponse, EventResponse, Resource
Response

●

Métodos da classe ActionResponse
- setPortletMode() - para adicionar parametros no RenderRequest
- setPortletMode() - para alterar o modo de operação do portlet
- setWindowState() - para mudar o estado da janela

●

Métodos da classe RenderResponse
- setNamespace() - para retornar o namespace do portlet
- createActionUrl() e createRenderUrl() - para criar urls para o
portlet

37


Classe PortletSession
●

●

A classe PortletSession fornece acesso rápido a objetos em nome
do usuário
Caracteristicas
- Dados da sessão são especificos para cada usuário. Objetos
em uma sessão estão disponiveis durante o ciclo de vida da
sessão, tanto para um usuário e portlet especifico qaunto para
um usuário e todos portlets dentro do aplicativo de portlet
- Objetos são removidos quando o objeto não é mais necessário
- Sessões são invalidas manualmente ou após certo tempo de
inatividade

38


A classe PortletSession define dois escopos para armazenamento
de objetos:
●

●

39

AAPLICATION_SCOPE – Objetos armazenados estão
disponiveis para todos portlets, servlets e jsp que pertencem ao
mesmo aplicativo de portlet
PORTLET_SCOPE – Objetos estão disponiveis para o portlet
durante requests na mesma janela de portlet


Usando portlet sessions de forma eficiente:
●

Armazene objetos na session quando:
- O objeto precisa estar disponivel para um request
subsequente
- O objeto é compartilhado com multiplos portlets dentro da
mesma aplicação

●

●

40

Remova objetos quando não são mais necessários
Certifique-se de que todos objetos armazenados na session são
serializable.


Object Scoping
A expectativa de vida do objeto ou escopos
Request scope - tem vida durante requisição atual
● Session scope - abrange os pedidos para o usuário conectado
● Application scope - aplica-se quando o aplicativo é carregado
Dicas para lidar com objetos
● Coloque objetos no escopo apropriado para a aplicação
● Remova os objetos do escopo quando eles não são mais
necessários
● Limitar o tamanho do objeto quando se trabalhar em sessão
● Objeto de sessão em um portal de cluster pode ser mantido em
um banco de dados
● Se um objeto não é específico do usuário, armazenar no
portletContext
●

41


Object Scoping
Lazy Instantition
●

●

É uma tecnica para criação de objetos
É vantajosa quando o uso do processador para recuperar os
dados é maior que aquele associado com a manutenção dos
objetos dentro de uma referência escopo local

Passos para implementa o Lazy Instantition:
●

Passo 1 - Crie o objeto no primeiro pedido

●

Passo 2 - Realizar acesso ao banco

●

Passo 3 – Faça Cache do objeto no escopo de portlet
- Session scope - se o mesmo usuário acessa-lo
- Application scope - para vários usuários

42


Checkpoint
Como você compartilha dados entre portlets de um
aplicativo de portal?
A – Armazena objetos dentro do Portlet Scope
B – Armazena objetos dentro do Application Scope
C – Usa Inter-Portlet Communication
D – Alternativas B e C estão corretas

43


Laboratório 2: Trabalhando com recursos do Portlet
●

Trabalhar com recursos do portal

●

Recuperar dados de um arquivo de propriedades

●

Implementar uma prática sugerida para cache

●

Implementar Lazy Instantiation

44


Compartilhando dados entre Portlets
●

Requisitos comuns em portlets:
- Portlets precisam se comunicar uns com os outros para que
uma ação em um portlet desencadeie uma resposta em outro
portlet
- Portlets precisam compartilhar e enviar dados para outro

●

Vários métodos são utilizados para compartilhamento de dados
entre portlets:
- Alguns métodos são interativos, e alguns são passivos
- Alguns métodos requerem que portlets pertencam ao mesmo
aplicativo de portlet, e outros não exigem

45


Você pode compartilhar dados entre portlets das seguintes formas:
●

Compartilhar RenderParameters entre portlets:
- Eles estão disponíveis para subscribing pelos aplicativos
- Declare RenderParameters públicos no descritor de
implementação do portlet (portlet.xml).

●

Compartilhar dados sobre no PortletSession:
- Adicionando atributos no APPLICATION_SCOPE

46


●

Compartilhar dados usando eventos:
- Especificação JSR 286
- Um portlet publica o evento
- Um ou mais portlets processam o evento

●

Compartilhe dados através de portlets cooperativos:
- Somente aplicável à portlets JSR 168
- Um portlet atua como fonte
- Um ou mais portlets agem como alvos

47


Novidades do JSR 286 – Render Parameters
●

Shared RenderParameters:
- Funcionam de forma semelhante a outros parâmetros que
entram no request
- Também pode ser chamados de Public RenderParameters

●

●

Na especificação JSR 286, RenderParameters podem ser
declarados públicos no portlet.xml para que possam ser
acessados em outro portlet
RenderParameters são strings:
- Recupera-se da mesma forma como os campos de um
formulário
- IBM WebSphere Portal re-entregam RenderParameters
através de uma atualização de janela ou a ação por outro portlet

48


Novidades do JSR 286 – Portlet Events
●

●

●

●

Nova fase no Ciclo de Vida: Event Processing
Events podem ser gerados durante a Action Phase ou Event
Phase - não durante a Render Phase
Event model é um modelo mediado flexível
● Um portlet publica um evento
● Um ou mais portlets processam o evento
Ambos os Events publishes e os Events process devem ser
portlets JSR 286

●

Portlets não precisam estar no mesmo aplicativo de portlet

●

Forma versátil de compartilhar dados entre portlets

49


Interface EventPortlet
●

Contém um método:
void processEvent(EventRequest, eventResponse)

●

●

O objeto EventRequest fornece carga do evento e outras
informações típicas de portlet (modo, estado da janela, etc)
Os eventos podem ser publicados através de métodos em
ActionResponse ou EventResponse
- setEvent() ou setEvents()
- Várias chamadas para setEvent e setEvents são permitidas

●

50

A entrega e processamento de pedidos não é garantida

●

●

●

●

51

Eventos devem ser definidos no arquivo portlet.xml
Após a definição do evento, cada portlet deve declarar quais os
eventos que irá publicar ou receber
Eventos definidos no Portal não precisam ser declarados no
portlet.xml
Nomeando um evento:
- Deve-se usar o padrão W3C QName
- Receiving events podem terminar com um caracter curinga *
- Pode declarar default-event-namespace no portlet.xml e usar
apenas nomes locais


●

Suportando eventos no arquivo portlet.xml
<portletapp xmlns:x="http://mycompany.com/portlet"
             xmlns:std="http://somestandardsbody.org/interopevents">
    <portlet>
        <supportedprocessingevent>
            <qname>x:address.showForUpdate</qname>
        </supportedprocessingevent>
        <supportedpublishingevent>
            <qname>x:address.updated</qname>
        </supportedprocessingevent>
    </portlet>
    <eventdefinition>
        <qname>x:address.showForUpdate</qname>
        <alias>std:address</alias>
        <valuetype>com.mycompany.portlets.common.Address</valuetype>
    </eventdefinition>
    <eventdefinition>
        <qname>x:address.updated</qname>
        <alias>std:address</alias>
        <valuetype>com.mycompany.portlets.common.Address</valuetype>
    </eventdefinition>
</portletapp>

52


●

Suportando eventos na classe Java
public class MyPortlet extends GenericPortlet {
    public static String NAMESPACE = "http://mycompany.com/portlet";

    @ProcessAction(name="address.updated")
    public void addressUpdated(ActionRequest request, ActionResponse response) {
      ...
      Address myAddress = ...;
      response.setEvent(new QName(NAMESPACE, "address.updated"), myAddress);
    }
    @ProcessEvent(name="address.showForUpdate")
    public void addressUpdated(EventRequest request, EventResponse response) {
      Address myAddress = (Address) request.getEvent();
      ...
    }
…
}

53


Novidades do JSR 286 – Resource Serving
●

Nova operação no Ciclo de Vida: serveResource()

●

O método serveResource() é iniciado usando Resource URLs

●

●

O container forcece um ResourceRequest e um
ResourceResponse ao método serveResource()
A chamada para o método serveResource() não é seguida por
uma chamada a fase de renderização
public class UserInfoPortlet extends GenericPortlet implements
ResourceServingPortlet {
...
public void serveResource
(ResourceRequest request,ResourceResponse response)
throws PortletException, IOException
{
...

54


Novidades do JSR 286 – Resource Serving
●

Resource Serving é um recurso fundamental para o
desenvolvimento Ajax:
- Permite iniciar um Resource serving portlet diretamente,
ignorando IBM WebSphere Portal
- Ajuda a servir os recursos e manter o acesso ao contexto do
portlet e seus dados

●

Portlets podem produzir conteúdo com
- OutputStream
- ResourceResponseWriter
- Delegate com uma chamada RequestDispatcher

55


Checkpoint
Na especificação JSR 286, portlets podem compartilhar
dados através de:
A – Render Parameters, Resource Serving, Cooperative
Portlets
B – Render Parameters, Resource Serving, Event Portlets
C – Render Parameters, Event Portlets, PortletSession
D – Render Parameters, Event Portlets, Cooperative
Portlets

56


Laboratório 3: Trabalhando com comunicação
entre Portlets
●

Ativar um portlet para publicar eventos

●

Ativar um portlet para processar eventos

●

Definir uma relação publish-process

57


Parte 4: Ambiente de
Desenvolvimento

1878A
58


Ambiente de Desenvolvimento
Ferramentas a serem consideradas:
Eclipse
● IBM Rational Application Developer
● IBM Web Experience Factory
●

Frameworks a serem considerados:
JSF
● Spring
● Struts
● Dojo
● jQuery
●

59


Ferramentas: Eclipse
●

IDE Open source mais utilizada do mercado

●

Vasto número de plugins

●

Curva de aprendizado pequena

●

Road map bem elaborado

●

Alguns processos de automação

●

Recursos de WYSIWYG limitados

●

●

Falta de ambiente de desenvolvimento dedicado ao Portal (plugin
para WP)
Deployment manual no WebSphere Portal

60


Ferramentas: Rational Application Developer
●

Baseado em Open Source e padrões da indústria

●

Excelente automação e geração automática de codigo

●

Assistentes para criação de Portlets

●

Componentes de UI facilmente integrados em portlets

●

Fácil realizar testes locais com um Portal Test server

●

Completamente integrado ao WAS & WebSphere Portal

●

Integração com outros produtos IBM:
WebSphere Portlet Factory
● Lotus Forms Designer
● Rational Automation Framework
● Rational Team Concert e muito mais...
●

61


Ferramentas: Web Experience Factory
●

●

●

●

●

Ferramenta de desenvolvimento baseada em modelos
para criação de Portlets e aplicações Web
Fácil de aprender, constroi aplicações complexas sem
necessidade de escrever código Java
Mais de 150 builders incluidos para acelerar o
desenvolvimento
Conhecimento de Java só é necessário para criação de
novos builders
Inclui builders para integração com backends (REST
and WebServices, SQL...), soluções proprietárias (SAP,
Oracle CRM, Peoplesoft), Camadas de Negócio e
Apresentação, etc...

62


Ferramentas: RAD vs WEF
●

●

●

É comum ambas serem utilizadas dentro de uma organização para
criação de portlets
Rational Application Developer é voltada para desenvolvedores Java
mais experientes
Web Experience Factory é indicada para usuários com pouca ou
nenhuma experiência em Java

63


Frameworks: Struts 2
●

Framework Web desenvolvido sobre o padrão MVC

●

Arquitetura Simples e fácil de estender

●

Não é padrão da industria, mas chegou a ser o framework web mais
utilizado no mercado

●

Struts 2 é uma grande mudança, junção do Struts 1.x e WebWork

●

O Struts 2 aceita plug-ins disponibilizados por terceiros

●

Struts 2 inclui suporte Ajax

●

Configurações baseadas em Anotações e XML

64


Frameworks: Spring MVC
●

Spring MVC é parte do Spring, que é muito mais abrangente

●

Flexível e Leve

●

●

●

Apesar de não ser padrão da instustria, é um framework bastante
popular
Integração com a maioria dos frameworks de apresentação como
JSP & JSTL, XSLT, JSF, Velocity, FreeMarker, Tiles
Configurações baseadas em anotações e XML

65


Frameworks: JavaServer Faces (JSF)
●

●

●

É mais do que um framework, é uma espeficifcação baseada em
MVC
Desenvolvimento WSYWIG
Padrão de mercado e muitas bibliotecas de terceiros disponiveis
(RichFaces, PrimeFaces, IceFaces, etc)

●

Inclui suporte Ajax

●

Facilidade para criação de componentes

●

JSF v2.0 é uma grande atualização

●

Suportado pelo IBM Rational Application Developer:
●

66

RAD v8.5 e WP v8.0 suportam JSF v2.0

Frameworks: jQuery
●

Framework JavaScript rápido e fácil de usar

●

Baseado em plugins (centenas disponiveis)

●

Suporte Ajax incluso

●

Documentação ampla e de boa qualidade

●

Comunidade grande e participativa

67


Frameworks: Dojo Toolkit
●

Poderoso framework JavaScript, Open Source, rápido e modular

●

Suporte Ajax incluso

●

Dojo fornece um grande conjunto de wigets (Dijit)

●

Documentação ampla e de boa qualidade

●

Comunidade grande e participativa

●

Suporte incluso no IBM Rational Application Developer:
RAD v8.5 e WP v8.0 suportam Dojo v1.7

68


Avaliando Frameworks: Metricas de comparação
●

Facilidade de uso

●

Facilidade de manutenção

●

Performance

●

Escalabilidade

●

Segurança

●

Recursos embutidos

●

Integração com IDEs

●

Comunidade e documentação

●

Futuro da tecnologia e roadmap*

●

Suporte a longo prazo / Dependencia de Fornecedor

69


Avaliando Frameworks: Como escolher?

70


Avaliando Frameworks: Como escolher?
●

Evite utilizar estudos ou comparações prontas

●

Coloque sua aplicação em perspectiva

●

Selecione uma pequena lista de frameworks

●

Avalie cada um e conduza testes

●

Documente prós e contras de cada um

71


Recursos disponíveis para desenvolvedores
●

Página de documentação do produto

●

Wiki do WebSphere Portal

●

Forum do WebSphere Portal no developerWorks

●

IBM RedBooks

●

IBM Lotus GreenHouse

72


Para saber mais...
WebSphere Portal and IBM Web Content Manager Information Center
http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html
WebSphere Portal and Web Content Manager Business Solutions Catalog
https://greenhouse.lotus.com/catalog/
WebSphere Portal developerWorks forum
http://www.ibm.com/developerworks/forums/forum.jspa?forumID=168
The WebSphere Portal wiki
http://www-10.lotus.com/ldd/portalwiki.nsf/xpViewCategories.xsp?lookupNa
me=IBM%20WebSphere%20Portal%208%20Product%20Documentation
IBM Redbooks® publications
http://www.redbooks.ibm.com/portals/websphere


Obrigado!!!

Rodrigo Reis
rodrigoareis@br.ibm.com
IT Specialist & Application Architect
IBM Software Services for Collaboration


© IBM Corporation 2013. All Rights Reserved.
The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and
accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this
information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for
any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended
to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of
the applicable license agreement governing the use of IBM software
.
References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates.
Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market
opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these
materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue
growth or other results.
Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or
performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming
in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an
individual user will achieve results similar to those stated here.
Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the
United States, and/or other countries.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.
ries in the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be
trademarks or service marks of others.
All references to OpenFinancial, Greenwell and Open Bier refer to a fictitious company and are used for illustration purposes only.


Construindo portlets para IBM WebSphere Portal – Parte 1

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Construindo portlets para IBM WebSphere Portal – Parte 1

Semelhante a Construindo portlets para IBM WebSphere Portal – Parte 1 (20)

Construindo portlets para IBM WebSphere Portal – Parte 1