IBM WebSphere Application Server 7 e JBoss Enterprise Application Platform 5 Custos de Propriedade Comparados

Tamanho: px
Começar a partir da página:

Download "IBM WebSphere Application Server 7 e JBoss Enterprise Application Platform 5 Custos de Propriedade Comparados"

Transcrição

1 IBM WebSphere Application Server 7 e JBoss Enterprise Application Platform 5 Custos de Propriedade Comparados Autores: Jason Armstrong, Jeff Howell, Alex Wang (Summa Technologies) Summa Technologies, Inc. 925 Liberty Avenue Pittsburgh, PA 15222, USA (412) de dezembro de 2010

2 RESUMO EXECUTIVO Para se manterem-se competitivas no ambiente econômico atual, cada vez mais as empresas buscam a adoção de software open source, visando à redução de custos. Especialmente no mercado de servidores de aplicações, tecnologias de código aberto cresceram em maturidade e confiabilidade, tornando-se cada vez mais uma alternativa viável para muitos cenários e organizações. Ao se considerar o software open source, na maior parte dos casos não é a possibilidade de modificação do código que atrai os consumidores, mas sim a potencial economia financeira que pode oferecer. Embora a maneira mais fácil e direta de se calcular esta economia seja através de custos de aquisição, muitas vezes essa visão ignora outros custos que a escolha de um servidor de aplicações pode acarretar. Exemplos são gerenciamento, administração, treinamento e custos de hardware, além dos custos de oportunidade de indisponibilidades inesperadas. De acordo com vários estudos independentes da indústria, os custos de manutenção de software nas últimas duas décadas cresceram mais de 90% (veja o Apêndice F). A escolha de um servidor de aplicações não deve ser baseada somente nos custos de aquisição, mas sim no Custo Total de Propriedade (Total Cost of Ownership, TCO) associado a um produto. Em uma nota da pesquisa G do Gartner, de março de 2009, é afirmado: Produtos disponíveis gratuitamente (como os open source), ou que possuem o mesmo custo, em um período de três a cinco anos, podem custar mais que uma compra comercial no valor de milhares de dólares. Para entender os custos no ciclo de vida de operações, a análise de várias informações fundamentais são necessárias, para que se tenha uma avaliação mais realista do custo total de gerenciamento dos produtos. O atual estudo fornece uma comparação aprofundada entre o IBM WebSphere Application Server Network Deployment V7 (WAS ND) e o JBoss Enterprise Application Platform V5 (JBoss EAP) da RedHat, medindo e quantificando os diversos custos associados a cada produto, oferecendo-se uma comparação detalhada dos seus respectivos custos totais de propriedade. Além disso, este documento fornece uma apresentação abrangente e transparente de testes extensivos que a Summa Technologies desenvolveu para a análise comparativa. A conclusão alcançada neste estudo é que, na maioria dos ambientes, embora os custos de aquisição do JBoss EAP sejam mais baixos, o IBM WAS ND apresentou um TCO mais baixo, devido às suas vantagens em estabilidade, gerenciamento, documentação e desempenho. Na configuração média, no período de cinco anos considerados neste estudo, o WAS ND apresentou 49% de vantagem no custo total de propriedade (TCO) em relação ao JBoss, como demonstrado no diagrama a seguir: IBM WebSphere AS 7 e JBoss EAP 5 1

3 Este documento ajudará o leitor a determinar se sua companhia se enquadra nessa maioria que pode obter economias com o WAS ND, ou se um servidor de aplicações open source como o JBoss Enterprise Application Platform (EAP), ou ainda alternativas como o Apache Geronimo ou o IBM WebSphere Application Server Community Edition (WAS CE), seriam mais apropriadas. PRINCIPAIS CONCLUSÕES Embora o JBoss possua uma vantagem de custos inicial, devido a nenhum custo de aquisição de licenças, nossos resultados indicam que durante um período de cinco anos, o TCO (custo total de propriedade) claramente favorece o WAS e o WAS ND. Além disso, ao JBoss faltam funcionalidades críticas, como será apresentado posteriormente neste documento. Projetando para um horizonte de cinco anos, o resultado do nosso estudo demonstra uma vantagem de 49% nos custos totais para o WAS ND em ambientes médios e grandes, os quais podem ser divididos da seguinte forma: Nota: A versão anterior deste documento determinava uma vantagem de TCO de 43% em relação ao JBoss; contudo a Red Hat modificou sua política de licenciamento para o JBoss e efetivamente dobrou os custos de suporte para processadores multicore, ao modificar o licenciamento baseado em sockets para o baseado no número de núcleos, em novembro de Este estudo considera o novo modelo de licenciamento do JBoss, baseado no número de núcleos, que é similar ao adotado pela IBM. Para acesso completo aos dados, incluindo os passos gravados (capturas de tela através do Camtasia) e as medições de tempo associadas, além das premissas consideradas quanto ao licenciamento de servidores, assim como as fórmulas utilizadas neste estudo, por favor entre em contato com a Summa ou um representante da IBM. Abaixo são apresentados alguns dos resultados deste estudo: Custos de hardware: Com base no comparativo de desempenho realizado em laboratório, os custos de hardware para o JBoss V5 representam 177% dos custos referentes ao IBM WAS ND V7, devido à diferença de desempenho entre os ambientes. São necessários mais servidores para se executar o JBoss, e um ambiente mais complexo, que por sua vez requer mais assinaturas de suporte de software e um aumento nos custos de administração, como mostrado nas próximas seções. Observe que a versão de 2007 deste estudo apontava que a diferença de desempenho entre o WebSphere V6.1 e o JBoss V4.2 era de apenas 39% a favor do WebSphere. No estudo atual (WebSphere v e JBoss EAP 5.0.1), constatamos uma diferença superior a 290% para determinados tipos de aplicações. Além disso, analisando comparativos amplamente aceitos pela indústria, a IBM é a primeira fornecedora a publicar tais dados, e atualmente detém o melhor resultado no comparativo SPECjEnterprise2012, que mede a performance para aplicações Java EE 5 em relação à escalabilidade (7, EjOPS) e também desempenho (226 EjOPS /core). No caso do JBoss, nunca foram publicados resultados para o comparativo SPECjEnterprise2010, e nem mesmo para o comparativo anterior da indústria, o SPECjAPPServer2004. IBM WebSphere AS 7 e JBoss EAP 5 2

4 Custos com licenciamento, assinaturas e suporte: uma assinatura anual deve ser adquirida para que se obtenha o software JBoss EAP. Os custos da assinatura anual do JBoss representam 42% dos custos combinados de licença e suporte do IBM WAS ND para um período de cinco anos. Com base nos comparativos de desempenho realizados neste estudo, o JBoss requer um número maior de assinaturas de suporte por CPU, para executar a mesma carga que o WebSphere. Outro fator que contribui, é o fato de a IBM empacotar o JDK, LDAP, Cache e servidores WLW com o WAS ND, sem custo adicional, enquanto que os clientes do JBoss precisam comprar a licença ou assinatura destes softwares separadamente (a menos que já existam LDAP, WLW e outros softwares no local e que possam ser reutilizados). A diferença nas licenças e no custo de suporte não são uma surpresa em softwares comerciais. Por exemplo, o WebSphere inicialmente custa mais, mas apresenta benefícios no longo prazo, graças à sua melhor experiência de usuário. Custos de administração de aplicações: Os custos específicos com mão-de-obra, para administração da aplicação e suporte do JBoss, são 291% superiores aos custos corresponentes com o IBM WAS ND. Isso se justifica pelos diferentes níveis de conhecimento técnico exigidos na administração, o tempo exigido para executar tarefas administrativas similares, e o maior tamanho do ambiente JBoss que deve ser gerenciado. Embora o JBoss tenha aprimorado sua capacidade de gerenciamento na última versão do JON, nossa pesquisa constatou que as novas funcionalidades apresentam problemas relevantes em relação à qualidade e à segurança do produto. Enquanto isso, o WAS continua a possuir vantagens nesta área. Como resultado geral, o investimento inicial favorece o WAS, e seus custos adicionais de licenciamento são compensados devido aos baixos custos administrativos e de mão-deobra. (Os cálculos neste estudo são baseados nos custos trabalhistas nos Estados Unidos.)e Custos administrativos da infraestrutura: Os custos provenientes do trabalho na administração da infraestrutura de suporte do JBoss compreendem 167% dos custos com o IBM WAS ND. Em aplicações similares à descrita acima, a instalação e o gerenciamento do núcleo de servidores de aplicações em produção é mais difícil no JBoss, pois requer um nível maior de conhecimento e mais esforço na manutenção. Além disso, o hardware adicional necessário para execução da carga no JBoss gera o custo adicional de gerenciamento do sistema operacional. Risco relativo e custos de indisponibilidade: O estudo revelou que o JBoss não fornece funcionalidades como recuperação de transações XA, separação de papéis de segurança entre administradores, capacidades de auditoria, um framework amplo de funcionalidades administrativas e outras importantes características corporativas de qualidade de serviço. A falta dessas funcionalidades introduz riscos e gera mais indisponibilidade. O impacto dos riscos e de indisponibilidade podem variar significativamente, dependendo do tipo de negócio ou aplicação. Em nosso estudo, partimos da suposição de que o valor anual de negócio do projeto é de $ (nove milhões de dólares), durante 5 anos. O custo aproximado com riscos adicionais e indisponibilidades para o JBoss foi calculado de forma conservadora, e é superior aos custos do WebSphere em $ Além de quantificar os custos totais de propriedade (TCO) também avaliamos diversos fatores de qualidade que influenciam a experiência do usuário para o WAS e o JBoss. Esses fatores podem ter impacto indireto no TCO para uma organização, e devem ser considerados na avaliação de um produto. Algumas descobertas significativas são: Desempenho Nossos testes de desempenho indicam uma vantagem favorecendo o WAS em relação ao JBoss, por um fator entre 1,4:1 e 2,9:1. Essa diferença em performance irá aumentar os custos de hardware, software e de administração para o JBoss, ao se tentar alcançar resultados de desempenho semelhantes. Utilizamos um fator de desempenho conservador de 170% (um fator de 100% indicaria desempenho idêntico). Documentação A documentação do JBoss é destinada principalmente aos desenvolvedores; contém muitos erros e em muitos casos necessita que um administrador identifique as configurações corretas através de tentativa e erro. Este pode ser um processo custoso, especialmente se um problema só for encontrado depois que o sistema entre em produção. Integridade transacional e suporte à recuperação de falhas Embora o JBoss tenha evoluído em algumas áreas no suporte à recuperação de falhas, como por exemplo na replicação de sessões HTTP, ainda possui problemas com a falha de múltiplos nós. Além disso, testes da IBM demonstram que o IBM WebSphere AS 7 e JBoss EAP 5 3

5 JBoss ainda apresenta problemas referentes à integridade transacional. Segurança Fora da Caixa As instalações compartilhadas do JBoss tentam formar clusters automaticamente, mas é necessário trabalho adicional para segregar servidores de aplicações JBoss em clusters menores. Em algumas instâncias, desabilitar o mecanismo padrão causa problemas em outros componentes, como por exemplo a integração com o servidor web. Diversas questões relativas à segurança serão descritas posteriormente neste documento. Problemas de compatibilidade entre ferramentas administrativas O JBoss adicionou um novo console gráfico administrativo baseado na web e uma versão atualizada do JBoss Operation Network (JON). Infelizmente, esses produtos apresentam uma série de problemas de qualidade, além do problema de compatibilidade com o modo tradicional de gerenciamento do JBoss, através da edição de arquivos de configuração no sistema de arquivos. Nossas experiências testando o novo console administrativo e o JON indicam que o administrador ainda necessitará editar algumas configurações diretamente. Reinício não planejados de servidores Durante a utilização do plugin (mod_cluster) no JBoss, encontramos problemas em que foi necessário o reinício dos servidores web se fosse reiniciado o servidor de aplicações, o que resultaria em interrupções visíveis aos clientes do ambiente de produção. Encontramos esse problema tanto em instalações em clusters quando em instalações standalone. Os testes no WAS indicaram que o reinício do servidor de aplicações não exigiu reinício do servidor web. Compatibilidade Retroativa Testes indicaram problemas de compatibilidade retroativa, entre o JBoss EAP 5 e o JBoss AS 4. Além disso, encontramos problemas de retrocompatibilidade entre a versão do JBoss AS 5.1 mantida pela comunidade e a versão comercial do JBoss EAP 5. Este último problema é esperado, pois a Red Hat não dá suporte à versão comunitária do JBoss e não garante a compatibilidade em produção ou com qualquer outro software suportado pela empresa. Ao escolher um servidor de aplicações, as organizações devem examinar cuidadosamente os custos e riscos associados a um produto, no contexto das capacidades de sua equipe, as características da aplicação e do ambiente e os riscos gerais, para determinar que soluções possuirão o menor custo total no longo prazo. As organizações de TI precisam frequentemente liberar implementações de software e selecionar produtos baseados em informações limitadas. A avaliação dos custos de um negócio durante toda a vida de uma aplicação é difícil de medir e pode incluir muitos outros fatores, como demonstrado a seguir: IBM WebSphere AS 7 e JBoss EAP 5 4

6 Além de deixar de levar em conta todos esses custos, há outras armadilhas. A estimativa dos custos de mãode-obra tipicamente deixa de contabilizar o nível de conhecimento necessário para desempenhar uma tarefa, especialmente de tarefas avançadas de configuração e administração. Gerentes frequentemente deixam de contabilizar o desenvolvimento de código não-funcional, necessário à manutenção de publicações, além de custos necessários para a manutenção de sistemas complexos. Fatores de custos O impacto relativo dos fatores sobre o custo total de propriedade (TCO) podem variar muito entre projetos, dependendo do ambiente e do tipo de aplicação sendo publicada. Os fatores de TCO considerados neste estudo são descritos na tabela a seguir. IBM WebSphere AS 7 e JBoss EAP 5 5

7 Área de TCO Licenciamento e suporte de software Exemplos de Custos Os custos iniciais de licenciamento e assinatura para todos os elementos de uma solução, incluindo servidor de aplicações, sistema operacional, servidor web, balanceador de carga, LDAP, servidor HTTP, JVM, etc. Custos contínuos de suporte ao produto e assinaturas Hardware Custos com hardware e suporte Custos com refrigeração e energia Gerenciamento das aplicações Gerenciamento da infraestrutura Riscos e Tempo de indisponibilidade Custos com instalação e configuração de projetos de desenvolvimento ou publicação Custos na integração de interfaces de sistemas externos e com suporte e teste Aprimoramento do desempenho e monitoramento do ambiente do servidor de aplicações Tempo gasto na solução de problemas em aplicações e ambientes de desenvolvimento Instalação, monitoramento e manutenções rotineiras em software de aplicação Atualizações de pacotes de correção no sistema operacional e no servidor de aplicações Atualização dos servidores para novas versões Backup e restauração do sistema operacional e do servidor de aplicações Recuperação automática de falhas, incluindo transações XA heurísticas Tempo de recuperação de falhas em filas e destinos JMS, HTTPSessions e outros serviços stateful; reinício do servidor e vazamentos de memória Verificação de consistência na configuração, para prevenir configurações ilegais Ferramentas de segurança para separação de papéis administrativos e auditorias Impacto da criptografia em comunicações dentro do cluster Treinamento Treinamento de administradores e desenvolvedores Considerações adicionais Custos de extensão de produtos para suportar acordos de nível de serviço (SLAs) Custos de integração de sistemas para desenvolvimento e instalação de serviços integrados, tais como pacotes de software (por exemplo SAP), produtos de messageria (ex.: WebSphere MQ, TIBCO), servidores LDAP e servidores de banco de dados Custos de desenvolvimento personalizado e testes de funcionalidades não suportadas Um fator não incluído são os custos de desenvolvimento de software, os quais decidimos não medir diretamente, devido ao seu alto grau de variabilidade (considerando práticas de desenvolvimento de software, tamanhos de equipe e nível de competência de uma organização individual). Com base em nossa experiência prática, adquirida ao testar os produtos, incluímos comentários e cálculos, nos pontos em que acreditamos que os custos do desenvolvimento de software podem ser diferentes para capacidades diferentes dos produtos. Onde era apropriado, extrapolamos possíveis implicações sobre o custo total de propriedade (TCO) relacionadas a essas diferenças. CONCLUSÕES DA ANÁLISE Executamos testes práticos para apoiar o cálculo de custos administrativos, e melhor compreender aspectos qualitativos desses custos para os produtos. A lista a seguir exibe os cenários de testes executados: IBM WebSphere AS 7 e JBoss EAP 5 6

