Monografia - Estudo e Avaliação Entre Dois Frameworks Para Desenvolvimento de Portais Corporativos

UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ

CAMPUS DE FOZ DO IGUAÇU

CENTRO DE ENGENHARIAS E CIÊNCIAS EXATAS

BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

ESTUDO E AVALIAÇÃO ENTRE DOIS FRAMEWORKS PARA

DESENVOLVIMENTO DE PORTAIS CORPORATIVOS

EMMANUELE SANABRA MORAES SILVA

FOZ DO IGUAÇU

2006



DESENVOLVIMENTO DE PORTAIS CORPORATIVOS

Monografia submetida à Universidade Estadual do Oeste do Paraná, Curso de

Ciência da Computação, como pré-requisito para obtenção do título de Bacharel em

Ciência da Computação. Orientadora: Professora Sueli Ishimatsu.

FOZ DO IGUAÇU

2006


DESENVOLVIMENTO DE PORTAIS CORPORATIVOSpor


Monografia apresentada a:

RENATO BOBSIN MACHADO

SUELI ISHIMATSU

WILLIAN FRANCISCO DA SILVA

Vista e permitida a impressão.

Foz do Iguaçu, ___/___/______

__________________________________

Sueli IshimatsuOrientadora

.

"O medo é o mais ignorante,

o mais injusto e o mais cruel dos conselheiros."

. Eduardo Burke

.

Dedico este trabalho ao meu pai Abrahão, à minha mãe Sandra eaos meus irmãos Italo e Stefano, pelo grande incentivo aos estudos.

Agradecimentos

À Deus pela grande força, que me acolheu em todas as horas de minha vida.

À minha família pelo apoio indireto ou direto durante todo o meu processo de

graduação.

Aos meus amigos Ana Paula (Aninha), Adriano (Medianeira) e Ronaldo (Tiou) pela

grande caminhada durante a graduação, sempre me fornecendo palavras e gestos de

amizade.

Aos meus amigos Roberlei e André (Pato), que me auxiliaram durante o desenvol-

vimento do projeto.

Ao meu namorado, Marcelo Gilcinei Tonelli, pelo grande incetivo e ajuda durante

todo o desenvolvimento deste trabalho.

Às grandes amizades que fiz nesses anos de faculdade, da turma atual, das tur-

mas anteriores e posteriores. O apoio e incentivo foi fundamental para a conclusão do

curso.

Aos meus amigos, colegas de classe que colaboraram para a criação de um ambi-

ente de aprendizado favorável, de cooperação e coleguismo, gerando um bom apro-

veitamento das aulas e trabalhos.

Aos professores do Curso de Ciência da Computação, que sempre buscam a exce-

lência no ensino e na qualidade das aulas.

À minha orientadora Sueli Ishimatsu pela paciência, esforço e dedicação emprega-

dos na orientação deste projeto, e pela ajuda direta ou indireta para que eu pudesse

concluir esse trabalho.

Resumo

O surgimento de sistemas de informação chamou a atenção de empresas interes-

sadas em automatizar pequenos processos internos, agilizando o trabalho, o que antes

era somente manual. Com o passar dos anos, muitas organizações ou empresas evo-

luíram juntamente com a tecnologia oferecida, agregando vários sistemas desenvolvi-

dos em tecnologias diferentes. Desde modo, as empresas passaram a ter um grande

número de sistemas heterogêneos, sem qualquer tipo de comunicação entre um e ou-

tro, se tornando desde modo em sistemas legados. A integração desses sistemas foi a

forma de atender às necessidades das organizações que tinham o objetivo de possuir

mais vantagem competitiva, de ter ferramentas de gerenciamento nos processos e nas

informações, facilitando nas tomadas de decisão. Para atender a necessidade de in-

tegração, a utilização de portais tem sido bastante discutido, devido a facilidade em

organizar um ambiente corporativo, gerenciando grande volume de informações de

uma organização em um único ponto de acesso. Os portais corporativos oferecem aos

usuários de uma organização a habilidade de alcançar uma larga variedade de fon-

tes de informação diretamente do seu ambiente de trabalho, funcionando como uma

infraestrutura web para a gerência de informação. Esses portais corporativos permi-

tem ainda às organizações acessarem informações externas e internas em uma única

interface, possibilitando a customização de conteúdo, interatividade entre usuários,

contribuindo com as necessidades dos usuários e para tomada de decisões. No mer-

cado surgiram vários frameworks ou ferramentas para desenvolver portais corporati-

vos, causando a necessidade de esclarecimento da tecnologia de portais, auxiliando

interessados (desenvolvedores e possíveis consumidores) para uma melhor seleção do

produto de acordo com o perfil ou necessidade. Portanto neste trabalho, são abordadas

duas ferramentas para desenvolvimento de portais, o BEA WebLogic Portal e o JBoss

Portal, realizando um comparativo entre duas tecnologias.

Palavras-chaves: portal corporativo; frameworks e aplicações web.

Abstract

The system information arise got the attention of companies interested in automa-

tizing small internal processes, speeding the work, where, before it, was only manual.

Years later, many organizations and companies evolved with the offered technology,

adding some systems developed in different technologies. This way, the companies

begun to have a great number of heterogeneous systems, without any kind of com-

munication among these systems, becoming, then, legacy systems. The integration of

these systems was the way to supply the needs of the organizations which had the ob-

jective of acquiring competitive advantage and having management tools for processes

and informations, making it easier to take decisions. To attend the need for integration,

the use of portals has been very discussed, because of the easiness when organizing a

corporative environment, managing great volume of information of a company in an

single point of access. The corporative portals offer to the users of an organization the

ability to directly reach a wide variety of sources of information directly from their

workplace, working as a web structure for information management. These corpora-

tive portals allow the organizations to have access of external and internal information

in only one interface, making possible the customization of content, the interactivity

among users, contributing to the user needs and decision taking. In the market, se-

veral frameworks and tools appeared, focused on development of corporative portals,

showing the need of explanation of the portals technology, helping interested people

(developers and possible consumers) to make a better selection of the product in ac-

cordance with their profile or need. Therefore in this work, two tools for development

of portals are shown, the BEA WebLogic Portal and the JBoss Portal, making a compa-

rative analysis between both technologies.

Key-words: corporative portal; frameworks e web applications.

Lista de Siglas

API Application Programming InterfaceB2B Business to BusinessB2C Business to ConsumerB2E Business to EmployeeB2G Business to Government

CORBA Common Object Request Broker ArchitectureCRM Customer Relationship ManagementCSS Cascading Style Sheets

DCOM Distributed Component Object ModelEAI Enterprise Application IntegrationEIP Enterprise Information PortalERP Enterprise Resource Planning

HTTPS HyperText Transfer Protocol SecureIPCUDI Igreja Presbiteriana Central de Uberlândia

J2EE Java 2 Platform, Enterprise EditionJDK J2SE Development KitJSP Java Server Page

JSR-168 Java Specification Request 168OASIS Organization for the Advancement of Structured Information Standards

ROI Return on InvestmentRPC Remote Procedure CallSDK Software Development KitSCM Supply Chain ManagementSOA Service-Oriented Architecture

SOAP Simple Object Access ProtocolTCP/IP Transmission Control Protocol/Internet ProtocolUDDI Universal Description, Discovery and IntegrationW3C World Wide Web ConsortiumWAR Web Application Archive

WSDL Web Service Description LanguageXML Extensible Markup LanguageXSL Extensible Stylesheet Language

Lista de Códigos

1 Arquivo portlet.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Especificação WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 Síntaxe do WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Especificação SOAP em um arquivo XML . . . . . . . . . . . . . . . . . . 35

5 Código fonte de ObjetoPortlet . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Código fonte de ClientePortlet . . . . . . . . . . . . . . . . . . . . . . . . . 50

7 Arquivo jboss-app.xml, no qual descreve as aplicações no JBoss AS . . . . 50

8 Arquivo cliente-object.xml, no qual descreve uma instância do portlet em

um portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

9 Arquivo XML que descreve o portlet de acordo com o padrão JSR-168

(portlet.xml) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

10 Fonte do ClientePageFlowController . . . . . . . . . . . . . . . . . . . . . . 58

Lista de Tabelas

1 Requisitos mínimos de hardware . . . . . . . . . . . . . . . . . . . . . . . . 60

Lista de Figuras

1 Origens das necessidades da integração . . . . . . . . . . . . . . . . . . . 6

2 Classificação de portais quanto ao contexto de utilização . . . . . . . . . 8

3 Classificação de portais quanto à funcionalidade . . . . . . . . . . . . . . 9

4 Exemplo de portal vertical . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Exemplo de portal horizontal . . . . . . . . . . . . . . . . . . . . . . . . . 11

6 Plumtree Corporate Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7 Portal do Paraná-Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

8 Portal de Negócios da Pecuária . . . . . . . . . . . . . . . . . . . . . . . . 13

9 Portal Colaborativo QPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

10 Principais componentes de um portal corporativo . . . . . . . . . . . . . 18

11 Componentes de um portal corporativo . . . . . . . . . . . . . . . . . . . 19

12 Componentes-chave da arquitetura de portais . . . . . . . . . . . . . . . 22

13 Portais utilizando portlets como componentes de conteúdo . . . . . . . . 23

14 Tecnologias existentes com WSRP . . . . . . . . . . . . . . . . . . . . . . . 27

15 Portal atuando como WSRP Consumer . . . . . . . . . . . . . . . . . . . . 28

16 Interação entre portlets producers e consumers . . . . . . . . . . . . . . . . . 29

17 Funcionamento de Web Service . . . . . . . . . . . . . . . . . . . . . . . . . 32

18 Documento WSDL realizando a integração entre duas aplicações de Web

Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

19 Aplicações clientes utilizando os registros UDDI para descobrir Web Ser-

vices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

20 Arquitetura Orientada a Serviço . . . . . . . . . . . . . . . . . . . . . . . 36

21 Arquitetura da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

22 Arquitetura do JBoss Portal . . . . . . . . . . . . . . . . . . . . . . . . . . 42

23 Portlet de administração no portal . . . . . . . . . . . . . . . . . . . . . . . 43

24 Sucesso na instalação do JBoss Portal . . . . . . . . . . . . . . . . . . . . . 45

25 Desenvolvimento genérico na maioria dos sistemas . . . . . . . . . . . . 46

26 Arquitetura proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

27 Arquitetura implantada para o modelo proposto . . . . . . . . . . . . . . 47

28 Diagrama de classe do objeto ObjetoPortlet . . . . . . . . . . . . . . . . . . 48

29 Diagrama de classe do objeto ClientePortlet . . . . . . . . . . . . . . . . . 49

30 Organização dos arquivos para geração do cliente-portlet.war . . . . . . . 52

31 Log gerado ao adicionar o cliente-portlet.war . . . . . . . . . . . . . . . . . 52

32 Visualização da integração no JBoss Portal . . . . . . . . . . . . . . . . . . 53

33 Ciclo de vida de gerenciamento de conteúdo no BEA WebLogic Portal . 54

34 Ambiente de desenvolvimento do Workshop . . . . . . . . . . . . . . . . . 55

35 Visualização da ferramenta administrativa no WebLogic Portal. . . . . . 55

36 Componentes individuais unificados em um portal. . . . . . . . . . . . . 56

37 Sucesso na instalação do BEA WebLogic Portal . . . . . . . . . . . . . . . 57

38 Fluxo de página no Cadastro de Clientes . . . . . . . . . . . . . . . . . . . 58

39 Construção do template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

40 Resultado da integração no WebLogic Portal . . . . . . . . . . . . . . . . 60

Sumário

Lista de Siglas

Lista de Códigos

Lista de Tabelas

Lista de Figuras

1 Introdução 1

2 Revisão Bibliográfica 4

2.1 EAI - Enterprise Application Integration . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Fatores Relacionados à Integração . . . . . . . . . . . . . . . . . . 5

2.1.2 EAI e Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Tipo de Portais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1.1 Quanto ao Contexto de Utilização . . . . . . . . . . . . . 9

2.2.1.2 Quanto à Funcionalidade . . . . . . . . . . . . . . . . . . 9

2.2.2 Requisitos Mínimos de um Portal Corporativo . . . . . . . . . . . 15

2.2.3 Arquitetura e Componentes . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Portlets e Padrões JSR e WSRP . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.1 JSR 168 - Java Specification Request 168 . . . . . . . . . . . . . . . . 23

2.3.2 WSRP - Web Services for Remote Portlets . . . . . . . . . . . . . . . . 27

2.3.2.1 Arquitetura WSRP . . . . . . . . . . . . . . . . . . . . . . 27

2.3.2.2 As Interfaces WSRP . . . . . . . . . . . . . . . . . . . . . 29

2.4 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4.1 Funcionamento da Tecnologia . . . . . . . . . . . . . . . . . . . . 31

2.4.1.1 WSDL - Web Service Description Language . . . . . . . . . 32

2.4.1.2 SOAP - Simple Object Access Protocol . . . . . . . . . . . . 33

2.4.1.3 UDDI - Universal Description, Discovery and Integration . 33

2.4.2 SOA - Service Oriented Architecture . . . . . . . . . . . . . . . . . . 36

2.5 Frameworks de Portais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.5.1 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.5.2 Componentes Principais . . . . . . . . . . . . . . . . . . . . . . . . 38

3 Estudo de Caso 40

3.1 Contextualização do Problema . . . . . . . . . . . . . . . . . . . . . . . . 40

Camada de Negócio . . . . . . . . . . . . . . . . . . . . . . 40

Camada de Aplicação . . . . . . . . . . . . . . . . . . . . . 41

3.2 JBoss Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.1 Instalação e Configuração . . . . . . . . . . . . . . . . . . . . . . . 45

3.2.2 Reestruturação do Sistema . . . . . . . . . . . . . . . . . . . . . . 46

Camada de Aplicação . . . . . . . . . . . . . . . . . . . . . 46

Camada de Apresentação (Portal) . . . . . . . . . . . . . . 48

3.2.3 Codificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.3 BEA WebLogic Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.3.1 Instalação e Configuração . . . . . . . . . . . . . . . . . . . . . . . 56

3.3.2 Reestruturação do Sistema . . . . . . . . . . . . . . . . . . . . . . 57

3.3.3 Codificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.4 Análise dos Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.4.1 Requesitos Mínimos e Dependências do Servidor . . . . . . . . . 60

3.4.2 Plataformas de Desenvolvimento . . . . . . . . . . . . . . . . . . . 61

