Portlets acessando LDAP

Um autenticador LDAP é peça fundamental em qualquer arquitetura que visa ter um ponto centralizado de autenticação. O WebSphere Portal permite configurar o seu repositório de autenticação apontando para um LDAP de forma nativa.

Entretanto há situações em que voce precisa acessar o LDAP diretamente por meio de um portlet. Há várias bibliotecas na internet com sugestões de conexões, mas a mais recomendada para o ambiente WebSphere é utilizar o próprio mecanismo de JNDI disponibilizado pelo application server.

Abaixo um código de exemplo de como fazer este acesso.

//* Indica propriedades do LDAP
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:389");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "cn=Manager,dc=ibm,dc=com");
env.put(Context.SECURITY_CREDENTIALS, "password");

try {
//* Permite enviar controles na busca do LDAP. Exemplo: SORT
Control[] connectionControls = null;

LdapContext ctx = new InitialLdapContext(env, connectionControls);
Attributes attrs = ctx.getAttributes("uid=alexbc,ou=users,dc=ibm,dc=com");

System.out.println("sn: " + attrs.get("userPassword").get());
System.out.println("sn: " + attrs.get("cn").get());

} catch (NameNotFoundException nnf) {
System.out.println("Elemento nao encontrado");

} catch (NamingException e) {
System.err.println("Erro no acesso LDAP: " + e);
}

Portlets chamando EJB

A arquitetura JEE (Java Enterprise Edition) prevê o uso de EJB's para o tratamento de lógicas de negócio e lógica de persistência.

Os portles, por serem especializados na camada de apresentação podem fazer uso deste tipo de componente para apresentação dos dados.

Neste panorama uma arquitetura recomendada é usar EJB's em uma JVM diferente da JVM utilizada para rodar os portlets. Para implementar esta arquitetura é necessário realizar uma configuração no Websphere para impedir que os CSIv2 enviem credencias de stub de cliente. O procedimento completo para realizar esta configuração pode ser visto no link abaixo:

http://www-01.ibm.com/support/docview.wss?uid=swg21218843

O código para chamar o EJB no portlet está abaixo:

Hashtable env= new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");
env.put(Context.PROVIDER_URL, "iiop://servidorEJB:10031");

InitialContext context= new InitialContext(env);
String jndiName= "ejb/aplicacao/ComponentFacade";

Object objRef = context.lookup(jndiName);
ComponentFacadeHome ejbHome= (ComponentFacadeHome) PortableRemoteObject.narrow(objRef, ComponentFacadeHome.class);
ComponenttFacade remote= (ComponentFacade)ejbHome.create();

ParametersTO netParameter = remote.getVerDados(valor);

Desenvolvendo Portlets para WebSphere Portal Server

Developing Portlets For Web Sphere Portal Server

View SlideShare presentation or Upload your own.

SlideShare Link

Linux

Linux esta cada vez mais presente nas diversas aplicações que nos rodeiam. O crescimento é lento mas sustentado. Uma propaganda legal de Linux e o boot de uma urna eleitoral. Dá-lhe Linux.

Mashups

Mashup's é a nova onda de desenvolvimento. Um vídeo muito interessante para entender melhor Mashup's.

Quero migrar para o Portal 6.1 e tenho o Portal 6.0. O que faço ?

Sem dúvida alguma o título deste POST já deve estar passando na cabeça de alguns arquitetos e desenvolvedores que utilizam a plataforma WebSphere Portal.

Um achado do meu amigo Rafael Osório é acessar o link recem publicado no developerworks contando o que precisa ser feito. Para maiores informações clique aqui.

Você quer experimentar as novidades do WebSphere Application Server 7

Eu pessoalmente só estudo as novas versões do WebSphere Application Server quando ele está próximo de ser lançado ao Portal. A versão 6.1.0.1 virá com suporte nativo ao WebSphere 7, ou seja, em breve precisaremos nos atualizar.

Para ver as novidades do WebSphere Application Server basta instalar conforme video abaixo.

Como integrar WebSphere Portal 6.1 e WebSphere Process Server 6.1

Um tendência crescente em projetos de portais corporativos é o uso processos integrados de BPM. A solução de BPM da IBM é o WebSphere Process Server. Para o desenvolvimento do processo é necessário modelar o processo e sem seguida instalar WebSphere Process Server.

