Especificações Técnicas

Especificações Técnicas Suíte Integrada de Servidor de Aplicação para o ambiente de processamento central da Dataprev. Especificação Técnica Servidor de Aplicação 1/42

1. Objeto Aquisição de licenças de suíte integrada de servidor de aplicação, incluindo serviços de instalação, implantação, orientação técnica, capacitação inicial, com garantia de atualização de versões e suporte técnico remoto aos produtos contratados, em conformidade com as especificações técnicas e demais condições constantes do Edital e seus Anexos. 2. Contexto Os sistemas de informações a serem desenvolvidos para suporte tecnológico ao Novo Modelo de Gestão do INSS (NMG) deverão prover completa automação e integração dos processos de trabalho da organização previdenciária para operações predominantemente on-line e em tempo real, implementando as complexas e numerosas regras de negócio da Previdência Social e armazenando grandes volumes de dados que deverão ser disponibilizados tempestivamente para subsidiar decisões em todos os níveis da organização. A arquitetura de sistemas prevista no Plano Diretor de Tecnologia da Informação (PDTI) apresenta requisitos de integração não encontrados, em geral, em modelos federados de bases de dados e isso se deve à necessidade de controle mais rigoroso dos processos de trabalho baseados em fluxos de informações, como é o caso da Previdência Social. Esse tipo de arquitetura, aqui apresentada de modo genérico, pode ser observada na figura abaixo, extraída do PDTI e atualizada. Observa-se na figura a necessidade de aplicação de algumas tecnologias como ERP (Enterprise Resource Planning) referente ao grupo GRP; CRM (Customer Relationship Management); BI (Business Intelligence); e aplicações de colaboração, todos integrados aos sistemas de negócio. Alinhado com esta arquitetura de sistemas, este projeto engloba recursos para execução e monitoramento/gestão das aplicações Java com segurança, facilidades de integração de aplicações, recursos de disponibilidade, apresentadas de forma facilitada ao cliente por meio de Portal com recursos de Especificação Técnica Servidor de Aplicação 2/42

colaboração. O Relatório da 1ª Fase do Projeto 11 do PDTI de 2002, que tratou da questão SELEÇÃO DE TECNOLOGIA PARA OS AMBIENTES, indicou o padrão J2EE como tecnologia capaz de prover portabilidade as aplicações permitindo a independência de fornecedor e oferecendo maturidade suficiente para suportar aplicações de missão critica. Este projeto concretiza a teoria de independência de fornecedor para a camada de aplicação visto que se propõe a adquirir requisitos calcados em padrões e não uma determinada solução de mercado. O Projeto 16 (Portal Integrador de Interfaces de Sistemas) definido no Plano de Execução do PDTI de 2001 prevê a criação de um portal interno Web, que possibilite o acesso único a todas as funções dos sistemas da Previdência Social. Este projeto prevê a disponibilização de produto de software que viabiliza esta necessidade. Dentre as Diretrizes Tecnológicas do PDTI destacamos algumas de relevância ao contexto deste documento do grupo 3.2 - Arquitetura de Aplicações e Middleware: 13.Desenvolver arquitetura utilizando N-camadas. 15.Utilizar aplicações com integração por middleware. 16.Não utilizar o banco de dados como middleware para comunicação em aplicações. 17.Quando possível, desenvolver aplicações utilizando comunicação assíncrona. 18.Utilizar extensible Markup Language (XML) como padrão para a comunicação de dados estruturados entre programas e aplicações. 19.Projetar para gerenciamento. 23.Atualizar dados através de regras de negócio. Observando mais das Diretrizes Tecnológicas do PDTI destacamos outras de relevância ao contexto deste documento do grupo 3.6 - Computação Colaborativa: 71.Selecionar ferramentas de colaboração que implementem padrões de mercado. 76.Implementar aplicações de Workflow aderentes aos processos de negócio. 77.Definir as aplicações de Workflow baseando-se nos conceitos de regras, rotas e papéis. 78.Utilizar um gerenciador de Workflow para prover a infraestrutura de gerenciamento para as aplicações de Workflow. 3. Sistemas de Informação 3.1 Arquitetura de Sistemas A nova arquitetura de sistemas da Dataprev para suportar os processos da Previdência Social deverá ser orientada tanto a serviços como a eventos. De um modo bastante simples, pode-se dizer que as características "orientadas a serviços" dessa arquitetura deverão atender aos serviços operacionais enquanto as características "orientadas a eventos" deverão atender às necessidades de controle de processos e informações. Em suma, essa nova arquitetura deverá apresentar as seguintes características estruturantes e funcionais: a) Interoperabilidade e portabilidade que a torne pronta para evoluir junto com o próprio negócio, primando pela conectividade das aplicações no conjunto dos sistemas. Sistemas de colaboração, tais como mensageria, workflow, calendário e GED, serão onipresentes nesse novo ambiente tecnológico. Especificação Técnica Servidor de Aplicação 3/42

