UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO

UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO CRM SGBD TeMIP TeMIPConnector JCA Aplicação J2EE ERP LDAP EIS Um Conector J2EE para a Plataforma de Gestão Integrada TeMIP Ricardo Jorge Feliciano Lopes Pereira (Licenciado) Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Orientador: Doutora Teresa Maria Sá Ferreira Vazão Vasques Júri Presidente: Doutor Arlindo Manuel Limede de Oliveira Vogais: Doutor Paulo de Costa Luís da Fonseca Pinto Doutora Teresa Maria Sá Ferreira Vazão Vasques Setembro 2002

Resumo I Resumo: O crescente tamanho, heterogeneidade e complexidade das redes de comunicação levaram muitas empresas a investir em Plataformas de Gestão Integradas. Estas aplicações concentram todas as tarefas relacionadas com a Gestão de Redes. No entanto, a informação encontrada noutras aplicações empresariais como Enterprise Resource Planning (ERP), Costumer Relationship Management (CRM) e aplicações de workflow pode permitir alcançar uma Gestão a nível de Serviço eficiente. Java 2 Enterprise Edition (J2EE) e a Java Connector Architecture (JCA) fornecem as bases para o desenvolvimento de aplicações que integram informação de várias fontes e actuam sobre essas mesmas fontes. Actualmente já estão disponíveis Conectores JCA para a maioria das aplicações empresariais de primeira linha, enquanto que as Plataformas de Gestão Integradas oferecem um ponto único de acesso aos elementos de rede. Esta dissertação apresenta um Conector JCA para a Plataforma de Gestão Integrada da Compaq Telecommunications Management Information Platform (TeMIP). São ainda apresentadas aplicações que demonstram potenciais usos para este Conector. Palavras-chave: Integração de Sistemas, Gestão de Redes, Java Connector Architecture (JCA), Plataformas de Gestão Integrada, Interfaces Web, Java 2 Enterprise Edition (J2EE)

Abstract III Abstract: The increasing size, heterogeneity and complexity of communication networks have prompted many companies to invest in Integrated Network Management Platforms. These applications concentrate all tasks related to network management. But information found in other applications, such as Enterprise Resource Planning (ERP), Costumer Relationship Management (CRM) and workflow applications can be very useful if effective Service Management is to be achieved. Java 2 Enterprise Edition (J2EE) and the Java Connector Architecture (JCA) provided a basis for developing applications that integrate data from several sources and drive these sources. JCA connectors are available for most of the major Enterprise Information Systems (EIS) and Integrated Network Management Platforms provide a single point of access to network elements. This thesis presents a JCA connector for the Compaq Telecommunications Management Information Platform (TeMIP) Integrated Network Management Platform. J2EE applications that demonstrate potential uses of the connector are also presented. Key-Words: System Integration, Network Management, Java Connector Architecture (JCA), Integrated Network Management Platform, Web Interface, Java 2 Enterprise Edition (J2EE)

Agradecimentos V Agradecimentos: Queria agradecer à minha orientadora, a Professora Teresa Vazão, por toda a atenção e apoio prestado, assim como pelo seu diligente esforço no sentido de proporcionar as condições de trabalho necessárias. Este trabalho não teria sido possível sem o apoio da Compaq Portugal, que cedeu generosamente hardware e software indispensável à sua realização: uma Workstation Alpha XP1000 com Tru64 Unix e o TeMIP 4.0.0. Gostaria ainda de estender os meus agradecimentos ao Christian Kuesters pela sua disponibilidade para manter e realizar upgrades ao TeMIP. Ao Eng. Ricardo Fortunato agradeço também a sua disponibilidade no esclarecimento de dúvidas sobre o TeMIP. O Eng. José Calhariz também merece uma palavra de apreço pela ajuda prestada na administração da máquina Tru64 e do TeMIP. Estendo ainda os meus agradecimentos ao INESC-ID pelas condições de trabalho proporcionadas.

Índice VII Capítulo 1 Introdução...1 1.1 Motivação...2 1.2 Solução proposta...8 1.3 Estrutura da tese...9 Capítulo 2 Gestão de redes... 11 2.1 O modelo de referência do TMForum... 12 2.1.1 Modelo de Responsabilidade... 12 2.1.2 Áreas Funcionais... 14 2.1.3 O modelo TOM... 17 2.2 Ferramentas de Gestão de Rede... 22 2.2.1 Classificação... 22 2.2.2 Plataforma de Gestão Integrada de Rede... 23 2.3 Integração de sistemas... 26 2.3.1 Java 2 Enterprise Edition... 26 2.3.2 CORBA - Common Object Request Broker Architecture... 28 2.3.3 Soluções proprietárias... 28 2.4 Sumário... 31 Capítulo 3 Tecnologias utilizadas... 33 3.1 TeMIP... 34 3.1.1 Capacidades de Integração... 35 3.1.2 TAL - TeMIP Access Library... 37 3.2 J2SE - Java 2 Standard Edition... 39 3.2.1 JNI - Java Native Interface... 44 3.2.2 RMI - Remote Method Invocation... 45 3.3 J2EE - Java 2 Enterprise Edition... 47 3.3.1 Java Servlets... 49 3.3.1.1 Ciclo de vida dos servlets... 51 3.3.1.2 Persistência dos dados... 52 3.3.1.3 Beans e sua utilização... 53 3.3.1.4 Outras funcionalidades... 53 3.3.2 JavaServer Pages... 54 3.3.3 EJB - Enterprise Java Beans... 57 3.4 JCA - Java Connector Architecture... 60 3.4.1 Papeis... 61 3.4.2 Gestão de ligações... 63 3.4.3 Transacções... 67 3.4.4 Segurança... 68 3.4.5 CCI - Common Client Interface... 69 3.4.6 Exceptions... 70 3.4.7 Packaging... 71 3.4.8 Vantagens da norma... 71 3.4.9 Actuais deficiências da norma... 72 3.4.10 Futuras adições à norma... 73 Capítulo 4 Arquitectura da solução... 75 4.1 Objectivos... 76 4.2 Arquitectura geral... 78 4.3 Biblioteca TalAccess... 83 4.4 Servidor RMI... 85 4.5 Conector... 88

Índice VIII Capítulo 5 Implementação... 91 5.1 Ferramentas utilizadas... 92 5.1.1 Java 2 Software Development Kit (SDK)... 92 5.1.2 Compilador C++ da Compaq... 93 5.1.3 NetBeans/Forte4Java EE... 93 5.1.4 CVS... 93 5.1.5 Ant... 94 5.1.6 Servidores J2EE... 95 5.1.6.1 J2EE Reference Implementation... 95 5.1.6.2 JBoss... 96 5.2 Biblioteca TalAccess... 97 5.2.1 API oferecida... 98 5.2.1.1 Representação das respostas e erros... 101 5.2.2 Interacção com o TAL... 104 5.2.2.1 Criação do objecto TalAccess... 105 5.2.2.2 Notificação de paragem do TeMIP... 107 5.2.2.3 Fim da utilização da biblioteca TalAccess... 108 5.2.2.4 Interrogações síncronas... 109 5.2.2.5 Verificação de username/password... 110 5.2.2.6 Interrogações assíncronas... 110 5.2.2.7 Cancelamento de interrogações assíncronas... 114 5.2.3 Limitações da biblioteca TalAccess... 114 5.2.4 Testes da biblioteca TalAccess - Cliente local... 115 5.3 Servidor RMI... 116 5.3.1 API oferecida... 117 5.3.2 Funcionamento... 118 5.3.2.1 Arranque... 119 5.3.2.2 Paragem do servidor... 120 5.3.2.3 Paragem do TeMIP... 121 5.3.2.4 Interrogação síncrona... 121 5.3.2.5 Verificação de username/password... 122 5.3.2.6 Interrogação assíncrona... 122 5.3.2.7 Cancelamento interrogação assíncrona... 123 5.3.2.8 Sistema de histórico... 124 5.3.3 Testes ao Servidor RMI - Cliente remoto... 124 5.4 Conector... 127 5.4.1 API oferecida... 127 5.4.2 Instalação... 128 5.4.3 Funcionamento... 129 5.4.3.1 Arranque e paragem... 129 5.4.3.2 Obtenção de uma ligação... 130 5.4.3.3 Invocação de métodos... 132 5.4.4 Testes ao Conector - Cliente J2EE... 132 Capítulo 6 Aplicações... 135 6.1 Interface Web... 136 6.1.1 A rede gerida... 137 6.1.2 Funcionalidades disponibilizadas... 138 6.1.3 Arquitectura... 142 6.1.4 Implementação... 143 6.2 Modulo de autenticação JAAS... 146

