gerência corporativa

Pontifícia Universidade Católica do Paraná
Centro de Ciências Exatas e Tecnológicas
Especialização em Sistemas Distribuídos
A UTILIZAÇÃO DE TECNOLOGIAS WEB EM
SISTEMAS DE GERÊNCIA CORPORATIVA
Curitiba, março de 2000
2
José Luís Vieira Carvilhe
A Utilização de Tecnologias WEB em Sistemas de
Gerência Corporativa
Monografia apresentada à Coordenação do
Curso
de
Distribuídos,
Especialização
da
Pontifícia
em
Sistemas
Universidade
Católica do Paraná, sob a orientação do
Professor Doutor Carlos Alberto Maziero.
Curitiba, março de 2000
3
Agradecimentos
À minha esposa Marcia pelo apoio e incentivo durante o período em que me
dediquei a este projeto pessoal.
Ao Professor Doutor Carlos Alberto Maziero pelo apoio durante o curso de
especialização e pela orientação desta monografia.
Aos amigos de trabalho da Companhia de Informática do Paraná - CELEPAR,
que direta ou indiretamente contribuíram através de críticas e sugestões, para a
melhoria da qualidade deste trabalho.
À Companhia de Informática do Paraná - CELEPAR pelo programa de
incentivo à educação na busca da qualidade dos serviços do estado para o cidadão.
4
Sumário
1 INTRODUÇÃO
11
2 GERÊNCIA CORPORATIVA
13
2.1
2.2
2.3
13
14
15
CONCEITO DE GERÊNCIA CORPORATIVA
BENEFÍCIOS DA GERÊNCIA CORPORATIVA
SISTEMAS CONVENCIONAIS DE GERÊNCIA CORPORATIVA
3 AS ÁREAS DE GERÊNCIA E SEUS PADRÕES
18
3.1
3.1.1
3.1.2
3.1.3
3.2
3.2.1
3.3
3.3.1
3.4
18
20
30
33
34
34
37
37
37
GERÊNCIA DE REDES
SNMP
CMIP
TMN
GERÊNCIA DE SISTEMAS
DMI
GERÊNCIA DE APLICAÇÕES
ARM
GERÊNCIA DE SERVIÇOS
4 GERÊNCIA VIA WEB
39
4.1
CONCEITO DE GERÊNCIA VIA WEB
4.1.1
FRAMEWORKS DE GERÊNCIA VIA WEB
4.1.2
BENEFÍCIOS DA GERÊNCIA VIA WEB
4.2
A EVOLUÇÃO DA INTERNET E SERVIÇOS WEB
4.3
TECNOLOGIAS WEB
4.3.1
PROTOCOLOS DE COMUNICAÇÃO
4.3.1
BROWSER WEB
4.3.2
SERVIDOR WEB
4.3.3
MARKUP LANGUAGES
4.3.4
LINGUAGENS DE PROGRAMAÇÃO WEB
4.3.5
LINGUAGENS SCRIPT WEB
4.3.6
FORMATOS GRÁFICOS
4.3.7
MIME
4.3.8
CGI
4.3.9
ACTIVEX
4.3.10
SEARCH ENGINES
4.3.11
BANCOS DE DADOS
4.3.12
VRML
4.3.13
COOKIES
4.4
CONCLUSÃO
39
40
44
46
48
48
51
53
55
62
64
68
69
69
70
70
70
71
71
71
5
5 JAVA MANAGEMENT EXTENSION - JMX
73
5.1
5.2
5.3
5.3.1
5.3.3
5.3.2
5.3.3
5.3.4
5.4
73
73
74
74
76
77
77
78
78
JMX
ARQUITETURA JMX
COMPONENTES JMX
RECURSO GERENCIÁVEL
AGENTE JMX
GERENTE JMX
SERVIÇOS DE GERÊNCIA
APIS PARA OUTROS PROTOCOLOS DE GERÊNCIA
CONCLUSÃO
6 WEB MANAGEMENT ENTERPRISE - WEBEM
79
6.1
6.2
6.2
6.2.1
6.2.2
6.2.3
6.2.3
6.3
79
80
83
83
87
87
87
88
INICIATIVA WEBEM
ARQUITETURA WEBEM
COMPONENTES DA ARQUITETURA WEBEM
CIM
CIMOM
HMMP
XML
CONCLUSÃO
7 ESTUDO UNICENTER TNG
89
7.1
INTRODUÇÃO
7.2
ARQUITETURA UNICENTER TNG
7.2.1
INTERFACE COM O MUNDO REAL
7.2.2
REPOSITÓRIO DE OBJETOS
7.2.3
VISÃO DE NEGÓCIOS
7.2.4
AUTO DISCOVERY
7.2.5
GERENTES E AGENTES
7.2.6
DISCIPLINAS DE GERÊNCIA CORPORATIVA
7.2.7
TECNOLOGIA DE REDES NEURAIS
7.2.8
UNICENTER TNG SDK
7.3
ANÁLISE DA SOLUÇÃO UNICENTER TNG
7.3.1
A SOLUÇÃO UNICENTER TNG E A GERÊNCIA CORPORATIVA
7.3.2
A SOLUÇÃO UNICENTER TNG E OS PADRÕES DE MERCADO
7.3.3
A SOLUÇÃO UNICENTER TNG E A GERÊNCIA VIA WEB
89
89
92
92
93
94
94
95
95
95
96
96
96
97
8 CONCLUSÕES
98
BIBLIOGRAFIA
101
6
Lista de Figuras
Figura 2.1 – Áreas de Gerência Corporativa ______________________________ 13
Figura 2.2 – Políticas de Gerência Corporativa ____________________________ 15
Figura 2.3 – Domínios de Gerência Corporativa ___________________________ 16
Figura 2.4 - Relação entre as áreas de gerência ___________________________ 17
Figura 3.1 – Modelo de Gerência de Redes ______________________________ 19
Figura 3.2 – Evolução da Versões do protocolo SNMP ______________________ 21
Figura 3.3 – Modelo de Referência SNMP ________________________________ 23
Figura 3.4 – Objetos da MIB __________________________________________ 25
Figura 3.5 – Versões do Protocolo RMON ________________________________ 30
Figura 3.6 – Estrutura do protocolo CMIP ________________________________ 31
Figura 3.7 – Serviços CMIP ___________________________________________ 32
Figura 3.8 – Arquitetura da Interface DMTF _______________________________ 36
Figura 3.9 – Arquitetura ARM __________________________________________ 38
Figura 4.1- Modelo Genérico de Gerência via WEB ________________________ 41
Figura 4.2 – Modelo de Framework Nativo _______________________________ 42
Figura 4.3 – Modelo de Framework Proxy ________________________________ 43
Figura 4.4 – Modelo de Framework Gateway _____________________________ 44
Figura 4.5 – Modelo TCP/IP ___________________________________________ 49
Figura 4.6 – Browser WEB ____________________________________________ 52
Figura 4.7 – Servidor WEB ___________________________________________ 54
Figura 4.8 – Transação HTTP _________________________________________ 55
Figura 4.9 – TAGs HTML versão 2.0 ____________________________________ 58
Figura 4.10 – TAGs HTML versão 3.2 ___________________________________ 60
Figura 4.11 – Exemplo de codificação da linguagem Java ___________________ 63
Figura 4.12 – Exemplo de codificação da linguagem C++ ____________________ 63
Figura 4.13 – Exemplo de codificação da linguagem C ______________________ 64
Figura 4.14 – Exemplo de codificação da linguagem JavaScript _______________ 65
Figura 4.15 – Exemplo de codificação da linguagem ECMAScript _____________ 66
Figura 4.16 – Exemplo de codificação da linguagem PERL __________________ 66
Figura 4.17 – Exemplo de codificação da linguagem TCL ____________________ 67
Figura 4.18 – Exemplo de codificação da linguagem Python__________________ 67
7
Figura 5.1 – Arquitetura JMX __________________________________________ 75
Figura 6.1 – Modelo de fluxo de dados WEBEM ___________________________ 80
Figura 6.2 – Modelo de Referência WEBEM ______________________________ 81
Figura 7.1 Arquitetura Unicenter TNG ___________________________________ 91
8
Lista de Abreviaturas
ACSE
Association Controll Service Element
API
Application Program Interface
ARM
Application Response Measure
ARP
Addres Resolution Protocol
ARPANET
Advanced Projects Agency Network
ASN.1
Abstract Syntax Notation One
ATM
Asynchronos Transfer Mode
BER
Basic Encolding Rules
CERN
European High-Energy Particle Physics Lab
CCI
Common Communication Interface
CCITT
International Consultive Committee on Telegraphy and
Telephony
CGI
Common Gateway Interface
CIM
Common Information Model
CIMOM
CIM Object Manager
CMIP
Common Management Information Protocol
CMIS
Common Management Information Service
CMISE
Common Management Information Service Element
CORBA
Common Object Request Broker Architecture
DMTF
Distributed Management Task Force
DMI
Desktop Management Interface
DOM
Document Object Model
DNS
Domain Naming Service
ENF
Event Notification Faciliy
FDDI
Fiber Distributed Data Interface
FTP
File Transfer Protocol
GDMO
Defining Managed Objects
GIF
Graphic Interchange Format
GUI
Graphical User Interface
HMMP
HyperMedia Management Protocol
HMMS
HyperMedia Management Object
9
HTML
Hypertext Markup Language
HTTP
Hypertest Transfer Protocol
IAB
International Architecture Board
IANA
Internet Assigned Number Authority
ICMP
Internet Control Message Protocol
IETF
Internet Engineering Task Force
IIOP
Internet Inter-ORB Protocol
IP
Internet Protocol
IPX
Internetwork Packet Exchange
ISO
International Standard Organization
ITU-T
International Telecomunications Union-Telecomunications
Sector
JDBC
Java Database Connectivity
JMX
Java Management Extension
JPEG
Joint Photographic Experts Group
MAC
Medium Access control
MIB
Management Information Base
MIF
Management Information Format
MIME
Multipurpose Internet Mail Extension
NMF
Network Management Forum
NCSA
National Center Supercomputing Applications
NSF
National Science Foundation
NSFNET
National Science Foundation Network
ODBC
Open Database Conectivity
ORB
Object Request Brocker
OSI
Open System Interconnection
PERL
Pratical Extraction and Report Language
PDU
Protocol Data Unit
PNG
Portable Network Graphics
RARP
Reverse Addres Resolution Protocol
RFC
Request for Comments
RMON
Remote Network Monitoring
ROSE
Remote Operations Service Element
SDK
System Developer Kit
10
SGML
Standard Generalized Markup Language
SMI
Structureof Management Information
SNMP
Simple Network Management Protocol
SPX
Sequence Packet Exchange
SSI
Server Side Includes
TCL
Tool Control Language
TCP
Transmission Control Protocol
TMN
Telecommunications Management Protocol
UDP
User Datagram Protocol
UML
Uniform Modeling Language
URL
Uniform Resource Location
VBNS
Very High Speed Backbone Network System
VRML
Virtual Reality Modeling Language
WEBEM
Web-based Enterprise Management
WWW
World Wide Web
XML
Extensible Markup Language
11
1
INTRODUÇÃO
As tecnologias baseadas na arquitetura WEB estão contribuindo para o
surgimento de um número crescente de aplicações. As principais características
destas aplicações são o fácil acesso de qualquer lugar da Internet e das rede
corporativas e a tendência de redução de custos com a utilização de interfaces
baseadas em browsers WEB.
A Internet e as tecnologias WEB estão influenciando o cotidiano das
pessoas de uma forma nunca antes vista. Mesmo quando uma pessoa tem em
mãos uma revista, um livro ou um jornal, acabará identificando uma referência a um
site na Internet ou um endereço de E-mail. No site do seu banco por exemplo, esta
pessoa pode realizar a maioria das suas transações bancárias, pagar as suas
contas e impostos, sem necessidade de sair de casa. Sem contar ainda com a
possibilidade de declarar o imposto de renda; acompanhar noticiários; participar de
um leilão online; comprar um livro entre outras inúmeras atividades, que cada vez
mais fazem parte da rotina dessas pessoas e das empresas.
No
universo
corporativo
diversas
aplicações
para
administração
e
gerenciamento de redes e sistemas baseados na arquitetura WEB estão surgindo,
caracterizando a tendência de utilização destas aplicações somada a necessidade
de redução dos custos envolvidos na implementação de sistemas de gerência
corporativa.
A gerência corporativa baseada em tecnologias WEB é representada por
um misto de tecnologias, protocolos e linguagens que podem ser implementadas de
forma pontual nas soluções de administração e gerência, ou podem servir de base
para novas plataformas de gerência que estão surgindo. Algumas iniciativas
apontam para o surgimento de novos modelos de frameworks de gerência
corporativa baseados nesta arquitetura.
Este trabalho tem como objetivo analisar a utilização das tecnologias WEB
em sistemas de gerência corporativa.
12
No capítulo 2 deste trabalho é apresentado o conceito de gerência
corporativa [HER99][MUR98][STA96], seus benefícios e uma visão geral sobre os
frameworks de gerência convencionais e áreas da gerência corporativa.
No
capítulo
3
são
detalhadas
as
áreas
[DMT99][HER99][LEI96][MUR98][STA96][THE99]
de
gerência
utilizados
e
padrões
para
cada
implementação.
No capítulo 4 é apresentado o conceito de gerência via WEB [HER99] e os
modelos de implementação de gerência via WEB [HER99]. Nesta capítulo são
ainda analisadas a evolução da Internet e Serviços WEB e as tecnologias [HER99]
utilizadas na implementação da gerência corporativa via WEB.
No capítulo 5 é apresentada a iniciativa JMX da Sun Microsystems para a
gerência corporativa via WEB. No capítulo 6 é apresentada a iniciativa WEBEM do
Distributed Management Task Force (DMTF) como solução para a integração dos
sistemas convencionais de gerência corporativa aos sistemas de gerência via
WEB.
E finalmente, no capítulo 7 é estudada a solução de gerência corporativa
Unicenter TNG da empresa Computer Associates. Neste capítulo esta solução é
estudada sobre a ótica da implementação de funcionalidades de gerência via WEB
e validação dos conceitos apresentados nos capítulos anteriores deste trabalho.
13
2
GERÊNCIA CORPORATIVA
2.1
Conceito de Gerência Corporativa
A gerência corporativa é conceituada em [HER99] como um conjunto de
aplicações associadas a softwares e hardwares que tem como objetivo monitorar e
controlar os recursos de informática de uma empresa. A principal função dos
sistemas de gerência corporativos é garantir a comunicação das informações da
empresa de forma eficiente e segura. Integrando aplicações de forma a se obter o
gerenciamento distribuído dos recursos de informática.
O maior desafio da gerência corporativa é o monitoramento e controle das
diversas plataformas de hardware e software existentes e emergentes. Somado a
complexidade de gerenciamento dos mais diversos sistemas, aplicações e serviços
existentes em uma rede heterogênea.
A gerência corporativa [HER99] abrange diversas áreas de gerência
definidas em camadas a partir da gerência de redes, conforme descrito na figura
2.1, seguida da gerência de sistemas, aplicações, serviços e outras disciplinas
de gerência que em conjunto definem todos os recursos corporativos que
necessitam ser gerenciados.
Redes
Sistemas
Aplicações
Serviços
Outras
Figura 2.1 – Áreas de Gerência Corporativa
14
2.2
Benefícios da Gerência Corporativa
Entre os vários benefícios decorrentes da correta implementação da Gerência
corporativa destacam-se [HER99]:

Alta disponibilidade dos recursos de informática, através da redução dos
gargalos de redes, sistemas, aplicações e serviços determinando de forma
pró-ativa os diversos tipos de gargalos antes de sua ocorrência;

Melhoria do fluxo de informações na empresa, através do aumento da
produtividade na criação, distribuição, utilização, impressão,
guarda e
backup;

Aumento da Segurança, através da adição de níveis de segurança para a
manutenção de dados de natureza crítica e confidencial. Incluindo a
implementação de políticas de segurança de acesso.

Redução do custo total de propriedade de todos os recursos de
informática, através da melhoria da manutenção, diminuição dos custos de
gerenciamento que seria feito de forma personalizada;

Aumento da flexibilidade dos procedimentos operacionais, através da
simplificação da execução de procedimentos operacionais e tarefas de
manutenção usuais como a migração para uma nova plataforma de
hardware ou software, realização de inventários, distribuição de softwares
entre outras.
Para que todos os benefícios da gerência corporativa possam ser
efetivamente implementados, é necessário definir quais são as políticas da
empresa. Isto irá facilitar a apresentação e definição dos objetivos da empresa. A
figura 2.2 descreve a política de gerência corporativa como parte de um grupo de
políticas que pode definir como toda a empresa funciona, Incluindo como a
tecnologia de rede é utilizada.
A política de gerência corporativa é constituída de dois importantes
aspectos: a funcionalidade de gerenciamento e o uso de frameworks baseados em
padrões
abertos.
A
funcionalidade
de
gerenciamento
trata
dos
detalhes
15
administrativos e operacionais de cada dispositivo ou recurso gerenciado, como
cada recurso é gerenciado e a que nível é gerenciado. O framework é definido pelo
tipo específico de padrão empregado. Os padrões predominantes em uso
atualmente incluem SNMP, CMIP, TMN, DMI entre diversos outros, utilizados pelos
fornecedores de soluções de gerência corporativa para a construção de seus
produtos em uso comercial.
Politicas da Empresa
Politicas
de Gerência
Corporativa
Funcionalidades
Frameworks
Baseados em
padrões abertos
Outras
Políticas da
empresa
(Segurança, etc.)
Figura 2.2 – Políticas de Gerência Corporativa
2.3
Sistemas Convencionais de Gerência Corporativa
Existem hoje no mercado diversos sistemas convencionais de gerência
corporativa, estes sistemas são conhecidos como frameworks. Estes frameworks
são baseados em padrões abertos, com suporte a diversas plataformas de
hardware e software, em ambientes de rede heterogênea. Nos últimos 10 anos
houve um grande crescimento e amadurecimento dos sistemas de gerência
corporativa. Neste período foram adicionados diversos tipos de gerenciamento e
novas funcionalidades.
16
O Internet Engineering Task Force (IETF) tem recomendado o Padrão SNMP
para a implementação da gerência de redes com TCP/IP por quase toda a última
década. Da mesma forma os frameworks de gerência de redes e sistema da ISO
com os protocolos CMIS/CMIP, tem sido utilizado nas redes OSI e nas grandes
companhias de telecomunicações por toda a última década. O crescimento da WEB
reativou a iniciativa e o interesse nos frameworks DMTF para gerência de sistemas
utilizando o padrão DMI. Todos estes frameworks de gerência têm estendido sua
atuação sobre a gerência de redes de dados e telecomunicações. E adicionalmente
aos padrões utilizados vários outros consórcios e fóruns estão desenvolvendo novos
frameworks e APIs,
promovendo desta forma o aumento da abrangência da
gerência corporativa de redes e sistemas.
O Network Management Forum (NMF) desenvolveu [HER99] um modelo de
referência para o TMN framework que representa muito bem a gerência
corporativa. O padrão TMN utiliza uma pirâmide para representar os vários níveis
dos domínios de gerência e sua inter-relação. Na figura 2.3, no nível mais baixo são
representados os dispositivos gerenciados de redes.
Gerência de
Negócio
Gerência de
Serviços
Gerência de
Redes
Gerência de
Sistemas
Gerência de
Dispositivos de rede
Figura 2.3 – Domínios de Gerência Corporativa
17
Na segunda camada são representadas as gerências de sistemas e redes.
Na terceira e quarta camadas, são representadas a gerência de serviços e
negócios da empresa.
Este modelo foi usado primeiramente para a gerencia de redes de
telecomunicações,
contudo
com
a
convergência
dos
dados
com
as
telecomunicações, este modelo pode ser utilizado para cobrir todos os dispositivos
de rede, sistemas, serviços e o negócio das empresas.
A gerência de redes é responsável pela gerência dos dispositivos da rede
estendendo a gerência a si mesma.
A gerência de sistema trata dos recursos
disponíveis numa determinada rede. Incluindo a gerência de aplicações que estão
sendo executadas num determinado sistema da rede. O grau de complexidade
aumenta com centralização da gerência de serviços específicos, como níveis de
serviço, políticas e conhecimento, de forma a se ter uma visão de gerência global do
negócio da empresa. A figura 2.4 representa a relação entre os tipos de Gerência
para cada dispositivo gerenciado da rede.
Outras áreas
de Gerência
Outras áreas
de Gerência
Gerência
de Serviços
Gerência
de Serviços
Gerência
de Aplicações
Gerência
de Aplicações
Gerência de Sistemas
Gerência de Sistemas
Gerência de Redes
Figura 2.4 - Relação entre as áreas de gerência
18
3
AS ÁREAS DE GERÊNCIA E SEUS PADRÕES
3.1
Gerência de Redes
Conforme detalhado em [MUR98][STA96], a gerência de redes é
responsável pela monitoração, controle e configuração de dispositivos de redes. A
ISO definiu cinco principais áreas funcionais de gerência que são utilizadas pelos
frameworks padrões IETF e OSI para as aplicações de gerência de redes. Estas
áreas funcionais estão definidas da seguinte forma [MUR98] [STA96]:

Gerência de Configuração, responsável pelo reconhecimento dos
dispositivos da rede, o seu mapeamento e como cada dispositivo é
configurado para operar;

Gerência de Falhas, responsável pela detecção, localização e correção
dos problemas de hardware e software da rede;

Gerência de Performance, responsável pela monitoração da performance
e sintonia da rede quando necessário. Trata da eficiência do uso da rede
e seus recursos;

Gerência de contabilização, responsável pela contabilização do uso dos
recursos de rede por usuário e aplicação;

Gerência de Segurança, responsável pela manutenção da privacidade,
definição de políticas e administração da segurança de acesso aos
recursos de rede e informações confidenciais da empresa.
Os frameworks IETF e OSI são representados respectivamente pelos
sistemas baseados em protocolos SNMP e CMIP. Estes protocolos apesar de terem
sido
criados
com
propósitos
e
padrões
diferentes,
apresentam
algumas
características comuns destacadas abaixo:

Possuem uma definição de como as informações de gerência são
estruturadas;

Possuem um conjunto de objetos gerenciados;

Possuem um protocolo de gerência;
19
Cada framework de gerência de redes possui uma notação padrão para a
definição da estrutura de informação de gerência. Esta notação é utilizada para a
definição do escopo dos objetos de gerência relevantes para cada dispositivo
gerenciado. O protocolo de gerência por sua vez define um conjunto de regras que
permitem dispositivos de gerência, conhecidos como gerentes, se comunicarem
com os dispositivos gerenciados ou agentes, com o propósito de realizar o
intercâmbio das informações de gerência.
O modelo genérico de arquitetura de gerência de redes descrito em
[MUR98], utilizado pela maioria dos frameworks convencionais e proprietários de
gerência de redes é apresentado na figura 3.1. Este modelo representa a estrutura
de um sistemas de gerência de redes, com os componentes individuais de cada
sistema e a inter-relação entre estes componentes.
Dispositivo de rede
Estação de gerência
de rede
Dispositivo de rede
Protocolo de
gerência de redes
Agente de gerência
Pilha de protocolos e
drivers
Pilha de protocolos e
drivers
Rede
Figura 3.1 – Modelo de Gerência de Redes
Neste modelo os dispositivos de rede são divididos em dispositivos de
gerência e dispositivos gerenciados.
Os protocolos de rede são representados
pelos protocolos de gerência de redes, SNMP para os frameworks padrão IETF e
CMIP para os framewoks padrão OSI. Os dispositivos de rede possuem softwares
de gerência de redes, incluindo os softwares para os agentes e gerentes com suas
20
implementações necessárias para o controle dos objetos gerenciados. Neste
modelo ainda são definidas as pilhas de protocolos e dispositivos específicos para
cada implementação. Os dispositivos de redes SNMP utilizam normalmente, o
conjunto de protocolos TCP/IP, mais especificamente o protocolo UDP, como
protocolo de redes e comunicação das aplicações de gerência. Os dispositivos
CMIP utilizam a pilha de protocolos OSI para o mesmo fim.
3.1.1 SNMP
O Simple Managemente Network Protocol (SNMP) é o protocolo padrão para
o gerenciamento de redes, permitindo o controle e monitoração de uma rede e seus
dispositivos. Este protocolo compõem, conforme descrito anteriormente, os
frameworks de gerência de redes padrão IETF.
O SNMP foi inicialmente desenvolvido em 1988 [STA96] como uma pequena
solução para gerenciamento de dispositivos conectados a Internet. O plano inicial
era substituir o SNMP pelo padrão OSI depois que ele fosse desenvolvido e
implementado. Este plano não teve sucesso pois a implementação do padrão OSI
era muito lenta e a esta altura o protocolo SNMP já havia se proliferado detendo o
apoio da industria. Como resultado esta substituição acabou não ocorrendo e o
SNMP tornou-se padrão para as redes baseadas no conjunto de protocolos TCP/IP
como a Internet, o CMIP tornou-se padrão inicialmente para as grandes redes de
telecomunicações e outras grandes organizações.
Originalmente o SNMP oferecia suporte somente para o gerenciamento de
bridges, routers e gateways, mas rapidamente este suporte foi estendido para todo
o tipo de dispositivo de rede. Os dispositivos de redes SNMP utilizaram
originalmente o conjunto de protocolos TCP/IP sobre redes ethernet, como protocolo
de redes e comunicação das aplicações de gerência, no entanto conforme descrito
em [MUR98] existem implementações do SNMP para suporte a Novell IPX/SPX,
ApleTalk DDP e outras tecnologias de enlace como ARCNET, ATM e FDDI.
A primeira versão do SNMP conhecida como SNMPv1 continua sendo a
versão completa padronizada para a Internet. Diversas tentativas de especificação
21
da segunda versão falharam, resultando apenas em especificações de nível
histórico ou experimental. Segundo o IETF cada especificação pode apresentar os
níveis proposta, rascunho, completa, experimental e histórica. O SNMPv3 é a
terceira versão do SNMP em desenvolvimento com a proposta de adicionar
características necessárias para o suporte dos ambientes de Internet atuais. Esta
versão está passando para o nível rascunho e as principais propostas são a
segurança e novas implementações para administração remota.
Nome
Nível
Descrição
SNMPv1
Completa
A versão Original, definida pela RFC 1157 [maio de 1990].
SNMPsec
Histórica
A primeira tentativa de adição de Segurança ao SNMPv1,
definida pelas RFCs 1351 [julho de 1992], 1352 [julho de
1992] e 1353 [julho de 1992].
SNMPv2p
Histórica
Outra tentativa de adição de Segurança ao SNMP, definida
pelas RFCs 1441[abril de 1993], 1445 [abril de 1993], 1446
[abril de 1993], 1448 [abril de 1993] e 1449 [abril de 1993].
SNMP2c
Experimental Foi uma tentativa de combinar o protocolo de operação do
SNMPv2 com com a segurança do SNMPv1, definida pelas
RFCs 1901 [janeiro de 1996] , 1905 [janeiro de 1996] e
1906 [janeiro de 1996].
SNMPv2u
Experimental Foi uma tentativa de oferecer segurança baseada em nas
operações de nomes de usuários e protocolos do SNMPv2,
definida pelas RFCs 1905 [January 1996],1906 [janeiro de
1996],1909 [fevereiro de 1996] e 1910 [fevereiro de 1996].
SNMPv2*
Experimental Foi uma tentativa de adicionar as melhores características
do SNMPv2p e SNMPv2u, definida pelo documento
encontrado no site SNMP Research.
SNMPv3
Proposta
Proposta atual para a adição de segurança e administração
remota ao SNMP, definida pelas RFCs 2271 [janeiro de
1998] e 2275 [janeiro de 1998].
Figura 3.2 – Evolução da Versões do protocolo SNMP
22
Na figura 3.2 está descrita a evolução das versões do SNMP.
3.1.1.1
Arquitetura SNMP
O modelo referencial apresentado na figura 3.3 descreve os componentes da
arquitetura SNMP. Incluindo a estação de gerência, o agente de gerência, a base de
informação e o protocolo de gerência.
Conforme detalhado em [STA96] a estação de gerência é caracterizada como
uma interface para a aplicação de gerência, com um conjunto de aplicações para
análise de dados e identificação de falhas; interface para monitoração e controle da
rede; um banco de dados com as informações extraídas das MIBs dos dispositivos
gerenciados na rede.
Os agentes quando instalados nos dispositivos de redes como hosts, bridges,
routers e hubs, respondem por solicitações de informações e ações efetuadas a
partir da estação de gerência e pode de forma assíncrona enviar informações
importantes para esta mesma estação de gerência sem a necessidade de
solicitação.
Os recursos de uma rede são representados como objetos, cada objeto é
uma variável de dados que representa um aspecto do agente gerenciado. A coleção
destes objetos é referenciada como base de informação de gerência MIB. A estação
de gerência executa as tarefas de monitoração buscando informações dos objetos
da MIB. A estação de gerência pode fazer com que o agente realize uma ação no
dispositivo gerenciado ou modificar uma configuração alterando o valor da variável
específica no agente do dispositivo gerenciado.
A estação de gerência e os agentes são ligados pelo protocolo SNMP. Este
protocolo possui a capacidade de realizar as operações de get, habilitando a
estação de gerência a requisitar os valores dos objetos no agente; set, habilitando a
estação de gerência a alterar valores dos objetos no agente; trap, habilitando o
agente a informar à estação de gerência sobre eventos importantes.
23
Gerente de rede
Interface de usuário
Dispositivo
gerenciado
Aplicação de
gerência
MIB
Estação
Protocolo SNMP
Estação
Gerência
Agent
Protocolos de Rede
Agent
MIB
Protocolos de Rede
Rede
Figura 3.3 – Modelo de Referência SNMP
3.1.1.2
SMI
A estrutura de informação de gerência (SMI) descreve como os objetos de
gerência das MIBs são definidos e codificados para serem transferidos sobre o
protocolo SNMP. Esta estrutura foi definida pela primeira vez em agosto de 1988 e
obteve o nível completo na RFC 1155. Melhorias na definição de objetos e formato
do mecanismo de trap, foram incluídas em 1991 nas RFCs 1212 e 1215.
Conforme detalhado em [MUR98][STA96], a SMI identifica quais os tipos de
dados que podem ser utilizados em uma MIB e especifica como os recursos da MIB
são representados e nomeados. A SMI se caracteriza pela definição de tipos de
dados simples do tipos escalar e tabelas bidimensionais. Os tipos de dados
complexos são evitados para simplificar a implementação.
A estrutura de informação de gerência possui três maneiras de representar as
informações de gerência de forma padronizada:
24

Fornecendo técnicas padronizadas para definição da estrutura de uma
determinada MIB;

Fornecendo técnicas padronizadas para definição de objetos individuais,
sua sintaxe e valores;

Fornecendo técnicas padronizadas para a codificação dos valores dos
objetos;
3.1.1.2.1
Estrutura da MIB
Conforme detalhado em [STA96] todos os objetos gerenciados de uma MIB
são representados na forma de uma árvore obedecendo uma disposição
hierárquica. Os objetos gerenciados são descritos através de uma linguagem
chamada ASN.1, esta linguagem define uma forma de representação padrão para
as informações de gerência que são trafegadas na rede. Associado a cada tipo de
objeto da MIB existe um identificador do tipo ASN.1 object identifier que serve para
nomear cada objeto. Este nome serve para identificar também a estrutura dos
grupos de objeto.
Conforme descrito na figura 3.4, o conjunto de objetos possui uma estrutura
em árvore, começando a partir da raiz existem três nós principais no primeiro nível,
o nós iso,ccitt e joint-iso-ccitt, cada um desses nós é administrado pela organização
específica. Dentro do nó iso, uma das ramificações corresponde a dod,
Departamento de Defesa Americano, que criou o primeiro nó para uso do IAB
(Internet). As outras são para uso de outras organizações. Neste caso o object
identifier corresponde ao valor 1.3.6.1. Este valor irá servir como prefixo para os nós
localizados nos níveis mais baixos da árvore.
O nó Internet é subdividido nos nós diretory, management, experimental e
private. O nó diretório está reservado para os serviços de diretório OSI a serem
implementados futuramente na Internet.
25
root-node
ccitt (0)
iso (1)
aut (1)
joint-isso-ccitt
(2)
bod (2)
org (3)
dod (6)
Internet (1)
diretory (1)
management
(2)
mib-2 (1)
System
(1)
Interfac
esAt
(2)(3)
experimental
(3)
private (4)
enterprises
(1)
Figura 3.4 – Objetos da MIB
Ip (4)
Icmp
(5) (6)
Tcp
Udp (7)
Egp (8)
Transm
ission
Snmp
(10)
(11)
26
O ramo management contém os objetos definidos pelo IAB. Sobre este ramo
da árvore , no ramo 1 está definida a MIB SNMP padrão. Incluindo todos os objetos
das MIBs padrões, incluindo a MIB-II que começam com o mesmo prefixo do object
identifier: 1.3.6.1.2.1. O Internet Assigment Number Authority (IANA) é responsável
pela administração deste ramo.
Os objetos utilizados para testes e pesquisa podem ser definidos no ramo
experimental, cujo prefixo object identifier corresponde a 1.3.6.1.3..1. Este ramo
também é administrado pelo IANA.
O ramo private possui atualmente apenas um nó definido, o nó enterprise.
Este nó é utilizado pelos fornecedores para a melhoria do gerenciamento de seus
dispositivos e compartilhamento de informações. Cada companhia interessada pode
requerer um número ao IANA para a inclusão de seus objetos.
3.1.1.2.2
Descrição dos Objetos da MIB
Todo objeto da MIB obedece uma definição formal utilizando a linguagem
ASN.1. A sintaxe define uma estrutura abstrata que corresponde a cada tipo de
objeto específico. Quatro atributos padrões devem ser definidos para cada objeto
para que estes sejam declarados de forma apropriada em uma MIB SNMPv1:

Syntax type;

Acces mode;

Status;

Name value.
O atributo syntax type é uma das opções do conjunto de objetos ASN.1
predefinidos. As opções podem ser subdivididas nas categorias simple, applicationwide e simple-constructed.
A categoria simple consiste de INTEGER, OCTET
STRING, OBJET IDENTIFIER E NULL. A categoria application-wide engloba
IpAddress, Netwok Address, Counter, Gauge, TimeTicks e Opaque. A categoria
simple-constructed contém listas e tabelas.
27
O atributo access mode é examinado pelo agente a cada request de
informações de um objeto. Os valores permitidos são read-only, read-write, writeonly e not-accessible.
O atributo status define o suporte requerido para a implementação do objeto.
O suporte pode ser mandatory ou optional. Um objeto pode ser especificado como
deprecated, neste caso indica que o objeto deve ser suportado, mas não será
suportado na versão posterior. O objeto pode ser ainda especificado como obsolete,
indicando que o sistema de gerência não implementa mais este objeto.
O atributo name value é um nome textual, chamado object descriptor que
eqüivale ao seu object identifier correspondente.
3.1.1.2.3
Codificação de Objetos
Os valores dos objetos definidos e declarados são transmitidos do agente
para o gerente e vice-versa, utilizando uma regra de codificação da linguagem
ASN.1 para a sintaxe do object type. A notação da sintaxe de transferência utilizada
no SNMP é a Basic Encoding Rules (BER). A BER especifica como a sintaxe é
codificada em octetos e transferida pela rede. A BER é um algoritmo que interpreta
os valores ASN.1 e codifica os bits em octetos apropriados para serem transmitidos
pela rede.
3.1.1.3
Protocolo SNMP
O protocolo SNMP é definido em [STA96] como um protocolo de aplicação
para serviço de gerência de redes. O SNMP foi projetado para ser um protocolo de
camada de aplicação, integrante do conjunto de protocolos TCP/IP. Operando desta
forma sobre o protocolo UDP. O SNMP é um protocolo de requisição e resposta
assíncrono que atende a estação de gerência e os agentes. O SNMPv1 suporta
cinco tipos de mensagens que contém o comando e os dados associados. A
estação de gerência tem a capacidade de transmitir mensagens com três diferentes
PDUs: Get-Request- PDU, GetNextRequest-PDU e SetRequest-PDU. O agente
28
pode transmitir mensagens com dois diferentes PDUs: GetResponse-PDU
processando requisições provenientes da estação de gerência e mensagens TrapPDU em situações onde o agente descobriu um evento predefinido que precisa ser
notificado ao gerente.
O SNMP faz o intercâmbio das informações de gerência através da troca de
mensagens do seu protocolo. Cada mensagem é representada de forma
independente em um único datagrama do serviço de transporte UDP. Cada
mensagem contém a identificação da versão, a comunidade SNMP e o PDU.
A comunidade SNMP identifica um grupo particular de gerentes e agentes.
Os membros de uma comunidade forçam a autenticação utilizando um esquema de
password não encriptada conhecida como trivial authentication scheme. A
comunidade public é geralmente utilizada como padrão nas configurações.
3.1.1.4
RMON
Conforme detalhado em [STA96], o RMON foi um dos mais importantes
padrões incorporadas ao protocolo SNMP.
O RMON permite a monitoração de
várias redes e segmentos identificando possíveis gargalos ou problemas. O RMON
permite o controle de operação da rede através da análise do tráfego, permitindo a
distribuição da carga dos dispositivos existentes na rede.
Os dados fornecidos pelas variáveis RMON podem ser utilizados para o
planejamento de capacidade e simulações de rede. A gerência pró-ativa de
performance é suportada através da utilização das estatísticas de performance na
configuração de alarmes, coleta de dados e análise de resultados na busca de
possíveis problemas.
O RMON é implementado normalmente através de dispositivos que ficam
“ouvindo” o tráfego da rede. Estes dispositivos reúnem e armazenam dados
importantes sobre a atividade da rede que podem ser utilizados para o ajuste de
performance da rede. Uma classe especial de dispositivos chamados probes ou
29
sondas tem sido dedicados para este propósito. Estes dispositivos são configurados
normalmente em cada seguimento da rede, com o objetivo de coletar informações
definidas em suas MIBs. Estas informações incluem banda disponível, contadores
de erros, alarmes, histórico de eventos, entre outros.
Conforme descrito em [STA96], a especificação RMON é antes de tudo uma
definição de MIB. Desta forma são definidas funções de monitoração de redes e
interfaces de comunicação entre a estação gerente e o monitor remoto. A RFC
1757 lista os objetivos projetados para um dispositivo RMON:

Operação off-line, Um agente RMON continua coletando informações
mesmo quando a conexão com estação gerente é perdida;

Monitoração pró-ativa, caso ocorra uma falha , o monitor pode notificar a
estação de gerência e fornecer informações úteis para o diagnóstico da
falha;

Detecção e informação de problemas, o agente pode ser configurado para
informar condições de erros importantes;

Dados adicionais, uma série de dados adicionais específicos podem ser
coletados pelo agente RMON para a estação gerente. Muitos destes
dados não estão disponíveis para a estação gerente quando esta não está
conectada diretamente em uma determinada sub-rede;

Múltiplos gerentes, o agente RMON deve suportar a comunicação com
mais de uma estação gerente.
O RMON nasceu oficialmente em 1991 com a capacidade de monitorar as
camadas 1 e 2. A primeira versão é chamada RMON-1 e está definida na RFC
1757. A versão RMON-2 definida na RFC 2021 é uma extensão natural da versão
RMON-1. A versão RMON-2 especifica a gerência das camadas OSI três a sete
permitindo a monitoração do tráfego dos protocolos IP, TCP, UDP HTTP e outros
protocolos de aplicação. A figura 3.5 descreve a atuação das versões do protocolo
RMON.
30
Sonda RMON
Gerente de rede
Aplicação
Apresentação
Gerente
RMON-2
Sessão
SNMP
Transporte
Rede
Enlace
RMON-1
Fisica
Rede
Figura 3.5 – Versões do Protocolo RMON
3.1.2 CMIP
A arquitetura de gerência de rede OSI, referenciada por CMIP e detalhada em
[HER99][LEI96], foi projetada inicialmente para dispositivos que utilizassem o
conjunto de protocolos OSI. E faz parte de um amplo conjunto de padrões que vem
sendo desenvolvidos para uso no modelo referencial OSI. Estes padrões são
definidos em mais de trinta documentos produzidos pela ISO. O padrões mais
importantes são descritos nos seguintes documentos:

OSI Management Framework (IS 7498-4);

Common Management Information Service (IS 9595);

Common Managemente Information Protocol (IS 9596);

Structure of Management Information (DIS 10165);

System Management Overview (DIS 10040);

Sysatem management Funtional Areas (DIS 10164).
31
Diferente do padrão SNMP, a arquitetura de gerência de redes OSI é
completamente orientada a objetos e fornece um conjunto de serviços através do
modelo de informação, modelo de organização, modelo de comunicação e modelo
funcional. Conforme descrito na figura 3.6, a estrutura do protocolo de gerência OSI
segue o modelo referencial OSI.
Processos de Aplicação de Gerência
CMISE
Camada 7
ACSE
Camada 6
ROSE
Apresentação ISO
Camada 5
Camada 4
Sessão ISO
Transporte ISO
Camada 3
Rede ISO
Camada 2
Enlace ISO
Camada 1
Física
Figura 3.6 – Estrutura do protocolo CMIP
O modelo de informação inclui uma estrutura de gerência de informação, uma
hierarquia de nomes, e uma definição de objetos. A linguagem ASN.1 é utilizada
para a descrição das informações.
O framework OSI é organizado da mesma maneira que o SNMP, com a
estrutura de gerente e agente. Da mesma forma que o SNMP o protocolo CMIP é
implementado na camada de aplicação do modelo OSI. O modelo de comunicação
utiliza o conjunto de protocolos OSI com serviços orientados a conexão.
32
Serviço
Descrição
M-INITIALIZE
Serviço de associação de gerenciamento utilizado para o estabelecimento
da associação
M-TERMINATE
Serviço de associação de gerenciamento utilizado para finalizar a
associação
M-ABORT
Serviço de associação de gerenciamento utilizado para uma parada não
confirmada
M-EVENT-REPORT
Serviço de associação de gerenciamento utilizado para sinalizar um evento
predefinido
M-GET
Serviço de associação de gerenciamento utilizado para a leitura de um
atributo de um objeto
M-CANCEL-GET
Serviço de associação de gerenciamento utilizado para o cancelamento de
uma leitura solicitada
M-SET
Serviço de associação de gerenciamento utilizado para modificar um
atributo de um determinado objeto
M-ACTION
Serviço de associação de gerenciamento que permite que o gerente
execute uma determinada operação num determinado recurso
M-CREATE
Serviço de associação de gerenciamento que permite a criação de uma
determinada instância de objeto
M-DELETE
Serviço de associação de gerenciamento que permite a destruição de um
determinada instância de objeto
Figura 3.7 – Serviços CMIP
O modelo funcional inclui as áreas funcionais de gerência vistas
anteriormente, falha, configuração contabilização, performance e segurança.
A definição dos serviços é chamada de Common Management Information
Services (CMIS). Estes serviços são apresentados na figura 3.7.
33
O protocolo CMIP define como devem ser implementados os serviços CMIS
especificando as PDUs e a sintaxe utilizada na codificação de informações do
protocolo. Três camadas do protocolo OSI necessitam ser implementadas :

Common Management Information Service Element (CMISE);

Association Control Service Element (ACSE);

Remote Operations Service Element (ROSE).
O elemento CMISE permite o acesso ao serviço de gerência CMIS que por sua vez
utiliza o CMIP para a comunicação com o agente e o gerente. O ACSE e ROSE são
utilizados pelo CMISE, sendo necessários para o controle das associações de
aplicação. O ACSE gerencia a abertura e fechamento da comunicação do agente e
do gerente e o ROSE gerencia a solicitação e resposta quando uma associação é
estabelecida.
3.1.3 TMN
O framework TMN engloba um conjunto de especificações que tratam da
gerência e controle de recursos e dispositivos de redes numa rede de
comunicações.
Conforme detalhado em [HER99] o TMN é orientado a objeto e inicialmente
utilizava o padrão de construção OSI, com a especificação de MIBs e objetos de
gerência, agentes e gerentes CMIP, e os protocolos OSI para a troca de
informações de gerência. O framework TMN possui sua própria terminologia. As
áreas funcionais de redes de telecomunicações são definidas por operação,
administração, manutenção e provisioning.
A ITU-T, antiga CCITT, começou o trabalho com o TMN em 1985. O TMN é
definido atualmente pelos documentos série M.3000 ITU-T. A lista de alguns deste
documentos é apresentada baixo.
34
3.2

Overview of TMN Recomendations (M.3000);

Principles for a Telecomunications Management Network (M.3010);

TMN Interface Specification Methodology (M.3020);

Catalog of TMN Management Information (M.3180);

TMN Management Services Overview (M.3200);

TMN Management Capabilities Presented at the F Interface (M.3300);

TMN Management Functions (M.3400)
Gerência de Sistemas
A área de gerência de sistemas trata especificamente dos componentes dos
servidores e computadores pessoais. A gerência de rede trata da rede como um
todo, por outro lado a gerência de sistemas trata do que está dentro de cada
dispositivo de rede. A gerência de sistemas [HER99] é responsável pelas
seguintes tarefas:

Inventário de software e status dos sistemas operacionais e aplicações;

Inventário de hardware e status de CPU, Memória, discos e periféricos
entre outros;

Controle de licenças de softwares;

Distribuição e atualização automática de softwares;

Controle remoto de Servidores e estações;

Outras tarefas relativas a sistemas e dispositivos específicos.
3.2.1 DMI
O Distributed Management Task Force (DMTF) é um dos grupos mais fortes
na criação de padrões de gerência de sistemas. Conforme detalhado em
[DMT99][HER99] o DMTF é um consórcio formado por diversos fornecedores que
35
definiram uma interface de programação padrão para a gerência de estações do tipo
DOS-Windows, permitindo a gerência destas estações e sua integração com outros
frameworks como SNMP.
A especificação da interface independe do sistema operacional de rede e
protocolo de gerência, isto irá permitir que o acesso das informações das estações
gerenciadas seja feito através do protocolo SNMP ou através de técnicas via WEB.
O consórcio DMTF foi formado em maio de 1992, e compreendia inicialmente
os seguintes membros:

Intel Corporation;

Novell, Inc.

SunConnect;

Microsoft Corporation;

SynOptcs

Communications, Inc.
Outras companhias entraram para o consórcio, a lista completa pode ser
encontrada no site www.dmtf.com. Entre elas:

International Business Machines Corporation;

Digital Equipament Corporation;

Hewlett-Packard.
A interface de programação padrão define como o protocolo de gerência e
outras aplicações podem acessar as informações das estações. A arquitetura da
interface DMTF e apresentada na figura 3.8. Embora o foco principal seja o SNMP,
futuramente serão incluídos outros protocolos de gerência e aplicações incluindo a
gerência via WEB.
36
SNMP
Outras Aplicações
Management Interface (MI)
DMI Service Layer
Component Interface (CI)
Componentes de
Hardware
Aplicações de
Software
Sistemas
Operacionais
Placas Adicionais
ESTAÇÃO
Figura 3.8 – Arquitetura da Interface DMTF
A Desktop Management Interface DMI, consiste da DMI Service Layer e das
interfaces MI e CI. A Management interface disponibiliza o acesso padronizado para
as aplicações de gerência solicitarem e receberem informações da DMI Service
Layer. A Component Interface caracteriza o acesso comum para os vários
componentes de hardware e software que podem residir na estação, permitindo a
gerência através de produtos de vários fornecedores. A Component Interface foi
definida para implementar facilmente as versões dos produtos de hardware e
softwares atuais e futuros.
Na DMI Service layer vários serviços são implementados. Estes serviços são
necessários para os comandos e respostas para a interface de gerência e para a
configuração e obtenção de informações de hardware e software a partir da
Component Interface.
37
3.3
Gerência de Aplicações
A gerência de aplicação [HER99] corresponde ao controle, monitoração e
configuração de aplicações que são executadas num determinado host conectado a
rede. Esta área de gerência é muito mais complexa que a gerência de sistema, pois
existem mais versões de aplicações sendo executadas do que sistemas. E diversas
variáveis precisam ser consideradas para a implementação deste tipo de gerência,
incluindo a lista de executáveis, arquivos de configurações associados, métodos de
comunicação entre processos, versões, compatibilidade entre plataformas entre
outras.
3.3.1 ARM
A mais importante iniciativa na área de gerência de aplicação é a API
Aplication Response Measurement (ARM) , definida em 1996 e mantida pela ARM
Working Group. Diversos exemplos de agentes, bibliotecas e programas podem ser
encontrados no site www.cmg.org.
Conforme estudado em [HER99] a API ARM permite que diversas aplicações
de cliente e servidor incluam chamadas de funções simples em seus códigos de
forma a prover informações que podem ser utilizadas para monitoração, medição de
utilização entre outras. A arquitetura ARM utiliza, também, o conceito de agente e
gerente. A figura 3.9 descreve como os servidores e clientes utilizam a API para
comunicar as informações de gerência de aplicação com as aplicação de gerência
de aplicação.
3.4
Gerência de Serviços
A gerência de serviços, incluindo a gerência de acordo de níveis de serviço,
descreve como são definidos, monitorados e apresentados, os serviços contratados
externamente pela empresa e os serviços utilizados internamente. Os serviços que
38
podem ser gerenciados incluem a utilização de canais de voz, tempo de resposta
diversos, acesso a Internet, carga de utilização de LANS e WANS, utilização de Emails, e outros serviços que possam ser quantificados. Os acordos de nível de
serviço são medidos em tempo de resposta, disponibilidade, utilização número de
pacotes entre outros. A gerência de serviço é a maneira principal de avaliar a
qualidade de serviços e os custos envolvidos na empresa.
Aplication
Response
Measurement
ARM Agent
ARM Agent
ARM API
ARM API
stop
start
stop
Server
start
Client
Aplicações
de Negócio
Aplicações
de Negócio
Rede
Figura 3.9 – Arquitetura ARM
39
4
GERÊNCIA VIA WEB
4.1
Conceito de Gerência via WEB
A Gerência via WEB é definida em [HER99] como a utilização de
tecnologias WEB para a realização da gerência corporativa. A gerência via WEB
é muito nova, existem várias frentes de trabalho definindo padrões, frameworks,
modelos de objetos, protocolos e APIs, implementando códigos e testes de
produtos. Para que a gerência via WEB se torne realidade muitas pessoas,
organizações aliadas a tecnlogias precisam reunir esforços e contribuições para
colocar a gerência corporativa sobre o controle desta nova aplicação de gerência
via WEB.
Conforme estudado no capitulo 2, a gerência corporativa utiliza uma série
de protocolos de comunicação sobre a rede com o objetivo de controlar os
dispositivos de rede e os seus softwares associados. A gerência corporativa
monitora, controla e configura todos estes componentes. Com o avanço das
tecnologias WEB, a gerência via WEB pode expandir este leque para incluir a
gerência de recursos de sistemas, aplicações, acordo de níveis de serviço, políticas,
propriedade intelectual, e outros recursos e funções de negócios.
As tecnologias WEB permitem a gerência corporativa a partir de qualquer
ponto da rede corporativa ou da Internet através de um browser (navegador).
Conforme descrito em [HER99] o modelo genérico de framework de gerência via
WEB é dividido em sete partes descritas abaixo. Este modelo é apresentado na
figura 4.1.

Cliente WEB, é o computador de gerência corporativa que contém o
browser WEB. O browser é a interface padrão para visualização das
informações de gerência. O browser permite que o usuário digite
comandos, solicite informações de gerência e apresente os resultados.

Servidor WEB, o servidor WEB corresponde ao programa servidor
responsável por atender as requisições realizadas a partir do browser e
40
retornar as respostas. O servidor WEB possui uma interface para a função
de mediação de dados;

Função de Mediação de Dados, é a função responsável pela conversão
dos dados de gerência do repositório de dados para um formato que seja
reconhecido pelo Servidor WEB pelas aplicações de gerência;

Repositório de Dados, corresponde ao banco de dados onde são
armazenadas as informações de gerência;

Função
de
Agrupamento
e
Mapeamento, corresponde a função
responsável pela conversão dos dados coletados pelos gerentes em um
formato padrão reconhecido pelo repositório de gerência;

Gerentes de Protocolos, correspondem ao lado gerente responsável pela
gerência convencional e a gerência via WEB. Cada gerente utiliza o seu
protocolo para se comunicar com o agente correspondente. Os gerentes
de protocolos tratam SNMP, CMIP, WEB entre outros frameworks de
gerência;

Agente, o agente de gerência corresponde à entidade processo
localizada no dispositivo gerenciado. Muitos agentes são capazes de gerar
alarmes indicando que alguma ação predefinida aconteceu no dispositivo
gerenciado.
4.1.1 Frameworks de Gerência via WEB
Os três principais modelos de frameworks de gerência via Web estudados em
[JAV99], são definidos de acordo com a forma de agrupamento de seus
componentes e relacionamentos. Os três modelos possíveis são o nativo, proxy e
gateway.
41
Cliente de
Gerência
baseado em
WEB
Repositório de
dados de
gerência
Dados da
função de
mediação de
dados
Servidor de
gerência
baseado em
WEB
Função de
agrupamento e
mapeamento
de dados
Gerência Convencional e Baseada em WEB
Gerentes de Protocolos
SNMP
CMIP
WEB
Outros
SNMP
CMIP
WEB
Outros
Figura 4.1- Modelo Genérico de Gerência via WEB
4.1.1.1
Nativo
O modelo de framework do tipo nativo descrito na figura 4.2, corresponde ao
cenário onde o browser se comunica diretamente com o servidor HTTP no
dispositivo gerenciado. O dispositivo gerenciado contém o servidor HTTP e o
suporte necessário para a leitura e gravação das variáveis de gerência. Para que
este modelo seja implementado é necessário que a entidade gerenciada possua as
camadas de protocolo TCP/IP necessárias e opcionalmente applets java para a
gerência via WEB. Os dispositivos gerenciados podem conter
adicionalmente
páginas HTML e todas as funcionalidades de um WEB Server. As requisições via
browser são executadas a partir do servidor WEB onde estão armazenadas as
applets java. As applets são carregadas no cliente browser e executadas.
42
Entidade de Gerência
Entidade Gerenciada
Aplicação Browser
Servidor de Aplicação
HTTP
HTTP
Rede TCP/IP
Rede TCP/IP
Rede
Figura 4.2 – Modelo de Framework Nativo
As páginas WEB armazenadas no servidor WEB podem conter links para
outras páginas e applets. As applets incluem suas interfaces, sockets, segurança,
entre outras características. Esta solução é barata,
pois não é necessário um
dispositivo de gerência intermediário, como por exemplo uma estação de gerência
de redes SNMP.
4.1.1.2
Proxy
O modelo de framework do tipo proxy descrito na figura 4.3, envolve o uso de
um servidor proxy para realizar a tradução da informação de gerência para
informação baseada em WEB para os dispositivos gerenciados. Este modelo de
framework representa a união e coexistência entre a gerência via WEB e os
agentes e gerentes da gerência de rede SNMP. O Gerente pode conter applets e
páginas WEB para as diversas entidades gerenciadas. Neste cenário o gerente é
definido também como servidor HTTP.
43
Entidade de
Gerência
Entidade de gerência
proxy
Servidor de Aplicação
Aplicação Browser
HTTP
Entidade
gerenciada
Mediação
HTTP
SNMP
TCP
UDP
Rede TCP/IP
SNMP
Rede
UDP
IP
Rede IP
Rede
Figura 4.3 – Modelo de Framework Proxy
As requisições via browser podem ser realizadas a partir de CGI´s localizados
onde as aplicações de gerência são armazenadas.
As aplicações escritas em
linguagens como PERL, conhecidas por interfaces Pearl2SNMP, executam
chamadas aos métodos apropriados nas bibliotecas SNMP. Estes métodos por sua
vez executam as operações SNMP nos agentes específicos.
4.1.1.2
Gateway
O modelo de framework do tipo gateway descrito na figura 4.4, envolve o uso
de um gateway para realizar a tradução de diferentes tipos de protocolos e formatos
de dados vindos de diversas fontes. O modelo de framework do tipo gateway
contém as funcionalidades necessárias e pode incluir a gerência de dados
provenientes de diferentes fontes. Pode também incluir um servidor de applets que
pode lançar applets de gerência permitindo a gerência de informação de diversos
tipos de dispositivos gerenciados, incluindo de forma híbrida os dispositivos
gerenciados via framework proxy.
44
Entidade de gerência
gateway
app 1
Entidade de
Gerência
Aplicação Browser
…
app n
Banco de dados
Servidor de
Aplicação
Mediação
HTTP
Gerente
TCP
Transporte
HTTP
Rede TCP/IP
Rede IP
Entidade
gerenciada
Agente
de
Gerência
Pilha
de
Protocolos
Rede
Figura 4.4 – Modelo de Framework Gateway
4.1.2 Benefícios da Gerência via WEB
Conforme descrito em [HER99], existem vários benefícios relacionados a
implementação da gerência baseada em tecnologias WEB. Entre os principais
benefícios, destacam-se o baixo custo de implementação e a facilidade de uso e
acesso via browser Internet. Os principais benefícios estão descritos abaixo:

Baixo custo de implementação, através da redução das despesas desta
solução em relação às soluções convencionais. A utilização do modelo
Internet e as ferramentas requeridas para o desenvolvimento de soluções
baseadas em tecnologia WEB, correspondem a custos bem menores que
os custos envolvidos no desenvolvimento de soluções convencionais.
Existe ainda a possibilidade de redução de custos relacionados a
treinamento, integração do Help Desk e suporte técnico entre outros;
45

Independência de localização do cliente de gerência, as informações de
gerência estão disponíveis em qualquer lugar na rede através do uso de
browsers Internet. Quando comparados as soluções convencionais, estas
informações estão mais disponíveis pela facilidade e flexibilidade de
visualização proporcionadas pela independência de localização do cliente
de gerência;

Facilidade de uso, as características básicas de uma ferramenta browser
podem ser aprendidas rapidamente. E os conceitos sobre HTML, URLs e
navegação sobre hiperlinks entre outros, estão cada vez mais difundidos;

Independência de plataforma e alto grau de interoperabilidade, a utilização
de tecnologias de gerência via WEB permite a gerência dos mais
diversos recursos corporativos, sem a necessidade de instalações,
manutenções e operações adicionais sobre a plataforma de gerência. A
interoperabilidade e independência de plataforma é alcançada através do
uso da linguagem Java e applets, linguagens script e das tecnologias
WEB adaptadas a quase todas as plataformas de computadores
existentes;

Modelo de dados de gerência corporativa amplo e acessibilidade,
conforme detalhado anteriormente no modelo geral de gerência via WEB,
os dados dos sistemas de gerência baseada em padrões e sistemas
proprietários serão coletados e armazenados em um formato padrão no
repositório de gerência;

Possibilidade
de
substituição
das
soluções
atuais
de
gerência
corporativa, a razão principal da pesquisa e uso da gerência via WEB é
a possibilidade de substituição das soluções atuais. A gerência via WEB
tem se posicionado como uma alternativa para as plataformas atuais de
gerência, estas plataformas são caras, difíceis de aprender e de difícil
manutenção e upgrade. A maioria das plataformas de gerência atuais para
serem implementadas necessitam de muito treinamento e do trabalho de
consultores.
46

Expansão das funcionalidades da gerência corporativa, através da
definição de WEB Servers embutidos em dispositivos, aumento da
acessibilidade a Help Desks, documentação online e links com mais
informações sobre o fornecedor entre outros.
4.2
A Evolução da Internet e Serviços WEB
A Internet teve seu início em 1969 como um projeto experimental de rede de
dados chamado Advanced Research Agency Network ARPANET. Conforme
descrito em [HER99] o departamento de defesa americano utilizava a rede como
teste para fins militares. A rede conectava inicialmente quatro universidades. E após
obter sucesso foi estendida com a adição de infra-estrutura de conexão e
computadores dentro dos Estados Unidos.
No início dos anos 70 alguns cientistas iniciaram o desenvolvimento de
protocolos e aplicações de redes aumentando o uso da rede. Em 1972 os cientistas
do NCSA desenvolveram o serviço Telnet, permitindo que usuários pudessem
executar o login em servidores remotos. No ano seguinte o serviço FTP foi
disponibilizado, padronizando desta forma a transferência de arquivos entre os
computadores da rede.
Em 1980 o conjunto de protocolos TCP/IP, tornou-se o único protocolo a ser
utilizado pela rede ARPANET. A década de 80 presenciou um grande crescimento
da difusão dos computadores pessoais e minicomputadores, com sistemas UNIX
versão Berkeley que incluíam os softwares de redes baseados no conjunto de
protocolos TCP/IP. Estes computadores utilizavam os serviços FTP e Telnet para
compartilhar e distribuir e aplicações na Internet.
O maior passo na expansão da Internet ocorreu em meados da década de
80 quando a NSF conectou inicialmente seis centros de supercomputadores. Esta
rede de conexão foi chamada de backbone NSFNET. Este backbone foi expandido
47
pela NSF, com a criação de redes regionais permitindo a conexão de universidades
e outras instituições a Internet. Em 1987 a NSF concedeu para a Merit Network o
direito de operação e gerência do backbone NSFNET. A Merit Network em conjunto
com a IBM e MCI trabalharam na pesquisa e desenvolvimento de uma tecnologia
mais rápida de redes. Em 1989 o backbone NSFNET mudou os seus troncos para a
tecnologia T1. Isto permitiu que o tráfego do backbone passasse para 1.544 Mbits/s.
Quatro anos depois mudou para T3 com velocidade de 45 Mbits/s. Em meados dos
anos 90 o backbone NSFNET foi substituído pela arquitetura vBNS. Este sistema
possui uma organização hierárquica que utiliza provedores de serviços de redes,
redes regionais, pontos de acesso de trabalho. Atualmente estão sendo discutidos
os projetos relacionados a Internet2.
Em 1991 o serviço chamado Gopher foi desenvolvido na Universidade de
Minnesota. Permitindo o acesso de informações através listas de arquivos, estas
listas são acessadas através de menus organizados de forma hierárquica. No
modelo cliente servidor do serviço Gopher, o cliente utiliza um visualizador que
permite a leitura de arquivos de forma individual.
Em 1992, Tim Berners-Lee trabalhando no laboratório europeu de física de
partículas (CERN) localizado na Suíça, criou juntamente com outras pessoas a
Word Wide WEB. A WEB introduziu as tecnologias essenciais para a gerência via
WEB. Incluindo o protocolo HTTP, a linguagem HTML, os links para hipertextos e
hipermidias e o esquema de endereçamento URL.
Uma das principais inovações da WEB foi o uso da linguagem HTML para a
publicação de páginas. As páginas WEB são transferidas entre o servidor e o cliente
através do protocolo HTTP, que é um protocolo de aplicação leve que roda sobre o
TCP. Além das páginas conterem textos podem conter links para hipertextos e
hipermídia. Desta forma, através do clique do mouse sobre o link é possível abrir
uma outra página ou ainda imagens, gráficos, áudio e vídeo.
Finalmente, a utilização da WEB de forma genérica teve seu grande incentivo
com a criação da versão gratuita do browser Mosaic. O browser Mosaic foi projetado
48
e desenvolvido por Marc Andreessen e outros estudantes da Universidade de
Illinois.
As versões comerciais foram projetadas e entregues pela Netscape,
Microsoft , entre outras empresas a partir de 1995.
A evolução dos Serviços Internet e da WEB continua ocorrendo de forma
muito rápida. Várias tecnologias baseadas em WEB estão sendo definidas, entre
estas, várias estão servindo de base para a implementação da gerência
corporativa via WEB.
4.3
Tecnologias WEB
Conforme estudado em [HER99], existem diversas tecnologias que são
utilizadas na gerência via WEB. Estas tecnologias incluem protocolos, interfaces,
padrões, linguagens e técnicas que estão sendo utilizadas e desenvolvidas para a
WEB. As principais tecnologias utilizadas atualmente na implementação da
gerência corporativa via WEB são apresentadas a seguir.
4.3.1 Protocolos de Comunicação
Os protocolos de comunicação correspondem a um conjunto de regras
[MUR98][STA96] que definem como a comunicação será realizada na WEB. O
conjunto de protocolos TCP/IP é o principal protocolo utilizado na Internet.
Conforme descrito na figura 4.5, o modelo TCP/IP, embora represente todas as
funcionalidades do modelo de sete camadas OSI, é representado de forma
condensada em um modelo de quatro camadas.
4.3.3.1
Protocolos de Camada de Acesso à Rede
A função principal dos protocolos de camada de acesso a rede [STA96] é
garantir a troca de informações de forma confiável entre o dispositivo e a rede onde
ele está conectado.
O software específico a ser utilizado nesta camada irá
49
depender do tipo de infra-estrutura de rede que será utilizada. Os padrões utilizados
incluem o protocolo X.25 e Ethernet, ATM, F.Relay, HDLC entre outros.
OSI
TCP/IP
Aplicação
Apresentação
Aplicação
Sessão
Transporte
Host-to-host
Rede
Internet
Link de Dados
Acesso à Rede
Fisica
Figura 4.5 – Modelo TCP/IP
4.3.3.2
Protocolos de Camada Internet
A função da camada Internet é transmitir os dados entre os dispositivos de
origem e destino. O principal componente da camada Internet é o protocolo IP. O
protocolo IP é utilizado nesta camada para fornecer [STA96] as funções de
roteamento entre múltiplas redes. Este protocolo é implementado não somente em
dispositivos de sistemas, mas também em roteadores.
O protocolo IP não é orientado a conexão. A RFC que define a versão 4 do
protocolo IP é a RFC 791. A
responsabilidade pela garantia das mensagens
transmitidas e de responsabilidade da camada de transporte. No caso de protocolos
de transporte não confiáveis como o UDP, esta responsabilidade passa a ser da
camada de aplicação. As mensagens transmitidas entre a camada de transporte e
IP são conhecidas como datagramas e possuem o seu tamanho limitado a 64
50
Kbytes. Estes datagramas são trocados entre as camadas da pilha de protocolos
para serem transmitidos e recebidos na Internet.
4.3.3.3
Protocolos Host-To-Host
A camada de transporte é responsável [STA96] pela transferência dos dados
entre aplicações de forma confiável através do protocolo TCP ou de forma não
confiável utilizando o protocolo UDP.
O protocolo TCP é um protocolo de transporte orientado a conexão. A RFC
que define o protocolo TCP é a RFC 793. Quando uma requisição é feita para um
dispositivo e a conexão TCP é estabelecida, os dados são transferidos e a conexão
é terminada. O protocolo TCP recebe um buffer de dados, divide-o em datagramas
e envia cada datagrama separadamente. O protocolo TCP mantém a lista dos
datagramas transmitidos, através de acknowledgment ou reconhecimento recebidos
por outros hosts, números sequenciais e timeouts. Se o outro host não receber um
pacote em particular, o protocolo TCP irá retransmitir o datagrama. O protocolo TCP
no host destino recompõem o datagrama na ordem correta. A transmissão no
protocolo TCP é feita de forma assíncrona. O protocolo TCP usa a seqüência no
reconhecimento para determinar quais datagramas foram recebidos e quais não
foram, dando maior eficiência ao protocolo.
O protocolo de datagramas de usuário (UDP) corresponde a um serviço de
transporte simples que permite que aplicações utilizem os serviços de rede IP.
Conforme estudado no capítulo três, o protocolo UDP é o protocolo de transporte
preferencialmente utilizado para a gerência SNMP. A RFC que define este protocolo
é a RFC 768.
Este protocolo é orientado a datagrama e fornece serviços não
orientados a conexão.
A confiabilidade deve ser fornecida pelas camadas de
aplicação. O protocolo UDP não fornece a capacidade de detecção e retransmissão
de datagramas perdidos. O protocolo UDP é incompleto pois não possui controle de
fluxo, congestionamento e seqüência de datagramas. A aplicação deve utilizar
mecanismo
como
retransmissão.
timeouts
para
determinar
quando
é
necessário
uma
51
4.3.3.1
Protocolo de Camada de Aplicação
A camada de aplicação [STA96] fornece os serviços de aplicações ou
serviços para usuários finais. Um número grande de aplicações têm sido
padronizadas para operarem sobre a camada de transporte, entre elas as
aplicações de Telnet, FTP, SMTP e SNMP.
O protocolo de camada de aplicação SNMP, estudado em detalhes no
capítulo três, é utilizado para a gerência de dispositivos de redes TCP/IP.
4.3.1 Browser WEB
O browser WEB [HER99] corresponde à aplicação executada no computador
cliente para a apresentação da interface de gerência via WEB. Esta aplicação
utiliza os protocolos padrões HTTP e FTP para a troca de informações na WEB. A
principal função do browser é a apresentação de páginas WEB.
Os primeiros
browsers eram utilizados para a apresentação de páginas baseadas em textos.
Atualmente todos os browsers possuem interface gráfica com a apresentação de
gráficos, hipertextos, e outros formatos himpermídia. Os browsers possuem suporte
ainda a plug-in, segurança,
execução de applets java, animação, gráficos
tridimensionais entre outros. Conforme descrito na figura 4.6 o browser é constituído
da interface GUI, um interpretador HTML e uma interface HTTP.
O esquema utilizado para o endereçamento de páginas WEB é chamado de
Uniforme Resource Location (URL). Este esquema utilizado globalmente como
convenção para endereçamento. A URL é constituída do nome do protocolo e
endereço. O endereço destino pode ser acessado tanto pelo endereço IP como pelo
nome de domínio Internet. O nome de domínio corresponde ao nome que é
resolvido pelos servidores DNS na WEB. A URL é constituída de três campos:
Protocolo://<nome de domínio>/<página ou objeto>
52
Cliente browser
Servidor WEB
Interface GUI
Aplicação Browser
Interpretador HTML
Servidor de Aplicação
Interface HTTP
HTTP
HTTP
Pilha TCP/IP
Pilha TCP/IP
Rede
Figura 4.6 – Browser WEB
Além da URL servir para endereçar páginas utilizando protocolos FTP ou
HTTP, pode ser utilizada também para a visualização de arquivos locais. Neste
caso o campo “file:” é utilizado como campo de protocolo.
Quando um browser é iniciado ele apresenta uma interface padrão,
constituída por uma barra de título, barra de menu, barra de endereço, a área de
apresentação da página WEB e a barra de mensagens.
A barra de título
corresponde ao título da página exibida no momento. A barra de menu contém os
comandos que podem ser executados pelo browser. Cada nova versão de browser
acrescenta novos itens de menu. Estes itens incluem o tratamento de arquivos
opções de edição, preferências, ferramentas de procura, help, bookmarks,
segurança entre outros. A barra de endereço corresponde ao campo onde é
informada a URL para a carga da página desejada. A área de apresentação da
página WEB corresponde a área onde a página é apresentada. O interpretador
53
HTML analisa a sintaxe e cria a página na área de apresentação. A área de
mensagem indica a URL correspondente a um hiperlink quando o mouse é
posicionado com a indicação de uma mão, ou ainda pode apresentar mensagens
genéricas ou mensagens de erro.
Os plug-ins
correspondem a uma parte importante das tecnologias de
clientes browsers. Os plug-ins correspondem a módulos de softwares ou hardwares
que executam determinadas aplicações. A maioria dos plug-ins mais populares
incluem os chamados áudio e vídeo players. Os plug-ins são na maioria das vezes
proprietários ou baseados em tipos de arquivos MIME. Com o aumento da
sofisticação dos browser e applets java a maioria dos plug-ins estão sendo incluídos
de forma padronizada e transparente.
4.3.2 Servidor WEB
O Servidor WEB [HER99] é responsável pela gerência dos recursos WEB
que são requisitados pelos clientes via WEB. A figura 4.7 descreve o modelo de um
Servidor WEB genérico. Um servidor WEB é composto de uma interface de código
HTTP, um gerador de páginas HTML e uma interface de servidor. Um Servidor WEB
pode incluir o tratamento de scripts CGI, acesso a banco de dados para requisições
de sistemas de procura (search engines), interface para configuração e
administração.
Muitos Servidores WEB são disponibilizados como parte integrante de
sistemas maiores que incluem compiladores de linguagens e editores, suporte para
frameworks convencionais de gerência entre outros.
Existem implementações de servidores WEB para a maioria das plataformas
existentes. Para as plataformas UNIX o serviço é implementado normalmente com o
nome “httpd” ou “http daemon” . Um daemon é um processo UNIX executado em
background. Em plataformas Windows o servidor WEB corresponde normalmente a
mais um serviço. A interface WEB possui uma interface HTTP que conversa com a
54
camada TCP. Como o serviço HTTP é orientado a conexão, o protocolo TCP é
utilizado ao invés do UDP utilizado pelo SNMP. O Servidor aguarda requisições da
camada de transporte realizadas pelos clientes normalmente na porta 80, que
corresponde a porta bem conhecida para a WEB.
Cliente browser
Servidor WEB
Interface Servidor
Aplicação Browser
Gerador de páginas
HTML
Servidor de Aplicação
Interface HTTP
HTTP
HTTP
Pilha TCP/IP
Pilha TCP/IP
Rede
Figura 4.7 – Servidor WEB
O protocolo HTTP é um protocolo [HER99] do tipo requisição/reposta utilizado
na WEB. O cliente browser estabelece uma conexão com o servidor HTTP e faz
requisições que são respondidas pelo servidor. Como o HTTP é um protocolo do
tipo stateless (sem estado), a conexão é desfeita após a transmissão da resposta ao
cliente. O HTTP define um conjunto de primitivas que descrevem o tipo de
requisição enviada pelo cliente ao servidor. A primitiva mais comum é a GET,
utilizada pelo cliente para solicitar uma arquivo HTML ou outro arquivo multimídia ao
servidor. O formato das requisições do cliente incluem o método de requisição, URL,
versão do protocolo, mensagem MIME com modificadores de requisição, informação
do cliente e conteúdo do corpo. A resposta do servidor inclui linha de status, versão
do protocolo de mensagem, código de retorno de erro ou sucesso, informações do
55
servidor em formato MIME e conteúdo do corpo da resposta. O protocolo HTTP é
definido na RFC 1945. Um exemplo de transação HTTP é apresentado na figura
4.8. Conforme descrito nesta figura, o protocolo HTTP é um protocolo leve que
utiliza conexões TCP de curta duração.
Cliente
Servidor
O Cliente estabelece
uma conexão TCP
O cliente envia a
requisição HTTP
O servidor retorna a
resposta
O servidor fecha a
conexão
Rede
Figura 4.8 – Transação HTTP
4.3.3 Markup languages
Conforme estudado em [HER99] as Markup languages são linguagens para
formatação de páginas WEB. Estas linguagens correspondem a uma das principais
razões do grande sucesso da WEB. O consórcio W3 está desenvolvendo padrões
para estas linguagens, especialmente para a HTML e XML. O consórcio W3 é
presidido por Tim Berners-Lee, criador da WEB. O consórcio é responsável pela
definição de padrões para a WEB. O site do consórcio pode ser acessado no
endereço http:/www.w3.org.
56
4.3.3.1
HTML
As páginas Web são escritas [HER99][THE99] na linguagem HTML (Hipertext
Markup Language). A linguagem HTML é derivada da linguagem SGML (Standard
Generalized Markup Language) utilizada para a gerência de grandes documentos.
A linguagem HTML já possui cerca de dez anos, com várias versões definidas.
Embora a versão atuais 4.0/4.1 [THE99] esteja ganhando popularidade, a versão
mais utilizada é a versão 3.2, que uniu as extensões dos browsers Netscape e
Microsoft e incluiu novas funcionalidades.
A linguagem HTML é composta por marcadores ou TAG e atributos. O TAG
define como a página é formatada, como um hiperlink é especificado, entre outros
aspectos. Os TAGS são definidos no formato <TAG> ... </TAG>. Um exemplo
simples de página WEB é apresentado a seguir.
<HTML.>
<HEAD><TITLE>
Exemplo de página WEB
</TITLE></HEAD>
<BODY>
TESTE
</BODY>
</HTML>
Os TAGS <HTML> e </HTML> definem o início e fim da página WEB. A
página é composta basicamente de um cabeçalho e um corpo. Dentro do cabeçalho
é definido o título com o nome da página. O título é apresentado na barra de títulos
do browser WEB. O corpo contém o conteúdo que é apresentado na área de
apresentação do browser. A Linguagem HTML versão 2.0 foi desenvolvido em 1994.
Esta versão foi a primeira versão utilizada e suportada pelos primeiros browsers
comerciais. A linguagem HTML versão 2.0, definiu oito tipos básicos de comandos:
tags de estrutura,
cabeçalhos, tags de caracteres, tags de âncoras, gráficos,
separadores de texto, listas, blocos de texto. A figura 4.9 descreve os TAGS HTML
versão 2.0 segundo os tipos definidos com uma breve descrição.
57
TAG
Tipo
Descrição
<HTML></HTML>
Estrutura
Especifica que a página é um documento WEB.
<HEAD></ HEAD >
Estrutura
Define o cabeçalho da página.
<BODY></BODY>
Estrutura
Define o corpo da página
<TITLE></TITLE>
Estrutura
Especifica o título da página.
<BASE>
Estrutura
Especifica o endereço base para resolução de
endereços.
<LINK>
Estrutura
Fornece informações que relacionam a página
corrente a outros documentos.
<META>
Estrutura
Especifica
meta-informação
associada
a
um
documento.
<H1></H1> …<H6></H6>
Estrutura
Especifica os níveis de cabeçalho de 1 a 6.
<B></B>
Caracteres
Especifica o formato de fonte bold para o texto.
<I></I>
Caracteres
Especifica o formato de fonte itálico para o texto.
<TT></TT>
Caracteres
Especifica o formato de fonte monospaced para o
texto.
<CITE></CITE>
Caracteres
Especifica uma citação em formato itálico.
<EM></EM>
Caracteres
Especifica uma frase enfatizada em formato itálico.
<KBD></KBD>
Caracteres
Especifica um texto a ser digitado pelo usuário.
<SAMP></SAMP>
Caracteres
Especifica uma seqüência de caracteres literais.
<STRONG></STRONG>
Caracteres
Especifica
a
apresentação
de
caracteres
fortemente enfatizados.
<VAR></VAR>
Caracteres
Inclui um texto usado como uma variável em
formato itálico.
<A></A>
Âncoras
Inclui um texto utilizado como uma âncora hiperlink.
58
<IMG>
Gráficos
Especifica uma imagem a ser apresentada na
página.
<P>
Separador de Define um salto de parágrafo.
textos
<BR>
Separador de Define um salto de linha.
textos
<HR>
Separador de Especifica a apresentação de uma régua horizontal
textos
<UL><LI></OL>
Lista
Especifica uma lista não ordenada, com cada
elemento listado com o tag <LI>.
<OL><LI></OL>
Lista
Especifica uma lista ordenada por números, com
cada elemento listado com o tag <LI>.
<DL><DT><DD></DL>
Lista
Especifica uma lista de definições onde cada termo
especificado
usa
<DT>
e
sua
definição
correspondente <DD>.
<DIR><LI></DIR>
Lista
Especifica uma lista de diretórios com cada
elemento especificado utilizando o tag <LI>.
<MENU><LI></MENU>
Lista
Especifica uma lista de menus com cada elemento
especificado utilizando o tag <LI>.
<ADRESS></ ADRESS>
Bloco
texto
de Inclui um texto de endereço para endereços,
assinaturas, entre outros apresentado em formato
itálico.
<BLOCKQUOTE>
Bloco
de Inclui textos entre aspas .
texto
</BLOCKQUOTE>
<PRE></PRE>
Bloco
de Inclui textos pré formatados.
texto
Figura 4.9 – TAGs HTML versão 2.0
59
A linguagem HTML versão 3.2 [HER99][THE00] uniu as extensões dos
browsers Netscape e Microsoft e incluiu novas funcionalidades. Entre estas
funcionalidades novos padrões de cores, imagens e fontes; alinhamento de textos;
tabelas; mapas; maior controle do tipo e tamanho de fontes. A figura 4.10 lista os
TAGS incluídos nesta versão.
TAG
Nome
<APPLET>
Java Applet
<AREA>
Area
<BIG>
Big Text
<CAPTION>
Caption
<DFN>
Definition
<DIV>
Division
<FONT>
Font
<INPUT>
Form Input File
<MAP>
Mao
<PARAM>
Parameters
<SMALL>
Small text
<SUB>
Subscript
<SUP>
Superscript
<TABLE>
Table
<TD>
Table Data
<TEXTFLOW>
Java Applet Textflow
<TH>
Table Header
60
<TR>
Table Row
Figura 4.10 – TAGs HTML versão 3.2
A
linguagem
HTML
versão
4.0
[HER99][THE00]
introduziu
novas
funcionalidades entre elas:

O suporte a múltiplos estilos de páginas;

Capacidade de construção de teclas de atalho para controle de páginas;

Suporte a acesso somente para leitura de documentos;

Suporte a Frames;

Suporte a objetos e scripts;

Maior versatilidade aos botões;

Suporte a usuários que não falam inglês e deficientes.
4.3.3.2
Service Side Includes
As Server Side Includes (SSI) [HER99][THE00] ou simplesmente includes de
Servidor, são um tipo de comentário HTML que direcionam o Servidor WEB a gerar
de forma dinâmica os dados de uma página sempre que ela for chamada. O formato
básico da include é:
<!-#command tag=”value”…>
Onde a diretiva #command pode ser qualquer um dos vários comandos
suportados pela implementação do servidor. Um exemplo é a utilização da diretiva
#include que insere o contexto de um arquivo especificado na página WEB. Um uso
comum deste comando é a utilização de um mesmo template para cada página
WEB definida no site. Desta forma as alterações de template serão sempre
61
realizadas somente em uma include. Existem ainda a possibilidade de executar
programas apresentando o resultado através da diretiva #exec.
4.3.3.3
Dinamic HTML
Dinamic HTML é o nome dado a um conjunto de proposta encaminhadas
para o Consórcio W3 pela Microsoft e Netscape. O objetivo da Dinamic HTML é
definir um comportamento mais dinâmico para os browsers, na forma como é feita
interação entre o usuário e as páginas WEB no lado cliente. A Dinamic HTML irá
reduzir de forma gigantesca o tráfego HTTP do servidor na criação de atualizações
de páginas WEB no lado cliente.
4.3.3.4
Extensible Markup Language
A Extensible Markup Language (XML) é uma linguagem [HER99][THE00] cujo
desenvolvimento está sendo supervisionado, também, pelo Consórcio W3. A XML
se diferencia da linguagem HTML, por ser uma linguagem de definição de dados.
Assim como a linguagem HTML, a XML é derivada da linguagem SGML. È uma
linguagem extensível pois permite a criação de novos TAGS. A maneira como a
linguagem XML irá se desenvolver, no meio dos esforços voltados para a linguagem
HTML é ainda uma incógnita.
No site WEBEM um documento escrito por Roger Boot, propõem a utilização
da linguagem XML para a apresentação de dados de gerência. Estes dados
poderão ser apresentados e manipulados por aplicações de gerência corporativa
WEBEM.
4.3.3.5
Cascading Style Sheets
a definição de múltiplos estilos de páginas (Cascading Style Sheets)
[HER99][THE00], tem por objetivo oferecer um maior controle da maneira como as
62
páginas WEB são apresentadas. Através da criação de estilos um layout de página
pode ser definido de forma a sobrepor vários estilos na mesma página. A
especificação do CSS está sendo definida pelo Consórcio W3 e poderá ser
suportada pelas releases futuras dos browser.
4.3.3.6
Document Object Model
Conforme descrito em [THE00] o Document Object Model (DOM) é uma
proposta de padrão, que irá permitir que programas e scripts acessem e atualizem
de forma dinâmica conteúdos, estrutura e estilos de documentos. Os documentos
poderão ser processados e seus resultados incorporados na página apresentada. A
especificação do DOM está sendo definida pelo Consórcio W3.
4.3.4 Linguagens de Programação WEB
As linguagens de programação WEB [HER99] são utilizadas para a criação
de conteúdos ativos e ainda para permitir a execução processos complexos e
processos interativos entre o Servidor e os Clientes WEB.
As linguagens mais
populares da WEB incluem Java, C++ e C. Uma série de outras linguagens são
também utilizadas, incluindo Visual Basic e as antigas linguagens de terceira
geração Fortran, Pascal, Assembly e mesmo o Cobol.
4.3.4.1
Linguagem Java
A linguagem de programação Java [HER99] é uma linguagem orientada a
objetos, desenvolvida em 1990 pela Sun Microsystems. A linguagem Java é
compilada em um formato “byte code” intermediário, que é interpretado pela
máquina virtual Java ativa no computador onde o programa é executado.
A utilização de applets java torna as páginas WEB mais dinâmicas. As
applets são pequenos programas que são carregados do servidore WEB para o
cliente sendo então executados.
63
A linguagem java fornece uma série de classes para criação de animação,
atualização de páginas,
entre outras funcionalidades que dificilmente seriam
implementadas somente com a tecnologia HTML. A figura 4.11 apresenta um
exemplo de codificação da linguagem Java.
// Exemplo de programa Java
class exemplo
{
public static void main (string args [])
{
String name;
name = “Exemplo”
System.out.println(name);
}
}
Figura 4.11 – Exemplo de codificação da linguagem Java
4.3.4.2
Linguagem C++
A linguagem de programação C++ [HER99] foi desenvolvida nos laboratórios
Bell por Bjarne Stroup no início de 1980. A linguagem C++ se diferencia da
linguagem C pela inclusão de construções orientadas a objeto e outras pequenas
melhorias. È uma linguagem muito utilizada para o desenvolvimento de aplicações e
sistemas. A figura 4.12 apresenta um exemplo de codificação da linguagem C++.
// Exemplo de programa C++
#include <iostream.h>
main ()
{
cout << “Exemplo\n”;
}
Figura 4.12 – Exemplo de codificação da linguagem C++
64
4.3.4.3
Linguagem C
A linguagem de programação C [HER99] foi desenvolvida no início de 1970
por Dennys Ritchie, como uma melhoria da linguagem de programação B que era
utilizada pelos laboratórios Bell para a programação do sistema operacional UNIX.
Quando Brian Kernighan e Dennys Ritchie liberaram a definição da linguagem C em
1978, a sua utilização foi ampliada. Em pouco tempo a linguagem C superou a
linguagem assembly como uma nova opção de linguagem de programação de
sistemas. A linguagem C passou também a ser amplamente utilizada para
programação de aplicações. A figura 4.13 apresenta um exemplo de codificação da
linguagem C.
// Exemplo de programa C
#include <stdio.h>
main ()
{
printf “Exemplo\n”;
}
Figura 4.13 – Exemplo de codificação da linguagem C
4.3.5 Linguagens Script WEB
A linguagens script [HER99] são ferramentas importantes para a extensão
das funcionalidades baseadas na WEB. São linguagens baratas e de fácil
aprendizado e desenvolvimento. Estas linguagens são ainda fáceis de serem
testadas por serem interpretadas. Os interpretadores de linguagem script estão
disponíveis para a maioria das plataformas, o que torna a programação
independente
da plataforma utilizada. São linguagens que oferecem maior
facilidade de manutenção e debug se comparadas as linguagens compiladas C e
C++. Muitos programas sofisticados e implementações de referência, relacionados
a estas linguagens, estão disponíveis gratuitamente na WEB. As principais
linguagens utilizadas incluem as Linguagens JavaScript, ECMAScript, PERL, TCL,
65
Python . Uma série de outras linguagens são também utilizadas, incluindo a
linguagem Rexx desenvolvida pela IBM, a VBScript desenvolvida pela Microsoft e
AppleScript da Apple.
4.3.5.1
JavaScript
A linguagem JavaScript [HER99] é uma linguagem script utilizada no lado
cliente. Esta linguagem foi desenvolvida pela Netscape para os browsers Internet,
tornando fácil a codificação de scripts no cliente através da adição de
funcionalidades ao conteúdo WEB. A linguagem JavaScript necessita apenas de um
suporte restrito do lado Servidor. Esta linguagem pode interagir com códigos fontes
HTML criando conteúdos dinâmicos.
<html>
<body>
<br>
<script language=”JavaScript”>
document.write(“Exemplo”)
</script>
<br>
</body>
</html>
Figura 4.14 – Exemplo de codificação da linguagem JavaScript
A linguagem JavaScript é considerada um padrão aberto, sendo suportada
pelos browser da Netscape e Microsoft, com algumas diferenças de implementação.
A figura 4.14 apresenta um exemplo de codificação da linguagem JavaScript.
4.3.5.2
ECMAScript
A linguagem ECMAScript [HER99] é uma linguagem script similar a
JavaScript, desenvolvida como padrão aberto para a Netscape, Microsoft e o
European Computer Standard Group ECMA. A primeira versão corresponde a
versão encontrada nos browsers Netscape Navigator 3. Tanto a Netscape como a
66
Microsoft implementam o padrão ECMAScript. A figura 4.15 apresenta um exemplo
de codificação da linguagem ECMAScript.
<html>
<body>
<br>
<script language=”ECMAScript”>
document.write(“Exemplo”)
</script>
<br>
</body>
</html>
Figura 4.15 – Exemplo de codificação da linguagem ECMAScript
4.3.5.3
PERL
A linguagem PERL (Pratical Extraction Report Language) [HER99] foi
desenvolvida por Larry Wall em 1986. Foi desenvolvida inicialmente para
codificação de relatórios, mas rapidamente ganhou popularidade como uma
linguagem script para administração de sistemas UNIX.
A linguagem PERL é
utilizada para unir as funcionalidades das linguagens shell UNIX e utilitários como o
SED e AWK numa linguagem de uso comum. A linguagem PERL é talvez a
linguagem script mais popular. A linguagem PERL tornou-se muito popular a partir
do momento que passou a ser utilizada com CGIs (Common Gateway Interface).
Com certeza a maioria dos scripts CGI são escritos na linguagem PERL.. A figura
4.16 apresenta um exemplo de codificação da linguagem PERL.
# Exemplo da linguagem PERL
print “Exemplo” “\n”;
Figura 4.16 – Exemplo de codificação da linguagem PERL
67
4.3.5.4
TCL
A linguagem TCL (Tool Command Language) [HER99] foi desenvolvida por
John Ousterhout. A linguagem TCL possui um modelo de dados simples e claro.
Esta linguagem é utilizada para a gerência de redes. Muitos fabricantes usam a
linguagem TCL como API para seus produtos, para criar funcionalidades adicionais.
A linguagem TCL possui um conjunto de ferramentas gráficas conhecidas como TK
para o desenvolvimento de interfaces de usuários. A figura 4.17 apresenta um
exemplo de codificação da linguagem TCL.
# Exemplo da linguagem TCL
puts stdout {Exemplo}
Figura 4.17 – Exemplo de codificação da linguagem TCL
4.3.5.5
Python
A linguagem Python [HER99] foi desenvolvida por Guido Van Rossun. A
linguagem Python possui uma série de funcionalidades orientadas a objeto.
# Exemplo da linguagem Python
exemplo=”Exemplo \n”
print exemplo
Figura 4.18 – Exemplo de codificação da linguagem Python
68
Esta linguagem inclui construções como módulos, exceções, tipos dinâmicos,
tipos dinâmicos de dados de alto nível, e classes. Inclui também interfaces para
chamadas e bibliotecas C e C++ e interfaces para diversos sistemas de janelas. A
linguagem Python é utilizada como uma linguagem de extensão para aplicações
para fornecer uma interface programável. Como a maioria das linguagens script , a
linguagem Python é portável para várias plataformas. A figura 4.18 apresenta um
exemplo de codificação da linguagem Python
4.3.6 Formatos Gráficos
Os formatos gráficos são muito importantes para a WEB, pois um arquivo de
formato GIF pode corresponder a um texto com centenas de palavras. Os dois
formatos gráficos mais populares que são compatíveis com os browsers atuais são
o Graphics Interchange Format (GIF), o Joint Photographic Experts Group (JPEG) e
o Portable Network Graphics (PNG).
O formato GIF [HER99] é o formato de arquivo mais utilizado na WEB. O
formato GIF suporta cores e várias resoluções.
Para diminuir o tempo de
transferência de imagens do servidor para o cliente economizando a quantidade de
espaço em disco necessária para gravar estas imagens, o formato GIF inclui
algoritmos de compressão.
Como o formato GIF é baseado em 8 bits, a maior limitação é que pode
apenas suportar até 256 cores. A Compulserve, criadora do formato GIF, estava
iniciando um trabalhando no desenvolvimento do padrão 24 bits, no entanto quando
a Unisys passou a reclamar a patente das partes principais da tecnologia de
compressão do formato GIF, cobrando pelo seu uso o desenvolvimento foi
cancelado.
O formato JPEG [HER99] é outro formato de arquivo muito popular. O
formato JPEG utiliza a técnica de compressão conhecida como “lossy”. Para realizar
a compressão de uma imagem o algoritmo descarta seletivamente partes da
imagem. O formato JPEG oferece maior flexibilidade em relação ao formato GIF é
possível configurar a taxa de compressão. Quanto maior a compressão menor será
a qualidade em relação a imagem original.
69
Outro formato gráfico que está se tornando muito popular na Internet é o
Portable Network Graphics (PNG) [PNG00]. Ao contrário do formato GIF o formato
PNG é livre de copyright. A especificação do PNG está sendo definida pelo
Consórcio W3. O formato PNG é um formato de compressão de imagens que foi
especialmente concebido para ser utilizado na WEB. O PNG utiliza um esquema de
compressão sem perdas e pretende ser uma alternativa à utilização do formato GIF
na transmissão de imagens tipo bitmap através da Internet. Embora mantenha
algumas
das
características
originais
do
formato
GIF,
o
PNG
introduz
simultaneamente novas facilidades com o objetivo de obter imagens com uma
qualidade cada vez maior. O formato PNG suporta imagens true color com uma
profundidade de cor até 48 bits/pixel e imagens grayscale com uma profundidade de
cor até 16 bits/pixel.
4.3.7 MIME
O Multipurpose Internet Mail Extensions (MIME) [HER99] é uma especificação
para formatação de mensagens que não utilizam o padrão ASCII. Estas mensagens
podem ser enviadas pela Internet por E-mail e browsers de cliente. Existem muitos
tipos MIME pré definidos como arquivos de formato GIF e arquivos PostScript. Tipos
customizados MIME podem ser definidos. A especificação MIME permite que os
browsers apresentem páginas que não são escritas na linguagem HTML.
4.3.8 CGI
O Common Gateway Interface (CGI) é um método de criação de programas
que permite que aplicações externas se conectem a Servidores WEB de forma
padrão. O CGI é um programa executável que pode adicionar informações de forma
dinâmica ao conteúdo de uma página WEB. Uma das primeiras utilizações do CGI
foi para o processamento de transações. Um usuário pode digitar informações em
vários campos, enviar as informações para o servidor, executar o processamento
das informações no servidor e apresentar os resultados na área de apresentação do
browser.
70
4.3.9 ACTIVEX
O ActiveX corresponde a um conjunto de tecnologias desenvolvida pela
Microsoft que são utilizadas para desenvolvimento WEB. ActiveX é baseado na
tecnologias Object Linking and Embedding (OLE) e Component Object Module
(COM) que permitem que programas diferentes trabalhem juntos e compartilhem
dados. O ActiveX é implementado como um controle embutido ou programa em
páginas WEB.
4.3.10 Search Engines
Os sistemas de busca ou Search Engines são utilizados para procurar,
catalogar e apresentar informações. Servidores especiais possuem sistemas de
busca que são utilizados para esta função. Os sites de busca mais populares são o
Alta Vista, Yahoo, Excite, Lycos entre outros.
4.3.11 Bancos de Dados
Os bancos de dados são os repositórios das informações da WEB que são
procuradas ou que necessitam ser armazenadas. Estas informações podem ser
utilizadas para aplicações importantes como as informações de gerência via WEB.
A padronização da interface WEB tem aumentado a utilização de Data Warehouses
e áreas de armazenamento de informações.
O padrão Open Database Conectivity (ODBC) é amplamente utilizado. O
ODBC é um método padrão de acesso a banco de dados que permite que qualquer
aplicação acesse dados de qualquer sistema gerenciador de banco de dados. O
acesso é realizado através de uma camada, conhecida como driver, entre a
aplicação e o sistema gerenciador de banco de dados. A função do driver é realizar
a tradução das solicitações de dados em formato conhecido pelo banco de dados
que foi implementado. Tanto o banco de dados quanto a aplicação devem suportar
a implementação ODBC. O ODBC é caracterizado como padrão de fato de mercado
e foi originalmente desenvolvido pela Microsoft.
71
A Sun possui uma nova interface para a arquitetura Java, conhecida como o
padrão Java Database Connectivity (JDBC).
4.3.12 VRML
A Virtual Realit Modeling Language (VRML) [HER99] é uma nova linguagem
de representação que permite a apresentação de objetos em duas ou três
dimensões em páginas WEB. As páginas WEB podem ser visualizadas através de
browsers especiais VRML ou com a utilização de plug-in especial VRML.
4.3.13 Cookies
O cookie [HER99] é um marcador de mensagem que pode ser enviado ao
browser a partir do servidor. O browser no lado cliente normalmente grava a
informação da mensagem em um arquivo. Desta forma o cookie pode ser
transmitido toda a vez que a página é solicitada no servidor.
Os cookies são
utilizados para a coleta de informações e segurança. O cookie pode ser utilizado
pelo servidor para a criação de auditoria e definição do perfil de usuários. Este
recurso pode ser utilizado para fazer as páginas visitadas mais amigáveis, inserindo
informações como o nome do usuário, tradução da página para a linguagem nativa,
entre outras. Os cookies podem ser utilizados para autenticação de usuários.
4.4
CONCLUSÃO
Neste Capítulo foram descritos o conceito de gerência via WEB [HER99] e
sua arquitetura e os modelos de framework nativo, proxy e gateway. A evolução da
Internet e da WEB e as tecnologias empregadas para a implementação da
gerência via WEB foram apresentadas. Entre as diversas tecnologias analisadas no
capítulo
4,
estão
o
conjunto
de
protocolos
de
comunicação
TCP/IP
[MUR98][STA96]; os browsers Internet [HER99], servidores WEB [HER99];
as
Markup Languages, incluindo HTML, XML entre outras [HER99]; as linguagens de
programação WEB Java, C, C++ [HER99]; as linguagens script WEB JavaScript,
72
ECMAScript, PERL, TCL e Phyton [HER99]; os formatos gráficos GIF e JPEG
[HER99] e PNG [PNG00]; os padrões MIME, CGI, ActiveX,
VRML entre outros
[HER99].
No dois próximos capítulos serão apresentadas as duas principais iniciativas
para a construção de frameworks de gerência corporativa via WEB. A iniciativa
Java Management Extension (JMX) [JAV99] da Sun Microsystems e a Web-based
Enterprise Management (WEBEM) [DMT99][HER99].
73
5
JAVA MANAGEMENT EXTENSION - JMX
5.1
JMX
Conforme detalhado em [JAV99] a JMX (Java Management Extension)
conhecida anteriormente por JMAPI, define uma arquitetura de gerência, APIs, e
serviços de gerência, todos sobre uma única especificação. A especificação para
JMX foi desenvolvida pela SUN junto com os principais líderes da indústria de
gerência, seguindo a Comunidade Java.
A JMX [JAV99] fornece uma maneira simples para instrumentação de objetos
Java. A instrumentação JMX tem muito poucas limitações porque é totalmente
independente da infra-estrutura de gerência. Isto significa que um recurso pode ser
gerenciado sem a preocupação de como seu gerente é implementado, se é
implementado por exemplo sobre TMN ou SNMP.
A JMX permite que os desenvolvedores de aplicações baseadas em
tecnologia Java crie os agentes inteligentes e gerentes na linguagem Java. Estas
aplicações podem ser integradas as soluções em sistemas de gerência existentes. A
arquitetura JMX é dividida em três níveis, nível de Instrumentação, nível de agente
e nível de gerente.
A JMX fornece ainda vários APIs Java para os protocolos padrões existentes.
São as APIs de protocolos de gerência adicionais. Estas APIs foram especificadas
de forma independente do modelo da arquitetura de três níveis, contudo elas são
essenciais porque elas permitem que as aplicações JMX escritas em Java se
integrem com as tecnologias de gerência existentes.
5.2
Arquitetura JMX
A arquitetura JMX [JAV99] é construída de acordo com uma modelo de três
níveis. O nível de instrumentação, agente e gerente. Conforme detalhado na figura
5.1, esta divisão traz flexibilidade permitindo que subconjuntos da especificação
74
sejam utilizados individualmente por diferentes comunidades de desenvolvedores
que utilizam a tecnologia Java.
O nível de instrumentação fornece a gerência imediata de qualquer objeto
baseado em tecnologia Java. Este nível é direcionado à toda a comunidade de
desenvolvedores que utiliza tecnologia Java.
O nível agente fornece os agentes de gerência. Os agentes JMX são
recipientes que contém a base dos serviços de gerência. Esta base pode ser
facilmente estendida adicionando-se recursos JMX. Este nível é direcionado para a
comunidade
de
desenvolvedores
de
soluções
de
gerência
e
fornece
o
gerenciamento através da tecnologia Java.
O nível gerente fornece os componentes de gerência que podem operar
como gerente ou agente para distribuição e consolidação dos serviços de gerência.
Este nível é direcionado para a comunidade de desenvolvedores de soluções de
gerência e complementa a gerência através da tecnologia Java provida pelo nível
agente. As APIs de protocolos de gerência adicionais são direcionadas para
comunidade de desenvolvedores de soluções de gerência e proporcionam a
integração com as soluções de gerência existentes.
5.3
Componentes JMX
5.3.1 Recurso Gerenciável
Um recurso gerenciável [JAV99] é um recurso que foi instrumentado
conforme o nível de especificação de instrumentação JMX e passou pelo conjunto
de testes de compatibilidade de nível de instrumentação. Um recurso pode ser uma
aplicação de negócio, um dispositivo, ou uma implementação de software de um
serviço ou política. Para ser instrumentado, um recurso pode ser escrito na
linguagem de programação Java ou somente oferecer uma capa de tecnologia
baseada em Java.
75
Nível
Aplicação
Gerente
Aplicação
WEB
Proprietária de
Proprietária de
Browser
Gerência
Gerência
APIs para
outros
Protocolos de
Gerência
Gerente
JMX
API para a
Gerência
Adaptador de Protocolo
SNMP
Nível
Agente
Mbean
API para a
Server
Gerência
CIM/WEBEM
Serviço
Níivel
Instrumentação
Objeto 1
Objeto 2
Máquina Virtual Java
Objeto 3
Máquina Virtual Java
API para a
Gerência
MBean ( Objeto Bean gerenciado registrado no servidor )
JavaBeans simples ( não registrado no servidor )
Figura 5.1 – Arquitetura JMX
TMN
76
Qualquer coisa que precisa ser gerenciada, de forma imediata ou no futuro
pode ser instrumentada e pode ser considerado como um recurso potencial.
Um Objeto Mbean é um objeto Java que representa um recurso JMX
gerenciável. Os objetos MBeans seguem o modelo JavaBeans e permitem o
mapeamento entre os componentes JavaBeans e o seu gerenciamento. Os objetos
Mbeans podem ser adaptados a qualquer agente JMX, pois permitem a
instrumentação de forma padrão dos recursos gerenciados.
5.3.3 Agente JMX
Um agente JMX é uma entidade de gerência implementada conforme
a
especificação de agente JMX e que passou pelo conjunto de testes de
compatibilidade de nível de agente. Um Agente JMX é composto de um servidor de
MBean, um Kit MBeans que representa os recursos gerenciados e por pelo menos
um adaptador de protocolo. Um Agente JMX pode conter serviços de gerência, que
são representados como MBeans.
O servidor de MBean corresponde a um registro para MBeans no agente. O
servidor de MBean é o componente que fornece os serviços que permitem a
manipulação de objetos MBeans. Todas as operações de gerência executadas no
MBeans são realizadas por interfaces baseadas em tecnologia Java no servidor de
MBean.
Os adaptadores de protocolos e conectores permitem que as aplicações de
gerência tenham acesso a um agente JMX e manipulem os seus objetos MBeans.
Os adaptadores de protocolo permitem a representação dos objetos MBeans de
forma direta sobre os protocolos HTML ou SNMP. Os conectores incluem um
componente remoto que permitem a comunicações com o agente sobre uma
variedade de protocolos, entre eles HTTP, HTTPS, IIOP. Como todos os conectores
possuem a mesma interface baseada em tecnologia Java, as aplicações de
77
gerência utilizam o conector mais apropriado ao ambiente de rede e mudam de
forma transparente os conectores quando necessário.
5.3.2 Gerente JMX
Um gerente JMX é uma entidade de gerência implementada conforme a
especificação de gerência JMX e que passou pelo conjunto de teste de
compatibilidade de nível de gerência. Um gerente JMX fornece uma interface para
que as aplicações de gerência possam interagir com o agente, distribuir ou
consolidar informação de gerência, e prover segurança. Os gerentes JMX podem
controlar qualquer número de agentes, simplificando a estrutura de gerência de
sistemas complexos e sistemas distribuídos.
5.3.3 Serviços de Gerência
Os Agentes e gerentes JMX integram serviços que lhes dão autonomia e
inteligência. Estes serviços permitem que os agentes manipulem os seus recursos e
transfiram informações entre os agentes e a aplicação de gerência. Os agentes são
mais autônomos porque podem incorporar certas tarefas de gerência como polling.
A inteligência é incorporada em lógicas simples que podem impedir que os
gerentes manipulem alarmes sem importância. Isto permite a redução do tráfego na
rede e melhoria da resistência das aplicações às paradas. Na arquitetura JMX os
serviços são objetos MBeans que podem ser adicionados ou removidos conforme a
necessidade. Isto dá escalabilidade aos agentes e gerentes, o que é crítico quando
estes são implementados em clientes magros.
A especificação JMX define atualmente a interface para tais serviços básicos
como um registro para MBeans, queries destes registros, operações sobre os
recursos e transmissão de eventos de volta aos gerentes, carga dinâmica de um
novo MBean, criação de relações e dependências entre MBeans, funções de tempo
e monitoração de atributos. Outros serviços de administração que serão integrados
78
na especificação incluem bootstrapping e persistência, gerência de políticas de
redes, descoberta de agentes e gerentes na rede e segurança.
5.3.4 APIs para outros Protocolos de Gerência
O objetivo das APIs para outros protocolos é fornecer uma forma padrão para
que a gerência de aplicações Java possa interagir com tecnologias de gerência
existentes. Desta forma a aplicação usará uma destas APIs para ter acesso a um
sistema legado e expor seus atributos como um recurso gerenciável JMX. Este
recurso permitirá qualquer aplicação de gerência padrão JMX administrar os
sistemas legados através de um agente JMX. Estas APIs criam uma ponte entre as
tecnologias existentes e as tecnologias futuras. A especificação JMX incluirá uma
API para um gerente SNMP, APIs para gerentes e provedores WBEM, Gerente
TMN, APIs para Alarmes e topologias.
5.4
CONCLUSÃO
Neste Capítulo foi descrita a iniciativa Java Management Extension, sua
arquitetura e componentes. A Java Management Extension (JMX) define uma
arquitetura de gerência, APIs e serviços de gerência, todos sobre uma única
especificação. Para isto a arquitetura de JMX é utiliza um modelo de três níveis,
instrumentação, agente e gerente.
No próximo capítulo será apresentada a iniciativa Web-based Enterprise
Management (WEBEM) [DMT99][HER99], para a construção de frameworks de
gerência corporativa via WEB.
79
6
WEB MANAGEMENT ENTERPRISE - WEBEM
6.1
Iniciativa WEBEM
Conforme detalhado em [DMT99][HER99] em meados do ano de 1996 um
grupo de grandes fornecedores interessados em gerência via WEB, entre eles a
BMC, CISCO, Compaq, Intel e Microsoft, anunciaram a iniciativa de definição de um
esquema de gerenciamento corporativo que trabalharia com a WEB e os
frameworks convencionais de gerência de redes e sistemas. Este framework é
conhecido como WEB-Based Enterprise Management WEBEM.
Conforme descrito em [HER99] um dos principais objetivos da iniciativa
WEBEM é a definição de uma modelo de dados padrão que possa ser utilizado
como repositório de dados de gerência. Permitindo que os frameworks de gerência
de redes e sistemas convencionais possam transformar os seus dados para este
formato padrão. O esquema de dados WEBEM permite também que os objetos de
sistemas legados ou proprietários sejam importados para o banco de dados de
objetos de gerência WEBEM, criando uma extensão destes esquemas. Este modelo
de dados é definido como Common Information Model (CIM). Com este modelo a
arquitetura WEBEM torna-se um ponto de integração dos diversos tipos de
frameworks existentes. Conforme apresentado na figura 6.1, todos os objetos de
dados WEBEM presentes no repositório podem ser acessadas através de
aplicações de gerência WEBEM. Estas aplicações podem ser executadas na
Internet usando como cliente um browser padrão.
O Segundo maior esforço da iniciativa WEBEM é a definição de um protocolo
que irá permitir que os objetos gerenciados WEBEM sejam acessados via rede. O
ideal é que este protocolo seja independente de plataforma e trabalhe sobre a
Internet. O protocolo proposto é o HyperMedia Management Protocol (HMMP),
contudo conforme descrito em [DMT99] existe um estudo que aponta para a
utilização da linguagem XML sobre HTTP.
80
O framework WEBEM é completamente orientado a objetos e permite a
herança
de
objetos
gerenciados,
abstração
de
dados,
polimorfismo
e
encapsulamento. O gerente de objetos é chamado CIM Object Manager (CIMOM).
Esta entidade de software é responsável pelo controle do objetos gerenciados,
incluindo o armazenamento e o acesso aos objetos no repositório central de dados.
WEBEM Server
Aplicação de Gerência WEBEM
Repositório de dados central
Gerente de Objetos
Dados SNMP
Dados CMIP
Dados DMI
Dados
Proprietários
Figura 6.1 – Modelo de fluxo de dados WEBEM
6.2
Arquitetura WEBEM
Conforme detalhado em [DMT99][HER99] o framework WEBEM é constituído
do Cliente WEBEM, pelo conjunto de dispositivos gerenciados, Servidor WEBEM e
pelo
repositório
central
de
dados
do
Servidor. Estes componentes são
representadas no modelo de referência WEBEM, apresentado na figura 6.2, onde
são apresentados os aspectos funcionais, dados, informações e adaptações
necessárias para a implementação do framework WEBEM.
81
Browser Cliente
WEBEM Server
Aplicação de
Gerência
WEBEM (1)
Aplicação de
Gerência
WEBEM (2)
Repositório de dados
CIMOM
Provedor (1)
Aplicação de
Gerência
WEBEM (n)
...
Provedor (2)
Provedor (n)
...
Agente
Agente
Agente
Objetos Gerenciados
Objetos Gerenciados
Objetos Gerenciados
Objetos Gerenciados
Objetos Gerenciados
Objetos Gerenciados
...
...
...
Dispositivo
Gerenciado (1)
Dispositivo
Gerenciado (2)
Figura 6.2 – Modelo de Referência WEBEM
Dispositivo
Gerenciado (n)
82
O Servidor WEBEM contém o gerenciador de objetos CIMOM, que pode
aceitar todos os objetos dos frameworks de gerência de sistemas e redes
existentes. Os dados de objetos são transformados em um formato padrão e
armazenados no repositório de dados central. O servidor WEBEM contém também o
servidor de aplicação WEBEM, que por sua vez pode ser acessado pelos clientes
WEBEM.
O browser cliente utiliza um conjunto de aplicações residentes no Servidor
WEBEM ou em um sistema distinto, acessando as aplicações de gerência através
do protocolo HMMP. Quando executadas as aplicações de gerência WEBEM
acessam o CIMOM, este por sua vez interpreta a requisição feita pela aplicação
para a informação solicitada sobre o objeto gerenciado. O CIMOM possui a sua
própria linguagem para definição de objetos gerenciados. Esta linguagem e
conhecida como Managed Object Format (MOF). A aplicação reconhece os objetos
presentes no repositório porque ela entende que a lista de objetos do esquema foi
instanciada. As informações dos objetos gerenciados são entregues ao CIMOM para
serem colocadas no repositório de dados pelos diversos provedores conectados.
Os provedores correspondem a um conjunto de processos que se comunicam
com os agentes de gerência de sistemas convencionais nos dispositivos
gerenciados, obtendo os valores dos objetos definidos. Os provedores são
responsáveis pela obtenção e apresentação dos dados de gerência dos protocolos
convencionais de gerência de sistemas e redes, que estão sendo trocados com o
agente do dispositivo gerenciado. Existem provedores que utilizam arquiteturas
padronizadas como SNMP, CMIP e DMI, estes provedores são denominados
Standard Providers. O framework WEBEM define os seguintes provedores:

Provedores de Propriedade, retornam os valores de propriedade de objetos
solicitados através de uma chave de identificação. Retorna informações em uma
única instância.

Provedores de Instância, retornam valores de instâncias de objetos. Retorna
informações da instância em uma única classe;
83

Provedores de Classe, retornam classes e instâncias. Controlam todas as
classes;

Provedores de Namespace, são capazes de gerenciar um espaço de nome
CIMOM definido. Controlam todos os espaços de nomes e instancias de objetos.
Os dispositivos gerenciados contém um agente composto por um conjunto
lógico de objetos gerenciados. Conforme detalhado em [HER99] estes objetos são
representados por classes, com seus atributos e métodos apropriados. Estas
classes são agrupadas de acordo com os domínios de gerência específicos que elas
pertencem. Incluindo representações de objetos para gerência de redes SNMP e
CMIP, e representação de objetos para gerência de sistemas DMI. Cada domínio de
gerência é enxergado como uma representação de objetos controlada pelo CIMOM
correspondente.
6.2
Componentes da Arquitetura WEBEM
6.2.1 CIM
O modelo geral de informação CIM (Common Information Management)
contém o modelo de descrição de dados para representação do ambiente
gerenciado. Conforme detalhado em [DMT99] o CIM foi projetado para receber
informações de agentes SNMP, CMIP, DMI entre outros. Permitindo que aplicações
corporativas de diferentes desenvolvedores que utilizam plataformas heterogêneas,
descrevam, criem e compartilhem todos os objetos de gerência. A intenção é criar
aplicações de gerência corporativa e ferramentas que possam monitorar e
controlar todas as redes sistemas e aplicações existentes nas empresas.
O CIM é composto pelo meta esquema (CIM Meta-Schema) e pelos
esquemas padrões (CIM Schemas). Existe ainda um arquivo texto padrão ASCII
chamado Managed Object File (MOF) que contém as definições dos esquemas
padrões (CIM Schemas) implementados.
6.2.1.1
CIM Meta-Schema
84
O meta esquema corresponde a definição formal do modelo. Define os
termos que serão utilizados para expressar o modelo. Incluindo a maneira
apropriada de usar estes termos e sua semântica. Os quatro principais elementos
de um modelo são esquemas, classes, propriedades e métodos. O modelo define
também dois tipos importantes de classes, as indicações e as associações e um tipo
de propriedade que é a referência.