b) Adaptabilidade e facilidade para mudanças, conforme o ritmo de mudanças do negócio e do mundo circundante. c) Ênfase no monitoramento em tempo real, onde os controles estarão na integração de aplicativos e dados, principalmente nas entradas e saídas e na intercomunicação entre as camadas da arquitetura. d) Prioridade para o atendimento das estratégias do negócio. Isto significa que a arquitetura tecnológica deverá servir ao negócio e não o contrário. e) Composição estilo lego, significando que a arquitetura deverá ser integrada por componentes menores montados de modo inteligente e funcional, mas que poderão ser trocados sem muito esforço, quando necessário. O que deverá garantir essa composição inteligente são os estilos estruturais de processos de negócio e softwares, padrões e a granularidade dos seus objetos fundacionais, ou tijolos (bricks). f) Abertura para o resto do mundo, onde as palavras-chave são operar on-line, integrar tudo e falar uma linguagem comum com as demais entidades do ecossistema informacional. g) Incorporação dos princípios e das regras do negócio como seus próprios princípios, fundamentando as decisões de TIC nas decisões do negócio. h) Comportamento de parceria em relação aos gestores do negócio, procurando sempre demonstrar (e não simplesmente mostrar) e vender suas vantagens para os gestores, com visão da evolução do negócio. i) Seleção rigorosa dos parceiros responsáveis pela integração dos componentes da arquitetura e dos serviços. j) Construção incremental. k) Evolução contínua, sem paradas. 3.2 Camada de Acesso e Apresentação A arquitetura dos sistemas para suporte aos processos da Previdência Social prevê uma camada de acesso e apresentação de sistemas na Web que deverá se responsabilizar por todas as necessidades de processamento de dados originadas dos aproximadamente 52.000 (cinquenta e dois mil) potenciais usuários internos do MPS e do INSS na organização previdenciária. Também devem ser incluídos os clientes na Internet: cerca de 26 milhões de pessoas cadastradas como aposentadas, pensionistas e outras situações com percepção de benefícios; cerca de 29 milhões de organizações e pessoas cadastradas como contribuintes ao fisco previdenciário e mais de 3,3 milhões de empregadores sendo uma parcela destes com acesso a Internet. Os números relativos a pagamentos de benefícios também são dessa grandeza: em torno de 4 milhões de benefícios concedidos anualmente, além da manutenção de um estoque de mais de 23 milhões de benefícios continuados, relativos a aposentadorias e pensões. O levantamento estatístico mais abrangente sobre a quantidade de usuários de Internet no Brasil foi feito pelo suplemento do PNAD-Pesquisa Nacional de Amostras por Domicílio em 2005 (IBGE) que pesquisou 408 mil pessoas e 142,5 mil unidades domiciliares que apontou a existência de 32,1 milhões Especificação Técnica Servidor de Aplicação 4/42

de usuários de Internet em 2005 (21% da população de 10 anos ou mais de idade). A pesquisa realizada pelo Ibope indicou que o total de pessoas com mais de 16 anos com acesso à internet em qualquer ambiente (casa, trabalho, escolas, universidades e outros locais) era de 36,9 milhões em Jun/07. O Núcleo de Informação e Coordenação (NIC) do Comitê Gestor de Internet (CGI) (Indicadores sobre Internet no Brasil) realizou em 2005 e 2006 pesquisa com cerca de 10 mil entrevistas utilizando o mesmo critério do PNAD. A Pesquisa TIC Domicílios estimou que 24,4% da população com mais de 10 anos de idade acessou a Internet nos últimos 90 dias em 2005 e 27,8% em 2006. Este percentual implicaria em 43,5 milhões de usuários de Internet em 2006. A UIT estimou em 42,6 milhões a quantidade de usuários de Internet no Brasil em 2006. Com esses dados, ressalta-se a necessidade de componentes computacionais bastante escaláveis na web, sujeitos a todas as oscilações de demanda de acesso e riscos de segurança característicos desse tipo de ambiente de sistemas. E, também, "janelas" de processamento batch adequadas para a preparação de uma folha de pagamentos gigantesca, acessando uma enorme massa de dados para sua execução. Outra informação importante é que os acessos aos sistemas da Previdência Social têm uma natural tendência a apresentar dois ou mais "picos" mensais, de acordo com datas preestabelecidas que se reportam a eventos típicos do negócio (principalmente datas de pagamento de benefícios e de recolhimento de contribuições). Espera-se, com essa solução, que quaisquer falhas computacionais dessa camada de sistemas possam ser prontamente superadas mediante o acionamento dos recursos de contingência, de modo inteiramente transparente e com um mínimo de transtorno para os usuários dos sistemas. Essa camada de apresentação deverá atender tanto à demanda de conexões dos sistemas transacionais (OLTP) como dos sistemas gerenciais (OLAP/BI), a partir de uma aplicação de Web Portal a ser adquirida. Os novos sistemas deverão ser desenvolvidos com linguagem Java, no padrão JEE, devendo ser processados nesse ambiente protocolos típicos de páginas Web estáticas, desenvolvidas em HTML (Hyper Text Markup Language), como HTTP (Hyper Text Transfer Protocol), e dinâmicas, como JSP (Java Server Pages). 3.3 Camada de Aplicação A camada de aplicações dos sistemas deverá processar código padrão JEE com as regras de negócio da Previdência Social, cuja portabilidade, fator decisivo para sua escolha, permitirá independência de plataforma tecnológica e a portabilidade. Os projetistas de infraestrutura computacional deverão, portanto, prestar a devida atenção para algumas questões típicas de processamento com Java, especialmente quando integrados a bancos de dados relacionais: a) consumo acentuado de memória de servidores devido ao processamento paralelo dos "coletores de lixo" (garbage colectors) para limpeza periódica de objetos persistidos em memória; b) necessidade de nós (equipamentos servidores) adequados ao empacotamento de aplicativos, visando-se uma otimização do desempenho da conectividade entre objetos mais acessados e entre objetos que operam em colaboração síncrona muito intensiva (exemplo: classes de acesso a bancos de dados e classes de geração de registros para auditoria); c) necessidade de alocação adequada de recursos computacionais para o processamento de aplicativos de mapeamento objeto-relacional; d) necessidade de alocação adequada de recursos computacionais para o processamento de componentes de serviço do tipo WebServices que podem ser consumidos por aplicações Especificação Técnica Servidor de Aplicação 5/42

hospedadas fora da Dataprev. 3.3.1 Camada de serviços Além do servidor de aplicação responsável pela execução da lógica de negócio e apresentação das novas aplicações, outros serviços agregam funcionalidade a este ambiente, provendo uma série de facilidades que tornam o desenho dos sistemas mais simples e gerenciáveis. Dentre eles temos o de Portal, barramento de serviços, gerenciador de filas, BPM e monitoração. A inclusão destes itens neste edital tem como objetivo prover a Previdência Social com um ambiente integrado e otimizado, permitindo reduzir os custos de infraestrutura e operação, além de prover as equipes de desenvolvimento de facilidades que reduzam a complexidade e o custo de desenvolvimento dos sistemas. A ferramenta de Portal permite disponibilizar a lógica das aplicações através de uma visão integrada e flexível, com facilidades como personalização. A existência de funcionalidades como gestão de formulários e pesquisa permitem disponibilizar rapidamente aplicações e regras de negócio que de outra forma teriam que ser desenvolvidas programaticamente, com um consequente aumento nos custos e prazos dos Projetos. O gerenciador de filas e barramento de serviços são facilidades que permitem integrar subsistemas de forma otimizada, reduzindo o acoplamento entre as partes e melhorando o gerenciamento. Algumas soluções de integração, sobretudo no novo sistema de Benefícios, utilizam mecanismos customizados para comunicação assíncrona entre diferentes módulos. A utilização de um gerenciador de filas e a API JMS permite padronizar este mecanismo de integração com a solução nativa da plataforma Java EE, reduzindo a quantidade de código customizado nas aplicações com uma consequente redução do custo de manutenção. O barramento de serviços introduz uma série de facilidades que vão além do gerenciador de filas, permitindo a racionalização das dependências entre os componentes de negócios em uma arquitetura distribuída. Além do enfileiramento de mensagens o barramento de serviço provê funcionalidades como roteamento, transformação e agregação de mensagens. Isto permite integrar componentes distribuídos com maior flexibilidade e com menos necessidade de adaptadores. Uma das principais vantagens na utilização do barramento é a facilidade de gestão tanto no que diz respeito a indisponibilidade de um determinado serviço quanto na monitoração do desempenho, permitindo um efetivo gerenciamento dos níveis de serviço. A ferramenta de BPM disponibiliza uma série de recursos que permitem uma efetiva análise e controle com uma consequente otimização dos processos de negócio. A partir do ciclo de projeto, monitoração, análise e otimização dos processo de negócio é possível implementar a melhoria contínua dos processos de negócio e a otimização dos sistemas. As facilidades propostas na camada de serviços tem como objetivo prover os desenvolvedores com recursos que facilitem a construção de sistemas com o aumento de desempenho e qualidade dos mesmos, considerando que soluções padronizadas e testadas serão utilizadas em detrimento de soluções pontuais. Para as equipes de infraestrutura estas ferramentas permitirão uma efetiva monitoração dos processos e sistemas, otimizando o uso dos recursos e a garantia dos níveis de serviço. 3.4 Camada de Dados O volume de dados corporativo dos sistemas atuais ocupam em Agosto/2010 aproximadamente 20 TB, prevendo-se que esse volume poderá aumentar com a evolução dos modelos de dados dos sistemas do NMG e da migração para bases de dados relacionais. A previsão inicial é que se atinja aproximadamente 700 TB em 5 anos. Outro aspecto importante a ser considerado é que o Modelo Especificação Técnica Servidor de Aplicação 6/42

Lógico de Dados apresenta uma concepção de integração no sentido de se evitar redundâncias e melhorar a qualidade dos dados da Previdência Social. Isso significa que, quando não comprometer o desempenho, deve-se evitar distribuição de bases de dados com redundâncias, preferindo-se bases mais consolidadas e centralizadas. 3.5 Infraestrutura A nova infraestrutura tecnológica da Previdência Social deverá implementar em dois sites, um primário destinado ao ambiente de produção e outro secundário para contingência (standby), uma arquitetura de processamento em três camadas, divididas em: camada de apresentação, camada de aplicação, camada de serviços e camada de banco de dados. Em caso de falha de um destes dois ambientes, o outro deve estar pronto para assumir as responsabilidades do primeiro de forma transparente para as aplicações. Os novos ambientes de processamento central apresentados possuirão as seguintes características mais relevantes: Os ambientes de desenvolvimento, homologação (de requisitos funcionais), testes (de requisitos não funcionais), treinamento e produção serão implementados de forma segregada evitando interferências entre os processos produtivos do ciclo de desenvolvimento. O ambiente de processamento central deve ser dotado de recursos de alta disponibilidade, escalabilidade, portabilidade e de recursos failover (ou de recuperação de falhas) para processamento centralizado dos sistemas transacionais, gerenciais e de colaboração. As camadas de processamento (apresentação, aplicação e serviços) serão atendidas por um pool de servidores padrão CISC (ou similar), de 64 bits (arquitetura computacional IA-64), com todos os produtos de software agregados para operações de servidores Web (Web servers). O pool de servidores secundário, tem as mesmas características do pool principal, com recurso de contingência, em outro Data Center disponível na Dataprev. Este ambiente poderá utilizar recursos de virtualização visando uma melhor consolidação e aproveitamento dos recursos. 3.6 Arquitetura da suíte integrada de aplicação A suíte integrada de aplicação está alinhada a arquitetura de sistemas e a arquitetura de desenvolvimento de aplicações Java. Para atender a todos os requisitos é necessário que a suíte de aplicação seja composta por elementos (produtos e tecnologias) que funcionem de forma integrada, segura e coordenada. Desta forma a suíte integrada se define por meio dos componentes conforme apresentado na figura abaixo. Especificação Técnica Servidor de Aplicação 7/42

Obs: A organização das funcionalidades nesta figura é meramente ilustrativa, não representa a forma como os produtos ofertados serão instalados fisicamente, nem demonstra a comunicação entre os elementos. Fazendo um paralelo com a Arquitetura de sistemas apresentada acima, as caixas HTTP e cache representam a Camada de Apresentação. A caixa Servidor de Aplicação Java representa a Camada de aplicação. As demais caixas fazem parte da Camada de serviços. Detalhando a Camada de serviços : a caixa SSO controla o ponto único de controle de acesso ao Portal na Intranet. O barramento de serviços e o gerenciador de filas proveem a integração entre as aplicações. A caixa Autoria de Conteúdo é o local de desenvolvimento das páginas/conteúdo do Portal (Internet e Intranet). BPM executa o motor que controla os processos de negócio. E a caixa gerência e monitoração contém todos os elementos de monitoração e suporte de todos os elementos da arquitetura. 3.7 Recursos de Hardware O conjunto de equipamentos onde se pretende instalar a suíte é composto por máquinas virtuais ou físicas baseadas em tecnologia CISC para, a princípio, executar a lógica de negócio das aplicações e outros serviços que exijam um maior poder de processamento como o de portal. E outro conjunto de equipamentos também CISC para, a princípio, executar a camada de apresentação (HTTP, cache e monitoração/administração) com menor poder de processamento. Embora o planejamento atual aponte para o uso de equipamentos CISC, espera-se que esta solução seja capaz de ser hospedada, toda ou parte da solução, em servidores com arquitetura RISC e EPIC também. Especificação Técnica Servidor de Aplicação 8/42

4. Requisitos Básicos 4.1 Deverão ser informados todos os componentes de software que compõem a solução ofertada, com o respectivo quantitativo e custo unitário. 4.2 Todos o(s) produto(s) ofertado(s) deverão ser de um único fabricante. 4.3 Todos os produtos de software necessários ofertados deverão ser suportados pelo fabricante durante toda a vigência do contrato. As licenças são de uso perpétuo, sendo o prazo de 36 meses referente ao período de suporte e manutenção oferecido pelo fornecedor e/ou fabricante. A Dataprev se reserva o direito de fazer uso das licenças adquiridas em qualquer arquitetura de processador existente em seu parque tecnológico, levando em consideração a prática de licenciamento adotada pelo fornecedor. É de responsabilidade do fornecedor informar qual a prática de licenciamento adotado para cada arquitetura de processador comercializado. 4.4 A solução deve disponibilizar os manuais técnicos do software, editados em língua inglesa ou língua portuguesa (Brasil). 4.5 A solução deve disponibilizar manuais técnicos do software, on-line em formato PDF de modo que os mesmos sejam livremente distribuídos dentro da empresa. 4.6 A solução deve suportar os idiomas português e inglês. 4.7 Deverá ser fornecido 1 conjunto de mídias (CD ou DVD) e documentação (incluindo manual de operação) para cada componente de software da solução ofertada. 4.8 O conjunto de mídias deverá conter, no mínimo, as versões correspondentes aos ambientes operacionais indicados no subitem relativo a Recursos de Hardware. 4.9 Correrá por conta da contratada toda e qualquer despesa, independente da sua natureza, decorrente dos serviços de entrega / instalação da solução ofertada. 4.10 O licitante deverá informar para cada item dos requisitos constantes desta especificação técnica, os itens e respectivas páginas de sua proposta técnica que comprovem o atendimento de cada requisito. 4.11 A solução deve ser suportada e homologada pelo fabricante para executar em ambiente virtualizado com VMWare Server ESX 4.0 ou superior. 4.12 O proponente deverá ser representante ou revendedor autorizado a sublicenciar o(s) produto (s) ofertado(s) em sua proposta. A comprovação deverá ser feita por meio de declaração do detentor da propriedade do(s) produto(s). Especificação Técnica Servidor de Aplicação 9/42

ESPECIFICAÇÃO TÉCNICA 1 Servidor de Aplicação JEE 1.1 Padrões 1.1.1 Suporte completo ao padrão JEE 5 e suporte retroativo a J2EE 1.4 1.1.2 JSE 6 e suporte a versões anteriores 1.1.3 JSR 116, SIP Servlets 1.1.4 JSR 168 e 286, Portlets 1.1.5 WSRP 1.0 e 2.0 1.1.6 SAAJ versão 1.2 e 1.3 1.1.7 WS-Security versão 1.0 1.1.8 WS-I Basic Profile versão 1.1 1.1.9 WS-I Attachment Profile versão 1.0 1.1.10 JAX-R versão 1.0 1.1.11 WS-Addressing 1.1.12 JSR-127 e JSR-252 (JSF 1.0, JSF 1.1 e JSF 1.2) 1.1.13 JSR-224 (JAX-WS 2.0) 1.1.14 MTOM 1.0 1.2 A solução deve ser compatível com os seguintes Sistemas Operacionais: 1.2.1 Red Hat Enterprise Linux Advanced Server 4.0; 1.2.2 Red Hat Enterprise Linux Advanced Server 5.0 ou superior; 1.2.3 SUSE Linux Enterprise Server p/ Intel (x86) 9 ou superiores; 1.2.4 IBM AIX 5.3; 1.2.5 IBM AIX 6.1 ou superior; 1.2.6 HP-UX 11i V2; 1.2.7 HP-UX 11i V3 ou superior; 1.3 Administração 1.3.1 Interface de Administração 1.3.1.1 Permitir que várias instâncias de servidores em execução espalhados em vários nós possam ser administrados a partir de um ponto central, mesmo estando estes nós em ambientes operacionais heterogêneos. 1.3.1.2 Possuir interface web para administrar o servidor de aplicação que não exija a instalação de nenhum software adicional além de um browser comum. 1.3.1.3 Possuir compatibilidade com Mozilla Firefox e Microsoft Internet Explorer. Especificação Técnica Servidor de Aplicação 10/42

1.3.1.4 Permitir via interface gráfica iniciar, parar e reiniciar o servidor de aplicação. 1.3.1.5 Permitir via interface gráfica iniciar e parar aplicações do servidor de aplicação. 1.3.1.6 Permitir via interface web instalar, configurar e remover aplicações do servidor de aplicação. 1.3.1.7 Permitir a implantação (deploy) ou atualização de aplicações sem a necessidade de reiniciar o servidor de aplicações. 1.3.1.8 Permitir adicionar, atualizar ou remover partes da aplicação. 1.3.1.9 Possuir interface web para administrar o cluster do servidor de aplicação. 1.3.1.10 Permitir via interface gráfica iniciar, parar e reiniciar os servidores de aplicação de um cluster. 1.3.1.11 Permitir via interface web a instalação, configuração e remoção de servidor de aplicação no cluster. 1.3.1.12 Permitir via interface web a visualização e configuração dos arquivos de metadados das aplicações J2EE (application.xml, web.xml, ejb-jar.xml, rar.xml). 1.3.1.13 Permitir via interface web a visualização e configuração de Data Sources. 1.3.1.14 Permitir via interface web a visualização e configuração de Filas JMS. 1.3.1.15 Permitir via interface web a visualização e configuração de Adaptadores JCA. 1.3.1.16 Permitir via interface web a visualização e configuração de Login Modules. 1.3.1.17 Permitir via interface web a visualização e configuração de bibliotecas compartilhadas. 1.3.1.18 Permitir via interface web a visualização dos parâmetros de inicialização da Máquina Virtual Java. 1.3.1.19 Possuir browser JNDI. 1.3.1.20 Possuir browser JMX. 1.3.1.21 Permitir que a autenticação dos usuários da interface de administração web seja feita contra um diretório padrão LDAP v3. 1.3.1.22 Permitir que a autorização dos usuários da interface de administração web seja feita contra um diretório padrão LDAP v3. 1.3.1.23 Permitir configurar o acesso com base em perfil de usuário. 1.3.1.24 Permitir diferenciar o escopo de atuação de administradores com o mesmo perfil. 1.3.1.25 Permitir via interface web a visualização, consulta e configuração dos arquivos de log. 1.3.1.26 Permitir a convivência de mais de uma versão da mesma aplicação no mesmo servidor de aplicação. 1.3.2 Construção de Scripts de Administração 1.3.2.1 Possuir interface de administração via CLI (Command Line Interface). 1.3.2.2 Permitir que a interface de administração via linha de comando controle remotamente vários servidores de aplicação. 1.3.2.3 Permitir instalar, configurar e remover aplicações do servidor de aplicação por Especificação Técnica Servidor de Aplicação 11/42

meio de tasks Ant. 1.3.2.4 Permitir acesso as funcionalidades de administração via JMX. 1.3.2.5 Permitir a construção de scripts de administração customizados via linguagens de script como Jython ou Groovy ou Shell script. 1.3.3 Arquivos de Log 1.3.3.1 Possuir mecanismo para rotacionar os logs do servidor de aplicação. 1.3.3.2 Permitir que os logs do servidor de aplicação sejam rotacionados por tempo. 1.3.3.3 Permitir que os logs do servidor de aplicação sejam rotacionados por tamanho dos arquivos. 1.3.3.4 Possuir mecanismo para consolidar o log de vários servidores de aplicação. 1.3.3.5 Permitir que os logs do servidor de aplicação sejam gerados em formato xml. 1.3.3.6 Permitir o rastreamento de erros a partir do correlacionamento dos arquivos de log, caso o servidor de aplicação grave informações de log em arquivos separados. 1.4 Desempenho e Disponibilidade 1.4.1 Desempenho 1.4.1.1 Gerenciar clusters dinâmicos, ou seja, alocar servidores para aplicações com base em uma política de serviços definidos previamente. 1.4.1.2 Permitir a análise do desempenho de aplicações J2EE em ambientes clusterizados e distribuídos de servidores de aplicação, automaticamente detectando todos os servidores de aplicação em execução em múltiplas máquinas virtuais Java (JVM) dentro do ambiente definido. 1.4.1.3 Alocar e realocar servidores para determinadas aplicações visando garantir um nível de serviço determinado. 1.4.1.4 Controlar a ordem em que as requisições serão feitas para a camada do servidor de aplicações e, usando uma classificação predefinida para cada serviço, decidir como e quando despachará a requisição HTTP para a próxima camada. 1.4.2 Balanceamento de Carga 1.4.2.1 Possuir mecanismo para controlar o balanceamento de carga entre o browser e o servidor HTTP. 1.4.2.2 Permitir que o mecanismo de balanceamento de carga entre o browser e o servidor HTTP detecte a falha dos servidores HTTP e redistribua a carga de trabalho. 1.4.2.3 Permitir que o mecanismo de balanceamento de carga entre o browser e o servidor HTTP seja capaz de distribuir a carga de trabalho segundo a capacidade de conexão do servidor HTTP. 1.4.2.4 Permitir que o mecanismo de balanceamento de carga entre o browser e o servidor HTTP seja capaz de distribuir a carga de trabalho conforme URL. 1.4.2.5 Permitir que o mecanismo de balanceamento de carga entre o browser e o servidor HTTP seja capaz de distribuir a carga de trabalho conforme expressão regular. 1.4.2.6 Permitir que o mecanismo de balanceamento de carga entre o browser e o Especificação Técnica Servidor de Aplicação 12/42

servidor HTTP mantenha afinidade entre a sessão do browser e o servidor HTTP. 1.4.2.7 Possuir mecanismo para controlar o balanceamento de carga entre o servidor HTTP e o servidor de aplicações. 1.4.2.8 Permitir que o mecanismo de balanceamento de carga entre o servidor HTTP e o servidor de aplicação detecte a indisponibilidade dos servidores de aplicação e redistribua a carga de trabalho. 1.4.2.9 Permitir que mecanismo de balanceamento de carga entre o servidor HTTP e o servidor de aplicações distribua a carga de trabalho de forma aleatória. 1.4.2.10 Permitir que mecanismo de balanceamento de carga entre o servidor HTTP e o servidor de aplicações distribua a carga de trabalho de forma igualitária. 1.4.2.11 Permitir que mecanismo de balanceamento de carga entre o servidor HTTP e o servidor de aplicação distribua a carga de trabalho conforme métricas coletadas do sistema operacional e servidores de aplicação. 1.4.2.12 Permitir que o mecanismo de balanceamento de carga entre o servidor HTTP e o servidor de aplicação mantenha afinidade de sessão entre o browser e o servidor de aplicação. 1.4.2.13 Possuir mecanismo para balanceamento de carga entre os clientes Java através de RMI sobre IIOP e os servidores de aplicação. 1.4.2.14 Possuir mecanismo para alta disponibilidade do serviço JMS do servidor de aplicação. 1.4.2.15 Possuir mecanismo para controlar dinamicamente o número de instâncias do servidor de aplicação conforme carga de trabalho. 1.4.3 Alta Disponibilidade 1.4.3.1 Permitir a formação de cluster com instâncias instaladas em plataformas de hardware (Sistema operacional e hardware) heterogêneos. 1.4.3.2 Possuir mecanismo para reinicialização automática dos componentes do servidor de aplicação em caso de morte ou inatividade. 1.4.3.3 Possuir mecanismo para propagar e sincronizar alterações entre os servidores de aplicação clusterizados. 1.4.3.4 Possuir mecanismo para replicar o estado das sessões HTTP entre os servidores de aplicação clusterizados. 1.4.3.5 Possuir mecanismo para replicar o estado dos Enterprise Java Beans entre os servidores de aplicação clusterizados. 1.4.3.6 Possuir mecanismo para replicar o estado da árvore JNDI entre os servidores de aplicação clusterizados. 1.4.3.7 Permitir que a replicação de estado seja disparada ao final de cada requisição. 1.4.3.8 Permitir que a replicação de estado seja disparada quando um atributo do objeto de sessão for alterado. 1.4.3.9 Permitir o atendimento da requisição do usuário por outra JVM numa eventual falha da JVM que estava atendendo, garantindo o estado. 1.4.3.10 Permitir que o mecanismo de replicação de estado dos objetos utilize o protocolo IP Multicast para sincronização dos servidores de aplicação. Especificação Técnica Servidor de Aplicação 13/42