Índice IX Capítulo 7 Testes de desempenho... 147 7.1 Cenário de testes... 148 7.2 Desempenho em modo síncrono... 150 7.3 Desempenho em modo assíncrono... 155 7.4 Conclusões... 158 Capítulo 8 Conclusões... 159 8.1 Conclusões... 160 8.2 Trabalho futuro no TeMIPConnector... 162 Referências Bibliográficas Anexo A - Glossário

Índice de Figuras XI Figura 1 O TeMIPConnector permite integrar o TeMIP com outras aplicações...8 Figura 2 Pirâmide de gestão... 14 Figura 3 TOM, modelo de processos de negócio... 19 Figura 4 Exemplo do fluxo de processos de garantia de serviço... 21 Figura 5 Classificação de ferramentas de gestão de rede... 22 Figura 6 Estrutura geral de uma Plataforma de Gestão... 24 Figura 7 Visão conceptual do modelo de gestão empregado no TeMIP... 34 Figura 8 Componentes do Java 2 Platform Standard Edition... 41 Figura 9 Componentes do Java 2 Enterprise Edition... 47 Figura 10 Arquitectura de uma solução assente em servlets... 50 Figura 11 Relação entre classes passíveis de extensão para a criação de um servlet.. 51 Figura 12 Arquitectura de um servidor HTTP com suporte para JSP... 55 Figura 13 Arquitectura JCA... 61 Figura 14 Interfaces constituintes da JCA... 64 Figura 15 Diagrama temporal para estabelecimento de nova ligacao... 65 Figura 16 Arquitectura global do TeMIPConnector... 78 Figura 17 Arquitectura da biblioteca TalAccess... 83 Figura 18 Biblioteca TalAccess... 97 Figura 19 Transformação das respostas do TAL... 101 Figura 20 Classes utilizadas nas respostas... 103 Figura 21 Início de utilização da biblioteca TalAccess e paragem do TeMIP... 106 Figura 22 Paragem da biblioteca TalAccess... 108 Figura 23 Realização de uma interrogação síncrona... 109 Figura 24 Realização de uma interrogação assíncrona... 111 Figura 25 Posicionamento do cliente local... 115 Figura 26 Posicionamento do cliente remoto... 125 Figura 27 Introdução da interrogação... 133 Figura 28 Apresentação da resposta... 133 Figura 29 Autenticação do utilizador... 134 Figura 30 Página inicial vista num PDA... 139 Figura 31 Página inicial vista num browser... 140 Figura 32 Escolha de OCs a monitorizar... 140 Figura 33 Lista de alarmes de um operation context... 141 Figura 34 Pormenores de um alarme... 142 Figura 35 Arquitectura global da aplicação Web... 143 Figura 36 Ritmo de resposta no modo síncrono... 151 Figura 37 Tempo de resposta no modo síncrono... 152 Figura 38 Detalhe do tempo de resposta no modo síncrono... 153 Figura 39 Ritmo de resposta para perguntas assíncronas... 156 Figura 40 Tempo de resposta para perguntas assíncronas... 156