3.4.3 Requisitos Mínimos Para o Desenvolvedor . . . . . . . . . . . . . 61

3.4.4 Tecnologias e Padrões Suportadas . . . . . . . . . . . . . . . . . . 61

4 Considerações Finais 62

4.1 Discussões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Referências 64

1

1 Introdução

O surgimento de sistemas de informação chamou a atenção de empresas interes-

sadas em automatizar pequenos processos internos, agilizando o trabalho, o que antes

era somente manual. Com o passar dos anos, as empresas cresceram, novas tecno-

logias foram criadas, soluções em novos sistemas foram oferecidos para atender às

necessidades das empresas.

Muitas empresas estão nesse contexto, evoluíram juntamente com a tecnologia ofe-

recida, agregando vários sistemas desenvolvidos em tecnologias diferentes. Desde

modo, as empresas passaram a ter um grande número de sistemas heterogêneos, sem

qualquer tipo de comunicação entre um e outro, se tornando em sistemas legados.

A integração desses sistemas foi a forma de atender às necessidades das organiza-

ções que tinham o objetivo de possuir mais vantagem competitiva, de ter ferramentas

de gerenciamento nos processos e nas informações, facilitando nas tomadas de deci-

são, assim fornecendo mais colaboração, aumentando a produtividade e a eficiência

nos processos.

A necessidade de solucionar em função dessa demanda, foram desenvolvidos vá-

rios frameworks para desenvolver portais corporativos. Esses portais corporativos per-

mitem às organizações acessarem informações externas e internas em uma única inter-

face, possibilitando a customização de conteúdo, interatividade entre usuários, contri-

buindo com as necessidades dos usuário e nas tomada de decisões.

Problemática

Muitas empresas neste contexto, possuem uma variedade de sistemas desenvolvi-

dos em tecnologias heterogêneas, sem qualquer tipo de comunicação se tornado em sis-

temas legados. Por isso, estas organizações têm-se interessado na tecnologia de portais,

que soluciona a necessidade de integração destes sistemas legados em um único ponto

de acesso. Contudo, no mercado oferece uma variedade de ferramentas para desenvol-

vimento desta tecnologia, entre algumas que pode-se destacar: IBM Web Sphere, Sun

2

One, BEA, JRUN, Liferay, Metadot, Pluto, Pentaho, JBoss Portal, GridSphere, Redhat

Portal Server, entre outros. Portanto escolher a ferramenta para atender esta necessi-

dade torna-se complexo, pois deve considerar as características de cada uma e qual

delas atendem melhor as necessidades do cliente.

Objetivo Geral

O objetivo desse trabalho é fazer um estudo sobre a tecnologia de portais, e fornecer

uma base de análise entre dois frameworks para desenvolvimento de portais corporati-

vos, BEA WebLogic Portal e JBoss Portal, destacando suas vantagens e desvantagens

de cada uma das tecnologias e a melhor aplicabilidade de cada uma.

Objetivos Específicos

Os objetivos específicos deste trabalho estão listados a seguir:

• Realizar o estudo sobre tecnologias de integração de sistemas;

• Realizar o estudo sobre a tecnologia de portais;

• Implantar a solução de portal em sistemas heterogêneos;

• Desenvolver uma solução simples para realizar o comparativo efetivo das tecno-

logias de desenvolvimento;

• Realizar um comparativo entre duas tecnologias para desenvolvimento de por-

tais: BEA WebLogic Portal e JBoss Portal;

• Realizar a conclusão do trabalho e apresentar futuros trabalhos que possam de-

rivar deste.

Entre os atributos para a realização do comparativo entre os dois frameworks para

desenvolvimento é analisar:

• As exigências para o desenvolvimento, como conhecimento base necessário que

o desenvolvedor deve ter;

• As plataformas de desenvolvimento;

• Os requisitos para desenvolvimento, como hardware e software;

• As depedências de servidor;

3

• Os tipos e quais as tecnologias e padrões disponíveis.

Justificativas

Entre algumas justificativas deste trabalho é pela necessidade de muitas organi-

zações de possuir um produto que integre serviços, sistemas e pessoas, desde modo,

este trabalho é abordado uma solução utilizando a tecnologia de portais corporativos,

destacando suas características, conceitos e objetivos. Além disto, proporciona aos de-

senvolvedores informações das mais utilizadas ferramentas de desenvolvimento, rele-

vando suas características de desenvolvimento, estrutura, etc., e uma base comparativa

entre elas, para que possam escolher entre uma e outra ferramenta, de acordo com as

necessidades de seu projeto.

Estrutura do Trabalho

O trabalho é constituído de 4 capítulos.

No capítulo 1 é apresentado esta introdução sobre o trabalho, contextualização do

problema, objetivos gerais e específicos.

No capítulo 2 é apresentado a Revisão Bibliográfica feita para o projeto, todo em-

basamento teórico utilizado para entender e desenvolver um portal. São mencionados

sobre o surgimento desta tecnologia, conceitos, características, requisitos mínimos de

um portal, arquitetura e padrões utilizados. Também é abordado uma nova forma de

programação de um portal utilizando o conceito de Arquitetura Orientada a Serviço

(SOA - Service Oriented Architecture). Por último, uma introdução dos dois frameworks

propostos o BEA WebLogic Portal e JBoss Portal.

No capítulo 3 é apresentado o Estudo de Caso, no qual contém a descrição do

problema abordado, como foi elaborada a solução, configuração das ferramentas, fra-

meworks e plugins utilizados.

O capítulo 4 contém as considerações finais sobre o trabalho realizado, resultados

obtidos e os trabalhos futuros.

4

2 Revisão Bibliográfica

A gestão da informação nas instituições é um item importante da tecnologia de

informação com demanda em forte crescimento. Isso se deve ao fato de que muitas

organizações que utilizam vários tipos ou geração de sistemas desenvolvidos ao longo

dos anos.

A necessidade de desenvolver esses sistemas pode ter ocorrido por eventualidade

do negócio, mudanças na infraestrutura ou até mesmo na política da empresa, etc.,

ocorrendo naturalmente, ao longo dos anos, por exemplo, se uma empresa possui apli-

cações desenvolvidas internamente e consegue alcançar a segunda época um pacote

de gestão empresarial (ERP - Enterprise Resource Planning). Em uma terceira época a

empresa consegue mercado, buscando uma nova necessidade de uma aplicativo para

gerenciar o relacionamento com os clientes (CRM - Customer Relationship Management).

Entre uma época e outra os sistemas podem ser desenvolvidos em tecnologias dife-

rentes, executados em ambiente heterogêneo de hardware e de software, dificultando a

interação entre si, desde modo, se tornando sistemas legados para as empresas (FER-

NANDEZ, 2004). Esses sistemas legados possuem valor para as empresas, mas isso não

significa muito se estes sistemas não puderem compartilhar as informações geradas

por eles com os demais sistemas da organização, deste modo se tornando “ilhas de

informação”.

Assim, a integração de aplicações existentes, fornece um retorno sobre o investi-

mento de forma mais rápida, do que a readaptação ou redesenvolvimento de sistemas,

isso quando é possível (FERNANDEZ, 2004).

Durante a década de 90, uma abordagem conhecida por Análise da Integração de

Aplicações (EAI - Enterprise Application Integration) surgiu como alternativa para tornar

possível a integração de aplicações empresariais com custos mais reduzidos que por

outros tipos de sistemas (CHAVES; BARONI; FERREIRA, 2004).

5

2.1 EAI - Enterprise Application Integration

O EAI (Enterprise Application Integration) fornece metodologia, ferramentas e plane-

jamento que possibilitam à organização obter vantagem competitiva com a integração

de todas as aplicações em um sistema unificado. Esse sistema é capaz de comparti-

lhar as informações e suportar os processos de fluxos de negócios (CHAVES; BARONI;

FERREIRA, 2004).

Um fator que contribuiu para a necessidade da integração de sistemas em uma

organização é o surgimento de alguns tipos de aplicações, transcendendo os limites fí-

sicos da corporação. Isso aconteceu devido à exigência do estabelecimento de relações

“colaborativas” e “instantâneas” através do acesso digital que interligam as empresas

ao mercado (FERNANDEZ, 2004). A seguir alguns exemplos de aplicações (FERNANDEZ,

2004; TOLEDO, 2002):

• Aplicações B2C (business to consumer) - as empresas se comunicam diretamente

com o seu consumidor final, disponibilizando acesso à compra de seus produtos,

informações comerciais e técnicas.

• Aplicações B2B (business to business) - as empresas se comunicam com outras em-

presas clientes e fornecedoras, fazendo troca de informações sobre pedido de

compra, crédito ou ainda informações financeiras.

• Aplicações B2G (business to government) - as empresas trocam informações sobre

tributos, movimento fiscal e contábil, processamento de exportações e outras in-

formações com órgãos governamentais.

• Aplicações B2E (business to employee) - são empresas que possuem ferramentas de

colaboração e serviços de informação de diferentes fontes, formatos e ambientes,

permitem integrar processos de negócios.

2.1.1 Fatores Relacionados à Integração

Além desses tipos de aplicações que possibilitaram às organizações ir além dos li-

mites corporativos, outros fatores causaram novas necessidades da integração. Alguns

fatores são (FERNANDEZ, 2004):

• atualizações ou criação de cada um dos tipos de aplicações ocorrem em épocas

6

diferentes, originadas por eventualidades do negócio, inviabilidade da operaci-

onalização conjunta de todas as mudanças, momentos financeiros ou da própria

política nas organizações;

• escolha de sistemas operacionais ou de sistemas de gerenciamento de banco de

dados diferentes das existentes por diversos fatores de conveniência;

• a reestruturação dos negócios como aquisições, criação ou consolidações de no-

vas unidades de negócio forçam mudanças nos sistemas de informação; na maio-

ria das vezes os sistemas normalmente não são construídos visando à integração

futura. Essa necessidade de integração é atual, resultado de construção de sis-

temas computacionais distribuídos sem qualquer tipo de planejamento ao longo

dos anos (LINTHICUM, 2000);

• não existe um padrão consolidado de integração no mercado de software.

A Figura 1 mostra graficamente as origens das necessidades pela integração das

aplicações.

Figura 1: Origens das necessidades da integraçãoFONTE: (FERNANDEZ, 2004)

2.1.2 EAI e Portal

Para atender a necessidade de integração, no final da década de 90, a idéia de

portais começou a ser discutida para designar um enfoque sobre os sistemas baseados

7

na Internet e Intranet. A tecnologia de portal advinda da Internet tem sido bastante útil

para organizar o ambiente corporativo, gerenciando o grande volume de informações

de uma organização em um único ponto de acesso (CHAVES; BARONI; FERREIRA, 2004).

O portal e o EAI, apesar de serem tecnologias independentes, ambas possuem em

comum o objetivo da integração. Utilizar as técnicas de EAI na construção de portais

pode ser bastante útil, pois provê uma interface unificada para os sistemas de informa-

ção.

2.2 Portal

Durante a década de 90, o termo usado como portal era conhecido como meca-

nismo de busca, por facilitar o acesso às informações contidas em vários pontos dis-

persos pela Internet. Posteriormente, agregaram aos sites de busca, algumas funções de

integração, como chats em tempo real, comunidades e listas de discussão, personaliza-

ção de conteúdo entre outros (TOLEDO, 2002). Enfim, normalmente relatam a evolução

de portais web destacando como progressão básica as seguintes fases: pesquisa boo-

leana, navegação por categorias, personalização e a expansão de funções para outras

áreas dos ambientes de informação e comerciais (REYNOLDS; KOULOPOULOS, 1999).

A trajetória dos portais corporativos e Web foram semelhantes, mas com o espaço

de tempo bem menor. Os primeiros portais corporativos, que possuíam informações

relativa à organização, continham mecanismos de busca, saltando rapidamente para

portais mais interativos e complexos que agregavam aplicações para aumentar a pro-

dutividade individual e do grupo (TOLEDO, 2002).

Na literatura encontra-se várias terminologias para tratar do conceito de portais

corporativos, entre os termos existentes além de “portais corporativos”, têm-se “por-

tais de negócios”, “portal de informações empresariais” e “portal de informações cor-

porativas” (FIRESTONE, 1999).

De acordo com (SHILAKES; TYLMAN, 1998) definem o termo “portal de informações

empresariais” como:

Portais de informações empresariais são aplicativos que permitem às empresas

libertar informações armazenadas interna e externamente, provendo aos usuários

uma única via de acesso à informação personalizada necessária para a tomada de

decisões de negócios. [Eles são]. . . um amálgama de aplicações de software que con-

8

solidam, gerenciam, analisam e distribuem informações não só internamente, como

também para o ambiente externo à organização (incluindo ferramentas de business

intelligence, gestão de conteúdo, datawarehouse, gestão de dados e informações).

A missão dos portais corporativos é acabar com as ilhas dos sistemas de informa-

ção, integrando-as em uma única aplicação que seria porta de entrada para todos os

usuários.

Os portais corporativos oferecem aos usuários de uma organização a habilidade de

alcançar uma larga variedade de fontes de informação diretamente no seu ambiente de

trabalho. Funcionando como uma infraestrutura web para a gerência de informação,

os portais podem fornecer as empresas um espaço de trabalho único que comparti-

lha as informações, facilitando o acesso ao índice de informação, às comunicações da

organização e à colaboração do grupo (DETLOR, 2000).

Em (MURRAY, 1999) complementa a idéia de (SHILAKES; TYLMAN, 1998), apresen-

tando uma visão de portal corporativo como algo além de uma porta de acesso às

informações de uma organização. Segundo (MURRAY, 1999), portais corporativos de-

vem ser capazes de atender as necessidades funcionais dos usuários da corporação, e

não apenas atender como uma ferramenta de acesso às informações ou de tomada de

decisões.

2.2.1 Tipo de Portais

De acordo com a definição de (MURRAY, 1999; DIAS, 2001; TATNALL, 2004; SHILAKES;

TYLMAN, 1998), os portais podem ser classificados quanto ao contexto de sua utilização

e quanto à função, Figuras 2 e 3. As duas próximas seções irão descrever cada um dos

casos.

Figura 2: Classificação de portais quanto ao contexto de utilizaçãoFONTE: (MURRAY, 1999; DIAS, 2001; TATNALL, 2004; SHILAKES; TYLMAN, 1998)

9

Figura 3: Classificação de portais quanto à funcionalidadeFONTE: (MURRAY, 1999; DIAS, 2001; TATNALL, 2004; SHILAKES; TYLMAN, 1998)

2.2.1.1 Quanto ao Contexto de Utilização

Os portais são classificados quanto o modo de utilização, no caso são dois: portais

públicos e portais corporativos.

• Portais Públicos - também conhecido como portais web, fornece ao usuário uma

única interface para vários servidores que formam a Internet. Os portais públicos

são subdivididos em:

– Portais verticais - geralmente destinados a um público predefinido, um bom

exemplo seria o site da IPCUDI (Igreja Presbiteriana Central de Uberlândia),

que é voltado para o público religioso, demonstrado na Figura 4:

– Portais horizontais - são voltados a toda e qualquer pessoa que busque in-

formações de interesse geral, um bom exemplo são sites como UOL, Terra,

MSN etc. Um exemplo desse portal é ilustrado na Figura 5.

• Portais Corporativos - são portais mais focados para redes internas (Intranets),

possibilitando a integração de sistemas heterogêneos, seja eles internos ou exter-

nos, para as pessoas da corporação possam acessar em uma única interface. Um

exemplo de portal corporativo é ilustrado na Figura 6.

2.2.1.2 Quanto à Funcionalidade

• Portais com ênfase em suporte à decisão - contribuem para gerentes, executivos e

analistas acessarem as informações para a tomada de decisão. Esse tipo de portal

pode ser classificado em uma das três sub-categorias a seguir:

10

Figura 4: Exemplo de portal verticalFONTE: http://www.ipcudi.org.br

11

Figura 5: Exemplo de portal horizontalFONTE: http://www.terra.com.br

Figura 6: Plumtree Corporate PortalFONTE: http://www.plumtree.com/

12

– Portal de informações ou conteúdo - é o tipo de portal mais simples, que

deve lidar com o grande volume de conteúdo de uma organização, seja por

tema ou assunto neles contidos, dando acesso para as pessoas da corpo-

ração à informação. O processamento colaborativo ocorre entre usuários e

especialistas e não há qualquer preocupação com a interatividade entre as

pessoas. Um exemplo de um portal de informação ou de contéudo é do

Paraná-Online demonstrado na Figura 7.

Figura 7: Portal do Paraná-OnlineFONTE: http://www.paraná-online.com.br

– Portal de negócios - conecta as informações estruturadas e não estruturadas

em aplicações de gerenciamento de conteúdo e de processamento de deci-

são. Entre as informações que esses usuário podem acessar são planilhas,

pequisas, relatórios, mensagens de correio eletrônico, documento de textos,

páginas web, etc. Um exemplo de portal de negócios é ilustrada na Figura 8.

– Portal de suporte à decisão - lida com informações armazenadas em base de

dados operacionais, no data warehouse ou em sistemas externos à organiza-

ção, gerando relatórios e análises de negócio, no qual esses relatórios serão

distribuídos eletronicamente em vários níveis de tomada de decisão. Para

13

Figura 8: Portal de Negócios da PecuáriaFONTE: http://www.portaldbo.com.br

o refinamento dessas informações, esse tipo de portal utiliza ferramentas

inteligentes e aplicativos analíticos.

• Portais com ênfase em processamento colaborativo - trabalha com informações

armazenadas e manipuladas por outros aplicativos corporativos ou com infor-

mações geradas por pessoas ou grupos dentro ou fora da cadeia produtiva. Esse

tipo de portal ainda pode ser classificado como:

– Portal colaborativo - as informações nesse tipo de portal são geralmente não

estruturadas, como gráficos, memorandos, textos, planilhas, correio eletrô-

nico, entre outros arquivos. Para as pessoas da corporação terem acesso à

essas informações, esse tipo de portal utiliza ferramentas colaborativas de

fluxo de documentos (workflow) ou tarefas e de trabalhos em grupo (group-

ware). Um exemplo desse portal é ilustrado na Figura 9.

– Portal de especialistas - é o um meio de comunicação relacionando e unindo

pessoas especializadas em determinadas áreas do conhecimento em tempo

real. Esse tipo de comunicação na corporação permite a troca de experiên-

cias, ensino à distância, etc.

14

Figura 9: Portal Colaborativo QPRFONTE: http://www.qpr.com

• Portais de suporte à decisão e processamento colaborativo - são portais mais com-

plexos, conectam os usuários a todas as informações e pessoas da corporação

para execução dos negócios. Em um único ambiente, encontram-se aplicativos

de gerenciamento de conteúdo, groupware, workflow, processamento de decisões,

sistemas especialistas, correio eletrônico, business intelligence entre outros.

– Portal de informações empresariais (EIP - Enterprise Information Portal) - são

portais que permitem às empresas libertarem informações armazenadas in-

ternamente e externamente, fornecendo aos usuários da corporação uma in-

terface integrada que possibilita o acesso em um único ponto à qualquer

tipo de informação, dentre as que se destacam as informações personaliza-

das. Essas informações são dados não estruturados, como imagens, correio

eletrônico, relatórios, arquivos de texto e planilhas entre outros. Para in-

tegrar esses dados o portal utiliza metadados e linguagem XML (Extensible

Markup Language) disponibilizando na rede corporativa (Intranet).

– Portal do conhecimento - é a junção dos portais de informações, sendo cola-

borativos e de especialistas. Nesse tipo de portal a principal característica é

o acesso a informações não estruturadas e nos especialistas, fornecendo aos

usuários um conteúdo personalizado de acordo com a atividade realizada

na corporação.

15

2.2.2 Requisitos Mínimos de um Portal Corporativo

O interesse de atender as necessidades das empresas que desejam agregar em um

só produto várias tecnologias, dando suporte aos negócios, agilizar e automatizar as

transações e-business tem crescido consideravelmente o número de fornecedores utili-

zando portal como solução. Para cada tipo de solução, possui características próprias,

componentes adicionais ou estrutura diferenciada, se destacando entre dezenas de ou-

tras soluções disponíveis no mercado (TOLEDO, 2002; DIAS, 2001).

Contudo, diante dessa crescente oferta de produtos para desenvolvimento de por-

tais, teve-se a necessidade de esclarecer essa nova tecnologia, auxiliando os possíveis

consumidores, os executivos das empresas, para melhor seleção do produto de acordo

com seu perfil ou necessidade de seu negócio. Vários consultores especializados no

assunto, como (ECKERSON, 1999c), do Patricia Seybold Group e (WHITE, 1999), do Data-

Base Associates International, têm publicado artigos e relatórios contendo os requisitos

mínimos de um portal corporativo (DIAS, 2001).

Em (ECKERSON, 1999c), relata os principais requisitos mínimos que um portal deve

atender. Veja as quinze regras de (ECKERSON, 1999c):

1. Fácil para usuários eventuais - os usuários devem conseguir localizar e acessar

facilmente a informação correta, com o mínimo de treinamento, não importando

o local de armazenamento dessa informação. Encontrar informações de negócios

no portal deve ser tão simples quanto usar um navegador web.

2. Classificação e pesquisa intuitiva - o portal deve ser capaz de indexar e organi-

zar as informações da empresa. Seu mecanismo de busca deve refinar e filtrar

as informações, suportar palavras-chave e operadores booleanos, e apresentar o

resultado da pesquisa em categorias de fácil compreensão.

3. Compartilhamento colaborativo - o portal deve permitir aos usuários publicar,

compartilhar e receber informações de outros usuários. O portal deve prover

um meio de interação entre pessoas e grupos na organização. Na publicação, o

usuário deve poder especificar quais usuários e grupos terão acesso a seus docu-

mentos/objetos.

4. Conectividade universal aos recursos informacionais - o portal deve prover am-

plo acesso a todo e qualquer recurso informacional, suportando conexão com

sistemas heterogêneos, tais como correio eletrônico, bancos de dados relacionais

16

e multidimensionais, sistemas de gestão de documentos, servidores web, group-

ware, sistemas de áudio, vídeo etc. Para isso, o portal deve ser capaz de gerenciar

vários formatos de dados estruturados e não estruturados.

5. Acesso dinâmico aos recursos informacionais - por meio de sistemas inteligen-

tes, o portal deve permitir acesso dinâmico às informações nele armazenadas,

fazendo com que os usuários sempre recebam informações atualizadas.

6. Roteamento inteligente - o portal deve ser capaz de direcionar automaticamente

relatórios e documentos a usuários selecionados como parte de um processo de

fluxo de informações.

7. Ferramenta de business intelligence integrada - para atender as necessidades de in-

formação dos usuários, o portal deve integrar os aspectos de pesquisas, relatório

e análise dos sistemas de business intelligence.

8. Arquitetura baseada em servidor - para suportar um grande número de usuários

e grandes volumes de informações, serviços e sessões concorrentes, o portal deve

basear-se em uma arquitetura cliente-servidor.

9. Serviços distribuídos - para o melhoramento de balanceamento de carga de pro-

cessamento, o portal deve distribuir os serviços por vários hosts. De acordo com

(TOLEDO, 2002), os processos de comunicação devem ser gerenciados por proto-

colos padrões (TCP/IP - Transmission Control Protocol/Internet Protocol, CORBA -

Common Object Request Broker Architecture, DCOM - Distributed Component Object

Model1, etc.).

10. Flexibilidade na definição das permissões de acesso - o administrador do portal

deve ser capaz de definir permissões de acesso para usuários e grupos da em-

presa, por meio dos perfis de usuário.

11. Interfaces externas - o portal deve ser capaz de se comunicar com outros sistemas

e aplicativos.

12. Interfaces programáveis - o portal também deve ser capaz de ser chamado por

outros aplicativos, tomando pública sua interface programável (API - Application

Programming Interface).

1Estes protocolos são descritos detalhadamente em (TANENBAUM, 2002)

17

13. Segurança - para salvaguardar as informações corporativas e prevenir acessos

não autorizados, o portal deve suportar serviços de segurança, como criptogra-

fia, autenticação, firewall etc. Deve também possibilitar auditoria dos acessos à

informações, das alterações de configuração, etc.

14. Fácil instalação e administração - deve ser de fácil instalação, configuração e ma-

nutenção, e aproveitar, na medida do possível, a base instalada de hardware e soft-

ware adquirida/contratada anteriormente pela organização. Deve ainda prover

um meio de gerenciar todas as informações corporativas e monitorar o funciona-

mento do portal de forma centralizada e dinâmica.

15. Customização e personalização - o administrador do portal deve ser capaz de

customizá-lo de acordo com as políticas e expectativas da organização, assim

como os próprios usuários devem ser capazes de personalizar sua interface para

facilitar e agilizar o acesso às informações consideradas relevantes.

2.2.3 Arquitetura e Componentes

Existem no mercado de portais corporativos muitos produtos para o desenvolvi-

mento de portais, possuindo características próprias, componentes adicionais ou es-

trutura diferenciada, se destacando entre dezenas de outros produtos (TOLEDO, 2002;

DIAS, 2001). Mas em todos os produtos, segundo (WHITE, 1999), existe uma arquitetura

básica, composto por um assistente de informações, provido por um navegador web, e

um servidor web, com os seguintes elementos: diretórios de informações de negócios,

máquina de busca, ferramenta de publicação, analisador de metadados, ferramenta de

assinatura, interfaces de importação e exportação de dados. Segundo (WHITE, 1999),

em uma arquitetura mais composta, os produtos podem ser independentes ou inte-

grados em outros sistemas. A Figura 10 apresenta arquitetura de um portal e seus

componentes.

Segundo (THE DELPHI GROUP, 2000), são nove componentes básicos de uma arqui-

tetura: integração, categorização, mecanismos de busca, publicação e distribuição, pro-

cessos, colaboração, personalização, apresentação e ciclo de aprendizado. A Figura 11

apresenta os componentes de um portal corporativo e em seguida a descrição de cada

componente (THE DELPHI GROUP, 2000).

• Integração - é o componente base para qualquer implementação de portal. Esse

componente é responsável pela capacidade de integração fornecendo uma estru-

18

Figura 10: Principais componentes de um portal corporativoFONTE: (WHITE, 1999)

19

Figura 11: Componentes de um portal corporativoFONTE: (THE DELPHI GROUP, 2000)

tura de acesso a fontes de informação internas e externas (TOLEDO, 2002). Em

(THE DELPHI GROUP, 2000), define três necessidades básicas de integração para

portais:

– integrar as informações estruturadas, são repositórios de sistemas legados,

pacotes de aplicação, repositórios de banco de dados das aplicações, siste-

mas de data warehouse e business intelligence.

– integrar as informações não estruturadas, são informações como mensagens

de correio eletrônico, documentos de texto, planilhas, multimídia, gráficos,

páginas web, etc.

– integrar as pessoas, isso é possível pela experiência da Internet, desenvol-

vendo um conjunto tecnologias para apoiar esse tipo de integração (TOLEDO,

2002).

• Categorização - o portal ganha um grande benefício quando as informações são

encontradas dentro de um contexto ou de um domínio de compreensão. Em

(TOLEDO, 2002) é citado que ao trabalhar com a informação, a organização pos-

sui elementos que constroem um contexto, elementos como práticas de negócio,

20

história corporativa, iniciativas de administração, recursos profissionais disponí-

veis, requisitos de aprendizagem, estrutura e cultura. Para rotular a informação,

são utilizados metadados, possibilitando que diferentes documentos possam ser

agrupados de forma lógica.

• Busca - fornecer uma busca fácil para localizar informações relevantes nas fontes

de dados estruturados e não estruturados disponíveis no portal. De acordo com

(THE DELPHI GROUP, 2000), para guiar o desenvolvimento do mecanismo de uma

busca eficaz deve atender a quatro requisitos: indexação contextual, acesso a me-

tadados, acesso completo a descrições de documentos e busca baseada em concei-

tos. No entanto, há uma necessidade de atender a vários tipos de busca, desde o

mais simples ao mais complexo, entre alguns tipos são: busca por palavra-chave e

frase exata; buscas booleanas; buscas conceituais que utilizam dicionários; busca

por contexto; busca em linguagem natural; buscas com filtros etc.

• Publicação e Distribuição - esse componente deve dar suporte a criação de con-

teúdo, inclusão e distribuição do mesmo, em qualquer formato, sendo que o con-

teúdo deve ficar disponível em toda rede da corporação (Intranet). De acordo

com (THE DELPHI GROUP, 2000) esse componente possui três serviços relevantes:

autorização, aprovação, processo de publicação e de manutenção.

• Suporte a Processos - esse componente deve conter aplicações projetadas para

automatizar os processos e dar suporte as atividades comuns de negócios eletrô-

