Construindo portlets para IBM WebSphere Portal – Parte 1

© 2013 IBM Corporation

Construindo Portlets para IBM WebSphere Portal – Parte 1

Rodrigo Reis IT Specialist & Application ArchitectIBM Collaboration Solutions

© 2013 IBM Corporation2

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


Introdução

● 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

4 © 2013 IBM Corporation

1878A

Parte 1: Portal & Portlets


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."


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:

● Portlet Container● Agregador de Conteúdo● 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:

● 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

● 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

● 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 desenvolvimentoLider: Martin Scott Nicklous, IBM


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


1878A

Parte 2: Contruindo Portlets para IBM WebSphere Portal


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



Banco de dados do WebSphere Portal:

● 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:

● 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 GeralBrowser / Systems

Model SPI

REST SPI

WebDAV SPI

Custom Development(Server Side – Theme, Extensions)

Web Experience Suite

Client Engine

Custom Development(Client Side)

Third Party

Custom Portlets

Markup (HTML)

Data (ATOM,binary…)

Theme / Portlets

IBM products

Out of the box features


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


Portlet Modes

● O Portal monitora o modo do portlet

● Um portlet pode conter 3 modos padrões:

● View – Modo de exibição padrão

● Edit – Usuário personaliza o portlet

● Help – Exibe janela de ajuda

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

● 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>


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:

● Minimize – exibe apenas o titulo da janela

● Maximize – exibe apenas o portlet na 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


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 novosPortlet Modes


Criando um Portlet

Desenvolvendo● Parte 1: Código do Portlet

● Part 2: Portlet descriptor

Empacotando & Publicando

public class HelloWorld extends GenericPortlet {

public void init (PortletConfig portletConfig) throws UnavailableException, PortletException {

super.init(portletConfig);

}

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

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>

<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>

+

WAR


Criando um Portlet

● Estrutura de um Portlet (arquivo WAR)

● Arquivos WAR contém os seguintes artefatos:

● Arquivos de classe Java

● Arquivos JSP

● O deployment descriptor, portlet.xml

● Arquivos JAR contendo qualquer biblioteca usada pelo porltet

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

● Um aplicativo de portlet pode conter um ou mais portlets


Laboratório 1: Criando o primeito Portlet

● Criar um projeto de Portlet

● Implementar a lógica de negócios

● Fazer Deploy do portlet


1878A

Parte 3: Especificação JSR 286


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()

● Public Render parameters● Resource Serving portlets


Portlet

Diagrama do Java Portlet Specification, Version 2.0


Ciclo de vida de um portlet

Portal Portlet

Portal Iniciado

Portlet init()

Usuário solicita páginaProcessAction(), render()

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

Portal Terminado

Portlet marckup

Portlet destroy()

Retorno da página


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.


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.


Relacionamento entre classes JSR286


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());


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);


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


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

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

<containerruntimeoption><name>javax.portlet.actionScopedRequestAttributes</name><value>true</value></containerruntimeoption>


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


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



A classe PortletSession define dois escopos para armazenamento de objetos:

● 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

● 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


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


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


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


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



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



● 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


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


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



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

● A entrega e processamento de pedidos não é garantida



● 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>



● 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(); ... }…}


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{...


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


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


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


1878A

Parte 4: Ambiente de Desenvolvimento


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


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


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...


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...


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


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


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


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:

● 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


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


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


Avaliando Frameworks: Como escolher?


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


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


Para saber mais...

WebSphere Portal and IBM Web Content Manager Information Centerhttp://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html

WebSphere Portal and Web Content Manager Business Solutions Cataloghttps://greenhouse.lotus.com/catalog/

WebSphere Portal developerWorks forumhttp://www.ibm.com/developerworks/forums/forum.jspa?forumID=168

The WebSphere Portal wikihttp://www-10.lotus.com/ldd/portalwiki.nsf/xpViewCategories.xsp?lookupNa

me=IBM%20WebSphere%20Portal%208%20Product%20Documentation

IBM Redbooks® publicationshttp://www.redbooks.ibm.com/portals/websphere


Obrigado!!!

Rodrigo [email protected]

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.

Technology

Construindo portlets para IBM WebSphere Portal – Parte 1