Índice de Tabelas XIII Tabela 1 Ritmo de resposta no modo síncrono (respostas/s)... 150 Tabela 2 Tempo de resposta no modo síncrono (ms)... 150 Tabela 3 Ritmo de respostas em modo assíncrono (respostas/s)... 155 Tabela 4 Tempo de resposta em modo assíncrono (ms)... 155

Introdução 1 Capítulo 1 Introdução Este capítulo apresenta o problema identificado e a solução proposta. A primeira secção apresenta a motivação para a realização deste trabalho. Na segunda secção é delineada a solução proposta, que será apresentada em detalhe nos capítulos seguintes. A última secção descreve a estrutura deste texto.

Introdução 2 1.1 Motivação As redes de comunicação ocupam hoje um papel central nas nossas vidas. É difícil imaginar como seria viver sem telefones, telemóveis, computadores e Internet. No entanto, todas estas tecnologias, às quais damos tanto valor, são ainda relativamente recentes, estando em constante evolução. Com o objectivo de tornar a vida do consumidor final cada vez mais simples e de aumentar a aceitação dos produtos, as redes de comunicação que os suportam são cada vez mais complexas. A manutenção e operação destas redes, das quais a nossa dependência aumenta de dia para dia, são também tarefas cada vez mais complexas. A evolução das redes de dados ditou e acompanhou a evolução dos próprios computadores e da forma como os utilizamos. Os primeiros computadores similares aos que conhecemos hoje eram sistemas centralizados, podendo os utilizadores aceder-lhes através de terminais remotos. As redes de acesso que ligavam os terminais aos sistemas centralizados eram de reduzida dimensão e isoladas. Foi por esta altura que começaram a surgir as primeiras redes de computadores, assentes sobre tecnologias proprietárias específicas de cada fabricante. Embora fossem estes computadores os primeiros a fazer parte da Internet, na altura esta era ainda uma experiência de diminutas proporções (década de 70). A década de 80 assistiu à explosão do mercado dos PCs (Personal Computers), cujos baixos preços levaram à colocação de um computador por secretária, em detrimento dos sistemas centralizados. As redes locais, em particular aquelas suportadas em Token-Ring e Ethernet, ligavam estes PCs. A manutenção de um grande número de PCs tornou-se uma tarefa complexa. Na década de 90 a Internet implantouse comercialmente, graças à popularidade da WWW (World Wide Web). As aplicações WWW retomaram o conceito de servidores centrais ao concentrar as aplicações nos servidores HTTP (Hyper Text Transport Protocol), facilitando a sua manutenção e distribuição. No entanto, nos últimos anos, à medida que cada vez mais aplicações adoptam interfaces Web, estas têm sofrido grandes avanços, tornando-se cada vez mais complexas e integrando um número cada vez maior de outros sistemas. Como resultado a sua gestão e manutenção também se tornaram mais complexas. Paralelamente, também as redes de telecomunicações evoluíram. Inicialmente destinadas apenas ao tráfego de voz, as redes de telecomunicações suportam hoje voz e

Introdução 3 dados. Enquanto a voz requer uma largura de banda relativamente baixa, a qual tem vindo a diminuir através de técnicas de codificação cada vez mais eficientes, as aplicações de dados requerem cada vez mais largura de banda. O volume de tráfego constituído por dados é cada mais significativo, havendo uma tendência para a criação de redes integradas, destinadas a suportar aplicações multimédia, sendo a voz transportada, por exemplo, sobre IP (Internet Protocol) [1]. Para isso ser possível é necessário introduzir qualidade de serviço na rede inteira. O aumento do número de utilizadores e carga na rede motiva a sua constante evolução e reengenharia. À medida que os operadores de rede adoptam novas tecnologias, estas têm de coexistir com as já presentes nas redes, aumentando assim a sua complexidade. Um operador de telecomunicações tem de gerir não só uma complexa rede de comunicações como um conjunto de aplicações destinadas a prestar os serviços aos clientes. Para complicar ainda mais a situação, frequentemente o operador não é dono da rede inteira, contratando serviços a outros operadores. Assim, um operador, para prestar determinado serviço aos clientes, tem de gerir os seus equipamentos e verificar se os seus próprios fornecedores lhe prestam o serviço contratado [2]. Este cenário, já de si complexo, é agravado pela necessidade de manter os custos baixos e disponibilizar rapidamente novos serviços devido à competição. Os esforços de normalização das redes de comunicações centraram-se no desenvolvimento das tecnologias de comunicação em si, deixando para segundo plano a gestão das redes. Assim, as normas de gestão de rede surgiram mais tarde. Nesta área, os fabricantes foram capazes de impor soluções proprietárias durante mais tempo, demonstrando que a maturação destas tecnologias foi um processo mais demorado. A necessidade de interligação dos operadores de telecomunicações obrigou o mercado a fornecer soluções normalizadas desde cedo. No entanto, sendo a gestão de rede muitas vezes um processo interno a cada organização, foi possível responder às necessidades dos operadores com soluções de gestão proprietárias. Existem várias tecnologias normalizadas, até certo ponto, que coexistem, nem sempre pacificamente, umas com as outras e com soluções proprietárias. Os finais da década de 80, inícios da década de 90, assistiram ao surgimento de esforços de normalização das arquitecturas de gestão. As mais bem sucedidas foram a SNMP (Simple Network Management Protocol) [3], promovido pelo IETF (Internet Engineering Task Force), e a OSI/TMN (Open Systems

Introdução 4 Interconnection/Telecommunications Management Network) [4][5], promovida pelo ISO (International Organization for Standardization) e pelo ITU-T (International Telecommunications Union Telecommunication Standardization Sector). Ambas as arquitecturas se baseiam num modelo cliente/servidor onde os clientes, sobre a forma de aplicações de gestão, comunicam com os servidores (agentes), que correm nos equipamentos geridos. Os agentes são componentes de software que permitem efectuar a gestão remota dos equipamentos. As duas arquitecturas distinguem-se principalmente pelo seu mercado alvo e nível de funcionalidade implementada nos agentes. O SNMP foi criado com o objectivo de gerir equipamentos ligados a redes de dados, nomeadamente à Internet ou a outras redes TCP/IP (Transport Control Protocol/Internet Protocol), tendo sido especificado de uma forma aberta através de RFCs (Request For Comments). O objectivo era a criação de uma arquitectura simples e fácil de implementar. Esse objectivo foi conseguido e o SNMP, devido ao seu baixo custo de implementação, é hoje suportado pela maioria dos equipamentos destinados a redes IP, mesmo quando estes suportam outras arquitecturas mais complexas. Os agentes SNMP apresentam uma funcionalidade muito limitada, sendo o processamento efectuado pela aplicação gestor. Isto implica que o gestor tem de aceder frequentemente aos agentes, resultando assim numa grande ocupação da rede. O transporte da informação de gestão sobre a rede gerida, e a utilização de um protocolo de transporte sem garantia de entrega (UDP User Datagram Protocol), limitam a utilização do SNMP em ambientes críticos. A simplicidade da arquitectura SNMP também é reflectida no modelo de informação, que não é orientado a objectos, tornando a sua adaptação às necessidades específicas de cada equipamento impossível. A consequência foi a criação de diversas MIBs (Management Information Base) proprietárias onde os fabricantes colocaram a informação específica dos seus produtos, obrigando as aplicações de gestão a conhecer explicitamente cada uma destas MIBs e diminuindo a interoperabilidade dos equipamentos a nível de gestão [6][7]. A arquitectura OSI/TMN foi criada através de um processo mais formal e moroso, fazendo com que tivesse uma implantação mais lenta. Esta arquitectura destina-se ao mercado dos operadores de telecomunicações, tendo maiores requisitos de disponibilidade que o SNMP. A comunicação entre agentes e gestores pode mesmo ser efectuada através de uma rede separada, física ou virtualmente, das redes geridas. Esta arquitectura permite ainda a troca de informação de gestão entre operadores de uma

Introdução 5 forma normalizada. A maior complexidade desta arquitectura está patente no modelo de informação e na funcionalidade atribuída aos agentes. A arquitectura usa um modelo de informação baseado em objectos, que para além de ser muito extenso, permite a sua fácil ampliação através do mecanismo de herança. No entanto, os agentes OSI/TMN são muito mais complexos, fazendo com que a sua implementação apenas se justifique em equipamentos mais caros. Estes são capazes de realizar algum processamento, permitindo que a gestão de rede seja realizada de uma forma distribuída, por oposição ao modelo centralizado do SNMP. Hoje a convergência das redes de telecomunicações e dados é cada vez mais uma realidade. Assim os operadores de telecomunicações são forçados a manter redes constituídas por equipamentos que utilizam tanto as arquitecturas de gestão referidas, como outras proprietárias. Muitos dos equipamentos de rede existentes não seguem as normas de gestão, quer porque estas não são suficientemente flexíveis para suportar as necessidades do equipamento, quer porque os fabricantes esperam fidelizar os clientes através do uso de protocolos e aplicações de gestão proprietárias. No entanto, uma gestão de rede eficaz só pode ser atingida através da recolha e análise da informação fornecida por todos os equipamentos constituintes da rede. Numa rede constituída por um grande número de equipamentos de diversas marcas a gestão individual de cada elemento de rede não é viável. Este tipo de gestão requer uma grande quantidade de recursos humanos e não consegue proporcionar uma visão global da rede. Como resposta a este problema, vários fabricantes desenvolveram aplicações capazes de gerir diferentes tipos de elementos de rede graças ao suporte de vários protocolos de gestão. Estas aplicações, denominadas Plataformas Integradas de Gestão de Rede, caracterizam-se ainda por poderem ser facilmente estendidas de forma a permitir a gestão de novos equipamentos [8]. É assim possível usar estas aplicações para efectuar a gestão de redes complexas, quer recorrendo às capacidades nativas da plataforma, quer comprando ou desenvolvendo módulos para comunicação com equipamentos específicos. Os próprios fabricantes dos equipamentos de rede podem vender módulos de acesso para Plataformas Integradas de Gestão de Rede de vários vendedores. A concentração da gestão de todos os elementos de rede numa única aplicação permite passar da gestão individual do elemento de rede para uma gestão ao nível da rede. Os serviços normalmente oferecidos por todas as Plataformas Integradas são: a monitorização de equipamento/rede (estado, desempenho), a indicação de faltas (valores

Introdução 6 fora dos limites estabelecidos, alarme, perda de contacto), a gestão de configuração e representação topológica da rede. No entanto, estes serviços podem ser complementados por outros, tais como a correlação de eventos ou a gestão de problemas. As Plataformas Integradas de Gestão de Rede podem proporcionar uma visão geral da rede e possibilitar a gestão ao nível de rede. Apesar disso, não permitem, por si só, atingir níveis mais elevados de abstracção, como os existentes no Modelo de Responsabilidades, recomendado pelo ITU-T [9]. Este é representado sobre a forma de uma pirâmide, onde cada nível assenta sobre o inferior, e proporciona um grau de abstracção superior. Na base encontramos a gestão ao nível de elemento de rede. O nível superior é o nível de rede, que pressupõe a agregação da gestão de todos os elementos de rede, permitindo assim uma visão global do comportamento da rede como um todo. No entanto, a rede apenas existe para suportar os serviços, e é este o nível seguinte da pirâmide. Neste nível são geridos os serviços, abstraindo a rede e os elementos de rede e focando o serviço como o cliente o vê. No topo da pirâmide reside a abstracção de nível de negócio, para o qual é relevante informação financeira, legal, estratégica, económica e métricas de rentabilidade do negócio. Quanto mais acima na pirâmide reside um nível de gestão, mais difícil é implementá-lo. No entanto, a Gestão de Serviço é hoje um objectivo a atingir [10][11][12], o qual só se atinge de uma forma eficaz se a informação de gestão de rede for combinada com outras fontes de informação como ferramentas de workflow, CRM (Costumer Relationship Management) e ERP (Enterprise Resource Planning). A concentração da gestão de rede numa única aplicação torna viável a integração desta informação com outras fontes, existindo muitas vantagens à espera de serem aproveitadas. O acesso à informação de gestão poderá ser utilizado para vários fins, tais como: criação de novos interfaces (WAP Wireless Application Protocol [13], WWW, PDA Personal Digital Assistent, 3G Third Generation of mobile communications technology); criação de interfaces de gestão Web [14][15]; geração automática de relatórios; integração em processos de workflow tais como aprovisionamento de serviços [16]. Informação proveniente de outras aplicações pode também ajudar à gestão de rede: a prioridade de um alarme pode ser alterada de acordo com o nível de serviço (Service Level Agreement SLA) acordado com o cliente afectado; a informação de contacto do responsável por um determinado equipamento pode ser retirada de um directório LDAP (Lightweight Directory Access Protocol), evitando assim a replicação de informação.

Introdução 7 As Plataformas Integrada de Gestão de Rede dão muita ênfase à capacidade de integrar vários tipos de elementos de rede. No entanto, a sua capacidade de integração com outras aplicações é reduzida. Por sua vez, o mercado das aplicações de integração fornece produtos capazes de realizar a integração da maior parte das aplicações acima referidas, excepto as Plataformas Integradas de Gestão de Rede. A integração eficiente de diversas aplicações requer o uso de uma plataforma de middleware que forneça acesso a estas aplicações [17][18]. O Java 2 Enterprise Edition (J2EE) [19] proporciona essa possibilidade ao mesmo tempo que oferece as vantagens associadas à linguagem Java: grande base de programadores; portabilidade de código fonte e compilado para um grande número de sistemas operativos e arquitecturas; suporte para Common Object Request Broker Architecture (CORBA) [20] permitindo o acesso directo a aplicações de gestão suportadas em CORBA. Adicionalmente o J2EE não é um produto mas uma norma suportada pelos grandes nomes da indústria, permitindo que uma aplicação J2EE possa correr em diferentes implementações (J2EE containers ou servidores) de diferentes vendedores. A interacção entre uma aplicação J2EE e Sistemas de Informação Empresariais, tais como Plataformas Integradas de Gestão de Rede, é conseguida através da Java Connector Architecture (JCA), uma das últimas adições ao J2EE [21]. Esta norma define interfaces que um connector e um servidor J2EE devem implementar para que um connector possa funcionar com qualquer servidor J2EE. O conceito de Conector não é novo, e produtos de middleware como o Vitria [22] ou o Tibco [23] há muito que fornecem tecnologias similares, conhecidas como Conectores ou Adaptadores [24]. Embora o JCA só tenha sido introduzido há alguns meses, já é listado como sendo suportado por nove vendedores de servidores J2EE, existindo connectors para os EIS mais utilizados, como por exemplo o SAP [25], para o qual já são conhecidos quinze connectors diferentes [26]. Estes primeiros connectors a surgir no mercado destinam-se a ERPs, aplicações de CRM, SGBDs (Sistemas de Gestão de Bases de Dados) e outros sistemas empresariais. No entanto, não se encontram disponíveis connectors para Plataformas Integradas de Gestão de Redes.

Introdução 8 1.2 Solução proposta Este trabalho apresenta um connector JCA para a Plataforma de Gestão Integrada Telecommunications Management Information Platform (TeMIP) da Compaq [27]. O TeMIPConnector, nome com que o connector foi baptizado, poderá ser utilizado no desenvolvimento de aplicações J2EE que comunicam com o TeMIP. O recurso a outros connectors possibilita o desenvolvimento de aplicações que comunicam com vários sistemas, servindo de hub, conforme ilustrado na Figura 1. É assim possível desenvolver aplicações para automatizar tarefas de gestão ao nível de serviço ou mesmo de negócio. Aplicação ERP Connector para ERP Aplicação de Facturação Connector para Apl. Fact. Aplicação J2EE Connector para CRM Aplicação CRM TeMIP Connector TeMIP Figura 1 O TeMIPConnector permite integrar o TeMIP com outras aplicações