1.4.4 Virtualização de Aplicações 1.4.4.1 Ser capaz de priorizar ou rotear requisições entres os servidores de aplicações, de forma inteligente, de acordo com classificadores das aplicações J2EE e políticas de níveis de serviço pré-definidas. 1.4.4.2 Ser capaz de dinamicamente alocar ou desalocar servidor de aplicações J2EE em um cluster para atender níveis de serviço previamente definidos, garantindo disponibilidade e performance das aplicações. 1.4.4.3 Ser capaz de virtualizar as aplicações J2EE definindo dinamicamente qual o servidor mais apto para executá-la de acordo com níveis de serviço pré-definidos. 1.4.4.4 Ser capaz de proativamente detectar problemas no servidor de aplicações (notificando os administradores no formato de alertas), executando automaticamente ações corretivas minimizando custos administrativos e prevenindo a indisponibilidade das aplicações. 1.4.4.5 Ser capaz de instalar novas versões das aplicações J2EE sem precisar interrompê-las, de forma atômica ou parcial, garantindo sua disponibilidade. 1.4.4.6 Ser capaz de manter diversas versões de uma mesma aplicação J2EE e gerenciar qual versão deve estar em execução, trocando de versões sem precisar interromper as aplicações J2EE, garantindo sua disponibilidade. 1.5 Cache 1.5.1 Possuir cache de conteúdo estático e dinâmico compatível com o padrão ESI (Edge Side Includes). 1.5.2 Permitir que o cache de conteúdo estático e dinâmico seja configurado como um proxy reverso localizado a frente dos servidores HTTP. 1.5.3 Possuir mecanismo para invalidação do cache de conteúdo estático e dinâmico. 1.5.4 Possuir mecanismo de compressão do cache de conteúdo estático e dinâmico. 1.5.5 Permitir a construção de CDN (Content Delivery Network) através da distribuição hierárquica dos mecanismos de cache. 1.5.6 Possuir mecanismo de cache de Web Services. 1.5.7 Suportar mecanismo de cache de JPA de segundo nível. 1.6 Cache de dados e objetos em memória 1.6.1 Solução deve prover funcionalidades de cache distribuído de objetos em memória principal. 1.6.2 Suporte nativo a cache de objetos para as seguintes linguagens: 1.6.2.1 Java 1.6.2.2 C++ 1.6.2.3.NET 1.6.3 Fornecer API's de desenvolvimento em Java, C++ e.net. 1.6.4 Possuir suporte a particionamento dinâmico dos objetos em memória com adição de novos nós no cluster. 1.6.5 Possuir suporte a replicação dinâmicos dos objetos em memória com adição de novos nós no cluster. Especificação Técnica Servidor de Aplicação 14/42

1.6.6 Possuir suporte aos seguintes frameworks de persistência para cache de objetos segundo nível: 1.6.6.1 Hibernate 1.6.7 JPA 1.6.8 Possuir suporte a processamento em paralelo, através do mecanismo de pesquisa em paralelo. 1.6.9 Possuir interface de gerenciamento baseada em JMX para os caches de objetos. 1.6.10 Possuir ferramental de gerenciamento para os caches de objetos. 1.6.11 Possuir suporte a gerenciamento e replicação de sessão HTTP para aplicações J2EE. 1.6.12 Possuir suporte ao protocolo TCMP ou oferecer suporte a gerenciamento autônomo do cluster utilizando protocolo Multicast suportando: descoberta de novos membros, detecção de falha, distribuição automática de objetos e partições de objetos dentro do cluster, sincronização e replicação de dados entre os membros do cluster. 1.6.13 Possuir suporte a compartilhar o cache dos objetos em diversos servidores, sejam físicos ou virtuais. 1.6.14 Possuir suporte a adicionar ou remover membros do cluster automaticamente, sem parada dos serviços. 1.7 Outras Características 1.7.1 Fornecer um mecanismo de integração para o Apache HTTP Server e o Microsoft IIS. 1.7.2 Recuperação de Desastres (Disaster Recovery) 1.7.2.1 Possuir mecanismo para implementar rotinas de backup dos servidores de aplicação. 1.7.2.2 Possuir mecanismo para clonar servidores de aplicação. 2 Portal 2.1 Requisitos Básicos 2.1.1 O portal server deve ser uma aplicação JEE 5 (desenvolvida ou suportada), Web Based e totalmente baseada em padrões abertos de mercado. 2.1.2 O serviço de portal deve executar na mesma solução de servidor de aplicação ofertada no item 1 desta especificação. 2.1.3 A solução de Portal deve ser escalável a no mínimo 52.000 usuários para a Intranet e 32 milhões de usuários na Internet. 2.1.4 Suportar arquitetura de alta disponibilidade em todas as camadas da solução, através de clusters ativo-ativo. 2.1.5 Suportar escalabilidade horizontal em todas as camadas com a adição de servidores às diferentes camadas da solução de modo a suportar maiores níveis de carga no sistema. 2.1.6 Suportar instalação em ambiente de hosting - Federação de Portais onde uma única infraestrutura pode ser utilizada para criação de múltiplos Portais, cada um com configurações, conteúdo, usuários e grupos próprios. Especificação Técnica Servidor de Aplicação 15/42

2.1.7 Ser totalmente baseado em ambiente Web, sem necessidade de instalação de plugins para visualização das páginas ou administração do Portal. 2.1.8 Possuir mecanismos de exportação e importação de objetos do Portal para migração entre diferentes ambientes (ex.: desenvolvimento, homologação, produção). 2.1.9 Permitir o uso de Java Tag Libraries em Portlets. 2.1.10 Permitir a criação e manutenção automatizada de usuários a partir de catálogo de diretórios central, com respectivos direitos de acesso. 2.1.11 A solução deve suportar alta disponibilidade (Clusterização e Backup Failover com balanceamento de carga), permitindo o uso das características de escalabilidade e tolerância a falha. 2.1.12 A solução deve ser capaz de autenticar usuários utilizando a tecnologia de certificado digital X509 v3. 2.1.13 A solução deve ser compatível com os seguintes Sistemas Operacionais: 2.1.13.1 Red Hat Enterprise Linux Advanced Server 4.0 ou superior; 2.1.13.2 SUSE Linux Enterprise Server p/ Intel (x86) 9 ou superior; 2.1.13.3 IBM AIX 5L; 2.1.13.4 HP-UX 11i V3 ou superior; 2.1.14 A solução deve suportar os seguintes sistemas de Bancos de Dados: 2.1.11.1 Oracle Database Enterprise Edition 9i Release 2 ou superior 2.1.11.2 SQL Server Enterprise Edition 2005 2.1.15 A solução deve ser capaz de integrar com os seguintes Diretórios de usuários, aderentes a especificação LDAP v3: 2.1.15.1 Microsoft Windows Active Directory 2003 e superior; 2.1.15.2 IBM Tivoli Directory Server 6.0 ou superior 2.1.15.3 IBM Lotus Domino Enterprise Server 2.1.15.4 Novell e-directory 8.7 ou superior 2.1.15.5 Sun Java Directory Server 5.2 2.1.16 A solução deve ser capaz de executar com os seguintes Servidores Web: 2.1.16.1 Apache Server 2.1.16.2 Microsoft Internet Information Server 6.0 ou superior 2.1.17 A solução deve suportar os seguintes navegadores Web (Browser) 2.1.17.1 Microsoft Internet Explorer 7 ou superior 2.1.17.2 Firefox 3 ou superior 2.1.17.3 Safari 3 ou superior 2.2 Padrões 2.2.1 Suporte a especificação Content Repository for Java API - JSR 170. 2.2.2 Suporte a especificação JSF 1.2 ou superior. 2.2.3 A solução deve possibilitar o uso de framework Struts 1.1 na construção de portlets, Especificação Técnica Servidor de Aplicação 16/42

inclusive para portlets compatíveis com a JSR-168. 2.2.4 A solução deve suportar o padrão OASIS WSRP 1.0 e 2.0 (Web Services for Remote Portlets). 2.3 Acessibilidade e Virtualização 2.3.1 Suportar o conceito de Portal Virtual permitindo reaproveitar a mesma estrutura de Portal para apresentação de diferentes conteúdos para diferentes grupos de usuários. 2.3.2 Permitir disponibilizar a construção de portais e sub-portais/sub-sites por meio da própria ferramenta, visualmente e sem necessidade de codificação. 2.3.3 Fornecer URLs amigáveis aos usuários para que eles possam acessar seus portais virtuais e páginas. 2.3.4 Fornecer funcionalidades que viabilizem a criação de sites aderentes pelo menos ao nível de acessibilidade de prioridade 1 do Modelo de Acessibilidade apresentado nas recomendações de acessibilidade para a construção e adaptação de conteúdo do Governo Brasileiro (e-mag/governo Eletrônico). 2.4 Personalização 2.4.1 Possibilidade de criação de regras de personalização para definir a apresentação e conteúdo baseado em informações do usuário. 2.4.2 Restrição de acesso a páginas e portlets do portal conforme o papel do usuário (direito de acesso). 2.4.3 Mecanismo de personalização de usuários. Se o usuário se auto-cadastrar, as características coletadas serão persistidas em seu perfil. 2.4.4 Mecanismo de personalização da apresentação do portal pelo próprio usuário, permitindo configurar elementos como cores, fontes, imagens, disposição de portlets conforme autorizado pelo administrador do ambiente. 2.4.5 Possibilitar a personalização dos padrões visuais para cada portlet (borda, título) em uma página. 2.4.6 Possibilitar a criação de estruturas de navegação hierárquicas como menus e páginas dentro de páginas. 2.4.7 Disponibilizar um mecanismo de personalização baseado em regras definido pelo administrador do ambiente. 2.4.8 A solução deve possibilitar a criação de regras de personalização de apresentação e conteúdo em função de dados do usuário definido pelo administrador do ambiente. 2.4.9 Possibilitar a personalização de páginas por meio da seleção ou remoção de portlets, pelo próprio usuário, desde que autorizado pelo administrador do portal. 2.4.10 Possibilitar a seleção pelo próprio usuário dos elementos de apresentação do portal como temas e idioma, desde que autorizado pelo administrador do portal. 2.4.11 Suporte a múltiplas línguas na apresentação diretamente no portal, sem necessidade de conjunto de portlets e portais diferenciados. 2.4.12 Permitir selecionar automaticamente o idioma de apresentação do portal, em função das preferências dos usuários finais, e conforme configurações do dispositivo de acesso. 2.4.13 Suporte ao I18N. Especificação Técnica Servidor de Aplicação 17/42

2.4.14 Suporte a Unicode. 2.4.15 Portlets para submissão de conteúdo e processo de aprovação pelos usuários nãotécnicos. 2.4.16 Controle de versão de conteúdo. 2.4.17 Armazenamento de todas as versões de conteúdo para acesso rápido em checkouts. 2.4.18 Disposição de metadados de conteúdo como: nome do conteúdo, autor, data da última modificação, comentário e status. 2.4.19 Processo de aprovação de conteúdo baseado no papel do usuário no portal. 2.4.20 Armazena o histórico de ações sobre o conteúdo publicado. 2.4.21 Disponibilidade de browsing do conteúdo. 2.4.22 Inclusão de diferentes tipos de conteúdo (gifs, bmps, jpgs, html, texto, DOC, ODT, documentos PDF, por exemplo). 2.4.23 Conteúdo do repositório com metadado que descreve validade do conteúdo, público/privado, palavra-chave, resumo e autor, podendo ser customizado para acomodar outras informações. 2.4.24 Permite o upload de documentos em PDF, XLS, PPT, DOC e ODT através de mecanismo nativo do portal. 2.4.25 Permite customização dos atributos dos documentos de acordo com o perfil do administrador de conteúdo. 2.4.26 Possuir interface aberta para integração com outras ferramentas de gerenciamento de documentos. (ex.: API ou Webservice) 2.4.27 Criação de páginas baseado em wizards. 2.4.28 Criação de páginas sem necessidade de programação, na própria ferramenta de Portal. 2.5 Administração 2.5.1 Possibilitar administração e configuração local por meio de navegador Web. 2.5.2 Possibilitar a administração e configuração remota por meio de navegador Web. 2.5.3 Permitir a delegação de direitos de administração do Portal. 2.5.4 Suportar múltiplos níveis de delegação de administração. 2.5.5 Geração de log das atividades administrativas. 2.5.6 Possuir interface Web para o deployment de portlets. 2.5.7 Possuir interface Web para o catálogo de portlets instalados. 2.5.8 Permitir a ativação e desativação pelo administrador de um portlet instalado. 2.6 Segurança e Controle 2.6.1 Permitir a atribuição de direitos de acesso em um portal a usuários, grupos ou papéis (roles). 2.6.2 Modelo de segurança de conteúdo, portlets e páginas baseado em usuários e grupos do diretório LDAP, com diferentes graus de permissões (globais e específicas para cada objeto do Portal visualizar, adicionar, modificar, gerenciar, etc.). Especificação Técnica Servidor de Aplicação 18/42

2.6.3 Apresentar uma tela/página/portlet para a entrada de usuário e senha, e esta tela/página/portlet deverá suportar a utilização de certificação digital baseada em SSL seguindo os padrões de HTTPS handshake. 2.6.4 Suportar certificados digitais X509 v3 compatíveis com ICP-Brasil. 2.6.5 Integrar com as seguintes ferramentas externas de autenticação de Mercado: 2.6.5.1 Oracle Identity Manager 2.6.5.2 Tivoli Access Manager for e-business 2.6.6 A solução deve disponibilizar autenticação única single sign-on (SSO), permitindo que o usuário autenticado no portal ou em uma aplicação J2EE acesse outra aplicação J2EE no mesmo domínio administrativo sem a necessidade de realizar login novamente. 2.6.7 Possuir servidor de diretório padrão LDAP v3 nativo para armazenamento de quantidade ilimitada de usuários e grupos. 2.6.8 Possuir funcionalidade de login único (single sign-on) com outras aplicações web sem necessidade de alteração no código das aplicações, através de um repositório seguro de senhas. 2.6.9 Possuir funcionalidade de login único (single sign-on) com outras aplicações através de mecanismos de confiança, sem transmissão de senha. 2.6.10 Possuir funcionalidade de login único (single sign-on) com aplicações Java que utilizem o padrão JAAS sem necessidade de alteração do código destas aplicações. 2.6.11 Suporte a autenticação através de certificados digitais X.509. 2.6.12 Suporte a autenticação através do protocolo Kerberos para autenticação transparente em ambiente de rede Windows. 2.6.13 Possuir console Web de administração delegada de usuários e grupos. 2.6.14 Possuir console self-service para administração de perfil e senha pelo usuário final. 2.6.15 Possibilidade de permitir o auto-registro de usuários. 2.6.17 Possibilitar a customização do processo de autenticação, permitindo a integração com a ferramenta de gestão de identidades e acessos utilizada pela Dataprev na definição de políticas com relação à utilização de senhas (histórico, bloqueio de contas, alteração forçada no primeiro login, bloqueio de contas com base em endereço IP). 2.6.16 Permitir a integração nativa em duas vias com servidores padrão LDAP v3, OpenLDAP, MS Active Directory. 2.6.17 Permitir a integração com bases de dados e outros diretórios através do desenvolvimento de conectores. 2.6.18 Suportar criptografia SSL em todos os canais de comunicação de dados entre os diferentes componentes da solução (entre navegador e o servidor de cache, entre o servidor de cache o servidor web, entre o servidor web e o servidor de aplicações, entre o servidor de aplicações e o banco de dados, entre o diretório LDAP, o banco de dados e o servidor de aplicações), sempre que os componentes de destino assim o permitirem. 2.6.19 Possuir facilidade de Virtualização de Diretórios com acesso a bancos de dados, servidores padrão LDAP v3, MS-AD sem a necessidade de replicação ou sincronização de dados. 2.6.20 Permitir o aprovisionamento de usuários a partir de bancos de dados, servidores Especificação Técnica Servidor de Aplicação 19/42

padrão LDAP, MS-AD sem a necessidade de replicação ou sincronização de dados entre estes componentes. 2.6.21 Possuir funcionalidade de controle de acesso a recursos web (portlets e aplicações) através de definição de políticas. 2.6.22 Possuir funcionalidade de gestão de usuários baseadas em grupos estáticos. 2.6.23 Possuir funcionalidade de delegação de administração de usuários e grupos sem limite dos níveis de delegação. 2.6.24 Possibilitar a geração de relatórios sobre os principais eventos de segurança, como por exemplo, estatísticas de autenticação, autorização, falhas de login, mudanças de senha e controle de acessos entre outros de mesma natureza. 2.7 Pesquisa e Busca 2.7.1 Possuir mecanismo de busca integrado ao Portal, com respeito às permissões definidas sobre o conteúdo do Portal. 2.7.2 O mecanismo de busca deve indexar o conteúdo de documentos nos principais formatos (XLS, DOC, ODT, PPT, PDF). 2.7.3 Incluir mecanismo de busca federada, com a possibilidade de programar buscas em um número ilimitado de repositórios como bancos de dados, servidores de e-mail IMAP, servidores de arquivos, web sites. 2.7.4 Possuir modo de busca avançada com possibilidade de parametrização por atributos de conteúdo (autor, data, etc.). 2.7.5 Permitir a criação de portlets de busca customizada, com definição de campos a serem disponibilizados aos usuários, campos pré-configurados e buscas automáticas (que rodam automaticamente quando o usuário acessa a página). 2.7.6 Pesquisar conteúdo em repositórios contendo informações estruturadas e não estruturadas, eliminando as redundâncias e combinando tudo em um único resultado. 2.7.7 A ferramenta de busca deve executar sobre o mesmo servidor de aplicações do Portal. 2.7.8 Suportar a criação de índices a partir da indexação de informações provenientes de sistemas de arquivos. 2.7.9 Suportar a criação de índices a partir da indexação de informações provenientes de bancos de dados relacionais. 2.7.10 Os itens exibidos nos resultados da busca devem obedecer às restrições de acesso de acordo com o perfil do usuário. 2.7.11 Buscar informações não estruturadas através de meta-dados. 2.7.12 Apresentar os resultados das buscas ordenados por ordem de relevância. 2.7.13 Permitir o agendamento da criação/atualização dos índices. 2.8 Gestão de Formulários 2.8.1 Os formulários eletrônicos da solução de portal devem executar no mesmo servidor de aplicações do Portal. 2.8.2 Devem ser inclusas ferramentas de desenvolvimento de formulários que sejam integradas às ferramentas de desenvolvimento do Portal. Especificação Técnica Servidor de Aplicação 20/42