8 Testes autônomos Instalar e configurar o servidor de aplicações Atualizar o software de uma versão anterior Publicação manual de aplicações Configuração de LDAP para segurança administrativa Publicação de aplicações por meio de rotinas automatizadas Aplicar pacotes de correção e hot fixes (reparos rápidos) Testes de desempenho em Web Services Testes de desempenho em Java EE 5 Testes recuperação heurística de transações Testes agrupados Instalar e configurar o servidor de aplicações Atualizar software de um lançamento anterior Adicionar servidor ao Cluster Configurar log de transações locais e distribuídas (XA) Publicação manual de aplicações Configurar LDAP para segurança administrativa Publicação de aplicações por meio de rotinas automatizadas Aplicar pacotes de correção e hot fixes (reparos rápidos) Testes de tolerância a falhas na replicação de sessões HTTP Testes de failover em JMS As áreas do TCO medidas como parte deste estudo são discutidas nas seguintes seções. Desempenho Vantagens em TCO: IBM WebSphere Application Server Nesta versão do estudo, realizamos diversas variações de testes de desempenho em ambientes autônomos (standalone), em vez de testes de desempenho em ambientes clusterizados. Esta mudança na estratégia de testes deve-se ao feedback de clientes, que indicaram fazer pouco uso do JBoss em ambientes clusterizados. O uso mais comum reportado foi como servidor autônomo para uso de aplicações orientadas a um propósito específico. Acreditamos que os resultados obtidos nos testes para um servidor autônomo podem ser extrapolados para um cenário ideal de operações em cluster. Nossa estratégia de testes incluiu os seguintes cenários de testes: Testes de 48-horas, 12 horas e 1 hora de duração do WAS e do JBoss, utilizando o Apache DayTrader em uma única máquina (com múltiplas JVMs se necessário): Máquina remota única para o servidor web; Servidor remoto de banco de dados executando IBM DB2; Uso de EJB3 como camada de persistência. Testes de 2-horas de testes de web services com complexidade moderada (SOAP/HTTP, entrada de 4 kb, saída de 2 kb): Máquina única para o servidor de aplicações com mais de uma JVM se necessário; Máquina remota única para o servidor web; Sem banco de dados; Serviço baseado em POJOs anotados com JAX-WS. Como parte dos testes de desempenho, gastamos tempo significativo otimizando tanto o JBoss quanto o WAS. As configurações de software e de hardware utilizadas nos testes estão descritas no Apêndice C. A média de utilização de CPU no servidor foi maior de 90% com o JBoss e com o WebSphere. Anteriormente a cada teste de desempenho executado, otimizamos as configurações de cada ambiente (JBoss e WAS) para desempenho otimizado. Houve algumas descobertas interessantes resultantes do processo de otimização. A otimização do WebSphere foi um processo relativamente simples, concluído em menos de um dia. O WebSphere já possui embutido o Tivoli Performance Viewer, que mesmo com sua interface de usuário não- IBM WebSphere AS 7 e JBoss EAP 5 7

9 Web 2.0, foi uma ferramenta importante durante o processo de otimização e monitoração. Com ela, fomos capazes de rever rapidamente estatísticas relevantes e alterar os valores no decorrer do tempo. Também notamos que o assistente de ajustes no WebSphere recomendou configurações mais conservadoras, que no nosso caso foram utilizadas apenas como ponto de início do processo de otimização. O processo de otimização do JBoss consumiu duas semanas para ser concluído, e exigiu entendimento mais profundo dos mecanismos internos do JBoss. Tanto a comunidade JBoss da Red Hat, quanto referências para melhores práticas, foram consultadas para identificar recomendações de ajustes finos. Para mais detalhes, consulte o documento Melhores práticas para otimização de desempenho da Plataforma de Aplicações Enterprise JBoss 5 (em inglês). Além dos ajustes relacionados ao tamanho do heap da JVM, pools de threads e vários outros, também foram consideradas recomendações do Laboratório de Desempenho da Red Hat (Red Hat Performance Lab) específicas para o DayTrader (apresentadas em diversas palestras na conferência mundial JBoss ocorrida na cidade de Boston EUA, em junho de 2010), incluindo: Utilizar o JBoss Message Resource Adapter (adaptador de recursos de mensagens JBoss) e o pooling de conexões JMS Utilizar StrictMaxPool para o Pool de sessões sem estado do EJB3 Desabilitar o rastreamento de conexões não-fechadas no jca-jboss-beans.xml Iniciar múltiplas JVMs do JBoss para remediar o bug nos locks do Gerenciador de Transações do JBoss Utilizar interfaces locais do EJB3, para evitar a serialização de chamadas de interfaces remotas Também identificamos problemas qualitativos (durante os testes e os ajustes finos de desempenho) que têm impacto no TCO. Por exemplo, como discutido acima, realizar ajustes finos no JBoss requer trabalho mais intensivo que no WebSphere, e exige maior nível de conhecimento. Várias das razões são destacadas abaixo: Pouca informação prática na documentação O site do JBoss (incluindo documentação, wikis e postagens nos fóruns) forneceu pouca informação prática e direta para nós. Tivemos que usar sites de terceiros para conseguir um melhor entendimento do que eram e como funcionavam várias opções de configuração. Informações incorretas na documentação O site do JBoss indicou uma série de configurações na camada EJB, que controlariam o tamanho do pool de EJBs. Essas alterações exigiram atualizações, ou no código-fonte ou nos descritores de deployment específicos. Após realizar as mudanças nesses descritores e tratar mensagens de erro difíceis de interpretar, percebemos que no final o JBoss EAP 5 não utiliza estas configurações. Problemas com ferramentas de monitoração de desempenho Devido a problemas de qualidade ligados às ferramentas JON de monitoração, descobrimos que a melhor abordagem para fazer o ajuste fino no JBoss envolvia o uso de ferramentas nativas do sistema operacional, ler arquivos de logs e trabalhar com o console administrativo JMX. Infelizmente, o console administrativo é incapaz de exibir as estatísticas de mais de um componente por vez, de forma que tivemos que constantemente mudar entre uma visão e outra de componentes. Problemas de escalabilidade do mod_cluster Durante o processo de ajuste fino, descobrimos que o mod_cluster do JBoss era um gargalo. Adicionamos um segundo servidor web para os testes com o JBoss. Acabamos removendo os servidores para o teste de 12-horas, para reduzir o número de variáveis envolvidas e oferecer uma comparação mais direta do desempenho dos servidores de aplicações. Reinício do JBoss Constatamos que, depois da maioria das modificações que podem ser feitas, incluindo aquelas realizadas através do console do JMX, o JBoss tem que ser reiniciado. Dois exemplos onde foi necessário o reinício do servidor são: Aumento do tamanho do pool de conexões do JDBC O aumento do pool de conexões de banco de dados através do console do JMX resulta em uma falha da aplicação, devido a um erro de conexão com o banco de dados. A única forma de eliminar o erro é reiniciando o JBoss. IBM WebSphere AS 7 e JBoss EAP 5 8