Introdução 9 1.3 Estrutura da tese A presente tese é constituída por oito capítulos e um anexo. O próximo capítulo apresenta uma perspectiva mais detalhada da problemática da gestão de rede e integração de aplicações. As tecnologias escolhidas para a realização deste trabalho são apresentadas no terceiro capítulo. O quarto capítulo detalha a arquitectura da solução, enquanto que o quinto foca os detalhes de implementação. No sexto capítulo é dado o exemplo de uma aplicação que utiliza o TeMIPConnector, explorando assim um possível cenário de utilização. O sétimo capítulo apresenta os testes de desempenho realizados com vista a avaliar a escalabilidade da solução. Esta dissertação termina com o oitavo capítulo onde são apresentadas as conclusões e caminhos possíveis para o desenvolvimento futuro do trabalho. Após as referências bibliográficas é apresentado, em anexo, um glossário.

Gestão de redes 11 Capítulo 2 Gestão de redes Este capítulo analisa a problemática de gestão de rede, segundo as normas e recomendações internacionais. Na primeira secção são apresentadas as normas e recomendação relevantes desenvolvidas pelos organismos internacionais de normalização ou consórcios industriais. A segunda secção apresenta algumas das funcionalidades fornecidas pelas plataformas de gestão de rede disponíveis, mostrando que estas soluções não são capazes, por si só, de realizar a visão idealizada pelos organismos de normalização. Devido à necessidade de integração das plataformas de gestão com outras aplicações empresariais para atingir uma gestão integrada de rede e serviços, são analisados na terceira secção algumas das soluções de integração utilizadas. Na última secção apresenta é apresentado um resumo deste capítulo.

Gestão de redes 12 2.1 O modelo de referência do TMForum O Telecommunications Management Forum (TMForum) é uma organização internacional sem fins lucrativos, sendo um consórcio de operadores de telecomunicações, prestadores de serviços e fabricantes de equipamentos e software para a indústria de serviços de informação e comunicação. O seu objectivo é concertar fornecedores e compradores de equipamentos e soluções, de modo a criar especificações e recomendações que facilitem a automação dos processos de negócio dos operadores e fornecedores de serviços de telecomunicações de uma forma eficiente em termos de tempo e custo. O TMForum tenta atingir os seus objectivos utilizando normas já existentes e, quando necessário, sugerindo às organizações internacionais de normalização a criação de novas normas. Parte do seu esforço envolve a implementação das suas próprias recomendações, processo que pode resultar na entrega de feed-back às referidas organizações. 2.1.1 Modelo de Responsabilidade Uma das normas em que o TMForum se apoia é o modelo de gestão OSI/TMN. Este é uma arquitectura de referência para a gestão distribuída de redes de telecomunicações. Um dos seus objectivos é permitir a troca de informação de gestão, de uma forma normalizada, entre operadores de rede ou fornecedores de serviços de telecomunicações. A arquitectura OSI/TMN foi a primeira a ser definida explicitamente através da sua separação em quatro modelos: o modelo de informação, o modelo de organização, o modelo de comunicação e o modelo funcional. O modelo de informação define a abstracção dos objectos geridos, definindo, por exemplo, os tipos de dados disponíveis para representar os objectos geridos e o sistema de nomes utilizado para identificar as instâncias dos objectos [28][29]. A quantidade de informação definida no modelo de informação e o detalhe desta informação restringem a funcionalidade e afectam a complexidade das aplicações de gestão. A arquitectura OSI/TMN recorre à modelação por objectos para representar os objectos geridos.