Para maiores informações sobre processos vale a pena ler o post do Rafael Osório falando sobre shopping de processos.

No portal existem várias maneiras de interagir com o processo. Vc. pode criar os portlets para enviar informações ao workflow ou pode utilizar o mecanismo do portal que permite interpretar as informações da interação humana e gerar um interface de portlet padronizada.

O video abaixo mostra como publicar e interagir com artefatos de WebSphere Portal e WebSphere Process Server.

Executando aplicações de Portlet Factory no Lotus Notes

Essa vai para todos que como eu utilizam Lotus Notes e também desenvolvem em Java.

O Lotus Notes é baseado em Java e tudo que falamos para Lotus Expeditor aplica-se para o Lotus Notes.

Para você habilitar a opção que permite a instalação de portles no notes basta acessar o arquivo C:\notes\framework\rcp\plugin_customization.ini e incluir a entrada abaixo:

com.ibm.notes.branding/enable.update.ui=true

Depois é só instalar os seus portlets e se divertir-se.

Lista de API's Web implementadas em produtos IBM

Não sei se vocês são como eu, mas eu adoro saber quais as API's que os produtos IBM utilizam para ter uma idéia de como as coisas são feitas.

Abaixo a lista dos produtos IBM com as suas respectivas implementação de API's Web 2.

	ATOM	DOJO	JSON	REST	Tags
InfoSphere MashupHub	X		X	X	X
Lotus Connections 1.0	X	X	X	X	X
Lotus Connections 2.0	X	X	X	X	X
Lotus Domino Designer 8	X	X
Lotus Mashups	X		X	X	X
Lotus Quickr 8.0	X			X
Sametime 8.0 Advanced	X			X	X
Rational Application Developer 7				X
Rational Application Developer 7.5			X	X
WebSphere MQ 6.0				X
WebSphere MQ 7.0				X
WebSphere sMash	X		X	X
WebSphere Portal 6.1	X	X		X

O que é Mashups ?

Um mashup é um website ou uma aplicação web que usa conteúdo de mais de uma fonte para criar um novo serviço completo.

O conteúdo usado em mashups é tipicamente código de terceiros através de uma interface pública ou de uma API. Outros métodos de codificação de conteúdo para mashups incluem Web feeds (exemplo: RSS ou Atom), Javascript e widgets que podem ser entendidas como mini aplicações web, disponíveis para serem incorporadas a outros sites.

Assim como os blogs revolucionaram a publicação online, os mashups estão revolucionando o desenvolvimento web possibilitando a qualquer um combinar dados de fontes como o eBay, Amazon.com, Google, MS Windows Live e Yahoo! de maneiras inovadoras. Uma maior disponibilidade de APIs leves e simples tem possibilitado mashups relativamente simples de projetar. Requerem um conhecimento técnico mínimo e os mashups feitos sob encomenda muitas vezes apresentam inovações que eram consideradas improváveis, combinando uma nova disponibilidade pública de dados e novos caminhos criativos.

Quer ver um Mashup na prática ? Olhe o Lotus Mashups e divirta-se.

Reportagem de portlets na Java Magazine

Eu sei ... passei o mês de maio em branco e não consegui lançar nenhum post no blog. Acreditem, é pura falta de tempo...que novidade !!!! :-)

vamos ao que interessa.

Neste mês há uma reportagem na Java Magazine sobre portlets. Adivinhe, quem escreveu !? Comprem a revista e descubram.

Para ver um resumo desta edição clique aqui.

Portal 6.1

O WebSphere Portal 6.1 devera ser lançado em breve e para dar um gostinho abaixo coloco um video da demonstração realizada no LotusSphere Comes to You.

Atencao especial aos efeitos em Dojo de arrastar portlets e o novo recurso de processamento independente de cada portlet.

Esta versao do portal procurar usufruir de forma massiva os recursos visuais de Web 2.0. Outro ponto importante esta na infraestrutura. O Websphere Portal utiliza o WebSphere Application Server 6.1 e portanto os recursos de Java EE 5 como EJB 3.0, JSF 1.2 podem ser usadas extensivamente.

Desenvolvendo portlets que acessam SAP

Dentro do panorama de integração de aplicações, o portal tem um papel fundamental como mecanismo unificador de interface. Neste contexto é muito comum você encontrar transações SAP na empresa e querer publicá-las no seu portal corporativo.

Para isto o WebSphere Portlet Factory possui uma série de builders que acessam os Business Objects (BAPI) do servidor R/3 do SAP e gera aplicações em Java.

No vídeo-aula de hoje mostraremos como desenvolver um componente Java para acessar um BAPI e disponibilizaremos primeiramente em uma página Web e em seguida em um portlet.

Agregando salas de bate papo ao seu portal

O servidor de comunicação instântanea da IBM é o Lotus Sametime. Este produto predominantemente baseado em Domino vem sofrendo modificações bastante interessantes nos últimos anos.

O processamento central dos serviços de Sametime está baseado em Domino, entretanto algumas funcionalidades satélites estão baseadas em Java.

Um destes novos serviços baseados em Java é o Lotus Sametime Advanced. Este produtos baseia-se em WebSphere Application Server, DB2 e MQSeries.

Um comparativo bem interessante entre as versões de sametime pode ser encontrado no Blog do Edson Oliveira.

O serviço que quero comentar hoje é o Persistent Chat Rooms. Com ele vocês podem criar salas de bate-papo que podem ajudar os seus clientes a colaborar informação. Os exemplos de negócio são inúmeros:

1) Imagine por exemplo um cliente que queira entrar em uma sala de bate-papo de um fabricante automobilístico para discutir os novas características de um modelo de carro, que ele está interessado em comprar.

2) Para o setor de finanças imagine um banco queira criar uma sala onde investidores possam discutir com especialistas financeiros a oscilação na bolsa e compartilhar a visão do banco para futuros investimentos. Os clientes compareceriam na sala de bate-papo em um horário pré-determinado e caso algum cliente não pudesse comparecer ele poderia ver tudo o que foi conversado.

As aplicabilidade de negócio são inúmeras.

Veja o vídeo (sem audio) que fiz com a navegação nas funcionalidades do produto.

WebAppIntegrator Portlet

Vou usufruir aqui um dos benefícios de blog. Aprender, aprender, aprender.... Eu confesso que nunca havia ouvida falar no portlet WebAppIntegrator até o Mario levantar a questão e acabei descobrindo uma ótima alternativa ao WebPage.

O WebAppIntegrator portlet permite recuperar informações de um outro website. Ele possui características funcionais parecidas com o WebPage ou iFrame com a vantagem de respeitar as politicas de segurança do firewall. Ele age como um proxy de aplicação para aplicações Web externas ao portal.

A instalação dele não segue o modelo padrão de portlets. Você deve seguir os passos abaixo:

1. Download o portlet e unzipar em um diretório temporário do Portal
2. Rodar o comando de linha para instalacao WPSconfig.bat deploy-webAppIntegrator -DWasPassword= -DPortalAdminPwd= -DWebAppIntegratorLocation=\wai_install

Para configurar SSO avançados ou customizações é possível modificar os componentes deste portlet conforme exemplo abaixo

  // Get the URL parameter if it is available
 String fromPortal = request.getParameter("fromPortal");

 // if the URL parameter is not set,
 // check for a session attribute

 if (fromPortal == null) {
     fromPortal=(String) session.getAttribute("fromPortal");
 }  else {
     session.setAttribute("fromPortal", fromPortal);
 }

 // if we are not coming from Portal then
 // show the web application's banner,
 // otherwise the banner will be hidden.

 if (fromPortal == null || !fromPortal.equalsIgnoreCase("yes")) {

     <%@include file="./myWebAppBanner.jspf" %>
 }

para maiores informações você pode consultar a documentação que acompanha o portlet.

Como agregar informações de um portal já existente no WebSphere Portal

Uma requerimento que usualmente aparece nos projetos de portais é a renderização de conteúdo do portal acessando informações de um outro website (intranet ou internet) já existente. Para isto temos 4 possiblidades.

Utilizando o portlet WebPage: Este portlet é bem simples é tem a capacidade de renderizar conteúdos a partir de um outro website. O ponto positivo é que neste caso não há a necessidade de mudar o conteúdo do website que está provendo a informação. Outro ponto importante é que você pode prover conteúdo de outro site em segundos.

Este portlet apesar de ser um ótima solução para alguns casos, ele tem três desvantagens bem significativas.

- A primeira é que o conteúdo segue o padrão do site original e isso pode causar conflitos visuais com o layout desenhado no tema do portal. Como o conteúdo original não foi montado pensando em componentização, este novo portal pode apresentar um excesso de rolagens de browser.

- A segunda desvantagem é que ao carregar a página, o browser soma o tempo de carga da página do portal com a página do site provedor da informação. Lentidões no site que provê a informação irá impactar diretamente o tempo de resposta do portal. Neste caso trabalhos de tunning não podem ajudar porque a responsabilidade de prover a página esta toda repassada ao site hospedeiro. Esta lentidão está associada ao fato de eu processar o protocolo HTTP duas vezes (uma para o portal e outra para o site provedor da informação).

- A terceira desvantagem é que na montagem do http-request é necessário abrir as portas do site hospedeiro. Isso faz com que o firewall tenha que liberar os acessos aos sites que provem a informação. Em uma intranet isso pode não significar muita coisa, mas em uma internet isso pode ser uma questão bem delicada.

Portlet WebClipping. Este portlet diferencia-se da solução anterior por ter a capacidade de pegar parte de uma página para apresentá-la no portal. Neste segundo caso o benefício desta técnica é voce poder reduzir o impacto com o layout e rolagem de conteúdo porque agora voce apresenta apenas parte dos dados. Uma outra vantagem é voce não apresentar os problemas de segurança da opção anterior. As dificuldades com performance são as mesmas.

WSRP. Este portlet permite você consumir conteúdo de outros portais utilizando WebServices Remote Portlet. Este formato reaproveita a camada de apresentação de outros portais no formato de serviço. Protocolo um pouco pesado para um grande volume de acesso mas os resultados em termos de visual e reaproveitamento são ótimos.

Uso como serviço. Esta opção é ótima porque você delega toda a responsabilidade de apresentação unicamente ao portal. Por outro lado, os websites hospedeiros cuidam apenas do processamento. Neste caso a performance é melhor, não apresenta problemas de segurança e o layout fica perfeito. Este serviços podem consumir dados em formatos como WebServices, EJB's, REST, RMI entre outros. O problema é que neste caso é necessário ajustar o serviço legado.

Uso de WebAppIntegrator portlet. Vide em post neste blog

A melhor opção ? Avalie as opções e veja qual das alternativas melhor atendem ao seu cliente.

Utilizando dados do Domino com WPF

No decorrer de diversas apresentações de Websphere Portal e Websphere Portlet Factory fui questionado de como seria o reaproveitamento de dados nos Databases Domino (.NSF).

A pergunta mais comum era:

- Terei que redesenvolver as minhas aplicações Domino em Java ?
- R: NNNNNÃÃÃÃÃÃÃOOOOOOOO

Você pode reaproveitar as informações no Domino de várias formas. Uma delas é lendo dados das bases por meio do Portlet Factory. Ele cria uma camada de abstração que oculta a forma de acesso as bases .nsf. Na prática todos os recursos de WPF que usamos até o momento podem ser utilizados com o Domino.

Abaixo vai uma demonstração em inglês deste processo. Quero ver se em breve disponibilizamos isso em português.

Montando uma solução de formulário eletrônico com Lotus Forms e Lotus Expeditor

Vimos em post anteriores que Lotus Expeditor é a solução de desktop da IBM. Uma outra solução interessante para preenchimento de dados é o Lotus Forms.

Com ele podemos criar formulários mantendo o preenchimento de estado entre campos, assinando um formulário ou mesmo assinando um formulário digitalmente.

Aqui vai uma demonstração do uso destas duas tecnologias.

O único detalhe é que este vídeo está em inglês. Mas de qualquer forma é possível entender a solução apenas vendo o que está ocorrendo.



Gostou ? Coloque comentário e podemos providenciar um passo-a-passo de como fazer isto.

Autenticação no Portal com Desktop Windows

Muito me perguntam sobre este assunto e quero compartilhar a resposta com vocês.

Existem três formas de se fazer isso:

1. Há um componente no Tivoli Access Manager chamado SPNego. Ele permite criar tokens oriundos do sistema operacional estabelecendo uma autenticação com uma aplicação Web. Sem dúvida alguma, esta é a única solução limpa para isto.

Para maiores informações sobre o SPNego clique aqui.

Para entender as outras duas alternativas é necessário entender o funcionamento do HTTP Server da Microsoft. O Internet Information Server (IIS).

O IIS faz uma chamada interna ao sistema operacional e pode receber um token de autenticação do Windows. Esta chamada não é padrão, sendo necessário configurar o recurso na console administrativa do IIS. Este token pode ser repassado para aplicações .net estabelecendo uma relação de autenticação. Neste token caminha a informação do usuário mas não tem a senha.

2. O Portal permite modificar toda a sua estrutura de autenticação. Para isto você pode criar classes que definem o comportamento de autenticação do Portal. A este recurso denominamos Custom User Registry (CUR). Este tipo de implementação requer um alto grau de conhecimento dos módulos de segurança do Portal. Neste caso você poderia ler o token do IIS usando um componente de .net e na porgramação do portal você desabilita a senha permitindo que somente requisições vindas do gateway em .net possa realizar a autenticaçao.

3. Você pode criar um gateway em Java que recebe as informações via gateway .net e autentica no portal via HTTP/HTTPS. Esta solução é a pior de todas devido a quantidade de controles de segurança que são necessários implementar para autenticar. A solução fica lenta e com alto grau de acoplamento coma tela do portal.

Novas idéias, sugestões ou mesmo experiências neste assunto são bem vindas.

Mais informações sobre Composite Applications

No último POST falamos sobre o desenvolvimento de WPF para Expeditor. Entretanto vale lembrar que o Notes 8 foi construído usando a plataforma Expeditor. Desta forma é possível concluir que componentes de WPF podem ser usados em Notes 8. BINGO !!!! Isso mesmo. Bem vindo ao mundo composite applications em Java.

Para maiores informações é possível acessar uma seção de Education da IBM onde pode-se encontrar explicações e outros vídeos sobre o assunto.

Criando aplicações Desktop

Neste quarto vídeo-aula da série de WPF mostraremos como criar uma aplicação desktop utilizando o ambiente de runtime do Lotus Expeditor.

IBM Lotus® Expeditor é o software cliente gerenciado para estender aplicativos compostos a laptops, desktops, quiosques e dispositivos móveis. Pode ser usado para estender as infra-estruturas IBM Lotus, IBM WebSphere, IBM® Workplace™ ou Eclipse™ para um ambiente gerenciado do cliente.

Nesta demo utilizamos o Lotus Expeditor 6.1.1 e WebSphere Portlet Factory 6.0.2.

Criando WebServices com WebSphere Portlet Factory

Neste terceiro vídeo-aula da série de WPF mostraremos como criar serviços de WebServices. WebServices são fundamentais na arquitetura SOA e são categorizados como Services Provider (WebServices que fornecem dados) e Service Consumer (WebServices que consomem dados).

Nesta demos estão sendo utilizados Rational Software Architect 7.0.1, DB2-C 9.0 e WebSphere Portlet Factory 6.0.2.

Acessando um banco de dados com WPF

Temos aqui o segundo vídeo-aula na série de Websphere Portlet Factory. Nele criaremos um componente que irá comunicar-se com um banco de dados relacional. Neste exemplo estamos utilizando o Eclipse 3.2, WebSphere Portlet Factory 6.0.2, WebSphere Application Server 6.0.12 e Apache Derby 10.1 (base do IBM Cloudscape).

Configurarando o WebSphere Portlet Factory e criando uma aplicação Ola Mundo

Este é o post de abertura deste blog de Portal.

O WebSphere Portal (antigo WebSphere Portal Server) é responsável pela camanda de apresentação de um arquitetura SOA. Na arquitetura de referência SOA esta camada é denominada Interaction Services.

Uma peça importante para o sucesso de um portal é a forma com que ele é desenvolvido. Nas versões mais recentes do Portal a IBM, foram implementados formas de melhorar a produtividade na produção de artefatos Java para portal. Uma das ferramentas mais poderosas na produção destes artefatos é o WebSphere Portlet Factory. No decorrer deste blog ele será identificado como WPF.

Neste tópico iremos apresentar alguns vídeos para a criação de componentes JEE (Java Enterprise Edition) para o desenvolvimento com portal.

Neste primeiro vídeo-aula mostraremos como configurar o ambiente do WPF. Em seguida criaremos uma aplicação chamada Ola Mundo.