Esquema, é definido como um conjunto de classes com um único
proprietário. São utilizados para a nomeação e administração de classes.
Dentro de um esquema os nomes de classes devem ser únicos;

Classe, é um conjunto de instâncias do mesmo tipo, com as mesmas
propriedades e métodos. A classe é a unidade básica de definição da
estrutura de gerenciamento. Uma classe pode ser vista como um
formulário para definição de objetos;

Propriedade, valor utilizado para caracterizar uma instância de uma
classe. A propriedade pode ser vista como um casal de funções get e set
que quando aplicadas no objeto retornam e definem estados deste objeto;

Método, define o tipo de conteúdo que pode ser aplicado sobre uma
classe ou instância. A definição de um método é uma assinatura, que
contém o nome do método, tipo de retorno e parâmetros;

Trigger, é o reconhecimento de algum evento, mudança de estado ou
alteração de alguma propriedade de um objeto;

Indicação, objetos criados como resultado de um trigger. As indicações
são tipos de classes, possuem propriedades e métodos e podem ser
organizadas em hierarquia de tipos;

Referência, são propriedades que uma classe ou instância possui.
O
valor é um ponteiro para um objeto;

Associação, é um tipo de classe que possui uma ou mais referências. São
utilizadas para criar relacionamentos entre objetos sem necessidade de
alterar as suas definições;

Qualificador, são utilizados para caracterizar classes, instâncias ou
métodos. Permite a extensão do esquema de forma limitada e controlada.
85
6.2.1.2
CIM Schemas
O esquema padrão corresponde a um conjunto padrão de classes com suas
propriedades e associações. Estas propriedades e associações fornecem a base
necessária para a organização da informação sobre todos os dispositivos
gerenciados numa organização que irá utilizar o padrão WEBEM. O esquema
padrão foi definido com o objetivo de promover a uniformidade dos procedimentos
de requisição sobre a rede de gerenciamento. O esquema padrão (CIM Schema) é
composto pelo Core Squema, Common Squema e Extension Squemas.
O Core Squema é constituído por um conjunto de objetos que são
referenciados por todas as áreas de gerência. O Core Squema é constituído das
sequintes classes:

Managed System Element, classe base para os elementos dos sistemas
gerenciados. Todos os componentes serão instanciados como uma
subclasse desta classe;

Physical
Element,
classe
correspondente
aos
elementos
físicos.
Exemplos: drivers de discos e adaptadores;

Logical Element, classe correspondente aos elementos que não são
físicos. Exemplos: Sistemas Operacionais e drivers de dispositivos;

System, classe correspondente a identificação do sistema, como PC, hub
ou router;

Network Component, corresponde a representação lógica do dispositivo
de rede física, como um ícone num mapa representando um servidor;

Service, classes que representam as capacidades e funcionalidades de
um elemento de sistema;

Physical Package, classes que representam o conteúdo físico de cada
dispositivo. Exemplos: um switch possui uma placa esta placa por sua vez
possui um processador e assim por diante.
86
Além das classes o Core Schema é constituído de várias associações
importantes:

Component, relaciona partes de objetos com grupos de objetos;

System Component, relacionam um sistema a seus elementos de sistema
gerenciados;

Dependency, relaciona as dependências existentes e dependências
funcionais;

Contains, relaciona a posição e localização de componentes físicos para
expressar relações de conteúdo;
6.2.1.3
CIM Extensions Schemas
As extensões de esquema (Extension Squemas) permitem o gerenciamento
de ambientes e plataformas específicas. Os exemplos incluem o desenvolvimento
de extensões de esquema para Sistemas Operacionais UNIX, Microsoft Windows,
Acordo de Níveis de Serviço, entre outros listados no site www.dmtf.org.
6.2.1.4
MOF
O arquivo texto padrão ASCII chamado Managed Object File (MOF), contém
as definições dos esquemas padrões (CIM Schemas) implementados. O MOF serve
de entrada para o compilador MOF de aplicações de gerência, que tem o objetivo de
criar as chamadas apropriadas para o CIMOM. O compilador MOF define as
classes, propriedades e qualificadores para serem incluídos no banco de dados
CIMOM, e também coloca as instâncias dessas classes neste mesmo banco de
dados.
A linguagem UML é utilizada nas especificações DMTF para descrever a
estrutura do esquema. A especificação CIM descreve a linguagem, convenção de
nomes e técnicas de mapeamento para outros modelos de dados de framework de
gerência. Incluindo as MIBs do protocolo SNMP, o Guidelines for Defining Managed
Objects (GDMO) do CMIP e a Management Information Format (MIF) do DMI. Como
todas as informações dos modelos são baseadas nos suas próprias definições de
87
esquema, um mapeamento precisa ser realizado para converter os dados de
gerência convencionais para o formato MOF.
6.2.2 CIMOM
O CIMOM, conforme descrito anteriormente é um gerenciador de objetos que
fornece vários mecanismos para que as aplicações de gerência possam trocar
dados com os objetos que estão sendo gerenciados. O CIMOM contem um modelo
de dados cuja tarefa é consolidar e traduzir os dados de gerência provenientes de
diferentes fontes como descrito na figura 2.6.
6.2.3 HMMP
O HiperMedia Management Protocol (HMMP) é o protocolo de comunicação
que transmite os objetos gerenciados CIM entre o servidor e o cliente. O HMMP
encapsula e transmite os objetos CIM sobre protocolos de transporte como o TCP
que é utilizado normalmente para comunicação Internet.
O protocolo HMMP especifica que cada operação é tratada separadamente.
Como exemplo, o suporte do CIMOM para criação, remoção, atualização e
requisição de classes e instâncias serão modelados cada um com sua própria
operação.
O protocolo HMMP é projetado para ser mapeado sobre diferentes protocolos
de transportes. O protocolo pode trabalhar orientado ou não a conexão. O protocolo
TCP é o protocolo de transporte recomendado, por ser o protocolo típico para
gerência via WEB e para comunicação na Internet.
6.2.3 XML
Conforme detalhado em [DMT99] um dos últimos estudos realizados pela
iniciativa WEBEM é a utilização da linguagem XML Extensible Mark-up Language,
como um método de representação das informações de gerência. No site WEBEM
88
um documento escrito por Roger Boot, propõem o mapeamento entre o modelo CIM
e construções XML. Isto poderá permitir qualquer objeto de gerência CIM ser
representado na forma de um ou mais documentos XML. O maior benefício disto é a
padronização da linguagem XML para a apresentação dos dados de gerência. Estes
dados poderiam desta forma ser apresentados e manipulados por aplicações de
gerência corporativa WEBEM.
6.3
CONCLUSÃO
Neste capítulo foi descrita a iniciativa Web-based Enterprise Management -
WEBEM [DMT99][HER99], sua arquitetura e componentes. A iniciativa WEBEM
define um esquema de gerenciamento corporativo com o objetivo de trabalhar com a
WEB e os frameworks convencionais de gerência de redes e sistemas existentes.
A iniciativa WEBEM define um modelo de dados padrão para ser utilizado como
repositório de dados comum de gerência. Permitindo que frameworks de gerência
de redes e sistemas convencionais possam transformar os seus dados para este
formato padrão.
No próximo capítulo será apresentado um estudo de caso da solução de
gerência corporativa Unicenter TNG. Neste capítulo esta solução é estudada sobre
a ótica de implementação de funcionalidades de gerência via WEB e validação dos
conceitos apresentados nos outros capítulos deste trabalho.
89
7
ESTUDO UNICENTER TNG
7.1
Introdução
A solução de gerência corporativa Unicenter TNG, da empresa Computer
Associates, é estudada neste capítulo sobre a ótica de implementação de
funcionalidades de gerência via WEB e validação dos conceitos apresentados nos
outros capítulos deste trabalho. Existem vários fabricantes de soluções de gerência
que já implementam a gerência via WEB em seus produtos. A solução da
Computer Associates foi escolhida pela sua disponibilidade, facilidade de instalação
e configuração de seu framework de gerência, distribuído gratuitamente para
diversas plataformas. Incluindo as plataformas Windows NT, plataformas UNIX de
diversos fabricantes, como HP-UX, SUN Solaris, IBM AIX e a plataforma Linux.
7.2
Arquitetura UNICENTER TNG
O framework Unicenter TNG [UNI00] é definido de forma a ser o centro do
gerenciamento corporativo. Nele são concentradas todas as disciplinas, permitindo
uma visão centralizada das diversas plataformas a serem gerenciadas e uma
integração entre as diversas disciplinas de gerência.
O gerenciamento de recursos não se limita a tecnologias específicas. Tendo
um amplo controle de todos os recursos corporativos, atuando em todos os tipos de
recursos: sistemas, redes, bancos de dados e aplicações. A integração de todos
estes recursos oferece uma visão unificada deste ambiente, através de um conjunto
de funções para gerenciamento desenvolvido com uma infra-estrutura flexível.
O maior desafio do gerenciamento corporativo é a integração de várias
ferramentas de diversas fontes. A Computer Associates criou o Framework
Unicenter TNG, permitindo a integração entre fabricantes de diversas plataformas e
aplicativos de gerência de terceiros. Este framework contém todos os serviços
distribuídos básicos necessários para o gerenciamento corporativo integrado.
90
O framework Unicenter TNG [UNI00] é disponibilizado com a infra-estrutura
necessária para o gerenciamento da maioria das plataformas existentes no
mercado. Entre elas a plataforma Windows NT, UNIX, Netware, AS/400, Tamdem
NSK e ainda os ambientes de Mainframe. O framework Unicenter TNG inclui as
seguintes funcionalidades básicas:

Enterprise Discovery, para a realização da descoberta ou discovery de
todos os objetos de rede e recursos existentes na rede corporativa.
Incluindo sistemas, estações redes, aplicações e bancos de dados;

Manager/Agent Event Management, para a monitoração completa de
status e logs de eventos, habilitando a resposta automatizadas para a
mudança do status de objetos;

Calendar Management, para a definição de data e sincronização
baseadas em tempo, para fornecer uma coordenação das mudanças que
afetam os processos de negócio;

Reporting, para a criação de relatórios padronizados e customizados;

Virus Detection, para detecção de vírus registrados e não registrados;

Common Object Repository; o repositório de objetos suporta todas as
funções de gerenciamento e a interface de mundo real (Real Word
Interface), Interface de Negócio (Business Process View) e os elementos
de interface de usuários incluindo as representações 2-D e 3-D;

Event Notification Faciliy (ENF) e a Common Communication Interface
(CCI), que reforçam a confiabilidade e escalabilidade do framework
fornecendo uma infra-estrutura de mensagens;

WEBEM Support, para habilitar os usuários corporativos a relacionarem
interfaces de gerência WEB a outros dados de gerência WEBEM de
diversas fontes, criando uma visão centralizada dos recursos dos
ambientes de tecnologia da empresa.

Entreprise/CSI (Configuration Standarization Initiative), para a gerência de
estações e servidores;

WakePC Technology, este sistema permite que técnicos executem tarefas
de manutenção remotamente;
91

DMI Support, permite que administradores possam identificar, visualizar e
gerenciar systemas, incluindo componentes de hardware e software e
dados estáticos e dinâmicos;

Real Word Interface, este serviço permite visualizar a topologia da rede e
todos os recursos de computação na rede corporativa, através de uma
interface real 2-D, 3-D e visualização via WEB.
Para suportar a escalabilidade e flexibilidade requerida pelo gerenciamento
em todos os níveis, o Unicenter TNG é baseado em uma arquitetura para
gerenciamento em múltiplos níveis gerente/agente. Os agentes do Unicenter TNG
são ativos e inteligentes, capazes de implementar políticas e coordenar juntamente
com outros agentes ativos as funções de monitoração de eventos e estados,
gerenciamento da configuração de ambientes distribuídos, entre outras.
Interface com o Mundo Real
(2-D, 3-D, WEB)
Repositório de Objetos
Gerente
Gerente
Gerente
Gerente
Agente
Agente
Agente
Agente
Figura 7.1 Arquitetura Unicenter TNG
...
...
92
A figura 7.1 descreve a arquitetura Unicenter TNG. A Arquitetura da solução
Unicenter TNG [UNI00] é definida pelas camadas de interface de mundo real,
repositório de objetos, gerentes e agentes.
7.2.1 Interface com o Mundo Real
A Interface de Mundo Real ou Real Word Interface [UNI00] utiliza visualização
em 3-D e animação para mostrar todos os recursos da rede, permitindo, assim, uma
forma intuitiva de navegação através dos sistemas e conexões da rede, iniciando
pelas cidades e prédios do mundo real. Esta Interface permite visualizar a topologia
da rede e todos os recursos de computação na rede corporativa, como
equipamentos, sistemas operacionais, aplicações, bancos de dados, entre outras.
Possui visualização em 2-D e 3-D de todos os recursos da rede Interface Windows
da Microsoft. Com a disponibilidade de um browser Java baseado nas tecnologias 2D ou VRML 3-D é possível, também, realizar o gerenciamento via WEB a partir de
qualquer ponto da rede.
O produto é configurável, permitindo aos clientes especificar mapas, edifícios
e controlar a configuração das redes e sistemas operacionais. Todos os recursos da
rede são representados como são no mundo real, e o funcionamento de cada
componente é sinalizado através de alertas coloridos verde, indicando uma situação
normal, amarelo indicando uma anormalidade ou vermelho indicando um problema
crítico.
7.2.2 Repositório de Objetos
As informações exibidas na console ou Wordview, estão armazenadas no
repositório de objetos (Common Object Repository) do Unicenter TNG [UNI00], onde
todas as funções de gerenciamento armazenam informações sobre os objetos
gerenciados, suas propriedades e relacionamentos. As aplicações, hardware,
software, bancos de dados e entidades como contas a pagar, contas a receber,
recursos humanos, entre outros, são exemplos de objetos gerenciados.
93
Os objetos gerenciados pelo Unicenter são formatados com base no modelo
padrão de objetos (Common Object Model), o que facilita a integração das diversas
aplicações e inclui recursos de pesquisa que permitem as funções de
gerenciamento encontrar e gerenciar objetos facilmente.
7.2.3 Visão de Negócios
A visão de negócios [UNI00] ou Business Process View , permite visualizar o
conjunto de objetos necessários a execução de aplicações críticas como servidores,
bancos de dados, terminais e impressoras. É uma visão totalmente configurável
dos processos de negócios da companhia para suas aplicações críticas.
A visão tradicional de administradores de sistemas, bancos de dados, redes, entre
outras, não permite enxergar todos os recursos necessários a execução de uma
aplicação. Cada administrador preocupa-se com uma instância específica:
A visão horizontal tradicional, não permite identificar processos de negócios
que se utilizam de diversos componentes existentes. Através de Business Process
views, o Unicenter TNG oferece uma nova visão de negócios, através da visão
vertical, ou seja, é possível visualizar somente as máquinas e ocorrências
envolvidas no processo de manufatura, nos aplicativos financeiros, e assim por
diante.
É possível saber por exemplo quais aplicativos ou negócios da empresa
serão afetados pela queda de um servidor, ou descobrir se um determinado servidor
é o gargalo de algum processo ou negócio. Um administrador de rede local poderia
visualizar somente o seu ambiente computacional e suas ocorrências, enquanto que
o administrador principal teria uma visão global do ambiente corporativo.
94
7.2.4 Auto Discovery
A criação e carga do repositório de objetos com os dados que descrevem a
rede corporativa é executada automaticamente pela função discovery que executa a
detecção automática da rede. As funções realizadas pelo discovery [UNI00]
automático incluem encontrar as entidades ou recursos e popular um repositório
com os objetos gerenciados; determinar os relacionamentos entres os recursos e
popular o repositório com representações destes relacionamentos.
A função de descobrimento e detecção não somente detecta a topologia e
dispositivos da rede, mas também os computadores e suas configurações de
hardware e software. Ela detecta também bancos de dados e aplicações.
Uma vez criado o repositório, estes objetos podem ser exibidos pela console ou
WorldView do Unicenter. As entidades que eles representam podem ser controladas
pelas aplicações de gerenciamento bem como por aplicações de terceiros. As
principais vantagens do serviço discovery do Unicenter são descritas abaixo.

Executar múltiplas instâncias de discovery simultaneamente;

É possível Iniciar o discovery automaticamente ou manualmente ;

É possível fazer um discovery de todas as entidades da rede ou somente de
uma sub-rede específica;

É possível especificar quais os recursos a serem detectados;
7.2.5 Gerentes e Agentes
O Unicenter TNG [UNI00] implementa o gerenciamento em múltiplos níveis
gerente/agente. Os gerentes podem estar localizados em qualquer lugar da rede e
os agentes residem próximo dos recursos gerenciados. Os agentes coletam,
identificam, filtram e enviam dados para os gerentes. Os gerentes analisam,
controlam e correlacionam os recursos gerenciados e as informações do ambiente,
analisando os padrões e tendências de forma a determinar a melhor forma de
controlar os recursos gerenciados. A estrutura gerente/agente é flexível e escalável.
95
Um gerente pode gerenciar múltiplos agentes e múltiplos gerentes podem gerenciar
um agente. Um gerente pode ainda atuar como um agente de outros gerentes. Esta
interação e cooperação entre gerente e agente permite a gerencia corporativa
distribuída.
7.2.6 Disciplinas de Gerência Corporativa
O framework Unicenter TNG [UNI00] serve de base para as diversas
disciplinas de gerência implementadas nas áreas de segurança, operações, redes,
Servidores e Estações, Groupware, Aplicações e Bancos de Dados, Help Desk,
Serviços Internet e Storage.
Para que estas as soluções de gerencia sejam
implementadas nestas áreas, agentes específicos são disponibilizados para cada
área e plataforma. Existem mais de 50 agentes desenvolvidos para cada área e
diversas plataformas. A documentação detalhada da implementação de cada
gerente específico pode ser acessada na página http://www.cai.com/unicenter/
prodinfo.htm.
7.2.7 Tecnologia de Redes Neurais
A tecnologia Neugents [UNI00] é composta por aplicações que utilizam a
tecnologia de redes neurais para prever falhas antes que elas ocorram. Os sistemas
convencionais de gerência de sistemas respondem somente a eventos baseados
em suposições anteriores. Os Neugents são capazes de se adaptarem, aprendendo
e observando a carga dos sistemas ao longo do tempo. A tecnologia Neugent lida
com performance e disponibilidade e foi introduzida na versão 2.2 do Unicenter
TNG.
7.2.8 Unicenter TNG SDK
O kit de desenvolvimento de software Unicenter TNG fornece conjuntos de
APIs documentadas que mapeam cada camada da arquitetura TNG. Estas APIs
96
correspondem a maneira para desenvolver aplicações de gerência integrando
soluções de clientes e terceiros.
7.3
Análise da Solução Unicenter TNG
7.3.1 A Solução Unicenter TNG e a Gerência Corporativa
A solução Unicenter TNG é apresentada pelo seu fornecedor como uma
solução de gerência corporativa, com o objetivo de integrar as diversas áreas de
gerência descritas no capítulo 2 e 3 deste trabalho. Incluindo as áreas de redes,
sistemas, aplicações e serviços.
A tecnologia de agentes permite a implementação da gerência das diversas
disciplinas nas áreas de segurança, operações, redes, Servidores e Estações,
Groupware, Aplicações e Bancos de Dados, Help Desk, Serviços Internet e
Storage. Incluindo agentes específicos disponibilizados para cada área e plataforma,
incluindo servidores Windows, UNIX e Mainframe entre outras.
7.3.2 A Solução Unicenter TNG e os Padrões de Mercado
A solução Unicenter TNG faz parte dos chamados sistemas convencionais de
gerência corporativa, descritos no capítulo 2 deste trabalho. E tem como base, a
aderência de seu framework aos padrões abertos, incluindo a o padrão SNMP para
a área de gerência de redes; o padrão DMI para a gerência de sistemas e o
padrão WEBEM para a gerência via WEB.
A pesar da solução da Computer Associates ser baseada em padrões
abertos, assim como outros fornecedores de sistemas convencionais, esta solução
não integra em seu framework as soluções de seus concorrentes. A gerência de
eventos transmitidos pelo produto Netview da IBM ou Open View por exemplo, não
pode ser integrada diretamente na console de eventos da solução Unicenter TNG.
97
A integração de produtos de terceiros é feita através do kit de
desenvolvimento de software SDK do Unicenter TNG. Este kit fornece conjuntos de
APIs documentadas que mapeam cada camada da arquitetura TNG. Estas APIs
correspondem a maneira encontrada para desenvolver aplicações de gerência
integrando soluções de clientes e terceiros.
7.3.3 A Solução Unicenter TNG e a Gerência Via WEB
A gerência via WEB foi implementada na versão 2.2 do Unicenter TNG como
uma interface alternativa para a gerência . Nesta versão foi disponibilizada o acesso
via WEB através das tecnologias de browsers Java 2-D ou VRML 3-D, estudas no
capitulo 4 deste trabalho. A disponibilização desta interface permite a gerência de
todos os recursos de qualquer ponto da rede corporativa via WEB.
O Unicenter TNG permite a visualização de informações via browser de forma
hierárquica ou em árvore. É possível visualizar a arvore das classes e instâncias;
objetos definidos para cada classe e a topologia de redes em formato de folders.
Através
da
ferramenta
Class
Wizard
disponível
nos
administradores podem criar ou modificar recursos gerenciados.
browsers,
os
As mudanças
realizadas via Class Wizard afetam as classes herdadas e seus objetos. A
ferramenta ObjectView fornece detalhes performance dos dispositivos de rede.
Através desta ferramenta são realizadas consultas SNMP para acessar em tempo
real as informações contidas nas MIBs dos dispositivos. As informações são
apresentadas através de painéis no monitor.
Conforme estudado anteriormente neste capítulo o framework Unicenter TNG
oferece suporte ao padrão WEBEM. Esta tecnologia foi estudada no capítulo 6
deste trabalho. Este suporte permite que usuários corporativos a relacionem
interfaces de gerência WEB a outros dados de gerência WEBEM de diversas fontes,
criando uma visão centralizada dos recursos dos ambientes de tecnologia da
empresa.
98
8
CONCLUSÕES
Com base nas informações apresentadas nos capítulos anteriores, é possível
concluir que a utilização de tecnologias WEB em sistemas de gerência
corporativa já é uma realidade presente [DMT99][IBM99][JAV99][UNI00][WEB99]
na maioria das soluções existentes no mercado.
Existe
uma
tendência
de
utilização
de
Tecnologias
WEB
para
a
implementação da gerência corporativa com objetivo de complementar as áreas
de gerência existentes. O que se pode constatar é que a utilização de tecnologias
WEB não significa simplesmente uma nova maneira de se apresentar informações
de gerência através de uma interface via browser [HERN99], e sim uma nova
plataforma de integração robusta, onde a redução de custos [WOL00] e a facilidade
de gerenciamento, seja via rede corporativa ou Internet, são fatores determinantes.
Conforme estudado anteriormente no capítulo 2, os sistemas convencionais
de gerência corporativa tiveram um grande amadurecimento ao longo dos últimos
10 anos, suportando diversos padrões existentes no mercado. Neste período foram
acrescidos diversos tipos de gerenciamento e novas funcionalidades. Incluindo a
integração com os diversos padrões abertos existentes e a adoção das tecnologias
WEB.
Entre os padrões estudados no capítulo 3,
estão o padrão SNMP
[MUR98][STA96], CMIP [LEI96] e TMN [HER99] para a área de gerência de redes;
o padrão DMI [HER99] para a área de gerência de sistemas e o padrão ARM
[HER99] para gerência de aplicações. Todos estes frameworks de gerência têm
estendido sua atuação sobre a gerência de redes de dados e telecomunicações. E
adicionalmente aos padrões utilizados vários outros consórcios e fóruns estão
desenvolvendo novos frameworks e APIs [DMT99][HER99][JAV99],
promovendo
desta forma o aumento da abrangência da gerência corporativa de redes e
sistemas. Entre estas iniciativas, estão as iniciativas de desenvolvimento e
padronização de frameworks baseados e tecnologia WEB, que propõem a
99
integração dos padrões existentes, principalmente na área de gerência de redes,
aos novos padrões que estão sendo definidos.
No capítulo 4 foi estudado o conceito de gerência via WEB e sua arquitetura
[HER99] composta pelos modelos de framework nativo, proxy e gateway. Foram
analisadas a evolução da Internet e da WEB e as tecnologias empregadas para a
implementação da gerência via WEB. Entre as tecnologias estudadas no capítulo 4,
estão o conjunto de protocolos de comunicação TCP/IP [MUR98][STA96]; os
browsers Internet [HER99],
servidor WEB [HER99];
as Markup Languages,
incluindo HTML, XML entre outras [HER99]; as linguagens de programação WEB
Java, C, C++ [HER99]; as linguagens script WEB JavaScript, ECMAScript, PERL,
TCL e Phyton [HER99]; os formatos gráficos GIF, JPEG [HER99] e NPG [PNG00];
os padrões MIME, CGI, ActiveX, VRML entre outros [HER99].
Nos capítulos 5 e 6 foram estudadas as duas principais iniciativas de projeto
de frameworks de gerência via WEB, a iniciativa Java Management Extension
(JMX) [JAV99] da Sun Microsystems e a Web-based Enterprise Management
(WEBEM) [DMT99][HER99]. A Java Management Extension (JMX) define uma
arquitetura de gerência,
APIs, e serviços de gerência, todos sobre uma única
especificação. A iniciativa WEBEM define um esquema de gerenciamento
corporativo com o objetivo de trabalhar com a WEB e os frameworks convencionais
de gerência de redes e sistemas.
Finalmente, no capítulo 7 foi realizado um estudo de caso da solução
Unicenter TNG [UNI00] da empresa Computer Associates. Neste capítulo esta
solução foi estudada sobre a ótica da implementação de funcionalidades de
gerência via WEB e a validação dos conceitos apresentados nos outros capítulos
deste trabalho. A partir deste estudo é possível concluir que, assim como outros
fabricantes de soluções de gerência, a empresa Computer Associates apresenta
uma forte inclinação para a utilização de gerência via WEB. Incluindo o suporte
para sistemas convencionais de gerência de redes e sistemas com base nos
padrões SNMP e DMI. Possui ainda, uma arquitetura orientada a objeto, incluindo
agentes inteligentes e repositório de objetos. E a grande inovação correspondente a
100
interface para mundo real (Real Word Interface) que permite a visualização em duas
ou três dimensões através de browsers baseados na tecnologia VRML [HER99]. O
acesso as informações de gerência pode ser realizado facilmente via ferramenta
browser, de qualquer lugar da rede corporativa ou através da Internet.
101
BIBLIOGRAFIA
[DMT99] Distributed Management Task Force: http://www.dmtf.org/wbem/index.html
. dezembro/1999
[HAR99] Harnedy, S. WEB-Based Management for de Enterprise.NewJersey :
Ed. Prentice Hall,1999
[IBM99] IBM Java Web-Based Network Management :
http://www.networking.ibm.com/cma/cmajava.html . dezembro/1999
[JAV99] Java Management Extension :
http://www.javasoft.com/products/JavaManagement/wp/ . dezembro/1999
[LEI96] Leiwand, A;Conroy, K.F. Network Management.New York : Ed. AddsonWeley,1996
[MUR98] Murray, J.d. Windows NT SNMP.California : Ed. O´Reilly,1998
[PNG00] Portable Network Graphics: http://www.w3.org/TR/REC-png.html .
fevereiro/2000
[STA96] Stallings, W. SNMP, SNMPv2, and RMON - Practical Network
Management,. Ed. Addison-Wesley, 1996
[THE99] The Simple Times: http://www.si’mple-times.org/pub/simple-times/issues/43.html . novembro/1999
[THE00] The Word Wilde Web Consortium: http://www.w3.org/ . janeiro/2000
[UNI00] Unicenter TNG Framework:
http://www.cai.com/products/unicent/framework/tng_framework.htm . janeiro/2000
102
[WEB99] Web-Based Network Management:
http://www.baynetworks.com/products/Papers/WEBbased.html . dezembro/1999
[WOL00] Wolcott k. Reducing Your Network Hardware Support Costs by Adding
Web-based Management : http://www.summitonline.com/techtrends/papers/rapid1.html . janeiro/2000