nicos como rotas de documentos e formulários, acompanhar os status de mensa-

gens de solicitação e respostas num processo de negociação, etc.

• Colaboração - essa camada permite interações de funcionário-para-funcionário,

funcionário-para-cliente e trocas entre parceiros de negócios e acionistas (HUM-

MINGBIRD, 2000). Em (THE DELPHI GROUP, 2000) complementa e chama atenção

para três áreas em que o impacto é maior na configuração de um projeto de co-

laboração: identificação dos níveis esperados de benefício, seleção das caracte-

rísticas de tecnologia de colaboração e avaliação de desenvolvimento de software.

A comunicação deve ser suportada na forma assíncrona (repositórios de dados,

correio eletrônico, fóruns de discussão, ferramentas de workflow etc.) e na forma

síncrona (videoconferência, ferramentas de chat, sistemas eletrônicos de reuniões,

etc.).

• Personalização - esse componente permite aos usuários configurarem suas inter-

21

faces, definindo que conteúdo é relevante para ser exibido, moldando a informa-

ção, desde modo, elimina o conteúdo desnecessário, maximizando a eficiência e

a produtividade.

• Apresentação - é nesse componente que se responsabiliza em atender o para-

digma de único ponto de acesso pelos portais. Essa camada, deve endereçar

tanto os layouts de exibição, integrando um grande volume de informações em

um pequeno espaço visual, quanto os contextos e a facilidade de uso (THE DELPHI

GROUP, 2000).

• Ciclo de Aprendizado - essa última camada muitas vezes é ignorada pela maioria

dos fornecedores de solução de portais. Esse componente fornece ao portal uma

grande eficácia, que identifica as mudanças de necessidade de informação, ajus-

tando e atualizando de forma automática e rápida. Nessa camada podem utilizar

ferramentas analíticas e tecnologias que possibilitam o aprendizado, avaliando e

gerenciando o conteúdo de forma inteligente (TOLEDO, 2002).

A arquitetura de (TERRA; GORDON, 2002) se assemelha com a apresentada por (THE

DELPHI GROUP, 2000), o que diferencia é a ausência da última camada ou compo-

nente Ciclo de Aprendizado. Nessa arquitetura proposta por (TERRA; GORDON, 2002),

compõem-se em: camada de apresentação e personalização, solução de busca, apli-

cações web e os conectores, responsáveis pela integração de outros componentes. Na

Figura 12 a arquitetura proposta por (TERRA; GORDON, 2002):

De forma geral, um portal corporativo deve fornecer uma arquitetura ou framework

de integração, desta forma, integrando em uma única interface ou ponto de acesso,

organizações e seus colaboradores uma vasta variedade de aplicações como gestão

de conteúdo (ERP, CRM, SCM (Supply Chain Management), correio eletrônico, sistemas

legados, colaboração e outros sistemas já existentes na empresa (TOLEDO, 2002).

Na próxima seção serão abordados as tecnologias mais utilizadas em uma arquite-

tura de portal, os portlets e seus padrões JSR-168 (Java Specification Request 168) e WSRP

(Web Service for Remote Portlet), abordando seus conceitos, características e suas funcio-

nalidades.

22

Figura 12: Componentes-chave da arquitetura de portaisFONTE: (TERRA; GORDON, 2002)

2.3 Portlets e Padrões JSR e WSRP

Nos últimos anos, muitas organizações utilizaram a tecnologia de portais para hos-

pedar aplicações internas ou externas, surgindo um mercado lucrativo de portais J2EE

(Java 2 Platform, Enterprise Edition). No princípio, o produto definia sua própria API

para construção de aplicações para portais e seus componentes (OLIVEIRA, 2004). De-

vido às estas diferenças de implementação, os produtos ficavam presos a um tipo de

portal e não a tecnologia. Muitos produtos ou portal server passaram a utilizar tec-

nologias padronizadas, podendo a aplicação ser reutilizada em outras tecnologias de

portais. O objetivo central de um portal server é fornecer maior produtividade às em-

presas, permitindo usuários e grupos trabalhar facilmente e com segurança dentro de

uma estrutura organizacional dinâmica.

Entre as tecnologias mais utilizadas no portal server é o portlet. Assim como portais,

os portlets são novas tecnologias emergentes, ganhando a atenção e,ntre os fornecedo-

res de soluções para integração de sistemas, isto acontece devido a sua facilidade no

desenvolvimento, a abundância de funcionalidades, a customização da interface e a

23

arquitetura maleável.

Em sistemas de portais mais recentes consiste normalmente em vários portlets, cada

um com a capacidade de processar pedidos do usuário a estes serviços e para gerar

conteúdo dinâmico em cada uma das requisições. Os portlets são usado nos portais

como componentes de conteúdo na interface contendo em cada um deles um serviço

disponível para o usuário (AKRAM et al., 2005).

A necessidade de padronização no desenvolvimento de portais e de seus compo-

nentes levou a JSR-168 (Java Specification Requests 168), buscando a interoperabilidade

entre portais e portlets, possibilitando que desenvolvedores de portais possam criar

seus componentes que executem em qualquer servidor de portal J2EE. Portlets em Java

aderem a norma JSR-168, que padroniza a interoperabilidade entre os portlets e os por-

tlets containers. Na Figura 13 é demonstrado um portal utilizando a tecnologia de por-

tlets.

Figura 13: Portais utilizando portlets como componentes de conteúdoFONTE: (CASTLE, 2005)

2.3.1 JSR 168 - Java Specification Request 168

O padrão JSR-168 (Java Specification Request 168) especifica como os componentes

de um servidor de um portal serão desenvolvidos. O padrão JSR-168 fornece intero-

24

perabilidade entre portlets e portlets containers nos frameworks dos portais, contribuindo

com a interoperabilidade na estrutura e na reutilização de código.

A especificação define um padrão de Portlet API e da infraestrutura em que fornece

facilidades para a personalização, a apresentação e a segurança. Esta norma beneficia

gerentes das corporações devido ao custo reduzido e aos desenvolvedores devido a

reusabilidade de código.

O padrão JSR-168 dirige-se aos seguintes tópicos:

• Gerência do ciclo de vida de um portlet - do mesmo modo que as extensões dos

servlets java funcionam dentro de um servlet container, o JSR-168 define um portlet

container para controlar portlets. Uma espécie de contrato ou assinatura é definida

para que os containers chamem métodos durante o ciclo de vida de um portlet. O

desenvolvedor pode implementar os seguintes métodos para atender a funcio-

nalidade desejada:

– init() - chamado quando um portlet é instanciado em um container.

– destroy() - chamado quando se destrói um portlet.

– processAction() - chamado depois do usuário enviar ações para os por-

tlets.

– render() - chamado sempre que o portlet é atualizado pelo ambiente de

trabalho do usuário. A partir do método render(), pode especificar a cha-

mada de outros métodos mais específicos baseado na modalidade do por-

tlet. Isso é possível, quando o desenvolvedor estende GenericPortlet e

implementa os seguintes métodos:

∗ doView() - chamado por render() quando o portlet está no modo de

visualização (View).

∗ doEdit() - chamado por render() quando o porlet está no modo de

edição (Edit).

∗ doHelp() - chamado por render() quando o portlet está no modo de

ajuda (Help).

• Uso do portlet e definição de estado da janela - cada portlet tem uma modalidade

atual, que indica que a função que o portlet está executando. Como citado an-

teriormente, as modalidades do portlet são View, Edit e Help. Estas modalidades

são definidas para a decisão de qual método será chamado a partir do método

25

render(). O estado da janela indica o tamanho do espaço na página do por-

tal será designada ao portlet. Os estados da janela do portlets são minimizado,

maximizado e normal.

• Preferências do portlet – usado para fornecer uma visualização ou comporta-

mento diferenciado dependendo do usuário que atua sobre o portlet. Na espe-

cificação do portlet, o container portlet é responsável pelo armazenamento e recu-

peração das preferências utilizando a interface PortletPreferences através

dos métodos setValues() e getValues() respectivamente. Os portlets tem

acesso ao objeto PortletPreferences durante o processo da requisição, mas

somente pode modificar os atributos durante a invocação do método process-

Action(). Quando o método store() for chamado antes do fim da execu-

ção do método processAction() as mudanças destes atributos serão perma-

nentes. Contudo, para validar os valores da preferência, deve ser executada a

classe PreferencesValidator, isso fará com que durante a execução do mé-

todo store() invocará o método validate() antes da alteração definitiva dos

dados.

• Informação do usuário - a especificação provê mecanismos para os portlets pos-

sam acessar informações do usuário, como nome, email, telefone e endereço.

• Empacotamento e distribuição – o empacotamento e a distribuição dos portlets

é como nos arquivos WAR (Web Application Arquive) que podem conter outros

componentes web, como JSP´s (Java Server Pages) e servlets. Além dos arquivos de

descrição como web.xml, existe o portlet.xml no qual todos os portlets e suas

relações. Um exemplo de arquivo portlet.xml é demonstrado no Código 1.

• Segurança - a especificação do portlet inclui diversas características para auxi-

liar os desenvolvedores a criar um portlets seguro. Entre algumas características,

o desenvolvedor pode restringir o portlet a executar somente sobre o protocolo

HTTPS (HyperText Transfer Protocol Secure), ideal para portlets que possuem con-

teúdo confidencial e que deve ser criptografado antes de enviá-lo pela rede. Tam-

bém o Portlet API inclui facilidade de autenticação para requisições dos usuários

e informações restritas.

• Tags JSP - contém uma biblioteca de tags JSP para ajudar visualizar páginas com

a tecnologia JSP.

26

1 <?xml version="1.0" encoding="UTF-8"?>2 <portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"3 version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"4 xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd5 http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd">6

7 <portlet>8 <description lang="EN">query_portlet</description>9 <portlet-name>query_portlet</portlet-name>

10 <display-name lang="EN">query_portlet</display-name>11 <portlet-class>QueryPortlet</portlet-class>12

13 <init-param>14 <name>view_url</name>15 <value>/templates/view.jsp</value>16 </init-param>17

18 <init-param>19 <name>edit_url</name>20 <value>/templates/edit.jsp</value>21 </init-param>22

23 <init-param>24 <name>help_url</name>25 <value>/templates/help.jsp</value>26 </init-param>27

28 <expiration-cache>-1</expiration-cache>29

30 <supports>31 <mime-type>text/html</mime-type>32 <portlet-mode>edit</portlet-mode>33 <portlet-mode>view</portlet-mode>34 <portlet-mode>help</portlet-mode>35 </supports>36

37 <supported-locale>en</supported-locale>38

39 <portlet-info>40 <title>Query Portlet</title>41 <short-title>Query Portlet</short-title>42 </portlet-info>43

44 <portlet-preferences>45

46 <preference>47 <name>title</name>48 <value>Employees</value>49 </preference>50

51 <preference>52 <name>sql</name>53 <value>SELECT * FROM emp</value>54 </preference>55

56 <preferences-validator>QueryPreferencesValidator</preferences-validator>57

58 </portlet-preferences>59 </portlet>60 </portlet-app>

Código 1: Arquivo portlet.xml

27

2.3.2 WSRP - Web Services for Remote Portlets

Outro padrão utilizado para o desenvolvimento de portais é o padrão WSRP, que

é uma especificação de Web Services (Assunto abordado na seção 2.4, p. 29) usado para

descrever o acesso ao conteúdo remoto de um portal. Em combinação com o padrão

JSR-168, facilita os desenvolvedores de portlets a publicar seus portlets em um portal

remoto (YANG; WANG; ALLAN, 2002).

O padrão WSRP é um produto de OASIS (Organization for the Advancement of Struc-

tured Information Standards), em que define um padrão de uma interface para comuni-

cação para Web Services. Esse serviços processam interações dos usuários e fornecem

a interoperabilidade, agregando os serviços em portais. Uma das características mais

importantes é que os serviços são orientados a apresentação, permitindo o usuário

possa interagir diretamente ao serviço a partir da interface (CASTLE, 2005).

(CASTLE, 2005) destaca que o WSRP está construído em cima de padrões Web Servi-

ces existentes, como SOAP (Simple Object Access Protocol), WSDL (Web Service Descrip-

tion Language) e UDDI (Universal Description, Discovery and Integration) (estes padrões

serão abordados na seção 2.4.1, p. 31). Na Figura 14 é demonstrado um desenho es-

quemático contendo as tecnologias existentes em WSRP.

Figura 14: Tecnologias existentes com WSRPFONTE: (CASTLE, 2005)

2.3.2.1 Arquitetura WSRP

De acordo com a especificação WSRP (CASTLE, 2005), define-se os seguintes atores

dentro de uma arquitetura WSRP:

• WSRP Producer: é um serviço web que oferece um ou mais portlets e implementa

um conjunto de interfaces WSRP. Este serviço pode oferecer ainda, apenas um

portlet ou um container para distribuir e gerenciar diversos portlets.

28

• WSRP Portlet: um WSRP Portlet inclui componentes de interface do usuário que

reside dentro do WSRP Producer, para que estes possam ser acessados remota-

mente através de uma interface definida por WSRP Producer.

• WSRP Consumer: é um serviço cliente web que consume os serviços oferecidos por

WSRP Producer e provê um ambiente para os usuários interagir com os portlets

oferecidos por um ou mais serviços web. Um exemplo de WSRP Consumer é um

portal.

Na Figura 15 é demonstrado cada um dos atores preliminares de uma arquitetura

WSRP.

Figura 15: Portal atuando como WSRP ConsumerFONTE: (CASTLE, 2005)

Na Figura 16 um exemplo dos portlets ou WSRP producers e consumers interagindo.

No centro da figura demonstra um portlet producer, no qual pode estabelecer uma

comunicação (Figura 16, seta 1) com os portlets consumers (Portals Servers) via servi-

ços padrões web como SOAP/UDDI/WSDL. Um dos possíveis consumidores proces-

sam o conteúdo do portlet producer, podendo organizar os dados como é conveniente,

emitido-os nas aplicações clientes (Figura 16, seta 2), abstraindo qualquer idéia de uma

arquitetura portlet. Depois a aplicação cliente pode retornar resultados ou ações ao por-

tlet consumer correspondente, finalizando o processo ou pode redirecionar ao portlet

producer para obter novos resultados (Figura 16, setas 3 e 4) (RUBIO, 2005).

29

Figura 16: Interação entre portlets producers e consumersFONTE: (RUBIO, 2005)

2.3.2.2 As Interfaces WSRP

Como vimos anteriormente, WSRP define um conjunto de interfaces padrões para

que todos WSRP Producers devem implementar, permitindo que os WSRP Consumers

possam interagir como portlet remoto. Desta forma, padronizando estas relações per-

mite que o portal interaja com genéricos portlets remotos. Veja quais são as interfaces

obrigatórias que todo WSRP Producer deve implementar, e as interfaces opcionais de

acordo com (CASTLE, 2005):

• Service Description Interface (obrigatório) - permite os WSRP Producers anunciem

seus serviços disponíveis para possíveis WSRP Consumers.

• Mark-up Interface (obrigatório) - permite os WSRP Consumers possam interagir

com os portlets remotos executados em um WSRP Producer.

• Registration Interface (opcional) - permite que WSRP Producer possa exigir que

WSRP Consumer seja registrado antes de qualquer tipo de interação com os servi-

ços.

• Portlet Management Interface (opcional) - fornece para WSRP Consumer o acesso do

ciclo de vida dos portlet remotos que estão em execução.

Um exemplo de definição dos serviços utilizando a especificação WSDL é demosn-

trado no Código 2.

2.4 Web Services

Os Web Services (Serviços Web) são serviços disponibilizados por um servidor e

uma rede interna (Intranet), como nas empresas, ou externa (Internet). Esses serviços

são componentes distribuídos utilizados como componentes de aplicações baseadas na

web (MARQUES, 2005; POTTS; KOPACK, 2003).

30

1 <?xml version="1.0" encoding="UTF-8"?>2 <wsdl:definitions xmlns:urn="urn:oasis:names:tc:wsrp:v1:bind"3 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"4 targetNamespace="urn:myproducer:wsdl">5

6 <wsdl:import namespace="urn:oasis:names:tc:wsrp:v1:bind"7 location="http://www.oasis-open.org/committees/wsrp/specifications8 /version1/wsrp_v1_bindings.wsdl"/>9

10 <wsdl:service name="WSRPService">11

12 <wsdl:port name="WSRPBaseService" binding="urn:WSRP_v1_Markup_Binding_SOAP">13 <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"14 location="http://myproducer.com:7007/portal/producer"/>15 </wsdl:port>16

17 <wsdl:port name="WSRPServiceDescriptionService"18 binding="urn:WSRP_v1_ServiceDescription_Binding_SOAP">19 <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"20 location="http://myproducer.com:7007/portal/producer"/>21 </wsdl:port>22

23 <wsdl:port name="WSRPRegistrationService"24 binding="urn:WSRP_v1_Registration_Binding_SOAP">25 <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"26 location="http://myproducer.com:7007/portal/producer"/>27 </wsdl:port>28

29 <wsdl:port name="WSRPPortletManagementService"30 binding="urn:WSRP_v1_PortletManagement_Binding_SOAP">31 <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"32 location="http://myproducer.com:7007/portal/producer"/>33 </wsdl:port>34 </wsdl:service>35 </wsdl:definitions>

Código 2: Especificação WSDL

31

Um Web Service descreve suas funcionalidades em uma linguagem específica, im-

plementando uma interface contendo um conjunto de operações, informações neces-

sária para interagir com ele, inclui também formatos de mensagens e protocolos utili-

zados e a sua localização (SILVA, 2001).

Como citado anteriormente, a principal característica do Web Service é possuir uma

interface de acesso ao serviço, escondendo os detalhes de implementação e permitindo

sua utilização independentemente de plataforma de hardware ou de software (MARQUES,

2005).

A tecnologia de Web Service facilita a integração de sistemas legados fornecendo

meios e ferramentas para que informações possam ser transferidas de um sistema le-

gado para outro. Um meio padrão de comunicação ou troca de mensagens é utilizar a

linguagem XML (SILVA, 2001; MARQUES, 2005).

2.4.1 Funcionamento da Tecnologia

O objetivo principal da tecnologia Web Service é permitir a interoperabilidade entre

plataformas, integração das aplicações e serviços. Esses sistemas podem ser escritos

em diversas linguagens, ferramentas e protocolos de comunicação. Essa grande vari-

edade de tecnologias pode causar uma deficiência nos Web Services devido a falta de

padrões. A W3C (World Wide Web Consortium) especificou SOAP (Simple Object Access

Protocol), WSDL (Web Service Description Language) e UDDI (Universal Description, Disco-

very and Integration), na tentativa de padronizar a criação de Web Services (CHRISTENSEN

et al., 2004). Todas essas especificações de Web Services são escritas em XML.

A seguir na Figura 17, como funciona um Web Service:

1. O Provedor de serviços (Service Provider), publica o serviço no Registro de Servi-

ços (Service Registry).

2. Quando o cliente (Service Requester) precisa de um serviço, ele o procura no regis-

tro através de palavras chaves enviando a classificação do mesmo.

3. Se encontrar, devolve para o cliente os detalhes da conexão para o cliente se co-

nectar ao servidor.

4. A partir dessas informações a interface do serviço é mapeada.

5. O cliente acessa o serviço.

32

Figura 17: Funcionamento de Web ServiceFONTE: (NANDI, 2005)

2.4.1.1 WSDL - Web Service Description Language

O WSDL (Web Service Description Language) é uma linguagem em XML que des-

creve os serviços da rede como um conjunto de informações orientadas a procedimen-

tos (CHRISTENSEN et al., 2004). É nessa especificação que são descritas os Web Services,

contendo informações como (CHRISTENSEN et al., 2004):

• URL´s para o serviço.

• Chamadas de método que o serviço possui, descrevendo cada um dos parâme-

tros e o que retorna na chamada.

• Quais protocolos podem ser processados.

• Quais especificações de formato de dados que comporta.

Na Figura 18 é demonstrado duas aplicações A e B, ambas traduziram partes de

suas funcionalidades da camada de negócios em um documento WSDL, criando desta

forma uma camada de integração. Desta maneira, a aplicação A pode usar serviços de

B através dessa nova interface de integração e vice-versa, que seriam os Web Services.

Desta forma, é possível integrar independentemente da tecnologia utilizada através do

WSDL de cada aplicação.

A estrutura do arquivo em que especifica o WSDL, possui quatro tipos de constru-

tores. São eles (NANDI, 2005):

• Interface - faz o mapeamento com o nome do serviço.

• Message - especifica as mensagens aceitas pelo Web Service.

• Service - descreve o Web Service.

• Binding - especifica os protocolos de comunicação usados por um Web Service.

33

Figura 18: Documento WSDL realizando a integração entre duas aplicações de WebServices

FONTE: (NANDI, 2005)

A sintaxe do WSDL e os quatros tipos de construtores são demontrados no Código

3.

2.4.1.2 SOAP - Simple Object Access Protocol

O SOAP (Simple Object Access Protocol) é um protocolo que contém uma mensagem,

no qual descreve em XML as chamadas dos métodos dos Web Services. Em (NANDI,

2005) descreve ainda que o SOAP estabelece um formato padrão de mensagem que

consistem em um documento XML capaz de hospedar informações centradas em do-

cumentos (document-centric) e informações centradas em RPC (Remote Procedure Call).

A especificação do SOAP é implementada em XML, contendo informações da men-

sagem SOAP, armazenada em um elemento chamado enveloper SOAP como demons-

tra o Código 4.

2.4.1.3 UDDI - Universal Description, Discovery and Integration

A última especificação, o UDDI (Universal Description, Discovery and Integration) um

tipo de registro de dados com informações sobre os Web Services. Esses registros são

armazenados em banco de dados podendo estar disponíveis publicamente para toda a

Internet, ou mesmo numa Intranet, facilitando que possíveis clientes possam encontrar

34

1 <wsdl:definitions name="nmtoken"? targetNamespace="uri">2 <import namespace="uri" location="uri"/> *3 <wsdl:documentation .... /> ?4

5 <wsdl:types> ?6 <wsdl:documentation .... /> ?7 <xsd:schema .... /> *8 </wsdl:types>9

10 <wsdl:message name="ncname"> *11 <wsdl:documentation .... /> ?12 <part name="ncname" element="qname"? type="qname"?/> *13 </wsdl:message>14

15 <wsdl:portType name="ncname"> *16 <wsdl:documentation .... /> ?17 <wsdl:operation name="ncname"> *18 <wsdl:documentation .... /> ?19 <wsdl:output message="qname"> ?20 <wsdl:documentation .... /> ?21 </wsdl:output>22 <wsdl:fault name="ncname" message="qname"> *23 <wsdl:documentation .... /> ?24 </wsdl:fault>25 </wsdl:operation>26 </wsdl:portType>27

28 <wsdl:serviceType name="ncname"> *29 <wsdl:portType name="qname"/> +30 </wsdl:serviceType>31

32 <wsdl:binding name="ncname" type="qname"> *33 <wsdl:documentation .... /> ?34 <-- binding details --> *35 <wsdl:operation name="ncname"> *36 <wsdl:documentation .... /> ?37 <-- binding details --> *38 <wsdl:output> ?39 <wsdl:documentation .... /> ?40 <-- binding details --> *41 </wsdl:output>42 <wsdl:fault name="ncname"> *43 <wsdl:documentation .... /> ?44 <-- binding details --> *45 </wsdl:fault>46 </wsdl:operation>47 </wsdl:binding>48

49 <wsdl:service name="ncname" serviceType="qname"> *50 <wsdl:documentation .... /> ?51 <wsdl:port name="ncname" binding="qname"> *52 <wsdl:documentation .... /> ?53 <-- address details -->54 </wsdl:port>55 </wsdl:service>56 </wsdl:definitions>

Código 3: Síntaxe do WSDL

35

1 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">2 <env:Header>3 ...4 </env:Header>5

6 <env:Body>7 ...8 <env:Fault>9 ...

10 </env:Fault>11 </env:Body>12 </env:Envelope>

Código 4: Especificação SOAP em um arquivo XML

os Web Services desejados (ERL, 2004; DATZ, 2005; POTTS; KOPACK, 2003).

De acordo com (CHRISTENSEN et al., 2004), define UDDI como:

Um registro público de negócio é um diretório global de descrições de serviços

internacionais de negócios. Instâncias deste registro são hospedadas em um grupo

de servidores UDDI dedicados. Estes registros UDDI são replicados automatica-

mente entre instâncias de repositórios.

Na Figura 19 são demonstrados os registros que podem estar disponíveis cons-

tituindo diretórios centralizados para que possam ser acessados (CHRISTENSEN et al.,

2004; NANDI, 2005).

Figura 19: Aplicações clientes utilizando os registros UDDI para descobrir Web ServicesFonte: (NANDI, 2005)

Com isso, utilizando WSDL, SOAP e UDDI como base para WSRP, fornece uma

arquitetura muito mais robusta entre os portlets producers e consumers (abordados na

seção 2.3.2, p. 27).

36

2.4.2 SOA - Service Oriented Architecture

Um software modularizado é o mínimo que se pode exigir para evitar falhas em

grandes sistemas, especialmente quando há exigências complexas dos usuários. (AK-

RAM et al., 2005) complementa ainda que mesmo nesses softwares modularizados, pode

ficar difícil encontrar a inter-independência de seus sub-componentes. Esses softwares

com componentes altamente acoplados, a maioria deles foram projetados dentro desse

contexto na primeira geração de portais. Essa falha fez com que muitos projetistas pen-

sassem na estrutura do portal desconsiderando a complexidade, contexto e tamanho

do software (AKRAM et al., 2005). Isto conduz ao conceito de uma arquitetura orientada

serviço (SOA -Service Oriented Architecture). Um SOA é uma coleção de serviços que

podem se comunicar com qualquer outro. Esses serviços são funcionalidades intero-

peráveis, ou seja, podem ser consumidos independentemente da linguagem em que

foi desenvolvida ou plataforma (AKRAM et al., 2005). Na Figura 20 é demonstrado a

integração de tecnologias.

Figura 20: Arquitetura Orientada a ServiçoFonte: (NANDI, 2005)

Esse novo conceito fez com que portais corporativos se adaptassem, deixando de

ser proprietários de serviços para ser consumidores dos serviços. Com esta transfor-

mação, os servidores de portais podem ser substituídos por portal de serviços que

fornecem aplicações e infraestrutura de serviços (FRYE, 2005).

37

2.5 Frameworks de Portais

Ao iniciar um projeto, muitos clientes questionam a importância da utilização de

um framework para construção de seu portal corporativo. Mas como foi abordado an-

tes, um portal corporativo deve ser desenvolvido de forma integrada aos processos

de negócios da empresa, tornado-se a principal ferramenta para usuários que preci-

sam acessar diariamente as informações e aplicações necessárias para trabalhar e se

tornarem mais produtivos (SULLIVAN, 2003; CONECTT, 2005).

Devido a isso, o seu desenvolvimento pode ser um desafio em termos de tecno-

logia. Existem vários desafios para construir um portal corporativo, podemos citar

alguns como: unificar vários aplicativos, que muitas vezes não tem integração entre

si; fazer aplicações independentes se comunicarem e possibilitar grande troca de in-

formações, etc. Ainda os portais corporativos devem possuir segurança, robustez e

performance (CONECTT, 2005; NEDUNGADI, 2005). De acordo com (CONECTT, 2005),

se tornaria inviável o desenvolvimento, se os desenvolvedores se preocupassem com

todos esses desafios. Portanto a idéia de utilizar os frameworks de portais no desenvol-

vimento tem se tornado muito atraente.

2.5.1 Características

A utilização de um framework cumpre vários papéis em um portal, entre os que

mais se destacam (CONECTT, 2005; NEDUNGADI, 2005; SULLIVAN, 2003):

• permitir que o sistema cresça de maneira estruturada, possibilitando maior con-

trole do administrador;

• no processo de desenvolvimento, otimiza a construção das páginas, permitindo

eventualidades mudanças maiores com mais facilidade;

• fornece maior flexibilidade na hora de projetar e modificar a interface, já que o

framework se concentra basicamente no conteúdo e permissões do portal;

• oferece uma série de serviços comuns que podem ser utilizados por quaisquer

aplicações, reduzindo drasticamente o custo do desenvolvimento, enquanto a

qualidade e usabilidade dos portais.

38

2.5.2 Componentes Principais

Os frameworks no modo genérico podem conter os seguintes componentes (NEDUN-

GADI, 2005):

• Integração - fornecem uma camada de apresentação comum para todo o portal,

podendo conter diferentes produtos como: interfaces, portlets, gadgets e webparts

entre outros. A página web pode ter vários destes produtos ou serviços, podendo

pertencer a qualquer aplicativo remoto. Além disso, existe outra camada respon-

sável pela comunicação entre os serviços, deste modo permitindo que aplicativos

troquem informações de uma maneira fácil e genérica. O framework utiliza tec-

nologias como CSS (Cascading Style Sheets), XSL (Extensible Stylesheet Language) e

XML para controlar e manter a consistência visual das informações exibidas para

o usuário final.

• Segurança - quando o framework trata da segurança, as aplicações podem ser

construídas sem preocupações em relação à administração da segurança do por-

tal. Processos como validação de login, integração com mecanismos de autenti-

cação externos, acesso via HTTPS, são tratados pelo próprio portal, centralizando

a autenticação, em um único ponto.

• Busca - geralmente integrada com a personalização e o controle de acesso do

portal, retorna apenas resultados de áreas às quais os usuários tenham permissão

de acesso.

• Performance - a performance é uma das grandes preocupações, para que o portal

seja bem-sucedido. Os frameworks são arquitetados de modo a gerar uma solução

final com performance otimizada.

• Escalabilidade e Robustez - um framework oferece escalabilidade para atender às

exigências dos grandes portais, utilizando um ambiente de balanceamento de

carga, onde servidores web podem ser dinamicamente adicionados ou removidos,

dependendo da demanda e das exigências de acesso. Deste modo, escalando os

processos para múltiplos servidores, aumenta a robustez e a disponibilidade da

solução.

• Gerando log e relatórios - a maioria dos frameworks de portais incluem ferramen-

tas para registro e geração de relatórios sobre a utilização do portal. Para os

39

administradores, essas informações geradas são essenciais para poder controlar

e analisar o retorno do investimento (ROI - Return on Investment) do portal.

• Templates - em templates podem armazenar elementos comuns nas páginas web,

como banners, barra de navegação, cabeçalho, rodapé, etc. A utilização de um

template permite que os construtores do portal atualizem a aparência e a estru-

tura das páginas de maneira centralizada, atualizando automaticamente todas as

páginas relacionadas.

Uma vez definida a necessidade de utilização de um framework, inicia-se outro pro-

cesso bastante complexo: a escolha da ferramenta. Com uma grande oferta de opções

disponíveis, cada vez mais as empresas e desenvolvedores se confundem, sem saber

qual escolher. Alguns fatores como requisitos de manutenção, infra-estrutura, ade-

rência aos processos e muitos outros influenciam na escolha. No próximo capítulo

(Estudo de Caso) abordaremos duas ferramentas para desenvolvimento de portais, o

BEA WebLogic Portal e o JBoss Portal.

40

3 Estudo de Caso

Este capítulo descreve o estudo de caso realizado sobre dois frameworks para desen-

volvimento de portais, JBoss Portal e BEA WebLogic Portal, elaboração de uma solução

para integração de sistemas em um único ponto de acesso, ferramentas e configuração

para desenvolvimento.

3.1 Contextualização do Problema

Muitas organizações possuem diversos sistemas heterogêneos que foram agrega-

dos, que na maioria das vezes foram desenvolvidos de acordo com a necessidade da

empresa naquele instante, sem qualquer planejamento para uma integração futura.

Esses sistemas isolados pela diversidade de tecnologias, de sistemas operacionais, de

banco de dados e de hardware, torna-se uma desvantagem competitiva para a organiza-

ção, pois esses sistemas dificultam no gerenciamento do grande volume de informação,

sem qualquer tipo de auxílio para tomada de decisão.

Mesmo esses sistemas sendo legados, provam valor para as empresas, mas isso

não tem muita eficiência se não puderem se conversar entre si, deste modo tornando

em ilhas de informação. A integração se torna uma solução atraente, pois o retorno do

investimento é mais rápido, do que a reestruturação do sistema, isso quando é possível.

Neste estudo de caso, foi desenvolvido um sistema simples de cliente-venda. Neste

caso foi adotado uma arquitera N-camadas demonstrada na Figura 21, utilizada nos

casos de Cadastro de Cliente, Cadastro de Produtos e Cadastro de Vendas.

A arquitetura basicamente comporta por camada de persistência, camada de negó-

cio, camada de aplicação e camada de apresentação. A seguir será descrita cada uma

das camadas, suas funcionalidades e características.

Camada de Negócio

41

Figura 21: Arquitetura da aplicação

• PERSISTENCE - responsável pela conexão com o banco de dados, fazendo com

que haja somente uma instância da conexão com o banco durante toda a transa-

ção (padrão de projeto singleton). Para a persistência dos dados foi utilizado o

Hibernate.

• DAO - responsável pela persistência dos objetos.

• FACTORY - responsável pelo gerenciamento e validação da informação, além de

possibilitar consultas específicas para cada objeto.

• TRANSACTION - responsável pela transacionalidade da informação, além de

possuir uma interface de acesso para camadas superiores.

Camada de Aplicação

• ACTION - camada responsável por possibilitar as ações necessárias sob a camada

de negócios para a camada de controle.

• CONTROLLER - camada que recebe as aquisições da interface.

A seguir, seções 3.2 e 3.3, serão apresentadas duas ferramentas para desenvolvi-

mento de portais: JBoss Portal e BEA WebLogic Portal.

42

3.2 JBoss Portal

Os portais corporativos, como abordado anteriormente, facilitam o acesso à infor-

mação fornecendo uma única fonte de interação. No entanto, hoje os frameworks fecha-

dos ajudam mais rapidamente no desenvolvimento de portais corporativos, portanto

o JBoss Portal (http://labs.jboss.com/portal/jbossportal) pode oferecer benefícios por

ser uma ferramenta open source, além de fornecer flexibilidade e escabilidade.

O JBoss Portal é licenciado sob o LGPL (Gnu Lesser General Public License) e está

livre para download e livre acesso para desenvolvimento. O JBoss Portal fornece uma

plataforma centralizada para o acesso de informação segura e a colaboração online,

com flexibilidade e interoperabilidade entre os portlets, ou seja, suporta o padrão JSR-

168, possibilitando a integração de páginas web e aplicações dinâmicas dentro de um

portlet padronizado e reutilizável. Além disso, os portlets suportam padrões abertos da

Internet, podendo utilizar serviços web (Web Services) e aplicações baseadas em J2EE

(JBOSS PORTAL, 2006a).

O JBoss Portal depende do servidor de aplicação do JBoss (JBoss AS - JBoss Appli-

cation Server), que possibilita a hospedagem de aplicações que requerem o alto desem-

penho e a alta escabilidade para sua execução. Seus serviços de alta disponibilidade

fornecem clustering, caching, fail-over, balanceamento de carga (load balancing), e as ca-

racterísticas de desenvolvimento distribuído (JBOSS PORTAL, 2006a).

O JBoss Portal é desenvolvido em Java fornecendo compatibilidade com vários sis-

temas operacionais que possuam a máquina virtual Java (JVM - Java Virtual Machine),

incluindo Windows, Unix e Linux. A seguir um desenho esquemático da arquitetura,

Figura 22, destacando as suas características (JBOSS PORTAL, 2006a).

Figura 22: Arquitetura do JBoss PortalFONTE: (JBOSS PORTAL, 2006a)

43

• Certificação JSR-168 Portlet Container;

• Fácil instalação e facilidade na publicação da aplicação no JBoss AS;

• Múltiplas instâncias de portal pode estar executando dentro um Portal Container;

• As instâncias do portal podem ser organizadas em um único ambiente;

• Os portlets podem ter seus próprios arquivos para internacionalização;

• Os portlets podem ser implementados utilizando JSF (Java Server Faces), MyFaces,

e Spring MVC, AJAX, JSP, entre outros;

• Escabilidade e segurança fornecido por JEMS (Journal and Event Management Sys-

tem) incluindo JBoss AS, JBoss Cache e JGroups;

• Acesso e persistência dos dados utilizando o Hibernate;

• Possui interoperabilidade com qualquer banco JDBC, incluindo MySQL, IBM

DB2, Oracle Database, Microsoft SQL Server, e outros;

• Opção de escolha e customização para autenticação para utilização dos serviços.

O JBoss Portal possibilita a administração do portal (Figura 23), fornecendo aos

administradores de portais, funcionalidades de forma segura, ou seja exigindo auten-

ticação de usuário. As funcionalidade disponíveis para a administração do portal são

(JBOSS PORTAL, 2006a):

Figura 23: Portlet de administração no portalFONTE: (JBOSS PORTAL, 2006d)

44

• Registro de usuário e login;

• Criar, editar e excluir contas de usuários;

• Criar, editar e excluir grupos de usuários;

• Associar regras a usuários;

• Associar regras a grupos de usuário;

• Validação de e-mail para novos usuários cadastrados;

• Modificação de layouts e temas do portal.

Além disso, o JBoss Portal fornece o gerenciamento de conteúdo, contendo as se-

guintes funcionalidades (JBOSS PORTAL, 2006a):

• Upload de conteúdo binário para qualquer diretório do sistema, possibilitando a

configuração do tamanho máximo do arquivo;

• Gerenciamento de diretórios: criar, mover, copiar em toda árvore de diretórios;

• Gerenciamento de arquivos: criar, mover, copiar e excluir arquivos;

• Simples navegação entre os diretórios;

• Gerenciamento de versões: novos arquivos podem ser criados com suporte a con-

trole de versão no modo padrão, possibilitando aos administradores recuperar

uma versão anterior;

• Customização de páginas de erro: as páginas de erro podem ser editadas de

acordo com a necessidade do site;

• Editor HTML integrado: suporta um editor HTML com o modo WYSIWYG, com

funcionalidade de pré-visualização e edição do código HTML;

• Possui total suporte a WebDav, permitindo as aplicações existentes acessarem e

editarem os arquivos armazenados no sistema.

45

3.2.1 Instalação e Configuração

Para a utilização do JBoss Portal 2.4, é recomendado utilizar JDK 5 (J2SE Develop-

ment Kit), devidamente instalado e configurado as variáveis de ambiente JAVA_HOME

e CLASSPATH.

O servidor utilizado foi o Pacote “JBoss Portal + JBoss AS”, o qual é o método mais

rápido e fácil para instalação e execução. Este pacote já contém o JBoss Application

Server e o JBoss Portal embutido utilizando o banco de dados Hypersonic.

Instalando o JBoss Portal:

• Passo 1 - Download do pacote está disponível em

(http://labs.jboss.com/portal/jbossportal/download/) .

• Passo 2 - Extrair o arquivo ZIP no diretório de sua escolha.

• Passo 3 - Para habilitar o servidor, execute o run.bat no Windows, run.sh se Linux

no DIRETORIO_JBOSS_PORTAL/bin.

Figura 24: Sucesso na instalação do JBoss PortalFONTE: (JBOSS PORTAL, 2006b)

46

• Passo 4 - Para verificar se o JBoss Portal foi devidamente instalado acesse o en-

dereço http://localhost:8080/portal, devendo aparecer uma tela semelhante a

Figura 24.

3.2.2 Reestruturação do Sistema

A maioria dos sistemas são desenvolvidos em camadas: camada de negócios, ca-

mada de apresentação, camada de persistência, etc., como é demonstrado a Figura

25. Neste casos, a reestruturação para adicionar a aplicação em um portal acontece

somente na camada de aplicação, o qual será implantada a tecnologia utilizada na

maioria dos portais, os portlets. Nesta camada, deve-se implementar uma classe que

herde de javax.portlet.GenericPortlet o qual será responsável em processar e

responder as aquisições do portlet. Na Figura 26 é demonstrado a arquitetura proposta

para a implementação dos portlets.

Figura 25: Desenvolvimento genérico na maioria dos sistemas

Na Figura 27 é apresentada uma arquitetura genérica que foi utilizada nos casos

de Cadastro de Cliente, Cadastro de Produto, Cadastro de Venda. Nesta arquitetura

pode-se reutilizar a camada de negócio, alterando somente a camada de aplicação.

Camada de Aplicação

• ACTION - camada responsável em possibilitar as ações necessárias para a ca-

mada de negócios (TRANSACTION). Com a nova arquitetura, torna-se possível

acessar as ações diretamente (Figura 27, seta 4) ou por consumo de serviço, os

Web Service (Figura 27, seta 5), de uma camada de negócios remota (Figura 27,

seta 6). Desse modo é possível acessar a camada de negócio dos sistemas, in-

dependentemente da linguagem utilizada na implementação (PHP, Delphi, C++,

47

Figura 26: Arquitetura proposta

Figura 27: Arquitetura implantada para o modelo proposto

48

Java).

• PORTLET - camada que substituiu a CONTROLLER, responsável pelo processa-

mento de aquisições. A camada PORTLET é responsável no controle dos portlets,

processando as aquisições da página web (JSP, JSF, etc...). Toda ação gerada, o

portlet submete à camada ACTION.

Camada de Apresentação (Portal) A camada de apresentação do portal possui con-

tainers portlets, que hospedam portlets. Esses portlets podem ser consumidos direta-

mente (Figura 27, seta 1), ou seja estão hospedados no mesmo servidor, ou consumidos

remotamente (Figura 27, seta 2), utilizando o WSRP, no qual possibilita acessar em um

ponto remoto uma instância de um portlet (Figura 27, seta 3).

3.2.3 Codificação

A solução encontrada para adaptar o Cadastro de Cliente, Cadastro de Produto e

Cadastro de Venda, foi utilizar uma classe abstrata base que herda de javax.port-

let.GenericPortlet, contendo métodos que suportem as aquisições de um cadas-

tro comum. O diagrama de classe de ObjetoPortlet é demonstrado na Figura 28.

Figura 28: Diagrama de classe do objeto ObjetoPortlet

Os métodos init(), processAction(), doView() são reimplementados para

o tratamento das aquisições do portlet container de acordo com as necessidades do ca-

dastro. Um trecho da implementação destes métodos é demonstrado no Código 5.

49

1 public abstract class ObjetoPortlet extends GenericPortlet {2 protected boolean isRemoto = false;3

4 public void init() {5 this.lista = new SearchPaginate();6 }7

8 public void processAction(ActionRequest request, ActionResponse response)9 throws PortletException, PortletSecurityException, IOException {

10 try {11

12 String action = request.getParameter("action");13 if ((action != null) && (action.trim().length() > 0)14 && (!action.equalsIgnoreCase(Messages.getString("voltar")))15 && (!action.equalsIgnoreCase(Messages.getString("cancelar")))) {16 Objeto objeto = this.getObjeto(request); // método abstrato17

18 if (action.equalsIgnoreCase(Messages.getString("inserir"))) {19 this.inserirAction(objeto);// método abstrato

Código 5: Código fonte de ObjetoPortlet

De acordo com o diagrama de classe de ObjetoPortlet (Figura 28), foram decla-

rados métodos abstratos para o tratamento das aquisições, forçando qualquer objeto

que herde de ObjetoPortlet a implementar esses métodos para o tratamento da

aquisição, isso ocorre nos portlets de cliente, produto e venda. Na Figura 29 é demons-

trado o diagrama de classe de ClientePortlet.

Figura 29: Diagrama de classe do objeto ClientePortlet

Na classe de ClientePortlet são implementados os métodos abstratos de Obje-

toPortlet, no qual faz o tratamento das aquisições do portlet de Cadastro de Clientes.

No Código 6 é demonstrado um trecho do código de ClientePortlet, implemen-

tando os métodos abstratos de ObjetoPortlet.

50

1 public class ClientePortlet extends ObjetoPortlet {2

3 public void init() {4 this.lista = new SearchPaginate();5 this.consultaDefault = ClienteSearchAction.BUSCAR_NOME;6

7 EDIT_PORTLET_PAGE = "/WEB-INF/clientes/list.jsp";8 HELP_PORTLET_PAGE = "/WEB-INF/clientes/help.jsp";9 VIEW_PORTLET_PAGE = "/WEB-INF/clientes/list.jsp";

10

11 INSERT_PAGE = "/WEB-INF/clientes/insert.jsp";12 UPDATE_PAGE = "/WEB-INF/clientes/update.jsp";13 DELETE_PAGE = "/WEB-INF/clientes/delete.jsp";14 ERROR_PAGE = "/WEB-INF/clientes/error.jsp";15 }16

17 protected void atualizarAction(Objeto objeto) throws Exception {18 new ClienteUpdateAction(this.isRemoto).execute(objeto);19 }20

21 protected void editar(PortletRequest request) throws Exception {22 String id = request.getParameter("id");23 this.lista = new ClienteSearchAction(this.isRemoto).execute(24 ClienteSearchAction.BUSCAR_ID, id, 0, this.lista25 .getNumMaxRegistrosPagina());26 request.setAttribute("cliente", this.lista.getResultado().get(0));27 this.proximaPagina = ObjetoPortlet.UPDATE_PAGE;28 }

Código 6: Código fonte de ClientePortlet

Finalizando a implementação do portlet, deve-se descrever os arquivos XML: port-

let.xml, jbossapp.xml e cliente-object.xml (Códigos 7, 9 e 8).

1 <?xml version="1.0" encoding="UTF-8"?>2 <jboss-app>3 <app-name>clienteportlet</app-name>4 </jboss-app>

Código 7: Arquivo jboss-app.xml, no qual descreve as aplicações no JBoss AS

1 <?xml version="1.0" encoding="UTF-8"?>

2 <deployments>

3 <deployment>

4 <if-exists>overwrite</if-exists>

5 <parent-ref>default</parent-ref>

6 <page>

7 <page-name>Cliente</page-name>

8 <window>

9 <window-name>ClientePortletWindow</window-name>

10 <instance-ref>ClientePortletInstance</instance-ref>

11 <region>center</region>

12 <height>0</height>

13 </window>

14 </page>

15 </deployment>

51

16 <deployment>17 <if-exists>overwrite</if-exists>18 <instance>19 <instance-name>ClientePortletInstance</instance-name>20 <component-ref>clienteportlet.ClientePortlet</component-ref>21 </instance>22 </deployment>23 </deployments>

Código 8: Arquivo cliente-object.xml, no qual descreve uma instância do portlet em umportal

Note que na tag <component-ref ../> em cliente-object.xml no Código

8, está relacionado respectivamente às tags <app-name ../> do XML de jboss-

app.xml (Código 7), e <portlet-name ../> do XML de portlet.xml (Código

9).

O portlet.xml é o arquivo que descreve o portlet, identificando a classe respon-

sável pelo tratamento de ações no portal, assim como os estados que possui (VIEW,

EDIT, HELP).

1 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"2 xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd3 /opt/SUNWps/dtd/portlet.xsd" version="1.0">4 <portlet>5 <portlet-name>ClientePortlet</portlet-name>6 <portlet-class>portalapp.portlet.ClientePortlet</portlet-class>7 <supports>8 <mime-type>text/html</mime-type>9 <portlet-mode>VIEW</portlet-mode>

10 <portlet-mode>EDIT</portlet-mode>11 <portlet-mode>HELP</portlet-mode>12 </supports>13 <portlet-info>14 <title>Cadastro de Clientes</title>15 </portlet-info>16 </portlet>

Código 9: Arquivo XML que descreve o portlet de acordo com o padrão JSR-168 (por-tlet.xml)

52

A organização dos arquivos gerados, entre eles arquivos binários, páginas web e os

XML´s está conforme a Figura 30.

Figura 30: Organização dos arquivos para geração do cliente-portlet.war

O arquivo WAR gerado deverá ser copiado para DIRETORIO_JBOSS_PORTAL/-

server/default/deploy, e bibliotecas ou JAR´s utilizados, deverá ser copiado para DI-

RETORIO_JBOSS_PORTAL/server/default/lib. No terminal de execução a informa-

ção a ser gerada é semelhante a Figura 31.

Figura 31: Log gerado ao adicionar o cliente-portlet.war

Finalizando, após o deploy da aplicação, é possível customizar pela administração

do portal (Figura 23), como por exemplo, adicionar páginas, portlets, definir layouts e

temas, níveis de acesso exigindo autenticação de usuário, etc. Na Figura 32 é demons-

trado o portal finalizado no JBoss Portal.

53

Figura 32: Visualização da integração no JBoss Portal

3.3 BEA WebLogic Portal

O BEA WebLogic Portal é um servidor de portal baseado em J2EE que facilita a

produção e o gerenciamento dos portais orientados a serviços. Seu framework, fornece

um acesso em um único ponto aos serviços e às informações que estão distribuídas

pela rede externa ou interna de uma empresa. O framework permite a unificação da

arquitetura pela utilização do SOA, ou seja, uma camada de serviços que pode ser

invocada por aplicações, diminuindo as dependências entre os sistemas.

O BEA WebLogic Portal é um produto da família WebLogic (http://www.bea.com),

que oferece uma infraestrutura de desenvolvimento, contendo um ambiente rico, como

ambiente gráfico para desenvolvimento de portais e um conjunto de ferramentas via

browser para especialistas de negócio.

A estrutura unificada do BEA WebLogic Portal pode reduzir o tempo total de cons-

trução de um portal. Em uma grande corporação, pode-se obter a flexibilidade de or-

ganizar sua própria arquitetura de modo que conduz o preço de um portal a um custo

mínimo de tempo,. Ainda o WebLogic Portal oferece um ciclo de vida de gerência de

conteúdo, ponta a ponta (end-to-end), deste modo, simplificando a produção e o geren-

ciamento do portal. Na Figura 33 é demonstrado o ciclo de vida de gerenciamento de

conteúdo do BEA WebLogic 8.1.

54

Figura 33: Ciclo de vida de gerenciamento de conteúdo no BEA WebLogic PortalFONTE: (BEA WEBLOGIC PORTAL, 2006a)

O ciclo de vida compõe-se em quatro fases:

• Architecture – durante esta fase é possível escolher o tipo de repositório de con-

teúdo a ser utilizado de acordo com a necessidade de negócio. Esta fase inclui

criação de tipos de conteúdo a ser armazenado, criação de workflows para refor-

çar o processo e criar pastas e diretórios para organizar o conteúdo.

• Develop – durante a fase, os desenvolvedores podem adicionar e desenvolver os

processos de negócio, os web services, os conteúdos do portal (portlets), criando

um template de um portal através de um ambiente gráfico, conforme ilustrado na

Figura 34.

• Assembly & Deploy– durante esta fase, através de uma ferramenta de adminis-

tração do portal, é possível criar áreas de trabalho (desktops) que são templates

desenvolvidos na fase anterior, customizando o seu conteúdo, layouts e temas.

• Manage – nesta fase é possível gerenciar usuários e grupos de acesso, atribuindo

regras de acesso. Esta fase é possível fornecer aos usuários a opção de customizar

e organizar o seu ambiente de trabalho de acordo com as suas necessidades. Na

Figura 35 é demonstrado a ferramenta administrativa do BEA WebLogic Portal.

A estrutura de um portal baseia-se em componentes individuais organizados hie-

rarquicamente. Esta estrutura possibilita o desenvolvimento de sistemas em módulos,

55

Figura 34: Ambiente de desenvolvimento do WorkshopFONTE: (BEA WEBLOGIC PORTAL, 2006c)

Figura 35: Visualização da ferramenta administrativa no WebLogic Portal.FONTE: (BEA WEBLOGIC PORTAL, 2006c)

56

o que é atrativo no desenvolvimento de um portal, tornando uma arquitetura flexível

e extensível. Na Figura 36 apresenta a hierarquia do portal da WebLogic.

Figura 36: Componentes individuais unificados em um portal.FONTE: (BEA WEBLOGIC PORTAL, 2006a)

3.3.1 Instalação e Configuração

Para a realização do download do BEA WebLogic Portal, é necessário cadastrar-

se, obtendo uma licença livre para desenvolvimento válida por um ano. A seguir os

passos para instalação e configuração do WebLogic Portal.

• Passo 1 – Faça o download do instalador da ferramenta que está disponível em

http://commerce.bea.com/showproduct.jsp?family=WLPORTAL&major=8.1&minor=0.

• Passo 2 - Instale o WebLogic Portal através do arquivo EXE.

• Passo 3 - Após a instalação é necessário configurar o servidor, o WebLogic Server

Domain, no qual é possível configurar o modo de iniciação do servidor, sendo

entre eles o modo de desenvolvimento ou de produção, e qual SDK (Software

Development Kit) a ser utilizado.

57

• Passo 4 – Inicie o servidor e para verificar se o BEA WebLogic Portal e o servi-

dor foi devidamente instalado, acesse o endereço http://localhost:7001/console,

devendo aparecer uma tela semelhante a Figura 37.

Figura 37: Sucesso na instalação do BEA WebLogic PortalFONTE: (BEA WEBLOGIC PORTAL, 2006b)

3.3.2 Reestruturação do Sistema

A reestruturação do sistema não se diferencia muito em relação à primeira ferra-

menta, veja na seção 3.2.2, p. 46. Devido ao suporte ao padrão de desenvolvimento do

portlet, o padrão JSR-168, pode-se aplicar a mesma arquitetura utilizada no desenvol-

vimento no JBoss Portal (Figura 27, p. 47).

Mas o BEA WebLogic Portal permite criar diferentes tipos de portlets, além do pa-

drão JSR-168, é possível criar portlets como JSP/HTML Portlet, Struts Portlet, Remote

Portlet e Java Page Flow Portlet. Em Cadastro de Clientes foi utilizada a implementação

do portlet por Page Flow, no qual na próxima seção será demonstrada a implementação

utilizada para criar o portlet.

3.3.3 Codificação

O controle do portlet de Cadastro de Clientes, foi atráves da classe ClientePage-

FlowController que herda de com.bea.wlw.netui.pageflow.PageFlowCon-

troller. Esta classe permite a navegação do portlet através de ações, como ilustrado

na Figura 38. Para cada ação possível no Cadastro de Clientes é um método a ser

implementado, Código 10.

Na Figura 38 é demonstrado que o arquivo list.jsp equivale a página de con-

sulta da aplicação e suas possíveis ações de consulta paginada. Em qualquer hipótese

58

Figura 38: Fluxo de página no Cadastro de Clientes

1 public class ClientePageFlowController extends PageFlowController {2 /**3 * @jpf:action4 * @jpf:forward name="success" path="list.jsp"5 * @jpf:forward name="error" path="error.jsp"6 */7 protected Forward consultarUltimaPagina(ConsultarFormCliente form){8 try {9 SearchPaginate lista = this.consultarForm.getListaClientes();

10 lista.setNumPagina(lista.getNumMaxPaginas());11 consultarForm.setListaClientes( new ClienteSearchAction(this.isRemoto).12 execute(consultarForm.getOpcaoConsulta(),13 consultarForm.getValorFiltroConsulta(),14 lista.getNumPagina(), 10));15 return new Forward("success");16 } catch (Exception e) {17 e.printStackTrace();18 return new Forward("error");19 }20 }

Código 10: Fonte do ClientePageFlowController

59

de erro ou exceção, o fluxo normal da página será direcionado para página que exibirá

o erro correspondente (error.jsp).

Após a codificação dos portlets, deve-se construir um template do portal, onde são

adicionados páginas de navegação (pages), em cada uma das páginas pode-se definir o

tipo de layout, que é o modo que serão organizados os portlets no ambiente de trabalho.

Na Figura 39 é ilustrado a construção do template do portal.

Figura 39: Construção do template.

Depois da construção do portal, pode-se personalizar o conteúdo, definindo temas

e/ou layouts, atribuindo regras de acesso. Na Figura 40 a visualização do portal no

BEA WebLogic Portal.

Na próxima seção será abordado a análise comparativa entre os dois frameworks

apresentados para o desenvolvimento para portais.

60

Figura 40: Resultado da integração no WebLogic Portal

3.4 Análise dos Frameworks

Este capítulo descreve a análise realizada nos frameworks de desenvolvimento de

portais, o BEA WebLogic Portal e o JBoss Portal, abordando os sequintes critérios como:

plataformas, requisitos e exigências para o desenvolvimento, depedências de servidor,

tipos e padrões de tecnologias disponíveis.

3.4.1 Requesitos Mínimos e Dependências do Servidor

Na ferramenta de desenvolvimendo de portais do JBoss, é utilizado o servidor

de aplicações da JBoss (JBoss AS). Em especial no JBoss Portal 2.4, utiliza a máquina

virtual Java 5 (JDK 1.5). No WebLogic Portal 8.1, utiliza o BEA WebLogic Server, que

pode ser executado em qualquer máquina virtual, sendo no máximo JDK 1.4 da Sun

ou BEA JRockit que vem juntamente com a ferramenta.

Os requisitos mínimos do sistema para o funcionamento no JBoss Portal 2.4 e no

BEA WebLogic Portal 8.1 estão descritos na Tabela 1.

JBoss Portal BEA WebLogic Portal512 MB RAM 1 GB RAM50 MB de HD 30 GB de HD400 MHz CPU 1.5 GHz CPU

Tabela 1: Requisitos mínimos de hardware

61

3.4.2 Plataformas de Desenvolvimento

Na construção do portal da JBoss, foi utilizado o Eclipse 3.1 com plugins extras

(Callisto, Web Tools Platform, entre outros. . . ) para desenvolvimento web, que possi-

bilita na criação de páginas web. Quanto ao portal da WebLogic, a própria ferramenta

disponibiliza um ambiente gráfico, o BEA WorkShop.

3.4.3 Requisitos Mínimos Para o Desenvolvedor

Em ambas ferramentas exige o mínimo de conhecimento em programação orien-

tada a objetos, em especial na linguagem Java. Além disso, exige conhecimento em

aplicações distribuídas, ou seja, saber desenvolver em aplicações J2EE e trabalhar com

páginas WEB (JSP, JSF, HTML, JavaScript, entre outras. . . ).

Para o desenvolvimento do portal em geral, exige que o desenvolvedor tenha co-

nhecimento da tecnologia de portais, das tecnologias a serem utilizadas como (portlets,

gadgets, webparts, entre outros).

Especificamente ao JBoss Portal, o desenvolvedor deve ter noções do funciona-

mento do servidor do JBoss AS, como configurações extras ou personalizadas do ser-

vidor, saber como e onde fazer deploy da aplicação, assim onde inserir API´s ou biblio-

tecas JARS extras para a execução da aplicação.

Quanto ao BEA WebLogic Portal, ter experiência com o servidor de aplicação do

BEA, em especial da família WebLogic, como configuração do SDK, ter noções de fun-

cionamento da máquina virtal Java do BEA, o JRockit. O desenvolvedor deve ter co-

nhecimento na ferramenta de desenvolvimento, o WorkShop da BEA, que é um ambi-

ente gráfico que possibilita a construção do portal, assim como a criação de portlets e a

implementação das regras de negócios, etc.

3.4.4 Tecnologias e Padrões Suportadas

Os dois frameworks de desenvolvimento suporta a tecnologia de portlets e seus pa-

drões JSR-168 e WSRP. Ainda, as duas ferramentas suportam frameworks Java para apli-

cações J2EE ou não, como Struts, Springs, Hibernate, JSF, EJB, JWS, entre outras.

62

4 Considerações Finais

No Estudo de Caso foi apresentado um problema de pequenos sistemas para rea-

lização de um comparativo entre as duas tecnologias, implementando a integração de

acordo com a arquitetura e características de cada um dos frameworks.

A decisão de escolher a ferramenta de desenvolvimento, pode ser implicada por

algumas variáveis do tipo: porte da empresa e dos sistemas utilizados relevando sua

complexidade e escabilidade, nível de robustez, estabilidade da ferramenta de desen-

volvimento, suporte, documentação, custo da integração para empresa e até mesmo o

custo da licença da ferramenta para desenvolvimento.

As duas ferramentas de desenvolvimento, o BEA WebLogic Portal e JBoss Portal,

possui características próprias podendo atender diferentes tipos de necessidade. A fer-

ramenta do JBoss Portal, pode atender as espectativas das empresas de pequena, mé-

dio e grande porte. Para os desenvolvedores, e indiretamente aos clientes do produto,

torna-se uma vantagem o uso desta ferramenta por ser software livre, que neste ramo,

cada vez mais tem se destacado entre outras open sources. Por outro lado, o BEA We-

bLogic Portal, pode oferecer uma arquitetura altamente adaptável, a qualquer tipo de

problema, o seu servidor suporta grandes processos, ideal para grandes companhias,

ainda de ser uma ferramenta que possui muita estabilidade no mercado.

4.1 Discussões

A integração dos sistemas utilizando a tecnologia de portais, torna-se muito atra-

ente devido principalmente ao rápido retorno do investimento aplicado na integração

dos sistemas. Uma vez conhecida a tecnologia de trabalho torna-se muito rápido a re-

estruturação da aplicação, podendo publicar os sistemas como serviço e consumindo-

os em um portal por uma interface Web.

Para os desenvolvedores, ter o conhecimento desta tecnologia, torna-se uma van-

63

tagem profissional, pois o mercado para atender as empresas que procuram soluções

de integração de sistemas tem-se alargado consideradamente.

Para as empresas, o uso de um portal na corporação alcançaram a integração de

vários sistemas, a organização de conteúdo, o acesso ao fluxo de documentos (workflow)

ou tarefas em grupos (groupware), a interatividade entre usuários, contribuindo com as

necessidades dos usuários e para tomada de decisões.

4.2 Conclusões

Conclui-se que este trabalho fornece uma larga variedade de informações sobre

a tecnologias de portais corporativos: conceito, caracterítiscas, tecnologias e padrões

oferecidos, assim como um comparativo entre dois frameworks para desenvolvimento

de portais, e como foi possível a integração de aplicações em um único ponto de acesso.

4.3 Trabalhos Futuros

Como trabalhos futuros, propõe-se:

• avaliar outros frameworks existes no mercado como por exemplo: IBM Web Sphere,

Sun One, JRUN, Liferay, Metadot, Pluto, Pentaho, GridSphere, Redhat Portal Ser-

ver, entre outros;

• fazer um estudo de uma solução de um portal de serviços, no qual utiliza-se

serviços remotos, ou seja, o uso da tecnologia WSRP (Web Services for Remote Por-

tlets);

• elaborar uma metodologia de avaliação para as ferramentas de desenvolvimento

de portais;

• desenvolver um portal com necessidades reais, podendo ser acessado atráves de

dispositivos móveis (PDA´s, celulares).

64

Referências

AKRAM, A. et al. A Service Oriented Architecture for Portals Using Portlets.Warrington WA4 4AD, UK, 2005.

AQUINO, F. Introdução às interfaces de portais corporativos. Intranet Portal -Primeiro site brasileiro focado em portais corporativos e gestão do conhecimento.Janeiro 2005. Disponível em: <http://www.intranetportal.com.br/interface/i_1>.Acesso em: 28 maio 2006.

BEA WEBLOGIC PORTAL. Documentation 8.1. [S.l.], 2006.

BEA WEBLOGIC PORTAL. User Manual 8.1. [S.l.], 2006.

BEA WEBLOGIC PORTAL. WebLogic Administration Portal Tutorial. [S.l.], 2006.

CASTLE, B. Introduction to Web Services for Remote Portlets. Abril 2005. Disponívelem: <http://www-128.ibm.com/developerworks/webservices/library/ws-wsrp/>.Acesso em: 2 jun. 2006.

CHAVES, L. G.; BARONI, R.; FERREIRA, M. Análise da integração de aplicações(EAI) no contexto de portais corporativos de médias e grandes empresas brasileiras.2004.

CHRISTENSEN, E. et al. Web Services Description Language 1.1. 2004. Disponívelem: <http://www.w3.org/TR/wsdl>. Acesso em: 20 maio 2006.

CONECTT. Por que adotar um framework na cons-trução de um portal. [S.l.], 2005. Disponível em:<http://www.conectt.com.br/objs/Noticias/editorial_news_abril2006.asp>.Acesso em: jun. 2006.

DATZ, T. What You Need to Know About Service-Oriented Architecture. 2005.

DETLOR, B. The corporate portal as information infrastructure: towards aframework for portal design. International Journal of Information Management, 2000.

DIAS, C. A. Portal corporativo: conceitos e características. Ci. Inf., Brasília, 2001.

ECKERSON, W. W. Business Portals: drivers, definitions, and rules. 1999.

ECKERSON, W. W. Plumtree blossoms: new version fullfills enterprise portalrequirements. 1999.

ECKERSON, W. W. Rules for Enterprise Portals. 1999.

65

ERL, T. T. Service-Oriented Architecture: a field guide to integrating XML and WebServices. 1. ed. New Jersey: Prentice Hall, 2004.

FERNANDEZ, F. H. Discussão de um modelo conceitual para enterprise applicationintegration - EAI. Dissertação (Mestrado) — Instituto de Computação da Unicamp,São Paulo, 2004.

FIRESTONE, J. M. Defining the Enterprise Information Portal. Jul. 1999. Disponívelem: <http://www.dkms.com/papers/eipdef.pdf>. Acesso em: 18 jun. 2006.

FRYE, C. Portal services to become key in SOA. 2005. Disponível em:<http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1145630,00.html>.Acesso em: 5 jun. 2006.

HUMMINGBIRD. Enterprise Information Portal Market - meet the needs of technologyand business. [S.l.], 2000.

JBOSS PORTAL. Documentation. [S.l.], 2006. Disponível em:<http://www.jboss.org/products/jbossportal>. Acesso em: out. 2006.

JBOSS PORTAL. Quick Start. [S.l.], 2006. Disponível em:<http://docs.jboss.com/jbportal/v2.4/quickstartuser/en/pdf/JBossPortalQuickStartforUsers.pdf>.Acesso em: out. 2006.

JBOSS PORTAL. Reference Manual. [S.l.], 2006. Disponí-vel em: <http://docs.jboss.com/jbportal/v2.4/reference-guide/en/pdf/JBossPortalreferenceGuide.pdf>. Acesso em: out. 2006.

JBOSS PORTAL. User Manual. [S.l.], 2006. Disponí-vel em: <http://docs.jboss.com/jbportal/v2.4/user-guide/en/pdf/JBossPortalUserGuide.pdf>. Acesso em: out. 2006.

LINTHICUM, D. S. Enterprise Application Integration. Canadá: Addison-WesleyInformation technology series, 2000.

MARQUES, J. A. Service Oriented Architecture (SOA) umatecnologia ou arquitectura? Lisboa, 2005. Disponível em:<http://capsi.dei.ist.utl.pt/actas/data/sessoes/4C.html>. Acesso em: 5 jun.2006.

MURRAY, G. The portal is the desktop. 1999.

NANDI, R. B. Estudo da arquitetura orientada a seviços para desenvolvimento desistemas. Monografia (Bacharelado em Ciência da Computação) — UniversidadeEstadual do Oeste do Paraná, Foz do Iguaçu, 2005.

NEDUNGADI, K. Tendências do Mercado Brasileiro de Portais Corporativos. Maio2005. Disponível em: <http://www.lumis.com.br/main.asp?View=95B0087D-7ACA-4EA9-8723-1954220F3E94&Team=&params=itemID={1A2FCC36-82BB-4004-A158-749062DC1FD9};&ServiceInstUID={9CFF571F-221E-43DF-B407-3C88ED9F8664}>.Acesso em: jun. 2006.

66

OASIS framework for web services implementation (FWSI) TC. Disponível em:<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=fwsi>. Acessoem: 10 jun. 2006.

OASIS UDDI specification TC. Disponível em: <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec>. Acesso em: 10jun. 2006.

OLIVEIRA, E. C. M. Tecnologia de Portais Java e a JSR 168. Outubro 2004. Disponível em:<http://www.linhadecodigo.com.br/artigos.asp?id_ac=494>. Acesso em: jun. 2006.

POTTS, S.; KOPACK, M. Aprenda em 24 Horas Web Services. 3. ed. Rio de Janeiro:Campus, 2003. Tradução de Marcus Vieira.

REYNOLDS, H.; KOULOPOULOS, T. Enterprise Knowledge Has aFace. Intelligence Enterprise, v. 2, n. 5, Mar. 1999. Disponível em:<http://www.intelligententerprise.com/db_area/archives/1999/993003/feat1.jhtml>.Acesso em: 12 jun. 2006.

RUBIO, D. Web Services, Portlets and WSRP. Outubro 2005. Disponível em:<http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1134722,00.html>.Acesso em: jun. 2006.

SHILAKES, C. C.; TYLMAN, J. Enterprise information portals. 1998.

SILVA, O. R. Tecnologia de Web Services aplicada à Computação Móvel. Monografia(Bacharelado em Ciência da Computação) — Pontifícia Universidade Católica, Rio deJaneiro, 2001.

SMITH, M. A. Portals: toward an application framework for interope-rability. ACM Portal, New York, v. 47, p. 93–97, 2004. Disponível em:<http://portal.acm.org/citation.cfm?id=1022594.1022600>. Acesso em: jun.2006.

SOA. Disponível em: <http://www.oasis-open.org/committees/tc_cat.php?cat=soa>. Acesso em: 10 jun. 2006.

SULLIVAN, D. Proven Portals: best practices for planning, designing, and developingenterprise portals. Boston: Addison Wesley, 2003.

TANENBAUM, A. S. Computers Networking. 4. ed. [S.l.]: Prentice Hall PTR, 2002.

TATNALL, A. Web portals: the new gateways to internet information and services.London: Idea Group Publishing, 2004.

TERRA, J. C. C.; GORDON, C. Portais Corporativos: a revolução na gestão doconhecimento. São Paulo: [s.n.], 2002.

THE DELPHI GROUP. Building Enterprise-Class E-Business Portals. [S.l.], 2000.

TOLEDO, A. M. Portais corporativos: uma ferramenta estratégica de apoio à gestão doconhecimento. Dissertação (Especialista em Sistemas de Negócios Integrados) — Escolade Engenharia da Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2002.

67

UDDI. Disponível em: <http://www.uddi.org/>. Acesso em: 10 jun. 2006.

WHITE, C. Decision Threshold: enterprise information portals. Disponível em:<http://www.intelligententerprise.com/db_area/archives/1999/991611/feat1.jhtml?_requestid=348104>.Acesso em: jun. 2006.

WHITE, C. Using Information Portals in the Enterprise. 1999. Disponível em:<http://www.dmreview.com/master.cfm?NavID=55&EdID=61>. Acesso em: 3 jun.2006.

WSRP. Disponível em: <http://looselycoupled.com/glossary/WSRP>. Acesso em:10 jun. 2006.

XIONG, W.; BAJWA, H.; MAURER, F. WIT: a framework for in-container testing ofweb-portal applications. Calgary, Alberta, Canada T2N 1N4.

YANG, X.; WANG, X. D.; ALLAN, R. Investigation of WSRP support in selectedopen-source portal frameworks. 2002.

ZUFFOLETTO, J. BEA WebLogic Server Bible. Nova York: EBOOK, 2002.

Monografia - Estudo e Avaliação Entre Dois Frameworks Para Desenvolvimento de Portais Corporativos

Documents

Transcript of Monografia - Estudo e Avaliação Entre Dois Frameworks Para Desenvolvimento de Portais Corporativos