10 Reiniciar o JBoss exige reiniciar o servidor web Devido a problemas com o mod_cluster, constatamos que quando o servidor de aplicações precisa ser reiniciado, também deve ser reiniciado o servidor web, devido a um checksum inválido durante o processo de negociação (handshake) do servidor. Nossos testes de desempenho indicam uma vantagem do WAS sobre o JBoss, por um fator entre 1,4 para 1 e 2,9 para 1. A diferença de desempenho aumenta os custos de hardware, software e administração do JBoss para obter resultados de desempenho comparáveis com o WAS. Temos usado de forma conservadora o fator de 170% de desempenho do WebSphere (o fator 100% significaria desempenho idêntico). Para uma documentação completa do teste de desempenho, arquivos do projeto, roteiros de cargas e arquivos de dados, por favor, entre em contato com o seu representante da IBM. Custos de hardware Vantagens em TCO: IBM WebSphere Application Server Executamos alguns testes de desempenho no JBoss EAP e no WebSphere Application Server, com configurações de um único servidor, e usando a aplicação de teste DayTrader da Apache, além de implementação simples de web service, executando sob carga simulada. Os detalhes dos testes podem ser encontrados na seção de testes de desempenho nesse documento. Com base nos resultados dos testes de desempenho, uma solução baseada no JBoss precisará de 40% a 290% a mais de hardware para tratar a mesma carga que uma solução baseada no WebSphere. O custo total de propriedade (TCO) estimado utiliza, de forma conservadora, 170%, para calcular os custos no relatório. Os componentes do TCO, como licenças de software e custos de assinatura/suporte, favorecem o WAS ND num período de cinco anos em 177% ($ vs. $ ). Esses números refletem os custos de assinaturas necessárias para suportar uma carga equivalente no JBoss, juntamente com um crescimento modesto previsto de 5% em transações por ano, e criação de quatro novas aplicações por ano com tamanho e complexidade similares à aplicação DayTrader. Custos de assinatura, licenciamento do software e manutenção Vantagens em TCO: IBM WebSphere Application Server O mantra comercial do open source tem sido: Se não precisar de suporte, não pague por ele. Se precisar de suporte, compre o suporte. Para alguns produtos open source e casos específicos de usuários, esse princípio pode ser verdadeiro. No entanto, nossos testes indicam que a assinatura do JBoss é essencial. Durante as análises, comparamos o suporte da versão comunitária do JBoss AS, com o suporte à versão comercial do JBoss EAP. Nos 32 projetos open source que compõem ambos os produtos, constatamos que o JBoss EAP usa as versões mais recentes de 14 dos seus componentes. Para obter o mesmo nível de versões destes projetos, seria preciso realizar as integrações desses projetos manualmente. Integrar manualmente esses 32 projetos open source em um pacote equivalente e gratuito, similar ao que o CentOS fez com o RHEL, seria muito custoso e demorado. Para o estudo do TCO, obtivemos a lista de preços para ambos JBoss EAP (JBoss NA Channel SKUs, e o IBM WebSphere Application Server (IBM WAS Server Pricing, em Decidimos usar o suporte premium da Red Hat para avaliar os cálculos de TCO, uma vez que fornecem uma correspondência mais próxima ao suporte básico 24x7 da IBM. A configuração do hardware usado para nossas análises dos custos de licenciamento possui 2 sockets de CPU por máquina, sendo que cada socket tem quatro núcleos. Tem assim o total de 8 núcleos por máquina. Para essa configuração, a IBM requer a compra de 560 PVUs (Valor de Processamento Unitário) por máquina, equanto o JBoss necessita de 0,5 pacotes por máquina, do seu pacote de assinatura anual de 16 núcleos. Há muitos fatores que podem influenciar o custo de licenciamento do software. A lista a seguir contém alguns dos itens mais importantes para serem levados em consideração: IBM WebSphere AS 7 e JBoss EAP 5 9

11 Ambos Red Hat e IBM dão descontos nos preços, com base no volume de negócios e dos ambientes para publicações das aplicações, o que gera preços muito diferente dependendo do caso. A análise do custo de licenciamento e suporte analisados neste estudo é baseada nos preços de rua, presumindo o desconto de 27% da lista de preços da IBM e o mesmo desconto para a Red Hat. Acreditamos que ambos são apropriados para efeitos desse estudo; no entanto há algumas evidências que sugerem que os descontos da JBoss não ultrapassam 20%. Os preços do JBoss requerem a compra de grupos de 16 ou 64 núcleos de CPU (ao contrário da antiga maneira de contar as CPUs por sockets, usada antes de novembro de 2010). Se for preciso uma configuração menor que 16 núcleos, não está claro como a Red Hat irá precificar seus produtos. A Red Hat também não fornece mais a assinatura gratuita do JON com o suporte da JBoss, e agora exige pagamento separado pelo JON (no passado o JON era gratuito para clientes que comprassem o suporte da JBoss para 32 ou mais CPUs). Tanto a Red Hat como a IBM têm políticas similares no que diz respeito ao licenciamento de subcapacidade, quando são usadas tecnologias de virtualização como o VMware ou outros hypervisors (gerenciadores de máquinas virtuais). O WAS-ND inclui o produto WebSphere Edge Components, que foi levado em conta na análise do TCO. As configurações que usam o WebSphere Edge Components têm benefícios adicionais em custos, em comparação ao JBoss EAP para tarefas como balanceamento de carga ou cache nas extremidades. Isso pode eliminar a necessidade de outros produtos de hardware e software, e de esforços de customização com integração, ao se utilizar o WebSphere. O WAS-ND inclui licenças gratuitas para o Tivoli Access Manager, que pode agir como um servidor LDAP; o JBoss EAP não inclui um servidor LDAP, então pode ser necessário um servidor LDAP externo. O custo de um Servidor de Diretórios Red Hat foi levado em consideração na análise do JBoss. Desde junho de 2009, a IBM oferece a versão IBM WebSphere Application Server for Developers Edition (WASDE) sem custos, com suporte pela comunidade, e uma versão com suporte pago. O WASDE tem exatamente o mesmo código do WebSphere Application Server. Os clientes que têm a licença completa do WebSphere também têm acesso ao Rational Developer Assembly and Deployment Tool (veja Essa ferramenta é um subconjunto do Rational Application Developer, que pode ser usado para desenvolver e empacotar as aplicações para publicação no WebSphere. Os componentes do TCO para licenças de software e com suporte/assinatura favorecem o WAS ND em um período de cinco anos, em 93% ($ vs. $ ). Esses números refletem custos adicionais de assinatura necessários para suportar uma carga equivalente no JBoss, além de uma previsão modesta de 5% de crescimento de transações por ano e a criação de três novas aplicações a cada ano de tamanho e complexidade similares à aplicação DayTrader. Custos com administração de aplicações e infraestrutura Vantagens em TCO: IBM WebSphere Application Server Como parte do estudo do TCO, executamos diversos cenários temporais para entender os passos envolvidos em tarefas administrativas variadas, e para compreender a complexidade relativa dessas tarefas e problemas encontrados durante sua execução. Os cenários específicos avaliados incluem instalação, atualização, migração, configuração, criação de clusters e fortalecimento da segurança do ambiente das aplicações, para um ambiente de tamanho moderado. Para cada caso de testes, foi calculado o impacto da diferença de TCO num período de cinco anos. Como parte dos testes, também estudamos os efeitos da curva de aprendizado associada a cada produto, além do nível de conhecimento requerido por cada produto. O cálculo de custos utilizou o resultado do melhor caso de cada um dos testes, para prevenir o aumento dos custos associados à adapatação/aprendizado de novos profissionais administradores. IBM WebSphere AS 7 e JBoss EAP 5 10

12 Com relação à curva de aprendizado, nossos testes indicaram que o WAS ND possui, em geral, uma curva menor de aprendizado em relação ao JBoss. Constatamos que a execução de determinada tarefa no JBoss pode ser 122% a 321% mais longa do que no WebSphere. Também identificamos que, na média, o nível de conhecimento necessário para completar as tarefas com o JBoss é maior que o exigido para realização das mesmas tarefas no WebSphere. O restante desta seção descreve os vários cenários testados e os resultados de cada teste, e mostra como os resultados se relacionam com o TCO. Também são discutidas as principais descobertas encontradas durante os testes. O estudo divide os custos administrativos em duas categorias. A primeira refere-se à administração da aplicação e a segunda, à administração da infraestrutura. Os custos de administração de uma aplicação são os que estão mais diretamente associados ao gerenciamento da aplicação, durante um projeto de desenvolvimento de software. Esses são os custos associados à criação de ambientes de desenvolvimento compartilhados, ambientes de QA (garantia de qualidade) e o ambiente de produção inicial. Muitas organizações tratam esta categoria como projetos de capital ou de trabalho planejado. Os custos com a gerência da infraestrutura são focados na operação diária e na manutenção do ambiente de produção em execução, a aplicação de pacotes de correção ou a adição de capacidade no servidor para suportar demandas crescentes. Muitas organizações tendem a categorizar esse tipo de trabalho como trabalho gasto (expense work). Após o estudo anterior, de 2007, decidimos dividir esses custos em duas categorias que melhor refletem como muitos dos leitores consideraram os custos administrativos. Considerando os custos administrativos de aplicações no período de cinco anos, o WAS possui vantagem de 291% em relação ao JBoss ($ vs. $ ). Os custos de administração de infraestrutura para o mesmo período favorecem o WAS em relação ao JBoss, em 167% ($ vs. $ ). Instalação e configuração Vantagem em TCO: IBM WebSphere Application Server Os testes se concentraram na instalação inicial e na configuração dos servidores de aplicações. O caso de teste capturou e comparou a experiência de aquisição inicial do produto, download, instalação e configuração, para JBoss, WAS e WAS ND. O estudo também cobriu o desenvolvimento inicial (sem clusters) da aplicação de testes. A lista a seguir demonstra os fatores e principais aspectos que o caso de teste de TCO demonstrou: Tempo de instalação do servidor de produção O download e instalação inicial de uma única instância de servidor JBoss adequada para desenvolvimento é mais simples e menor que o WAS. Aplicar atualizações e correções para o JBoss demanda mais trabalho e um processo que exige mais trabalho manual que para o WAS. Configuração do servidor O fortalecimento da segurança nos componentes administrativos do JBoss para uso em produção é mais difícil e consome mais tempo, e o JBoss Operations Network (JON) não auxilia nas seguintes tarefas: A configuração de integração com um servidor LDAP requer edição manual de diversos arquivos no sistema de arquivos. Para adicionar segurança nas comunicações JMS, é necessário configurar uma série de arquivos no sistema de arquivos. A documentação está incorreta em relação à efetividade desta tarefa. Além disso, existem muitas informações divergentes nos fóruns de discussão JBoss, páginas wiki e blogs. IBM WebSphere AS 7 e JBoss EAP 5 11

13 O fortalecimento da segurança dos componentes administrativos no WebSphere é muito mais simples: Durante o processo de instalação, o administrador é questionado para selecionar um usuário e senha para o console de administração. Após completar a instalação inicial, o administrador pode utilizar um tutorial passo a passo, no console de administração, para conectar o servidor a uma série de diferentes servidores LDAP. (InfoCenter fornece os passos detalhados para configurar o acesso no Microsoft Active Directory.) Configurações predefinidas O JBoss fornece várias configurações predefinidas, baseadas em tipos de uso; mas as diferenças entre as configurações é pouco documentada. Também não está claro o que é exigido para criar novas combinações de servidores. Trocar de uma configuração para a outra requer uma manutenção dos binários de aplicações, bem como informações relevantes de configuração ou bibliotecas de terceiros distribuídas, que ficam em múltiplos diretórios no sistema de arquivos. Com base nas aplicações instaladas no servidor, o WebSphere irá determinar quais componentes, como por exemplo container web, container EJB, JMS etc., devem ser carregadas em tempo de execução. Esta abordagem não requer que administradores tomem qualquer ação, ou que personalizem a configuração do servidor de forma otimizada. Para uma empresa com múltiplos servidores, isso simplifica muito os processos de configuração, instalação e otimização dos servidores. O WebSphere fornece a opção de otimizar o servidor para uso em desenvolvimento ou produção. Observamos que a configuração padrão de produção do WAS irá habilitar funcionalidades que aumentam o tempo de inicialização, mas aprimoram a eficiência geral quando o servidor de aplicações está em execução por longos períodos. O modo de desenvolvimento reduz o tempo de inicialização, retardando a inicialização destes componentes até que isso seja necessário. Para alternar entre o modo de produção e o de desenvolvimento, basta selecionar um checkbox e reiniciar o servidor; as aplicações não necessitam ser republicadas ou reconfiguradas. Configuração do servidor web Nossos testes indicaram que o servidor HTTP da IBM não é suportado pelo plug-in mod_ cluster do JBoss, para integração de servidores web. Por esse motivo, foi necessário compilar manualmente e instalar o servidor Apache HTTPD para nossos ambientes JBoss. O componente mod_cluster JBoss utiliza multicasting para vincular servidores web e servidores de aplicações. Encontramos diversos problemas nessa abordagem: O JBoss e o mod_cluster escutam por padrão um endereço específico de multicast. Uma falha na modificação destes endereços padrão podem levar a criação de clusters ad hoc (sob deman. Esta abordagem vai contra os princípios de menor privilégio e de menor surpresa. Em nossos testes, dois administradores em momentos distintos acidentalmente criaram um cluster de duas instâncias JBoss que deveriam estar separadas. Mudar o endereço default de multicast gerou um comportamento inesperado durante o encerramento do servidor de aplicações, incluindo erros provenientes do provedor de JMS. É possível desabilitar os anúncios de multicast, mas isso também leva a comportamentos inesperados. Em particular, reiniciar o JBoss exigiu reiniciar o servidor web, devido a um erro de checksum inválido encontrado durante o processo de vinculação do servidor. IBM WebSphere AS 7 e JBoss EAP 5 12

14 A documentação do JBoss é vaga em relação aos modos eficazes e seguros de realizar a configuração da integração entre o servidor web e o servidor de aplicações. Em nossos testes com o JBoss, também descobrimos que o uso do componente de gerenciamento do mod_cluster é essencial para verificação, diagnóstico e monitoramento da configuração do servidor web. Este componente deve ser configurando através da diretiva <Location> do Apache, o que significa que os administradores também devem se certificar que a URL está segura (por exemplo, restringindo o acesso à URL de fora da DMZ). O WebSphere fornece um plugin para uma variedade de servidores web, incluindo o servidor Apache HTTP e IBM HTTP (IHS). Em nossos testes, utilizamos o IHS, pois, de acordo com a nossa experiência, empresas utilizando o WebSphere tendem a também utilizar o IHS. Também foi possível utilizar o instalador da IBM para automaticamente instalar o servidor web e o plugin simultaneamente no servidor. A configuração do servidor web para uso com o WAS e o WAS ND é relativamente direta, e a integração inicial do servidor web com o servidor de aplicações foi realizada através do uso de um script gerado automaticamente pelo software de instalação. O único problema ocorreu na verificação se a aplicação foi publicada corretamente: houve certa confusão quanto ao ambiente de hosts virtuais do WebSphere e em garantir se os nomes de hosts e as portas do container web estavam configuradas corretamente no console de administração. Clientes que possuam pelo menos uma licença do WAS ND podem ter o benefício das funcionalidades do Gerenciador Central de Instalação (Central Installation Manager, ou CIM). O CIM fornece ao administradores a capacidade de remotamente instalar novas aplicações ou aplicar pacotes de correção em um servidor, através do console de administração. Utilizando o CIM, um administrador pode instalar o gerenciador de publicações (deployment manager) e ao mesmo tempo criar um repositório CIM inicial. O administrador pode identificar servidores de destino para instalar o WAS, tanto como servidor isolado ou como parte de um cluster. O administrador especifica o nome do host, o tipo de sistema operacional, o nome do usuário e a senha que deseja utilizar no processo de instalação. O administrador também pode adicionar ao respositório mídias de instalação do WAS para sistemas operacionais suportados. Por exemplo, um repositório CMI instalado no Windows pode também conter mídias de instalação para Linux e Solaris. Uma vez que o administrador forneça a informação de conexão, e as respostas apropriadas a serem utilizadas durante o processo de instalação, pode-se iniciar o processo de instalação no console de administração, e periodicamente verificar o progresso da instalação. Através dessa funcionalidade, múltiplos nós podem ser configurados de forma simultânea. Os pacotes de correção (fix packs) do WebSphere também podem ser instalados de forma similar. O administrador instala os pacotes de correção no gerenciador de instalação, adiciona ao repositório CIM o instalador de atualizações e os pacotes de correção (ou opcionalmente realiza o download desses pacotes através do console de administração), e então seleciona quais servidores deseja instalar. O CIM automaticamente verifica se o servidor possui a versão correta do instalador de atualizações, e então realiza a atualização sem necessidade de interação ou intervenção do administrador. Nossos cenários administrativos para o WAS incluem o uso do CIM para o gerenciamento de ambientes baseados no WAS ND. O JBoss não possui funcionalidade equivalente para instalação automática de servidores de maneira remota ou distribuída. De forma geral, observamos que as tarefas administrativas com o WebSphere são mais simples de serem executadas e não exigem uma equipe administrativa altamente qualificada. As configurações personalizadas e avançadas são mais consistentes, pois seguem os princípios de menor permissão e menor surpresa. O console administrativo do WebSphere se mantém consistente por diversas versões e praticamente mantém a mesma estrutura de navegação. Apenas pequenas modificações foram realizadas, e administradores WebSphere experientes se adaptarão rapidamente a estas mudanças. Utilizando informaçções de suporte publicamente acessíveis, como, por exemplo no IBM InfoCenter, além dos arquivos de ajuda interna do console IBM WebSphere AS 7 e JBoss EAP 5 13

15 de administração, o administrador deve ser capaz de realizar uma instalação e configuração rápidas, tanto em ambientes isolados quanto em ambientes clusterizados. A administração do JBoss exige administradores altamente capacitados com profundo conhecimento do funcionamento interno do JBoss. Os desenvolvedores têm solicitado um console administrativo mais complexo para substituir o JMX console, e os nossos testes indicaram, de fato, que é necessário editar tanto no JXM console como em arquivos diretamente. Além disso, não recomendamos o uso do novo console de administração, até que essa solução amadureça e se torne mais confiável. A documentação continua difícil e focada nos desenvolvedores, ao invés de nos administradores de sistema. Na maior parte dos nossos cenários de testes, foi necessário o complementação ou substituição da documentação do JBoss através de informações encontradas nos grupos de discussões do JBoss, wikis e posts de blogs. Durante a avaliação do novo console de administração embutido e do JON, encontramos diversos resultados inconsistentes. Por exemplo, quando instalamos uma aplicação com erros no descritor de deployment, recebemos uma mensagem do JBoss informando que a publicação falhou. Em seguida, tentamos instalar a aplicação após corrigir o descritor e recebemos um erro, informando que a aplicação não podia ser publicada, porque já o tinha sido previamente. Infelizmente, a aplicação só apareceu na lista de aplicações publicadas quando foii reiniciado o servidor de aplicações. Após o reinício do servidor, a aplicação surgiu na lista, mas quanto tentávamos removê-la, o servidor informava que a aplicação não podia ser removida porque não estava instalada. Foi necessário reiniciar o servidor novamente, o que aparentemente corrigiu o problema. Em outro caso, um arquivo WAR foi instalado com sucesso no JBoss, mas não pôde ser desinstalado através do console de administração ou via o JON. No final, o arquivo WAR teve que ser manualmente apagado. Estes erros não aconteceram somente uma vez. Os experimentos foram repetidos diversas vezes. A documentação do JBoss também indica que a edição de arquivos, ou a edição simultânea das definições de configuração via arquivo ou console de administração não é completamente suportada. A documentação do JBoss EAP afirma explicitamente que os recursos instalados e modificados via console devem ser somente alterados via console de administração. Também afirma que mudanças realizadas no console não são diretamente persistidas no arquivo original de configuração (Capítulo 11 do Guia de Início Rápido do Console de Administração do JBoss EAP 5.0). Essse problema não é encontrado durante a utilização do console de administração WebSphere ou do cliente de scripting administrativo. Resumindo, os ambientes de produção do WebSphere são mais fáceis de serem instalados e configurados do que o ambiente do JBoss EAP, enquanto que a instalação do JBoss é mais simples e rápida no desktop do desenvolvedor. Administração de clusters Vantagem em TCO: IBM WebSphere Application Server Nossos testes foram focados na análise das seguintes condições relativas às operações de clusters no WebSphere e no JBoss. Os casos específicos analisados foram: As diferenças exigida na mudança de uma configuração em um único servidor com relação a uma configuração em cluster. Habilidade para configurar e administrar os clusters com segurança. Avaliação do esforço para adicionar um novo nó ao cluster. Configuração e tratamento dos vários cenários de recuperação de falhas relacionados com sessões HTTP e em operações de recuperação da JMS. A lista a seguir apresenta as principais observações e os fatores chave que afetaram os resultados do nosso caso de teste em relação ao TCO: Habilidades exigidas IBM WebSphere AS 7 e JBoss EAP 5 14

16 As configurações do servidor de aplicações em cluster no JBoss EAP exigiram conhecimentos técnicos avançados no planejamento e na definição da arquitetura do ambiente de cluster. Isso inclui um entendimento das questões relativas à segurança no design e configuração da comunicação entre servidores web e servidores de aplicações em cluster. Também é exigido um conhecimento profundo do comportamento interno do JBoss, incluindo mod_cluster, jbossweb e cache JGroups. A configuração do ambiente em cluster no WebSphere pode ser realizada através da leitura das informações disponíveis no InfoCenter e executando as receitas. Um entendimento básico da arquitetura do WebSphere é exigido, e pode ser obtido a partir da documentação disponível. Publicação de aplicações Com o JBoss AS 5.1 e o JBoss EAP 5, a instalação em um grupo de clusters (farm deployment) passou novamente a ser suportada oficialmente. A opção havia sido removida do JBoss AS 5.0 e Aparentemente, o JBoss EAP 5 adicionou diversas configurações com objetivo de aprimorar as configurações deste tipo de serviço ( FarmDeploymentsinJBossAS5x). Ela está habilitada por padrão nas configurações production e all. Dado o potencial mal uso ou confusão, as configurações padrões utilizadas nesse serviço aparentemente violam os princípios de menor surpresa e privilégio, e a documentação para este serviço é muito imprecisa. Com o WebSphere Application Server, a instalação da aplicação em um ambiente de cluster é muito similar à instalação em uma única máquina. A aplicação é instalada de forma centralizada no console de administração, e o cluster é selecionado como destino, ao invés de ser escolhido um servidor isolado. Estas mudanças, então, são automaticamente sincronizadas para os nós. Criação de clusters Conforme mencionado na seção anterior, configurar um cluster no JBoss é uma tarefa muito simples e pode até ser feita acidentalmente, somente utilizando as configurações padrão. Contudo os passos para realizar a configuração correta e o isolamento de múltiplos clusters na mesma subrede e requerem mais tempo e esforço. Criar um cluster utilizando o WAS ND é um processo mais controlado. Para adicionar nós em um cluster, precisam ser explicitamente adicionados ao cluster por um administrador. Ao contrário de clusters do JBoss, não se pode criar clusters acidentalmente utilizando a instalação padrão. Comunicação segura no cluster A adição de um nó inseguro ao cluster é muito mais fácil no JBoss AS do que no WAS ND. Os impactos dessa funcionalidade serão discutidos em detalhe posteriomente neste documento. Por padrão, a comunicação entre nós em um cluster do WAS ND utiliza SSL e LTPA para a comunicação dentro do cluster. Instalação e inclusão de nós Utilizamos a funcionalidade do Gerenciador de Instalação Central (CIM) do WebSphere para instalar e atualizar nosso cluster WebSphere. Não existe funcionalidade equivalente ao CIM no JBoss. Mais detalhes relativos a nossas experiências com o CIM podem ser encontrados posteriormente neste documento. Constatamos que o uso da ferramenta reduziu muito a quantidade de tempo humano envolvido no setup e configuração de servidores de aplicações, quando utilizamos o WAS ND (tanto para servidores clusterizados quando para servidores isolados federados). Isso simplificou enormemente o processo de configuração do cluster, porque nos deu a opção de adicionar um nó ao servidor como parte do processo de instalação. Adicionar um novo nó ao cluster no JBoss exige o mesmo esforço que a instalação de um novo IBM WebSphere AS 7 e JBoss EAP 5 15

17 servidor. Todos os passos devem ser manualmente realizados através da linha de comando. A maior parte dos arquivos pode ser copiada de um servidor para outro, mas isso pode exigir modificações para preservar o identificador único de cada nó. Replicação de sessões HTTP A replicação de sessões HTTP é difícil de ser configurada, embora a documentação para configuração do JBoss neste aspecto evoluiu muito desde os últimos releases. Contudo, durante os nossos testes de replicação de sessões HTTP descobrimos que algumas configurações não possuem impacto mensurável. A implementação de replicação de sessões no JBoss não pode ser realizada no JON e requer acesso para modificar tanto o descritor de instalação web.xml quanto o jbossweb.xml. O WebSphere suporta diferentes abordagens de replicação de sessões HTTP. As opções disponíveis são: a persistência de sessões em banco de dados; de memória para memória (memory-to-memory) através de grupos; ou de memória para memória (memory-to-memory) usando a recuperação de falhas ativa e passiva. Essa funcionalidade pode ser configurada através do console de administração, ou com a ferramenta de linha de comando wsadmin; não é necessário fazer qualquer mudança nos descritores de instalação para habilitar a replicação de sessões. Os resultados referentes aos testes de falhas podem ser encontrados posteriormente nesta documentação, incluindo situações onde o JBoss resultou em interrupções perceptíveis para os clientes. Recuperação de falhas do JMS Ambos os servidores de aplicações exigem um administrador sênior para configurar adequadamente o serviço JMS para operações de alta disponibilidade. O WebSphere é menos complicado para configurar através páginas do barramento de integração de sistemas (SIBus), no console de administração. O JBoss requerer modificações em uma série de arquivos XML para configurar adequadamente o serviço JMS em um ambiente de cluster, incluindo a configuração de um data source JDBC e de vários arquivos de configuração. Os parâmetros de linha de comando no servidor também precisaram ser modificados, para incluir um único id de nó e garantir que cada servidor JMS fosse identificado unicamente dentro de um cluster. O JBoss utiliza a mesma abordagem de multicasting para localizar servidores JMS e requer o mesmo cuidado para separação adequada dos nós. Em contraste, o WebSphere utiliza configurações explícitas para identificar quais servidores devem fazer parte do barramento SI Bus. Resultados de testes com falhas podem ser encontrados posteriormente neste documento. Em resumo, apesar de o JBoss tentar simplificar as configurações de cluster e corrigir a tendência de criar um cluster ad hoc com as condições padrões, constatamos que o processo de configuração do JBoss é manual e propenso a erros, tendo-se trabalho significativo para validar as configurações apropriadamente. Em um ambiente com um único cluster JBoss é simples configurar as operações do cluster; no entanto, em um ambiente mais complexo (como um cluster de teste de aceitação e cluster de produção) torna-se mais difícil a configuração e gerenciamento. Nossa experiência com o WebSphere, especialmente quando configuramos os clusters usando o Gerenciador de Instalação Central (Central Installation Manager, CIM), é que a instalação do nó e criação do cluster é um processo relativamente simples. As habilidades necessárias para gerenciar os servidores autônomos são as mesmas a serem usadas no WAS ND, que usa uma interface de usuário consistente para administração. Além disso, as configurações padrão são adequadas e eliminam o trabalho de investigação, quando é necessário criar configurações de ambientes que variam em tamanho e complexidade. IBM WebSphere AS 7 e JBoss EAP 5 16

18 Administração da segurança Vantagem em TCO: IBM WebSphere Application Server Os testes se concentraram na configuração de diversos aspectos de interfaces administrativas. O ambiente foi configurado para usar o Active Directory como servidor LDAP. O caso de teste requer o uso de grupos administrativos no LDAP e o gerenciamento de senhas, para controlar os acessos e restringir as funções administrativas. Para o JBoss EAP, é usado o console JMX. A lista a seguir apresenta os principais fatores e conclusões: Segurança administrativa A proteção por senha do JMX e do console de administração interno é agora um passo obrigatório durante a publicação no JBoss EAP 5. No mínimo devem ser configurados nome do usuário e senha em dois arquivos diferentes (sendo um arquivo do console JMX e outro para o console administrativo interno). O acesso de segurança administrativa no JBoss é mais difícil e não é tão completo quando comparado ao WAS e ao WAS ND, devido às funcionalidades adicionais fornecidas pelo WAS e o WAS ND, não são suportadas no JBoss. Um administrador experiente em JBoss pode proteger o console administrativo em aproximadamente a mesma quantidade de tempo que um administrador sem experiência em WebSphere protegeria o WAS e o WAS ND. No entanto, nos cenários de testes, um administrador inexperiente de JBoss levou cerca de seis vezes mais tempo para configurar a autenticação no LDAP no JBoss em comparação com o WAS. Ausência de padrões para configuração de segurança em cluster no JBoss EAP Muitas falhas de segurança têm origem de dentro da empresa. Essa quantidade de falhas podem ser desde pequenos problemas, até a perda de todos os dados e a queda completa da rede. Algumas formas de falhas podem também resultar na exposição externa de recursos privados da rede. O JBoss não fornece capacidade para criptografar a comunicação dentro do cluster, e permite que instâncias de servidores não autorizadas sejam adicionadas ao cluster, contanto que o intruso saiba o endereço IP de multicast do cluster. O modelo empregado pelo WAS ND pode ser configurado para obrigar a comunicação segura entre os nós do cluster e o gerenciador de publicações, e é habilitado por padrão. Novos nós não podem ser adicionados ao cluster, exceto com consentimento expresso do administrador, ao usar as ferramentas de federação fornecidas com o WAS ND. A configuração padrão do JBoss EAP pode levar a vulnerabilidades de segurança Formação de cluster automático Como discutido neste documento, o JBoss automaticamente formará clusters quando usado com a configuração all ou production. Isso pode levar a resultados inesperados e potenciais riscos de segurança, já que alguns passos adicionais precisam ser tomados para separar um nó do cluster. Serviços de farming Por padrão, cada nó de um cluster do JBoss participa do serviço de publicação de aplicações distribuídas em uma farm, para outros nós do cluster. Isso significa que se alguém criar um novo nó e adicioná-lo no cluster, ambos poderiam receber um cópia das aplicações publicadas e de suas configurações, e publicar suas próprias versões no cluster. Avisos do servidor e multicast o mod_cluster é um serviço novo do JBoss para conectar servidores web e servidores de aplicações JBoss. É considerado um substituto para o mod_jk. Por padrão usa o multicasting de IP para vincular servidores web e servidores de aplicações. Em sua configuração padrão, um servidor de aplicações permite que qualquer servidor web com o mod_cluster configurado processe requisições. Felizmente, há maneiras de desativar essa funcionalidade. Mas com a opção desativada, tivemos que reiniciar os servidores web sempre que um dos servidores de aplicações vinculado era reiniciado. IBM WebSphere AS 7 e JBoss EAP 5 17

19 Ausência de regras administrativas para segurança no JBoss O WebSphere fornece um modelo de segurança administrativa que permite o controle de acesso a funções administrativas com base em papéis (roles), tanto na interfaces administrativa para web como na linguagem de script. A segurança do JBoss dependente exclusivamente de permissões de acesso do sistema operacional, com base em arquivos XML. O WAS e o WAS ND usam diversos papéis para segurança administrativa, para a execução de diferentes tarefas administrativas (Operador, Administrador, Monitor, Auditor de Segurança, Publicador, Configurador etc.); também permite que os usuários limitem o acesso aos recursos de diferentes administradores (por exemplo, Pedro pode gerenciar a Aplicação A, mas não a Aplicação B). Essa funcionalidade permite que administradores de sistemas controle mais refinadamente quem pode executar diferentes funções na administração do servidor de aplicações. O JBoss não apresenta conceito similar. O JON tem suporte para papéis (roles) e pode mapear papéis dos usuários para ações e recursos. Como não fomos capazes de fazer o JON funcionar de forma confiável, os administradores serão forçados a configurar manualmente, editando os arquivos do sistema. Mas isso eliminaria os benefícios dos papéis executados pelo JON. Auditoria segura de ações administrativas Vantagem em TCO: IBM WebSphere Application Server Em muitas empresas, um registro de auditoria de todas as mudanças de configurações do sistema precisa ser mantido. Como o JBoss mantém todas as informações de configurações em arquivos XML, é fácil fazer mudanças nas configurações sem a supervisão de um software que controla as alterações. As mudanças precisam ser manualmente registradas e revisadas, ou um processo deve ser desenvolvido para garantir que as alterações estão sendo registradas. O WAS pode ser configurado para registrar todas as mudanças feitas nas configurações, que podem então ser enviadas para a revisão de auditores. Há um role especial Auditor no WAS que possui esta capacidade. Os usuários com esta permissão podem verificar e modificar as definições das configurações para o subsistema de auditoria segura. Por exemplo, um usuário com a regra de auditor pode habilitar ou desabilitar o subsistema de auditoria segura, configurar as políticas de auditoria, e definir que os eventos de segurança precisam ser auditados. O auditor tem autoridade completa para ler e modificar as propriedades do subsistema de auditoria segura. O administrador pode ver, mas não pode modificar, as definições de auditoria. Publicação de aplicações Vantagem em TCO: IBM WebSphere Application Server O controle seguro e automatizado da publicação de aplicações é importante nos ambientes em que profissionais de operações e administração mantêm o ambiente de produção separado dos desenvolvedores e administradores. Nossos testes foram focados nas tarefas que requerem roteiros (scripts) para a publicação de uma aplicação em cluster, incluindo a definição de recursos (JDBC e JMS). A lista a seguir descreve os fatores chave e as descobertas que afetaram o resultado dos testes: Todas as informações de configuração no JBoss são mantidas em um conjunto de arquivos XML. Alguns arquivos podem ser alterados durante a execução, outros exigem reinicio do servidor. O WAS e o WAS ND também mantêm as configurações do servidor em um conjunto de arquivos XML, mas expõem o acesso das configurações através de uma interface web e ferramentas administrativas baseadas em linhas de comando. Algumas mudanças requerem o reinicio de ambos os servidores de aplicações. Com o WAS ND, a interface administrativa web do usuário indica quando o servidor precisa ser reiniciado após uma mudança. Com o JBoss, o administrador precisa distribuir manualmente mudanças em configurações no nível do IBM WebSphere AS 7 e JBoss EAP 5 18

20 cluster, ou desenvolver e testar scripts para tratar automaticamente dessa distribuição. Com o WAS ND, comandos administrativos podem ser aplicados a um servidor individual, a todos os servidores de um nó, ou a todo o cluster. O WAS e o WAS ND suportam JACL e versões baseadas em Jython da ferramenta interativa wsadmin. As mudanças podem ser muito refinadas (por exemplo, somente alterar a senha para uma fonte de dados JDBC). Com a funcionalidade Assistente de Comando do Console Administrativo do IBM WebSphere, os comandos do Jython podem ser acessados, com base em ações executadas manualmente no Console Administrativo. Isso pode ser usado para gerar scripts para uso em outros ambientes ou publicações. A criação de scripts para JBoss normalmente é feita com scripts do Ant e do shell, que agregam e movem grupos de arquivos. O modo que o JBoss organiza as informações, dita a granularidade de como as mudanças são protegidas e distribuídas. Por exemplo, ao atualizar o tamanho do pool de threads do container web do JBoss, precisamos modificar o arquivo jbossweb.sar/server.xml. Este arquivo contém pelo menos uma configuração que é especifica ao nome do servidor, na identificação dos nós do cluster. A quantidade de scripts necessária para definir o tamanho do pool de threads sem afetar o nome do servidor exige mais que uma simples cópia de arquivo ou scripts Ant/shell; requer uma ferramenta de script mais poderosa, que não é fornecida pelo JBoss. No JBoss, a implementação para gerar a trilha de auditoria deve ser feita pelo usuário, via scripts. Os arquivos de ambiente do JBoss EAP são normalmente mantidos em um sistema de controle de versões, como o Subversion; os scripts do wsadmin podem ser gerenciados como parte do processo de promoção entre ambientes. Com o WAS e o WAS ND, as mudanças resultantes da execução de scripts ou ações do usuário no console de administração são registradas em um arquivo de log do servidor. Ao testar a publicação de aplicações, encontramos alguns erros no JBoss, reportados por outros usuários no JIRA público do JBoss (veja o Apêndice D). Outras economias podem ser feitas ao usar o novo WebSphere Cloudburst Appliance, que permite executar configurações do cluster inteiro dentro da nuvem de recursos gerenciados pelos hypervisors (gerenciadores de máquinas virtuais), em questão de minutos. Essas economias adicionais não foram incluídas neste estudo. Não há produtos comparáveis oferecidos pelo JBoss. Recuperação de falhas e velocidade de reestabelecimento Vantagem em TCO: IBM WebSphere Application Server Cedo ou tarde, as coisas irão parar de funcionar. Há muitos tipos de falhas, como erros humanos, sobrecarga do sistema, defeitos da aplicação, falha do hardware etc. O ideal é evitar completamente as falhas, mas quando acontecerem, a recuperação deve ser rápida, sem perdas significativas de serviços essenciais. Isso significa que seu servidor de aplicações, precisa transferir os logs de transações, filas de JMS e outras informações críticas para máquinas de backup em um cluster, ou talvez para um cluster completamente diferente. O WAS fornece uma implementação bem madura para esses recursos, através do Gerenciador de Alta Disponibilidade (High Availability Manager, HA) e fornece um mecanismo muito rápido para replicação de dados. Por exemplo, o tempo normal para recuperar todas os destinatários d JMS de um servidor é inferior a 15 segundos, quando são usadas as configurações recomendadas do HA. Em nosso estudo, testamos o tempo da replicação de memória-para-memória para recuperar de uma falha, comparando os servidores WebSphere e JBoss. Nossos testes com o WebSphere indicaram que a recuperação de falhas levaria menos de dois segundos. Nos testes de falhas na replicação de sessões HTTP, foram usados os seguintes passos, tanto para o WebSphere como para o JBoss. 1. Iniciar múltiplos nós dentro do cluster. 2. Iniciar um único servidor web. IBM WebSphere AS 7 e JBoss EAP 5 19

21 3. Lançar um número leve de usuários virtuais usando nosso gerador de carga. 4. Reciclar cada nó do cluster sem interrupções abruptas. 5. Derrubar um servidor de aplicações usando kill Acompanhar os arquivos de log dos servidores as taxas de sobrevivência e taxas de erros na aplicação. 7. Iniciar manualmente o servidor que foi derrubado. 8. Derrubar outro servidor de aplicações usando o kill Manualmente reiniciar o servidor que foi derrubado. Os resultados com o WebSphere foram: Ao usar a funcionalidade Ripple Start do console de administração, esperávamos que cada servidor iniciasse e parasse sem problemas. Em vez disso, o servidor de aplicações fez uma parada imediata e em seguida inicializou. Esse comportamento não era esperado. Iniciar e parar manualmente os servidores individualmente utilizando os comandos stopserver.sh e startserver.sh e o console de administração funcionaram como esperado. As requisições em execução finalizaram e as requisições subsequentes da mesma sessão foram encaminhadas para outro servidor de aplicações. Derrubar manualmente os servidores de aplicações usando o comando kill-9 resultou em uma notificação em menos de um segundo para cada servidor, e as requisições subsequentes foram automaticamente enviadas para os servidores restantes. Em uma instância que foi derrubada, observamos que uma transação de banco de dados que estava em execução havia sido desfeita em outro servidor, porque a instância do servidor derrubado não havia finalizado a transação. Este foi o comportamento apropriado e esperado. Não foi necessário reiniciar o servidor web durante esse teste. Nossos resultados com o JBoss não foram tão positivos: Ao parar o servidor de aplicações através do script de shutdown.sh, constatamos que as sessões foram transferidas para um servidor secundário em poucos segundos. O resumo a seguir descreve os eventos e passos realizados para restaurar a conectividade: Infelizmente o mod_cluster continuou enviando requisições para o servidor de aplicações que foi parado. Ao iniciar o servidor de aplicações novamente, constatamos que o servidor web estava indisponível para se ligar com outros servidores de aplicações, devido a uma assinatura inválida reportada pelo servidor web. Então reiniciamos o servidor web e as operações foram retomadas normalmente; depois o servidor web e os servidores de aplicações estavam disponíveis para serem vinculados novamente. Diversos ajustes na replicação de sessões foram feitos para melhorar o comportamento de replicação, mas não tiveram resultado perceptível. Por exemplo, ligar/desligar a opção stickysessionforce não evitou a necessidade de reiniciar o servidor web (a documentação indicava que isso seria possível). Quando forçamos a parada do servidor através do comando kill-9, os resultados foram um tanto imprevisíveis. Algumas instâncias de sessões não foram redirecionadas para os servidores que restaram, e o estado da sessão foi perdido para aquelas instâncias. Isso parece estar relacionado com a configuração do mod_cluster ou com a replicação de sessões. IBM WebSphere AS 7 e JBoss EAP 5 20

22 O maior problema durante os testes da replicação de sessões com o JBoss foi a necessidade de reiniciar o servidor web depois de reiniciar o servidor de aplicações. Este problema pode causar interrupções no cliente mesmo se houvesse uma farm web com múltiplos servidores web, já que cada servidor web precisaria ser reiniciado. Nos testes de recuperação de falhas com JMS, foram usados os seguintes passos, tanto no WebSphere como no JBoss: 1. Iniciar múltiplos nós dentro do cluster. 2. Iniciar um cliente de teste para enviar mensagens JMS para a fila. 3. Reciclar cada nó do cluster com shutdown. 4. Derrubar um servidor de aplicações usando o comando kill Acompanhar nos arquivos de log dos servidores as taxas de sobrevivência e de erros na aplicação. 6. Iniciar manualmente o servidor que foi derrubado. 7. Derrubar outro servidor de aplicações usando o kill Iniciar manualmente o servidor que foi derrubado. Os resultados com o WebSphere foram: Ao usar a funcionalidade Ripple Start do console de administração, esperávamos que cada servidor iniciasse e parassem sem sustos. Em vez disso, o servidor de aplicações fez uma parada imediata e em seguida iniciou. Este comportamento não era esperado. Iniciar e parar manualmente os servidores individualmente usando os comandos stopserver.sh e startserver.sh e o console de administração funcionaram como esperados. A recuperação das transações para os outros servidores foi tranquila. Derrubar manualmente os servidores de aplicações usando o comando kill-9 resultou em uma notificação para cada servidor, e as requisições subsequentes foram automaticamente enviadas para os outros servidores do cluster. De maneira similar aos resultados com a replicação da sessões HTTP, os testes com o JBoss não foram tão positivos: Ao parar o servidor de aplicações usando o script shutdown.sh, constatamos que as requisições foram transferidas para um servidor secundário em poucos segundos. Depois de parar o segundo servidor e então iniciar o primeiro novamente, começamos a ver erros no cliente. Depois de algumas pesquisas, identificamos o problema JBMESSAGING-1743 ( jboss.org/browse/jbmessaging-1743). Em resumo, apesar da disposição do JBoss para formar clusters automaticamente, suas operações em cluster não são tão confiáveis como no WebSphere. Monitoramento de servidores Vantagem em TCO: IBM WebSphere Application Server Como parte dos testes em servidores isolados, também avaliamos o console de administração embarcado (também conhecido como Embedded-JOPR), novo no JBoss EAP 5. Os testes identificaram vários problemas, listados a seguir: Como parte dos nossos testes, publicamos uma aplicação (arquivo EAR) com informações erradas para testar a solução de problemas. O console de administração reportou um erro ao publicar a aplicação; IBM WebSphere AS 7 e JBoss EAP 5 21

23 no entanto, falhou ao desfazer a instalação, e a versão anterior que estava correta ficou indisponível para servir as requisições dos usuários. Tentativas subsequentes de publicar a aplicação com o descritor de publicação correto resultaram em erros indicando que uma aplicação com o mesmo nome já existia, mesmo depois que a aplicação não era mais apresentada na lista de aplicações publicadas. Depois de reiniciar o servidor de aplicações, a aplicação apareceu na lista de aplicações publicadas, em estado de erro. O WebSphere não apresenta o mesmo comportamento com falhas na instalação ou na atualização de aplicações. Um instalação com falhas é desfeita, e se for uma instalação nova, não deixa vestígios. Em caso de atualização da aplicação, a instalação com falhas é completamente desfeita, e a última publicação com sucesso permanece disponível e funcionando corretamente. Muitas tarefas administrativas dentro do JBoss precisam ser manualmente modificadas, em um ou mais arquivos de configuração do sistema de arquivos do servidor de aplicações. Por exemplo, aumentar o pool de threads de um container web ou configurar a integração do servidor web ainda requer uma atualização no arquivo de configuração em XML. A edição direta nos arquivos em XML, além de ter potencial para introduzir erros de digitação, levando a erros de configuração, representa um furo de segurança, porque o acesso administrativo não pode ser segregado em diferentes papéis e não é possível se fazer auditoria de mudanças. Como parte do exercício de otimização do desempenho, avaliamos a capacidade interna de cada ferramenta. Para o JBoss, utilizamos o console JMX interno e para o WebSphere usamos as capacidades inclusas do PMI e do Tivoli Performance Viewer no console administrativo. Aqui está o resumo da avaliação: O console JMX do JBoss contém poucas opções e usa uma convenção de nomes pouco clara para os MBeans do JMX. Para conhecer os itens é preciso conhecer a fundo a arquitetura fundamental do JBoss e os componentes envolvidos. Atualmente, não é possível acompanhar múltiplos valores de diferentes recursos; por exemplo, acompanhar o tamanho do pool de conexões com o banco de dados e o número atual de threads de um container web. Para isso é preciso usar múltiplas janelas do browser, ou manualmente navegar entre as páginas. No WebSphere, a interface de usuário do Tivoli Performance Viewer (TPV) não é intuitiva, mas permite acompanhar múltiplos recursos ao mesmo tempo. A interface de usuário do TPV poderia ser feita com um front-end rico usando RIA (Rich Internet Application), para eliminar o recarregamento constante do IFrame utilizado atualmente. O WebSphere fornece internamente o Tivoli Performance and Diagnostic Advisor (TPDA), que fornece um assessor que ajuda a refinar o sistema para otimizar o desempenho e fornecer recomendações quanto a configurações ineficientes, através da coleta de dados do PMI (Performance Monitoring Infrastructure). Por exemplo, o TPDA pode sugerir configurações opcionais para o tamanho do cache do HTTPSession, ou configuração do pool de conexões JDBC, o tamanho do pilha da JVM, e muitas outras configurações com base nas análises e comparações da carga de trabalho da versão atual com o estado anterior do sistema ( publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/ zseries/ae/c%20prf_choosingperfadvisor.html). Para completar os testes no console JMX e o novo console administrativo interno, também testamos o JBoss Operations Network (JON). A seguir temos um resumo da avaliação: O JON é lento para responder a operações. Por exemplo, depois de adicionar um script para o JBoss, o JON levou pelo menos cinco minutos para responder. Ao verificar através de outra instância, era mostrado que o script havia sido criado e disponibilizado, apesar de a execução no servidor JON indicar uma situação pendente. O monitoramento de status no JON é um problema. Treze minutos depois de executar o script run. sh para iniciar o servidor, o console mostrava o status de Em Progresso. Quinze minutos depois o script que estava executando mudou o status para Falha com uma mensagem de erro time out. Manualmente verificando a lista de processos em execução, no servidor físico, indica que o servidor foi iniciado com sucesso. Os status dos servidores JBoss não são precisos no JON. Todas as instâncias do JBoss no cluster IBM WebSphere AS 7 e JBoss EAP 5 22

24 estavam reportados como parados, quando eles de fato estavam em execução. O JON não foi capaz de parar uma instância que estava em execução do JBoss EAP. A resposta foi que o servidor já estava parado. Mas o servidor que foi parado ainda continuava em execução. Depois de expirar o tempo da sessão do JON, tentamos fazer o login novamente mas houve uma falha com uma mensagem de erro indicando que a fonte de dados do backend está indisponível. Compatibilidade retroativa para aplicações Vantagem em TCO: IBM WebSphere Application Server Além da atualização do servidor e custos adicionais de instalação e configuração, pode haver custos de desenvolvimentos associados a uma atualização. O JBoss não fornece o mesmo nível de compatibilidade com as versões anteriores de aplicações que o WAS e o WAS ND. A IBM fornece o compromisso de suportar as atualizações N-2 para características do produto. O JBoss não se pronuncia publicamente sobre a compatibilidade com versões anteriores em sua documentação; e notas de lançamento do JBoss 5 indicam que várias áreas de compatibilidade com as versões anteriores foram quebradas. Os resultados indicam que a versão do J2EE 1.4 da aplicação de testes usada na análise anterior (WAS V6.x vs. JBoss 4.x) era capaz de executar sem mudanças ou ajustes de configuração no WAS 7; no entanto a mesma aplicação não executaria mais no JBoss AS 5.0. Quando comparamos a aplicação JBoss AS 5.0 com o JBoss AS 5.1 (um componente do JBoss EAP 5), constatamos que a compatibilidade foi quebrada entre estas duas versões. Verificamos que a razão do problema era um bug no container EJB3, que foi depois corrigido na versão liberada do JBoss EAP 5 em novembro de Quando migramos da versão 7 do WebSphere para a correção 11 (v ), nenhum problema foi encontrado na aplicação como resultado do processo de atualização. Migração e atualização do servidor Vantagem em TCO: IBM WebSphere Application Server Nosso estudo é baseado no pressuposto que haverá uma nova versão para atualizar o ambiente inteiro no período de avaliação de cinco anos. Por exemplo, no ano zero do estudo, a versão 7 do WAS seria instalada e no ano três, os servidores seriam atualizados para a versão 8. Para a análise de custos desse estudo, usamos os resultados dos cenários atualizados da versão 6.1 para 7 do WAS e para a migração do JBoss 4 para o JBoss 5. Em nosso cenário, atualizamos do JBoss 4 para o JBoss 5, usando a abordagem do JBoss, de instalar e configurar um novo servidor e manualmente republicar todas as aplicações para o novo servidor. Isso inclui a migração manual das fontes de dados e de outros recursos do Java EE. Todos os arquivos de configuração foram registrados e configurados manualmente. Juntamente com alguns problemas de compatibilidade retroativa, o processo de atualização do JBoss 4 para o JBoss 5 pode ser mais difícil. Para uma organização com um pequeno número de servidores de aplicações, isso pode ser um problema pequeno, mas qualquer organização com mais que alguns poucos servidores irá achar o processo demorado e potencialmente sujeito a erros. Pela comparação, as mídias de instalação do WAS incluem uma ferramenta de migração que irá exportar as definições da versão anterior do WebSphere Application Server. Este teste foca na atualização e migração de uma aplicação de uma versão anterior para a versão atual do servidor. Isso envolve a migração da versão legada do J2EE 1.4 da aplicação DayTrader do WAS e WAS ND 6.1 para a versão 7, e a migração do JBoss 4 para o JBoss 5. A publicação da versão J2EE 1.4 do DayTrader no WAS ND usa o assistente de migração interno. A aplicação funcionou sem modificações ou reconfiguração de recursos do JDBC ou do JMS. IBM WebSphere AS 7 e JBoss EAP 5 23

25 A publicação da versão J2EE 1.4 do DayTrader falhou ao ser executada no JBoss 5. O JBoss não fornece um assistente de migração; deste modo a configuração das definições e publicação das aplicações precisam ser copiadas manualmente em diversos arquivos XML, da versão instalada anteriormente para os novos arquivos XML. A configuração foi validada, comparando-se com a versão do ambiente do JBoss 4, para garantir que os parâmetros de configuração e aplicação fossem os mesmos. Em geral, isso significa que o ciclo de publicação e depuração precisa ser repetido para cada aplicação. Para grandes instalações isso pode consumir bastante tempo. O mesmo conceito se aplica à nova versão do JBoss algumas vezes com o mesmo número de revisão (revision number). Como o processo de instalação do JBoss não atualiza as configurações anteriores, para a maioria das atualizações de maior porte, é preciso migrar as aplicações manualmente como descrito anteriormente. Os reparos (hot fixes) são tratados de forma diferente no WebSphere e no JBoss. Os reparos ou correções temporárias para o WebSphere são normalmente instaladas usando o utilitário Update Installer, enquanto que no JBoss os reparos são aplicados manualmente no servidor. Pode-se desfazer um reparo no WebSphere também usando o utilitário Update Installer; para o JBoss isso precisa ser executado manualmente. Durante a verificação inicial da aplicação, tentamos instalar alguns reparos no JBoss, mas com resultados negativos. O próprio servidor de aplicações falha ao iniciar depois de aplicar os reparos usando a documentação fornecida pela JBoss para cada reparo. Identificação e solução de problemas Vantagem em TCO: IBM WebSphere Application Server Usando as mesmas ferramentas, o processo de configuração da aplicação de testes para publicar com sucesso no JBoss levou cinco vezes mais tempo que no WAS. O tempo adicional foi causado pela documentação incorreta ou incompleta, e também pela falta de suporte ao problema e de ferramentas de diagnóstico. A solução de problemas no JBoss exige tentativa e erro, com base em informações incompletas e incorretas espalhadas na documentação oficial, fóruns e blogs. Foi necessário alterar o código, devido a bugs na implementação do especificação do EJB3 do JBoss, além de problemas com o dialeto do Hibernate para IBM DB2. É importante mencionar que o tempo para corrigir o problema do dialeto do DB2 não foi incluído no tempo necessário para iniciar a aplicação no JBoss, já que provavelmente uma plataforma de banco de dados diferente não apresentaria o mesmo problema. Quando configuramos a aplicação para o WAS e WAS ND, não foi necessário modificar o código, e problemas encontrados durante a configuração da aplicação foram facilmente identificados usando o InfoCenter da IBM, e ferramentas para determinação do problema. Durante a verificação da aplicação de testes, tanto para o JBoss como para o WAS, também constatamos que foram feitas melhorias significativas no WAS e no WAS ND, com relação a versões anteriores. Não foi preciso reiniciar o servidor de aplicações depois de configurações (ex.: configurar o fornecedor do JDBC e fonte de dados, assim como recursos JMS). Na versão anterior do WAS, eram precisos reinícios frequentes, o que consumia bastante tempo. O JBoss exigiu reinícios frequentes, durante o processo de configuração. Em alguns casos, estes reinícios ocorreram para permitir que as mudanças tivessem efeito. Durante os testes, também constatamos os efeitos de introduzir erros ao editar manualmente os arquivos de configuração. Em alguns desses testes, paramos o servidor, apagamos o diretório temporário e republicamos a aplicação anterior para iniciar o servidor novamente. A tabela a seguir, resume a lista de situações em que foi necessário reiniciar o servidor: IBM WebSphere AS 7 e JBoss EAP 5 24

26 Ações Precisa reiniciar? WebSphere Mudar o classpath do provider do JDBC S S Ajustar o tamanho do pool de fontes de dados JDBC (no nível de célula) S S Ajustar o tamanho do pool de fontes de dados JDBC (em nível de nó ou servidor) Ajustar as configurações da fonte de dados JDBC (tamanho do pool, texto de conexão, usuário, senha, etc.) Adicionar um novo membro JMS no barramento (bus) ou nó S N Mudanças na configuração do JMS N S Republicar uma aplicação depois que a publicação falhou N S Vincular um servidor web a um servidor de aplicações N S N N JBoss S S A reinicialização do JBoss leva de 60 a 90 segundos, dependendo se a aplicação de testes foi publicada ou não. O reinício do WAS 7 foi sempre de 30 segundos, independente de se a aplicação de teste foi publicada ou não. A publicação da aplicação foi sempre 10 segundos no WAS, enquanto que no JBoss variou de 15 a 30 segundos por publicação. Também testamos os efeitos de erros comuns de configuração, tal como erros de digitação no nome JNDI nas referências a EJBs. Este teste no JBoss resultou em um NullPointerException lançado durante o processo de publicação. A causa exata do erro não foi facilmente identificável por causa dos poucos detalhes fornecidos sobre o erro. O suporte online no fórum do JBoss não ajudou a resolver esse problema. Se o suporte pago estivesse disponível, isso poderia exigir chamadas frequentes ao suporte. Ao contrário, o WAS fornece um código de erro que pode ser usado para determinar a causa do problema. A solução de problemas no WebSphere é muito mais simples que no JBoss. Muitos problemas encontrados nas configurações do WebSphere incluem códigos de erro que podem ser consultados online e referências para as correções apropriadas podem ser rapidamente encontradas. Por outro lado, o JBoss favorece o uso do mecanismo de tratamento de exceções do Java para reporte dos erros. Infelizmente, em muitos casos, a pesquisa por NullPointerException e vários pedaços da stack trace ou mensagens próximas retornaria poucos resultados úteis. Documentação e facilidade de manutenção Vantagem em TCO: IBM WebSphere Application Server Pode ser bastante difícil lidar com logs, rastreamento (tracing) e outros diagnósticos, especialmente em ambientes complexos. O JBoss EAP não fornece um mecanismo para acessar informações de erros ou arquivos de log fora do sistema de arquivos. O WAS e o WAS ND, no entanto, têm a habilidade para acessar arquivos de log, sem precisar acesso aos arquivos do SO. Os comandos administrativos e o console administrativo fornecem ferramentas para análise de rastreamento e reporte de erros sobre as falhas. Nossa experiência indica que os detalhes sobre erros reportados pelo WebSphere são mais consistentes, completos e acessíveis que os de erros do JBoss. No JBoss 4, a ajuda disponível em vários fóruns de suporte online e listas de era razoavelmente madura. O JBoss 5, no entanto, foi reescrito para usar a nova arquitetura de micro-container. Esta mudança de arquitetura coloca em dúvida a eficácia das muitas documentações do JBoss 4, quando aplicadas ao JBoss EAP 5. Nos testes, encontramos muitos erros que podem causar uma falha ao iniciar o servidor. Constatamos também que a documentação ficava cada vez menos confiável quando aplicada a configurações mais complexas, como em ambientes de produção com fortalecimento da segurança. Em nossos testes, foi difícil efetuar a análise da causa raiz de alguns problemas, devido à quantidade de mudanças necessárias na configuração para resolver tais problemas. Foi gasto muito tempo e esforço para meticulosamente registrar e IBM WebSphere AS 7 e JBoss EAP 5 25

27 validar cada alteração feita. Constatamos, ainda, que muitas postagens nos fóruns do JBoss e artigos de wikis fornecem informações conflitantes. Em alguns casos, isso se deve ao grande ciclo de atualizações do JBoss 5 e o número de defeitos que foram abertos e fechados durante o processo de desenvolvimento. Infelizmente, quando verificamos se as soluções propostas resolviam nossos problemas, geralmente descobríamos problemas adicionais, ou que a solução não atendia nossas necessidades. Uma tendência geral que observamos na documentação do JBoss é que é voltada mais para desenvolvedores do que para administradores. Por exemplo, muitos guias de inicio rápido são orientados para configurar o ambiente rapidamente para desenvolvimento simples oulocal, ao invés de configurações para uso em ambientes com múltiplos servidores. Gerenciamento de grandes topologias Vantagem em TCO: IBM WebSphere Application Server O WAS tem uma capacidade exclusiva chamada Gerenciamento Flexivel (Flexible Management), que permite submeter tarefas administrativas assincronamente para os servidores de aplicações registrados por agentes administrativos e por gerenciadores de publicações (deployment managers). As tarefas podem ser submetidas para um ou mais servidores, incluindo servidores dispersos geograficamente. O gerenciador de tarefas administrativas pode enfileirar tarefas administrativas diretamente em um nó de servidor de aplicações isolado, ou em domíncios clusterizados. O gerenciador de tarefas pode administrar de modo assíncrono as submissões de jobs e pode completar as seguintes tarefas: Configurar a submissão de tarefa para ter efeito ou expirar em um hora especifica. Especificar que a submissão da tarefa ocorra em um intervalo de tempo especifico. Notificar o administrador através de de que a tarefa terminou. O JBoss não tem funcionalidade parecida. Essa funcionalidade pode reduzir horas de trabalho de administradores, ou ser usada para evitar gastos com consultoria e suporte. Embora este estudo foque em cenários médios e grandes, abaixo listamos alguns cenários muito grandes e exemplos de situações onde o gerenciador de tarefas poderia ser útil. Observe que não incluímos esta capacidade em nossos cálculos de custos; mas para algumas empresas isso pode ser um fator significativo: Ambiente de filial de empresa Uma empresa tem milhares de lojas espalhadas geograficamente pelo continente. Cada loja possui alguns servidores de aplicações ou uma pequena célula de publicação em rede, que consiste de duas ou três máquinas. Cada loja é gerenciada localmente por equipes de operações. No entanto, cada loja também está conectada ao data center situado na matriz da companhia, potencialmente a milhares de quilômetros de distância. Algumas conexões com a matriz são feitas com a velocidade de modems. As matrizes usam o gerenciador de tarefas (job manager) para periodicamente encaminhar tarefas administrativas às lojas. Ambiente contendo centenas de servidores de aplicações Um administrador configura centenas de máquinas de baixo custo, executando clones idênticos de um servidor de aplicações. Cada nó do servidor, registrado com um agente administrativo, encontra-se registrado no gerenciador de tarefas. O administrador usa o gerenciador de tarefas para agregar comandos administrativos em todos os servidores de aplicações, como por exemplo, criar um novo servidor, instalar ou atualizar uma aplicação. Ambiente contendo dúzias de células gerenciadoras de publicações Um administrador configura centenas de servidores de aplicações, divididos em trinta grupos diferentes. Cada grupo é configurado em uma célula. As células são geograficamente IBM WebSphere AS 7 e JBoss EAP 5 26

28 distribuídas em cinco regiões, sendo cada região constituída de três a sete células. Cada célula é usada para suportar de uma a quinze filiais, totalizando 230 estabelecimentos suportados. Cada célula contém aproximadamente trinta aplicações, que rodam em clusters de dois nós de alta disponibilidade para tolerância a falhas, resultando em um total de servidores de aplicações. O administrador usa o gerenciador de tarefas para agregar comandos administrativos em todas as células, por exemplo, para iniciar e parar servidores, para instalar ou atualizar uma aplicação. Com base nos resultados de nosso testes práticos, gerenciar o JBoss em ambientes desse tipo pode ser muito difícil, sem a criação de um framework personalizado de gerenciamento de crescimento, similar ao que foi discutido anteriormente. Integridade transacional Vantagem em TCO: IBM WebSphere Application Server Dados de baixa qualidade irão acarretar à indústria bancária um aumento de 27 bilhões de dólares em custos operacionais ( O mesmo estudo indica que metade dos clientes permitem que seus bancos cometam erros somente duas vezes, antes de considerarem a troca por outro banco. O diagrama a seguir ilustra uma versão simplificada de uma transação de transferência monetária. Em muito bancos, o Núcleo do Sistema Bancário é uma aplicação separada do Internet Banking, Sistemas de Cartão de Crédito, e alguns outros sistemas não mostrados aqui. A operação de transferência monetária deve ser capaz de atualizar, com segurança, todos os sistemas relacionados, como se fossem uma única unidade de trabalho (XA) ou a execução de uma transação de longa duração. IBM WebSphere AS 7 e JBoss EAP 5 27

29 A integridade transacional é importante quando múltiplos passos relacionados precisam ser concluídos por uma transação bem sucedida. Por exemplo, o que aconteceria se um cliente iniciasse uma transferência de fundos entre duas contas e um dos servidores falhasse durante a transação? Idealmente, o sistema deveria ser capaz de detectar a falha automaticamente e tomar uma ação apropriada. Outra possível solução seria desfazer a transação e permitir que o usuário tente novamente. Se nenhum tratamento apropriado for tomado, os preciosos dados da transação, nos quais se incluem o dinheiro do seu cliente, podem ser perdidos ou incorretamente registrados. Uma falha de transação em um sistema crítico pode custar milhões de dólares para a companhia, em perdas de receita e satisfação do cliente. Com base nesse risco, é essencial que as aplicações tratem corretamente as transações e garantam que os dados corporativos acessados durante uma transação de negócio mantenham-se em um estado seguro e consistente, independentemente de qualquer falha que possa ocorrer no sistema ou no negócio. O WebSphere Application Server 7 fornece um mecanismo de transações altamente eficaz, construído sobre uma base sólida desde o momento em que foi introduzido, há mais de dez anos. Foi projetado para detectar e recuperar automaticamente problemas em transações ocorridos durante o commit em duas fases (two-phase commits). A versão 7 do WAS traz ferramentas poderosas, tais como um visualizador de logs de transações, além de passos simples para especificar as configurações de recuperação de transações. Essas habilidades ajudam a garantir a integridade da transações para usuários do WebSphere Application Server. Parece haver um problema no projeto do JBoss que impede o seu mecanismo de transações recuperar corretamente as transações duvidosas. O problema está documentado nas ocorrências de defeito no JIRA do JBoss (JBAS e JBAS JBAS-6244). O defeito descreve um problema de integridade na recuperação transacional do JBoss AS, mas não apresenta especificamente como se corrige o problema. A situação levanta a questão de saber se o JBoss pode automaticamente recuperar todas as falhas de integridade transacional. Além disso, parece não haver documentação sobre como configurar ou corrigir o JBoss para recuperação automática de problemas de integridade transacional na ocorrência de falha em transações distribuídas. Em vez disso, encontramos postagens em fóruns sobre o problema especifico de recuperação de transações com o JBoss Application Server, ou discussões sobre o problema de recuperação de transações que não informam como efetivamente corrigi-lo. Baseando-se em informações públicas, a IBM fez um estudo ( watch?v=uzwvxroe15y) para tentar determinar se o problema de integridade transacional no JBoss pode ser reproduzido, se está sendo consertado ou já foi resolvido (ftp://ftp.software.ibm.com/common/ssi/ sa/wh/n/wsw14068usen/wsw14068usen.pdf). Parece que o problema ainda permanece na versão 5.0 do JBoss EAP, e a situação de seu registro no JIRA continua como Critico-Não Resolvido. Isso significa que transações XA envolvendo bancos de dados, sistemas de mensageria, adaptadores e demais gerenciadores de recursos não podem ser seguramente recuperadas pelo JBoss, se a falha ocorreu durante a segunda fase do protocolo 2PC. Isso leva a uma perda de dados ou a custos significativos de mão-de-obra para analisar e recuperar manualmente cada instância que falhou. Deve-se notar que a recuperação manual é demorada, custosa e sujeita a erros adicionais afinal, é feita manualmente. Custos com treinamento Vantagem em TCO: IBM WebSphere Application Server Os treinamentos em WAS 7 e JBoss EAP 5, disponibilizados pela IBM e pela Red Hat, são divididos e focados em tópicos que tratam desde a publicação de aplicações até a administração. A análise do TCO tem como premissa básica que o treinamento para administradores e desenvolvedores será fornecido no período inicial dos cinco anos da análise, e novamente na metade deste intervalo de cinco anos, para dar conta do volume de negócios, crescimento ou atualizações maiores que venham a ocorrer. A quantidade e o nível das habilidades dos administradores, baseiam-se em resultados de análises práticas. Para o propósito deste estudo, usamos o tamanho da nossa equipe de estudo (três administradores). É importante notar que em grandes ambientes baseados no JBoss, o custo com treinamento pode ser elevado, devido à diferença de desempenho e ao aumento associado com o número de servidores necessário. IBM WebSphere AS 7 e JBoss EAP 5 28

30 Em nosso estudo, o montante dos custos com treinamento foi diluído no calculo do TCO. Em um período de cinco anos, o custo foi de $ para o treinamento em WAS ND, contra $ no caso do JBoss EAP uma diferença de 181%. CUSTOS NÃO INCLUÍDOS NESTE ESTUDO Nossos testes detalhados, descritos anteriormente, tentam cobrir os principais aspectos quantificáveis do TCO que uma organização pode encontrar na avaliação de servidores de aplicações. No entanto, não cobrem todos os fatores possíveis que afetam o TCO. Os testes não abrangem alguns fatores que podem impactar no TCO e no processo de seleção do fornecedor do servidor de aplicações. A forma como esses fatores são mensurados e afetam o TCO pode variar muito entre duas organizações, portantonão incluímos os resultados a seguir nas fórmulas usadas para calcular o TCO. É possível que para certas organizações, as considerações adicionais descritas a seguir, no agregado, excedam as considerações de custos discutidas nas sessões anteriores. As organizações que requerem alta qualidade de serviços em suas infraestruturas devem fazer uma análise de custo/benefício das capacidades discutidas a seguir. Virtualização de aplicações e instalações em grandes data centers A virtualização de infraestrutura de aplicações complementa o servidor, o storage e a virtualização da rede. É uma quarta categoria da virtualização do data center (veja a imagem a seguir) que permite seu negocio ultrapassar os limites da infraestrutura de TI, adicionando maior agilidade, reduzindo custos, e aumentando a eficiência operacional e a gerenciabilidade. O potencial impacto do WebSphere Virtual Enterprise (WVE) no TCO não foi considerado neste estudo. O WVE fornece capacidades para virtualizar a infraestrutura de aplicações, reduzindo custos operacionais e de energia para criar, executar e gerenciar aplicações corporativas e ambientes baseados na arquitetura orientada a serviços (SOA), em nuvens privadas. Além disso, os administradores podem publicar e utilizar recursos de modo rápido e ininterrupto durante períodos de pico, reagindo também aos picos/quedas inesperados na demanda de processamento em várias aplicações de missão critica. Os administradores podem também aplicar políticas que os auxiliem a garantir tempos de resposta e níveis de serviço, para que cumpram contratos de nível de serviço. O WVE pode ampliar os benefícios da virtualização de servidores, usando uma abordagem capaz de lidar com os possíveis problemas e limitações inerentes a algumas aplicações. O WebSphere Virtual Enterprise pode ser considerado como um hypervisor para servidores de aplicações, possibilitando combinar a virtualização de servidores com a virtualização da infraestrutura para aplicações, obtendo-se com isso as vantagens de ambas as abordagens. O JBoss não possui funcionalidades semelhantes para suportar ambientes de grande escala. O hardware, os custos de licenciamento e a redução de custos com mão-de-obra administrativa, resultam em uma grande vantagem no TCO do WebSphere quando comparado ao JBoss. IBM WebSphere AS 7 e JBoss EAP 5 29

31 Suporte a cloud computing De acordo com um estudo da IBM, o WebSphere Cloudburst Appliance pode reduzir em até 80% a quantidade de horas de mão-de-obra em software, quando comparado ao processo de publicação manual (veja referências). O JBoss não fornece capacidade similar. Embora a virtualização e a padronização possam reduzir no longo prazo o custo total de mão-de-obra, a tarefa de publicar um ambiente completo de software em uma imagem de VM, mantida por um servidor virtualizado, tem sido historicamente uma tarefa muito trabalhosa. Por exemplo, deve-se primeiro fazer a primeira publicação e configurar o SO com todas as atualizações (patches) necessárias. Depois o administrador deve instalar e configurar o servidor de aplicações e todos os componentes que o constituem (ex.: servidor HTTP etc), bem como patches e outras correções. Para as aplicações que precisam de um banco de dados, este componente é mais uma parte que precisa ser instalada e configurada. E há a própria aplicação. Publicar e testar manualmente uma aplicação completa, portanto, pode levar dias ou semanas, dependendo da complexidade do ambiente e da aplicação. Em um ambiente de cloud privativa, essa demora torna o processo inviável. O WebSphere Cloudburst Appliance (WCA) é especialmente projetado para lidar com esse problema. É disponibilizado como um hardware appliance e acumula mais de 10 anos de boas práticas em publicação no WebSphere Application Server (WAS), além de encapsular tudo isso em imagens predefinidas e customizadas, que podem ser distribuídas em vários hypervisors usados em servidores virtualizados. O uso de técnicas de scripting e automação reduzem muito o trabalho necessário para executar tarefas de publicação, e o WebSphere Cloudburst Appliance trabalha bem com o WebSphere Virtual Enterprise. Ambos podem fornecer valor significativo para os clientes do WebSphere. Custos com desenvolvimento de software Uma crença comum é que as soluções de código aberto incorporam mais rapidamente novos padrões e funcionalidades. Ao longo dos três anos de condução deste estudo, descobrimos que este não é mais o caso. Na verdade, no que diz respeito ao WebSphere e ao JBoss, a situação parece ter sido revertida. Com o WebSphere 6.1, a IBM introduziu o conceito de uma arquitetura modular, através do uso de pacotes gratuitos de funcionalidades. Esses pacotes permitem que as organizações tirem proveito dos novos padrões rapidamente, sem precisar esperar pela próxima versão completa do WebSphere. A versão 5 do JBoss marca a sua entrada em uma arquitetura de microcontainer modular, que permite compor diferentes configurações de servidor e potencialmente adaptá-las às mudanças de padrão de forma mais rápida. Além disso, embora o JBoss tenha sido o primeiro servidor de aplicações a suportar partes da especificação EJB3, ficou atrás da IBM e da Oracle ao passar pelos testes de compatibilidade com o Java EE 5. Qualidade e disponibilidade do suporte do fornecedor A qualidade do suporte do fornecedor pode ter um impacto direto nos custos da operação. A IBM disponibiliza suporte no idioma e horário locais em vários países. A IBM oferece vários níveis de suporte, que vão desde 9x5 (horário local) ao suporte 24x7. Além do suporte pago, a IBM oferece o InfoCenter. Ao longo dos últimos anos, a qualidade e a precisão da documentação disponível no InfoCenter tem melhorado. Por fim, a IBM definiu um calendário trimestral de lançamentos para os pacotes de correções e ajustes provisórios do WebSphere Application Server, e os hot fixes continuam sendo disponibilizados regularmente, quando necessários. A Red Hat fornece opções de suporte em 12x5 ou 24x7, mas em muitos lugares do mundo não há suporte no idioma nativo. A documentação é disponibilizada online, mas, como foi observado ao longo deste trabalho, apresenta muitas deficiências. Com relação aos pacotes de correções, aparentemente a RedHat não estabeleceu um período fixo para lançamentos de versões de manutenção, e os hot fixes são lançados conforme a necessidade. IBM WebSphere AS 7 e JBoss EAP 5 30

32 CONCLUSÕES Comparações entre o WebSphere e o JBoss geralmente se concentram apenas no ponto de vista do desenvolvimento de aplicações, e consideram apenas o conjunto de recursos e os custos de aquisição. Infelizmente, os custos de administração de longo prazo associados ao JBoss não são levados em consideração nessa equação. Muitas vezes, o custo zero inicial leva os desenvolvedores a favorecerem o JBoss. A nossa experiência e a análise deste estudo revelam que há muito mais fatores a serem considerados pelas organizações em seus processos de seleção, que vão além dos custos iniciais de aquisição. Nossas projeções indicam que, na medida que aumentam o tamanho e a complexidade das aplicações e das próprias organizações, os custos migram da aquisição do produto para atividades administrativas e operacionais. Além dos níveis mais altos de conhecimento exigidos para administração do JBoss EAP, observaram-se deficiências funcionais significativas quando o JBoss é usado em ambientes de aplicações corporativas de produção. Isso se deve tanto à ausência de funcionalidades importantes do produto, como a dificuldades associadas à sua administração. Faltam ao JBoss EAP 5 funcionalidades críticas em muitas áreas, como segurança, administração, compatibilidade retroativa e confiabilidade em ambientes de cluster. Ao examinar outros fatores, incluindo administração, manutenção do software e facilidade de integração, além de custos de desenvolvimento, constatamos que os produtos têm abordagens muito diferentes, que impactam significativamente o TCO. O JBoss 5 tem ainda deficiências significativas nas áreas de disponibilidade de suporte e de documentação confiável, que prejudicam o desenvolvimento e a administração dos sistemas. Por outro lado, o WAS 7 parece ser muito mais estável, além de ter continuado sua evolução com base em lições aprendidas com as versões anteriores do WAS. Após um longo ciclo de desenvolvimento e teste público da versão beta, o JBoss EAP 5 foi lançado em Muitos dos mesmos problemas encontrados em versões anteriores a este estudo ainda existem nesta versão, e poucos recursos novos foram adicionados ao produto. Enquanto isso, a IBM continuou a adicionar novos recursos e funcionalidades ao WAS, aumentando o seu valor para os clientes. A IBM empenhou recursos para garantir uma rota de migração de versões anteriores para as versões mais recentes do WAS, e forneceu ferramentas para auxiliar o processo de migração. O JBoss não apresentou nenhuma declaração oficial sobre o suporte a compatibilidade de versões anteriores e, em alguns casos, aplicações que funcionavam no JBoss 4, não funcionam mais no JBoss 5. Embora o WebSphere Application Server tenha um custo inicial de aquisição mais elevado, com o tempo essa diferença é compensada pelo baixo custo de administração, melhor desempenho, maior confiabilidade e, no geral, menores riscos. A conclusão principal é que, por mais que um servidor de aplicações open source possa parecer gratuito, na verdade não é. As organizações devem examinar cuidadosamente os custos e riscos associados a um servidor de aplicações, e escolher um produto com base no custo total de propriedade, TCO levando em conta a capacidade de seus profissionais, os ambientes e aplicações da empresa, e a sua tolerância a riscos. Sobre este estudo Este estudo foi encomendado pela IBM e realizado pela Summa Technologies. Todos os resultados do estudo são sustentados pela reputação sólida da Summa. Desde 1996, a Summa vem arquitetando e implementando aplicações comerciais para organizações de todos os tamanhos, incluindo empresas da Fortune 100. Os serviços de consultoria em TI da Summa ajudam as companhias na avaliação e implementação de estratégias modernas para aplicações distribuídas multicamadas. A Summa auxilia seus clientes a fazerem os investimentos corretos em tecnologia, a partir de um exame inicial do ambiente atual, e pela recomendação e implementação de soluções tecnológicas que melhorem a satisfação do cliente, a produtividade dos funcionários e o relacionamento com parceiros. Os autores deste relatório possuem, no agregado, mais de 35 anos de experiência no desenvolvimento e suporte a sistemas de grande escala. Para mais informações sobre a Summa, acesse IBM WebSphere AS 7 e JBoss EAP 5 31

33 APÊNDICE A METODOLOGIA DE ANÁLISE Esta seção fornece uma visão geral sobre a metodologia usada na realização das análises para o atual relatório. A análise e o modelo de TCO propiciaram uma comparação quantitativa e qualitativa entre o JBoss e o WAS ND com base em uma combinação de testes e pesquisas sobre os produtos, além da execução de uma série de testes planejados de validação. Os servidores de aplicações são usados para suportar uma ampla gama de ambientes e tipos de aplicações. Para realizar a nossa análise, primeiramente consideramos características de diferentes classificações de ambientes, e organizamos a análise em quatro categorias. Categoria um Pequeno: ambientes que hospedam aplicações pequenas e não-críticas, ou soluções de software empacotadas que necessitem de um servidor de aplicações embutido. Esses aplicativos podem exigir menos segurança, menor disponibilidade e uma frequência de administração menor em comparação a outras categorias. Características, como clusterização e replicação de sessões para o balanceamento de carga ou failover, não são necessárias. Essas aplicações são normalmente utilizadas em organizações muito pequenas. Categoria dois Médio: foco em aplicações departamentais, em empresas de médio e grande porte. As aplicações são menores em tamanho, quando comparadas às categorias três e quatro, mas podem exigir alguma combinação de segurança, clusterização ou administração mais frequente. Categoria três Grande: focado em ambientes de aplicações web, o que compreende uma variedade ampla de tamanhos e complexidades. Estes ambientes, na forma que definimos, possuem de seis a vinte servidores, com muitos exigindo clusterização para manter confiabilidade, escalabilidade, disponibilidade e desempenho. Esses ambientes podem também exigir tratamento de segurança mais abrangente do que a primeira categoria, devido à criticidade e à exposição da aplicação. Atributos comuns de aplicações e publicações neste ambiente incluem: Hospedagem de várias aplicações independentes e integradas; Necessidade de níveis de segurança que vão de moderado a elevado, para infraestrutura e aplicações; Requisitos de alta disponibilidade, que conduzem à necessidade de clusterização de serviços; Divisão de responsabilidades entre desenvolvedores e administradores, por razões de cumprimento de regulamentação (ex.: Sarbanes-Oxley), eficiência, ou por outras razões organizacionais; Políticas sólidas de gestão de mudanças, para gerenciar as configurações do software e do servidor, IBM WebSphere AS 7 e JBoss EAP 5 32

34 que são promovidas de ambientes de desenvolvimento para testes e de produção; Exemplos de aplicações nesta categoria incluem aplicações internet banking e outros sistemas de serviços financeiros de tamanho moderado; sistemas de processamento de acionamento de seguros, e sistemas de gestão de processos de fabricação. Categoria quatro Muito Grande: ambientes nesta categoria são classificados como muito grandes, clusterizados e de alta disponibilidade. Exemplos nessa categoria são aplicações web de grande volume, voltadas ao consumidor final; ou grandes aplicações financeiras online. Devido à necessidade de suportar requisitos complexos de monitoração e de controle de mudanças, abrangendo uma variedade grande de tecnologias, tais ambientes se beneficiam de tecnologias de virtualização. A maior parte da análise feita neste trabalho tem como foco os fatores que impactam os ambientes das categorias dois e três. Esse enfoque foi adotado por diversas razões. O ambiente da primeira categoria é um é alvo razoável para softwares open source; no entanto, dependendo do nível de suporte contratado do fornecedor, o WAS Base pode ser mais eficiente em custos do que o JBoss. A categoria quatro é um alvo claro de softwares comerciais altamente escaláveis; portanto, uma análise detalhada de TCO não teria tanto valor. O impacto do TCO, e a compreensão de toda a gama e impacto dos seus fatores, é mais significativo em ambientes da segunda e terceira categorias. O resumo a seguir destaca os elementos chave da análise, para que os leitores possam compreender as escolhas feitas na seleção dos critérios e resultados do TCO. Uma lista de fatores de TCO no uso do servidor de aplicações foi determinada, confrontando-se os requisitos comuns de arquitetura, implantação e operacionais. Com base nos dados obtidos, quatro cenários de categorias de uso foram estabelecidos, para propósito de comparação. As categorias dividem a análise em ambientes com pesos muito diferentes para fatores de TCO. Seguindo as definições de cenário e de ambiente, um conjunto de casos de teste foi desenvolvido e revisto. Os casos de teste definiram os requisitos de configuração, objetivos e scripts para o conjunto de ações a serem realizadas e medidas, diante de problemas reais e requisitos de configuração de sistema de cada produto. A lista a seguir resume a cobertura dos casos de teste: Instalação e configuração Configuração de segurança administrativa Integração com LDAP Configuração de cluster Segurança em cluster Estender um cluster Log de transações e configuração XA Configuração da persistência do JMS Publicação automatizada de uma aplicação no cluster Solução de problemas em aplicações operando em cluster Uso de memória pelo servidor de aplicações Teste de estresse executado por um período longo Gerenciamento do rastreamento de auditoria administrativa IBM WebSphere AS 7 e JBoss EAP 5 33

35 Os testes foram realizados realizando-se medidas de tempo em ambos os ambientes servidores de aplicações. As atividades incluíram planejamento, implementação e validação dos passos de execução, para cada caso de teste. Foram cronometrados e documentados detalhes sobre a realização de operações específicas, problemas encontrados, abordagem para resolução de problemas e casos de falha. Os itens a seguir foram medidos separadamente e tiveram seus tempos registrados: Tempo inicial para pesquisar e definir alternativas e a abordagem a ser seguida Tempo para realizar a implementação inicial Tempo para executar as operações subsequentes Em muitos casos, as operações dentro do mesmo teste requerem diferentes níveis de habilidade. Para a avaliação, seguimos os níveis de habilidade exigidos, definidos pelos níveis de administração de sistemas [SAGE 01] do grupo de interesses específicos da associação Usenix SAGE. Os custos para os administradores foram associados aos níveis de habilidade, usando como apoio a pesquisa salarial por nível de habilidade. O modelo deriva os cálculos de TCO com base no número de vezes em que as operações são realizadas durante o período de análise de TCO. Os valores são baseados em fatores de tamanho do ambiente, como: Número de servidores de aplicações, servidores HTTP, servidores LDAP, servidores WLM, servidores de cache Número de clusters Número de aplicações, suas complexidades e frequência de atualizações Número de administradores Número de desenvolvedores do software APÊNDICE B APLICAÇÃO DE TESTE Além de estabelecer um ambiente servidor representativo, era necessário uma aplicação de testes realista. Para avaliar o TCO, foi usado o projeto Day Trader, disponibilizado pelo Apache Geronimo. As razões pelas quais a aplicação DayTrader foi selecionada incluem: Uso de um conjunto significativo de serviços Java EE 5, incluindo JDBC, JMS, EJBs, Servlets/JSPs, JTS/ JTA. Requisitos de serviços de nível corporativo, incluindo segurança, desempenho, clusterização e transações. Suporte a vários sistemas de bancos de dados e ambientes JMS. Desempenho em um ambiente de servidores de aplicações clusterizado. Estratégia de migração de aplicações J2EE 1.4 para o Java EE 5. O diagrama a seguir fornece uma visão geral da arquitetura da aplicação Java EE DayTrader. IBM WebSphere AS 7 e JBoss EAP 5 34

36 O DayTrader não inclui recursos de web services. Para testar o desempenho de web services, foi desenvolvida uma aplicação específica, que usa web services moderadamente complexos, implementados como POJOs anotados com JAX-WS 2.0 e hospedados pelo servidor de aplicações. O desenvolvimento foi feito da baixo para cima: o POJO principal e todas as classes POJO dependentes foram desenvolvidas primeiro, e só então a classe POJO principal recebeu a O método de negócio usou parte da entrada de dados para gerar uma saída semi-aleatória. Nenhum serviço de backend foi chamado durante a execução do web service. As classes de dados utilizadas no web service são representativas de uma aplicação real normalmente encontrada no setor financeiro. Há um total de 30 POJOs inter-relacionados que juntos formam a entrada e a saída lógica do web service. Combinadas, as 30 classes possuem mais de 150 campos de tipos primitivos quase todos os tipos de dados primitivos usados em Java. Alguns tipos de dados foram estruturados como matrizes, e surgem várias vezes na carga de entrada em XML. A carga de trabalho para os testes de desempenho do web service incluem requisições SOAP / HTTP de tamanhos variados, incluindo requisições e respostas de 1K, 2K, 10K, 110k. APÊNDICE C AMBIENTE DE TESTES Para realizar a análise, um ambiente variado e realista foi criado para os testes. Os componentes do ambiente de testes foram selecionados com base em combinações comuns encontradas em ambientes reais. Foram utilizadas as mesmas configurações de hardware e software em ambos os ambientes técnicos de testes, para garantir que as diferenças dos ambientes não fossem um fator considerado nas medidas do CTO. As versões do WAS ND, JBoss EAP e do JON; foram inicialmente selecionadas com base nos pacotes mais recentes de produção e níveis de patch (pacote de correção) de disponibilidade geral, a partir de abril de 2010 e atualizados posteriormente em julho do mesmo ano. Os componentes do ambiente de testes foram selecionados com base em combinações comuns encontradas em ambientes operacionais de TI do mundo real. Foi configurado um conjunto de três diferentes grupos de máquinas virtuais, hospedados no VWware Server, sendo executados em ambientes RedHat Enterprise Linux. Cada grupo de máquinas virtuais permitiu que IBM WebSphere AS 7 e JBoss EAP 5 35

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Appliance virtual do StruxureWare Data Center Expert O servidor do StruxureWare Data Center Expert 7.2 está agora disponível como um appliance

Leia mais

LEIA ISTO PRIMEIRO. IBM Tivoli Configuration Manager, Versão 4.2.1

LEIA ISTO PRIMEIRO. IBM Tivoli Configuration Manager, Versão 4.2.1 LEIA ISTO PRIMEIRO IBM Tivoli, Versão 4.2.1 O IBM Tivoli, Versão 4.2.1, é uma solução para controlar a distribuição de software e o inventário de gerenciamento de recursos em um ambiente multiplataformas.

Leia mais

Solitaire Interglobal

Solitaire Interglobal Solitaire Interglobal POWERLINUX OU WINDOWS PARA IMPLANTAÇÃO SAP Escolher entre as plataformas concorrentes de sistema operacional Linux e Windows para SAP pode ser uma tarefa confusa para as organizações.

Leia mais

http://aurelio.net/vim/vim-basico.txt Entrar neste site/arquivo e estudar esse aplicativo Prof. Ricardo César de Carvalho

http://aurelio.net/vim/vim-basico.txt Entrar neste site/arquivo e estudar esse aplicativo Prof. Ricardo César de Carvalho vi http://aurelio.net/vim/vim-basico.txt Entrar neste site/arquivo e estudar esse aplicativo Administração de Redes de Computadores Resumo de Serviços em Rede Linux Controlador de Domínio Servidor DNS

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Modelo Cliente-Servidor: Introdução aos tipos de servidores e clientes Prof. MSc. Hugo Souza Iniciando o módulo 03 da primeira unidade, iremos abordar sobre o Modelo Cliente-Servidor

Leia mais

Novidades no Q-flow 3.02

Novidades no Q-flow 3.02 Novidades no Q-flow 3.02 Introdução Um dos principais objetivos do Q-flow 3.02 é adequar-se às necessidades das grandes organizações. Por isso, o Q-flow 3.02 possui uma versão Enterprise que inclui funcionalidades

Leia mais

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Definição Geral: Disciplina de Compiladores Prof. Jorge Bidarra (UNIOESTE) A especificação de requisitos tem como objetivo

Leia mais

Soluções de Gerenciamento de Clientes e de Impressão Universal

Soluções de Gerenciamento de Clientes e de Impressão Universal Soluções de Gerenciamento de Clientes e de Impressão Universal Guia do Usuário Copyright 2007 Hewlett-Packard Development Company, L.P. Windows é uma marca registrada nos Estados Unidos da Microsoft Corporation.

Leia mais

Procedimentos para Reinstalação do Sisloc

Procedimentos para Reinstalação do Sisloc Procedimentos para Reinstalação do Sisloc Sumário: 1. Informações Gerais... 3 2. Criação de backups importantes... 3 3. Reinstalação do Sisloc... 4 Passo a passo... 4 4. Instalação da base de dados Sisloc...

Leia mais

ESTUDO DE CASO WINDOWS VISTA

ESTUDO DE CASO WINDOWS VISTA ESTUDO DE CASO WINDOWS VISTA História Os sistemas operacionais da Microsoft para PCs desktop e portáteis e para servidores podem ser divididos em 3 famílias: MS-DOS Windows baseado em MS-DOS Windows baseado

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Processos- Clientes, Servidores, Migração Capítulo 3 Agenda Clientes Interfaces de usuário em rede Sistema X Window Software do lado cliente para

Leia mais

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

Leia mais

Tópicos. Atualizações e segurança do sistema. Manutenção Preventiva e Corretiva de Software (utilizando o MS Windows XP)

Tópicos. Atualizações e segurança do sistema. Manutenção Preventiva e Corretiva de Software (utilizando o MS Windows XP) teste 1 Manutenção Preventiva e Corretiva de Software (utilizando o MS Windows XP) Rafael Fernando Diorio www.diorio.com.br Tópicos - Atualizações e segurança do sistema - Gerenciamento do computador -

Leia mais

Introdução ao Modelos de Duas Camadas Cliente Servidor

Introdução ao Modelos de Duas Camadas Cliente Servidor Introdução ao Modelos de Duas Camadas Cliente Servidor Desenvolvimento de Sistemas Cliente Servidor Prof. Esp. MBA Heuber G. F. Lima Aula 1 Ciclo de Vida Clássico Aonde estamos? Page 2 Análise O que fizemos

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

Análise de custo projetado da plataforma SAP HANA

Análise de custo projetado da plataforma SAP HANA Um estudo Total Economic Impact da Forrester Encomendado pela SAP Diretora do projeto: Shaheen Parks Abril de 2014 Análise de custo projetado da plataforma SAP HANA Economia de custo proporcionada pela

Leia mais

agility made possible

agility made possible RESUMO DA SOLUÇÃO Utilitário ConfigXpress no CA IdentityMinder a minha solução de gerenciamento de identidades pode se adaptar rapidamente aos requisitos e processos de negócio em constante mudança? agility

Leia mais

Considerações no Projeto de Sistemas Cliente/Servidor

Considerações no Projeto de Sistemas Cliente/Servidor Cliente/Servidor Desenvolvimento de Sistemas Graça Bressan Graça Bressan/LARC 2000 1 Desenvolvimento de Sistemas Cliente/Servidor As metodologias clássicas, tradicional ou orientada a objeto, são aplicáveis

Leia mais

INTERNET HOST CONNECTOR

INTERNET HOST CONNECTOR INTERNET HOST CONNECTOR INTERNET HOST CONNECTOR IHC: INTEGRAÇÃO TOTAL COM PRESERVAÇÃO DE INVESTIMENTOS Ao longo das últimas décadas, as organizações investiram milhões de reais em sistemas e aplicativos

Leia mais

Especificações da oferta Gerenciamento de dispositivos distribuídos: Gerenciamento de ativos

Especificações da oferta Gerenciamento de dispositivos distribuídos: Gerenciamento de ativos Visão geral do Serviço Especificações da oferta Gerenciamento de dispositivos distribuídos: Gerenciamento de ativos Os Serviços de gerenciamento de dispositivos distribuídos ajudam você a controlar ativos

Leia mais

Gerenciamento de Incidentes

Gerenciamento de Incidentes Gerenciamento de Incidentes Os usuários do negócio ou os usuários finais solicitam os serviços de Tecnologia da Informação para melhorar a eficiência dos seus próprios processos de negócio, de forma que

Leia mais

Satélite. Manual de instalação e configuração. CENPECT Informática www.cenpect.com.br cenpect@cenpect.com.br

Satélite. Manual de instalação e configuração. CENPECT Informática www.cenpect.com.br cenpect@cenpect.com.br Satélite Manual de instalação e configuração CENPECT Informática www.cenpect.com.br cenpect@cenpect.com.br Índice Índice 1.Informações gerais 1.1.Sobre este manual 1.2.Visão geral do sistema 1.3.História

Leia mais

FileMaker Pro 13. Utilização de uma Conexão de Área de Trabalho Remota com o FileMaker Pro 13

FileMaker Pro 13. Utilização de uma Conexão de Área de Trabalho Remota com o FileMaker Pro 13 FileMaker Pro 13 Utilização de uma Conexão de Área de Trabalho Remota com o FileMaker Pro 13 2007-2013 FileMaker Inc. Todos os direitos reservados. FileMaker Inc. 5201 Patrick Henry Drive Santa Clara,

Leia mais

Sistemas de Gestão Ambiental O QUE MUDOU COM A NOVA ISO 14001:2004

Sistemas de Gestão Ambiental O QUE MUDOU COM A NOVA ISO 14001:2004 QSP Informe Reservado Nº 41 Dezembro/2004 Sistemas de Gestão O QUE MUDOU COM A NOVA ISO 14001:2004 Material especialmente preparado para os Associados ao QSP. QSP Informe Reservado Nº 41 Dezembro/2004

Leia mais

CSAU 10.0. Guia: Manual do CSAU 10.0 como implementar e utilizar.

CSAU 10.0. Guia: Manual do CSAU 10.0 como implementar e utilizar. CSAU 10.0 Guia: Manual do CSAU 10.0 como implementar e utilizar. Data do Documento: Janeiro de 2012 Sumário 1. Sobre o manual do CSAU... 3 2. Interface do CSAU 10.0... 4 2.1. Início... 4 2.2. Update...

Leia mais

Oracle WebLogic Server 11g: Conceitos Básicos de Administração

Oracle WebLogic Server 11g: Conceitos Básicos de Administração Oracle University Entre em contato: 0800 891 6502 Oracle WebLogic Server 11g: Conceitos Básicos de Administração Duração: 5 Dias Objetivos do Curso Este curso treina administradores Web nas técnicas para

Leia mais

Conceitos Básicos de Rede. Um manual para empresas com até 75 computadores

Conceitos Básicos de Rede. Um manual para empresas com até 75 computadores Conceitos Básicos de Rede Um manual para empresas com até 75 computadores 1 Conceitos Básicos de Rede Conceitos Básicos de Rede... 1 A Função de Uma Rede... 1 Introdução às Redes... 2 Mais Conceitos Básicos

Leia mais

Fábrica de Software 29/04/2015

Fábrica de Software 29/04/2015 Fábrica de Software 29/04/2015 Crise do Software Fábrica de Software Analogias costumam ser usadas para tentar entender melhor algo ou alguma coisa. A idéia é simples: compara-se o conceito que não se

Leia mais

Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira.

Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Período letivo: 4 Semestre. Quinzena: 5ª. Faculdades Santa Cruz - Inove Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Unidade Curricular Sistemas Distribuídos Processos

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

Leia mais

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

Kerio Exchange Migration Tool

Kerio Exchange Migration Tool Kerio Exchange Migration Tool Versão: 7.3 2012 Kerio Technologies, Inc. Todos os direitos reservados. 1 Introdução Documento fornece orientações para a migração de contas de usuário e as pastas públicas

Leia mais

As principais características da abordagem de um banco de dados versus a abordagem de processamento de arquivos são as seguintes:

As principais características da abordagem de um banco de dados versus a abordagem de processamento de arquivos são as seguintes: SGBD Características do Emprego de Bancos de Dados As principais características da abordagem de um banco de dados versus a abordagem de processamento de arquivos são as seguintes: Natureza autodescritiva

Leia mais

Aumente sua velocidade e flexibilidade com a implantação da nuvem gerenciada de software da SAP

Aumente sua velocidade e flexibilidade com a implantação da nuvem gerenciada de software da SAP Parceiros de serviços em nuvem gerenciada Aumente sua velocidade e flexibilidade com a implantação da nuvem gerenciada de software da SAP Implemente a versão mais recente do software da SAP de classe mundial,

Leia mais

Universidade Paulista

Universidade Paulista Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen

Leia mais

A LIBERDADE DO LINUX COM A QUALIDADE ITAUTEC

A LIBERDADE DO LINUX COM A QUALIDADE ITAUTEC A LIBERDADE DO LINUX COM A QUALIDADE ITAUTEC O AMBIENTE OPERACIONAL QUE AGREGA A CONFIABILIDADE E O SUPORTE DA ITAUTEC À SEGURANÇA E À PERFORMANCE DO LINUX O LIBRIX É UMA DISTRIBUIÇÃO PROFISSIONAL LINUX

Leia mais

Versão 1.0 09/10. Xerox ColorQube 9301/9302/9303 Serviços de Internet

Versão 1.0 09/10. Xerox ColorQube 9301/9302/9303 Serviços de Internet Versão 1.0 09/10 Xerox 2010 Xerox Corporation. Todos os direitos reservados. Direitos reservados de não publicação sob as leis de direitos autorais dos Estados Unidos. O conteúdo desta publicação não pode

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governança de TI. ITIL v.2&3. parte 1 Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços

Leia mais

Consolidação inteligente de servidores com o System Center

Consolidação inteligente de servidores com o System Center Consolidação de servidores por meio da virtualização Determinação do local dos sistemas convidados: a necessidade de determinar o melhor host de virtualização que possa lidar com os requisitos do sistema

Leia mais

Comparativo de desempenho do Pervasive PSQL v11

Comparativo de desempenho do Pervasive PSQL v11 Comparativo de desempenho do Pervasive PSQL v11 Um artigo Pervasive PSQL Setembro de 2010 Conteúdo Resumo executivo... 3 O impacto das novas arquiteturas de hardware nos aplicativos... 3 O projeto do Pervasive

Leia mais

Síntese das discussões do fórum Livro-APF: Julho/2010

Síntese das discussões do fórum Livro-APF: Julho/2010 Síntese das discussões do fórum Livro-APF: Julho/2010 Assunto: Estimativa de Aumento de Produtividade Data: 01/07/2010 Link: http://br.groups.yahoo.com/group/livro-apf/message/2577 Dúvida: Existe alguma

Leia mais

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE LIBERAÇÃO

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE LIBERAÇÃO 1 ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE LIBERAÇÃO 2 INTRODUÇÃO A cada dia que passa, cresce a pressão pela liberação para uso de novas tecnologias disponibilizadas pela área de TI, sob o argumento

Leia mais

DIMENSIONANDO PROJETOS DE WEB-ENABLING. Uma aplicação da Análise de Pontos de Função. Dimensionando projetos de Web- Enabling

DIMENSIONANDO PROJETOS DE WEB-ENABLING. Uma aplicação da Análise de Pontos de Função. Dimensionando projetos de Web- Enabling DIMENSIONANDO PROJETOS DE WEB-ENABLING Uma aplicação da Análise de Pontos de Função Dimensionando projetos de Web- Enabling Índice INTRODUÇÃO...3 FRONTEIRA DA APLICAÇÃO E TIPO DE CONTAGEM...3 ESCOPO DA

Leia mais

FileMaker Pro 14. Utilização de uma Conexão de Área de Trabalho Remota com o FileMaker Pro 14

FileMaker Pro 14. Utilização de uma Conexão de Área de Trabalho Remota com o FileMaker Pro 14 FileMaker Pro 14 Utilização de uma Conexão de Área de Trabalho Remota com o FileMaker Pro 14 2007-2015 FileMaker, Inc. Todos os direitos reservados. FileMaker Inc. 5201 Patrick Henry Drive Santa Clara,

Leia mais

Guia do Administrador de Licenças de Usuários Autorizados do IBM SPSS Modeler

Guia do Administrador de Licenças de Usuários Autorizados do IBM SPSS Modeler Guia do Administrador de Licenças de Usuários Autorizados do IBM SPSS Modeler Índice Guia do Administrador........ 1 Antes de Iniciar............. 1 Serviços Citrix e Terminal......... 1 Instalação do

Leia mais

Gerenciador de Mudanças automatizadas

Gerenciador de Mudanças automatizadas Benefícios para os Negócios Minimizando a dependência em processos manuais e reduzindo risco de erro humano Reduz o tempo, esforço e risco de erro humano que existem ao mudar a configuração em dispositivos

Leia mais

4 Um Exemplo de Implementação

4 Um Exemplo de Implementação 4 Um Exemplo de Implementação Neste capítulo será discutida uma implementação baseada na arquitetura proposta. Para tanto, será explicado como a arquitetura proposta se casa com as necessidades da aplicação

Leia mais

PROPOSTA COMERCIAL PARA TREINAMENTOS DE TI

PROPOSTA COMERCIAL PARA TREINAMENTOS DE TI PROPOSTA COMERCIAL PARA TREINAMENTOS DE TI Curso: Formação para certificação MCSA em Windows Server 2012 Prepara para as provas: 70-410, 70-411 e 70-412 Em parceria com Pág. 1 Objetivo Adquirindo a formação

Leia mais

GERENCIAMENTO CENTRALIZADO DELL POWERVAULT DL 2000 BASEADO EM TECNOLOGIA SYMANTEC

GERENCIAMENTO CENTRALIZADO DELL POWERVAULT DL 2000 BASEADO EM TECNOLOGIA SYMANTEC GERENCIAMENTO CENTRALIZADO DELL POWERVAULT DL 2000 BASEADO EM TECNOLOGIA SYMANTEC RESUMO EXECUTIVO O PowerVault DL2000, baseado na tecnologia Symantec Backup Exec, oferece a única solução de backup em

Leia mais

Guia de Atualização PROJURIS WEB 4.5. Manual do Técnico Atualização - ProJuris Web 4.5. Manual do Técnico Atualização - ProJuris Web 4.

Guia de Atualização PROJURIS WEB 4.5. Manual do Técnico Atualização - ProJuris Web 4.5. Manual do Técnico Atualização - ProJuris Web 4. Guia de Atualização PROJURIS WEB 4.5 Por: Fabio Pozzebon Soares Página 1 de 11 Sistema ProJuris é um conjunto de componentes 100% Web, nativamente integrados, e que possuem interface com vários idiomas,

Leia mais

O sistema que completa sua empresa Roteiro de Instalação (rev. 15.10.09) Página 1

O sistema que completa sua empresa Roteiro de Instalação (rev. 15.10.09) Página 1 Roteiro de Instalação (rev. 15.10.09) Página 1 O objetivo deste roteiro é descrever os passos para a instalação do UNICO. O roteiro poderá ser usado não apenas pelas revendas que apenas estão realizando

Leia mais

Sistemas de Gerenciamento de Banco de Dados

Sistemas de Gerenciamento de Banco de Dados Sistemas de Gerenciamento de Banco de Dados A U L A : C R I A Ç Ã O D E B A N C O D E D A D O S - R E Q U I S I T O S F U N C I O N A I S E O P E R A C I O N A I S P R O F. : A N D R É L U I Z M O N T

Leia mais

Noções de. Microsoft SQL Server. Microsoft SQL Server

Noções de. Microsoft SQL Server. Microsoft SQL Server Noções de 1 Considerações Iniciais Basicamente existem dois tipos de usuários do SQL Server: Implementadores Administradores 2 1 Implementadores Utilizam o SQL Server para criar e alterar base de dados

Leia mais

Parceiro Oficial de Soluções Zabbix no Brasil

Parceiro Oficial de Soluções Zabbix no Brasil Apresentação A Vantage TI conta uma estrutura completa para atender empresas de todos os segmentos e portes, nacionais e internacionais. Nossos profissionais dedicam-se ao desenvolvimento e criação de

Leia mais

Entendendo como funciona o NAT

Entendendo como funciona o NAT Entendendo como funciona o NAT Vamos inicialmente entender exatamente qual a função do NAT e em que situações ele é indicado. O NAT surgiu como uma alternativa real para o problema de falta de endereços

Leia mais

IBM Managed Security Services for Agent Redeployment and Reactivation

IBM Managed Security Services for Agent Redeployment and Reactivation Descrição de Serviços IBM Managed Security Services for Agent Redeployment and Reactivation EM ADIÇÃO AOS TERMOS E CONDIÇÕES ESPECIFICADOS ABAIXO, ESSA DESCRIÇÃO DE SERVIÇOS INCLUI AS IBM MANAGED SECURITY

Leia mais

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás

Leia mais

Conceitos de Banco de Dados

Conceitos de Banco de Dados Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir

Leia mais

CA Mainframe Chorus for Storage Management Versão 2.0

CA Mainframe Chorus for Storage Management Versão 2.0 FOLHA DO PRODUTO CA Mainframe Chorus for Storage Management CA Mainframe Chorus for Storage Management Versão 2.0 Simplifique e otimize suas tarefas de gerenciamento de armazenamento, aumente a produtividade

Leia mais

EAGLE TECNOLOGIA E DESIGN CRIAÇÃO DE SERVIDOR CLONE APCEF/RS

EAGLE TECNOLOGIA E DESIGN CRIAÇÃO DE SERVIDOR CLONE APCEF/RS EAGLE TECNOLOGIA E DESIGN CRIAÇÃO DE SERVIDOR CLONE APCEF/RS Relatório Nº 03/2013 Porto Alegre, 22 de Agosto de 2013. ANÁLISE DE SOLUÇÕES: # RAID 1: O que é: RAID-1 é o nível de RAID que implementa o espelhamento

Leia mais

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial 1 of 14 27/01/2014 17:33 Sistema de Paginação de Esportes Universitários Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data 30 de novembro de 1999 Versão Descrição Autor 1.0 Versão

Leia mais

Aranda INVENTORY. Benefícios Estratégicos para sua Organização. (Standard & Plus Edition) Beneficios. Características V.2.0907

Aranda INVENTORY. Benefícios Estratégicos para sua Organização. (Standard & Plus Edition) Beneficios. Características V.2.0907 Uma ferramenta de inventario que automatiza o cadastro de ativos informáticos em detalhe e reporta qualquer troca de hardware ou software mediante a geração de alarmes. Beneficios Informação atualizada

Leia mais

CA Nimsoft Monitor Snap

CA Nimsoft Monitor Snap CA Nimsoft Monitor Snap Guia de Configuração do Monitoramento da máquina virtual Java jvm_monitor série 1.4 Aviso de copyright do CA Nimsoft Monitor Snap Este sistema de ajuda online (o Sistema ) destina-se

Leia mais

Gerenciamento de software como ativo de automação industrial

Gerenciamento de software como ativo de automação industrial Gerenciamento de software como ativo de automação industrial INTRODUÇÃO Quando falamos em gerenciamento de ativos na área de automação industrial, fica evidente a intenção de cuidar e manter bens materiais

Leia mais

ArpPrintServer. Sistema de Gerenciamento de Impressão By Netsource www.netsource.com.br Rev: 02

ArpPrintServer. Sistema de Gerenciamento de Impressão By Netsource www.netsource.com.br Rev: 02 ArpPrintServer Sistema de Gerenciamento de Impressão By Netsource www.netsource.com.br Rev: 02 1 Sumário INTRODUÇÃO... 3 CARACTERÍSTICAS PRINCIPAIS DO SISTEMA... 3 REQUISITOS DE SISTEMA... 4 INSTALAÇÃO

Leia mais

A seguir, respostas aos questionamentos referentes ao Pregão Presencial nº 17/14:

A seguir, respostas aos questionamentos referentes ao Pregão Presencial nº 17/14: Senhores, A seguir, respostas aos questionamentos referentes ao Pregão Presencial nº 17/14: Questionamento 1: 2. ESPECIFICAÇÕES TÉCNICAS MÍNIMCAS No que diz respeito ao subitem 2.1.2, temos a seguinte

Leia mais

Introdução a listas - Windows SharePoint Services - Microsoft Office Online

Introdução a listas - Windows SharePoint Services - Microsoft Office Online Page 1 of 5 Windows SharePoint Services Introdução a listas Ocultar tudo Uma lista é um conjunto de informações que você compartilha com membros da equipe. Por exemplo, você pode criar uma folha de inscrição

Leia mais

BRAlarmExpert. Software para Gerenciamento de Alarmes. BENEFÍCIOS obtidos com a utilização do BRAlarmExpert:

BRAlarmExpert. Software para Gerenciamento de Alarmes. BENEFÍCIOS obtidos com a utilização do BRAlarmExpert: BRAlarmExpert Software para Gerenciamento de Alarmes A TriSolutions conta com um produto diferenciado para gerenciamento de alarmes que é totalmente flexível e amigável. O software BRAlarmExpert é uma

Leia mais

Forneça a próxima onda de inovações empresariais com o Open Network Environment

Forneça a próxima onda de inovações empresariais com o Open Network Environment Visão geral da solução Forneça a próxima onda de inovações empresariais com o Open Network Environment Visão geral À medida que tecnologias como nuvem, mobilidade, mídias sociais e vídeo assumem papéis

Leia mais

ERP Enterprise Resource Planning

ERP Enterprise Resource Planning ERP Enterprise Resource Planning Sistemas Integrados de Gestão Evolução dos SI s CRM OPERACIONAL TÁTICO OPERACIONAL ESTRATÉGICO TÁTICO ESTRATÉGICO OPERACIONAL TÁTICO ESTRATÉGICO SIT SIG SAE SAD ES EIS

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Suporte Técnico de Software HP

Suporte Técnico de Software HP Suporte Técnico de Software HP Serviços Tecnológicos HP - Serviços Contratuais Dados técnicos O Suporte Técnico de Software HP fornece serviços completos de suporte de software remoto para produtos de

Leia mais

Especificação Suplementar

Especificação Suplementar Especificação Suplementar Versão Histórico de Revisões Data Versão Descrição Autor 29/10/2014 2.0 2.1 funcionalidade e segurança de M. Vinícius acesso 30/10/2014

Leia mais

Soluções de Gestão de Clientes e Impressão Universal

Soluções de Gestão de Clientes e Impressão Universal Soluções de Gestão de Clientes e Impressão Universal Manual do utilizador Copyright 2007 Hewlett-Packard Development Company, L.P. Windows é uma marca registada da Microsoft Corporation nos E.U.A. As informações

Leia mais

MODELO CMM MATURIDADE DE SOFTWARE

MODELO CMM MATURIDADE DE SOFTWARE MODELO CMM MATURIDADE DE SOFTWARE O modelo CMM Capability Maturity Model foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo

Leia mais

Semântica para Sharepoint. Busca semântica utilizando ontologias

Semântica para Sharepoint. Busca semântica utilizando ontologias Semântica para Sharepoint Busca semântica utilizando ontologias Índice 1 Introdução... 2 2 Arquitetura... 3 3 Componentes do Produto... 4 3.1 OntoBroker... 4 3.2 OntoStudio... 4 3.3 SemanticCore para SharePoint...

Leia mais

Procedimentos para Instalação do SISLOC

Procedimentos para Instalação do SISLOC Procedimentos para Instalação do SISLOC Sumário 1. Informações Gerais...3 2. Instalação do SISLOC...3 Passo a passo...3 3. Instalação da Base de Dados SISLOC... 11 Passo a passo... 11 4. Instalação de

Leia mais

NOVO MODELO DE ATUALIZAÇÃO FOCCO Atualização automática com o FoccoUPDATE

NOVO MODELO DE ATUALIZAÇÃO FOCCO Atualização automática com o FoccoUPDATE NOVO MODELO DE ATUALIZAÇÃO FOCCO Atualização automática com o FoccoUPDATE Fevereiro/2012 Índice APRESENTAÇÃO... 3 ENTENDENDO A MUDANÇA... 3 QUAIS OS BENEFÍCIOS?... 3 FERRAMENTA PARA ATUALIZAÇÃO... 4 ABRANGÊNCIA

Leia mais

Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos

Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos Referência: An Introductory Overview of ITIL v2 Livros ITIL v2 Cenário de TI nas organizações Aumento da dependência da TI para alcance

Leia mais

Gerenciamento de Problemas

Gerenciamento de Problemas Gerenciamento de Problemas O processo de Gerenciamento de Problemas se concentra em encontrar os erros conhecidos da infra-estrutura de TI. Tudo que é realizado neste processo está voltado a: Encontrar

Leia mais

CA ARCserve Backup PERGUNTAS MAIS FREQUENTES: ARCSERVE BACKUP R12.5

CA ARCserve Backup PERGUNTAS MAIS FREQUENTES: ARCSERVE BACKUP R12.5 PERGUNTAS MAIS FREQUENTES: ARCSERVE BACKUP R12.5 CA ARCserve Backup Este documento aborda as perguntas mais freqüentes sobre o CA ARCserve Backup r12.5. Para detalhes adicionais sobre os novos recursos

Leia mais

HOW TO Procedimento para instalar Aker Firewall virtualizado no ESXi 5.0

HOW TO Procedimento para instalar Aker Firewall virtualizado no ESXi 5.0 Procedimento para instalar virtualizado no Página: 1 de 15 Introdução Este documento abordará os procedimentos necessários para instalar o (AFW) virtualizado em um servidor ESXi. Será compreendido desde

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

10 DICAS DE TECNOLOGIA PARA AUMENTAR SUA PRODUTIVIDADE NO TRABALHO

10 DICAS DE TECNOLOGIA PARA AUMENTAR SUA PRODUTIVIDADE NO TRABALHO 10 DICAS DE TECNOLOGIA PARA AUMENTAR SUA PRODUTIVIDADE NO TRABALHO UMA DAS GRANDES FUNÇÕES DA TECNOLOGIA É A DE FACILITAR A VIDA DO HOMEM, SEJA NA VIDA PESSOAL OU CORPORATIVA. ATRAVÉS DELA, ELE CONSEGUE

Leia mais

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com

Leia mais

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis

Leia mais

Procedimentos para Instalação do Sisloc

Procedimentos para Instalação do Sisloc Procedimentos para Instalação do Sisloc Sumário: 1. Informações Gerais... 3 2. Instalação do Sisloc... 3 Passo a passo... 3 3. Instalação da base de dados Sisloc... 16 Passo a passo... 16 4. Instalação

Leia mais

FIREWALL. Prof. Fabio de Jesus Souza. fabiojsouza@gmail.com. Professor Fabio Souza

FIREWALL. Prof. Fabio de Jesus Souza. fabiojsouza@gmail.com. Professor Fabio Souza FIREWALL Prof. Fabio de Jesus Souza fabiojsouza@gmail.com Professor Fabio Souza O que são Firewalls? Os firewalls são sistemas de segurança que podem ser baseados em: um único elemento de hardware; um

Leia mais

Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler

Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler Introdução Objetivos da Gestão dos Custos Processos da Gerência de Custos Planejamento dos recursos Estimativa dos

Leia mais

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Ferramenta de apoio a gerência de configuração de software Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Gerência de Configuração

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais