Desenvolvendo Wires com Portlet Factory

Abaixo um vídeo de como criar Wires utilizando o Portlet Factory

Mecanismo de Persistência ideal

Nas minhas andanças pelos clientes, muitos me questionam sobre o mecanismo de persistência ideal.

Abaixo vou manifestar as minhas opiniões.

Caso você possa e queira deixar o controle da transação por responsabilidade do portal, voce pode usar o WebSphere Portlet Factory utilizando o SQL Call. Ele usa chamadas JDBC e no geral possui um bom tempo de resposta para operações de CRUD.

Entendo que há casos em que vc. precisa trabalhar com a granularidade de transações no banco de dados e até mesmo compartilhar o desenvolvimento de uma classe de persistencia com outros projetos que não necessariamente utilizem a plataforma de portal.

Para estes casos onde o desenvolvimento parece ser a melhor opção eu recomendo o uso de JPA utilizando anotações. Agora o problema é saber qual JPA Provider é mais adequado ao Portal. Posso adiantar que o melhor JPA Persitence Provider pode variar em função da sua experiencia, caracteristica da sua aplicação ou quantidade de registros.

Aqui vai um link com uma comparação bem interessantes entre alguns dos principais JPA de mercado.

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.