1
UNIVERSIDADE FEDERAL DE SANTA CATARINA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA
COMPUTAÇÃO
ROSELEINE CALGARO DE MELLO
UMA MIB DE APOIO À GERÊNCIA DO
RELACIONAMENTO COM O CLIENTE EM
COMÉRCIO ELETRÔNICO
Dissertação submetida à Universidade Federal de Santa Catarina como requisito final para a obtenção do grau de Mestre em Ciência da Computação
Profa. Dra. ELIZABETH SUELI SPECIALSKI
2
UMA MIB DE APOIO À GERÊNCIA DO RELACIONAMENTO
COM O CLIENTE EM COMÉRCIO ELETRÔNICO
ROSELEINE CALGARO DE MELLO
Esta dissertação foi julgada adequada para a obtenção do título de Mestre em Ciência da Computação Área de Concentração Sistemas de Computação e aprovada em sua forma final pelo Programa de Pós-Graduação em Ciência da Computação.
_______________________________________ Dr. Fernando A. O. Gauthier
Banca Examinadora
________________________________________ Profa. Dra. Elizabeth Sueli Specialski (orientadora)
________________________________________ Profa. Dra. Liane Margarida Rockenbach Tarouco
________________________________________ Prof. Dr. Alexandre Moraes Ramos
3
DEDICATÓRIA
4
AGRADECIMENTOS
Ao meu esposo Bobi pela compreensão nos meus momentos de mau humor e pela força quando o ânimo quase se esgotava.
À super professora Beth, além de orientadora de mestrado, orientadora de vida.
Aos professores Liane e Alexandre, pelas orientações e tempo dedicado. A todos os professores que me ensinaram e orientaram – desde a alfabetização até este momento.
Aos meus familiares, amigos e colegas que sempre incentivaram e passaram boas energias. Às pessoas que contribuíram para este trabalho das mais variadas formas – prestando seus serviços ou fazendo gentilezas.
5
RESUMO
Este trabalho trata do gerenciamento das atividades de sites de comércio eletrônico. Para isto é proposto uma MIB seguindo o Modelo de Gerenciamento Internet, para monitorar a interação dos clientes com uma loja virtual durante as atividades de consulta ou compra de produtos. O modelo proposto obtém o perfil dos clientes – identificando os produtos consultados, o período de acesso e as formas de pagamento -, as atividades realizadas no site e os problemas encontrados pelos clientes durante a interação. Os grupos e objetos definidos para esta MIB abrangem os segmentos de mercado com maior atividade na Internet. Estes grupos e objetos são escritos de acordo com os padrões da SMIv2 e depois compilados para a verificar a sintaxe e estrutura do módulo. Para a construção de uma MIB vários aspectos são considerados, e propõe-se uma metodologia para o desenvolvimento de MIBs que estabelece os passos necessários para a definição dos objetos e grupos e esclarece a sintaxe das macros e cláusulas definidas na SMIv2.
6
ABSTRACT
This work focuses on management of e-commerce sites’ activities. For this purpose is proposed a MIB according with the Internet Management Model to analyse the interaction between clients and an e-commerce site. The model proposed achieve the client’s profile – identifing which are the prefered products, when the client access the site and how he pay the products purchased, - the site’s activities during a search or a purchase and the problems faced by the clients on the site. The groups and objects defined for this MIB cover the main market segments. This groups and objects are written in conformity with the SMIv2 and after that compiled to check the module’s syntax and structure. To build a MIB some aspects must be considered, and this work suggests a methodology for MIB’s development which establish the main steps to define the groups and objects and clarify the macro’s and clause’s syntax from SMIv2.
7
LISTA DE FIGURAS
Fig. 2.1 Cálculo do frete e prazo de entrega...21
Fig. 2.2 Autenticação de cartão de Crédito ...22
Fig. 2.3 Modelo de Gerência Internet ...29
Fig. 2.4 Formato das PDUs SNMPv1 ...32
Fig. 2.5 Descrição do objeto sysDescr ...35
Fig. 2.6 Árvore de objetos da MIB-I...36
Fig. 2.7 Entidade SNMPv3...41
Fig. 3.1 Exemplo de cláusula IMPORTS...50
Fig. 3.2 Exemplo de registro do nível mais alto em uma MIB...51
Fig. 3.3 Resultado da compilação usando o MG-SOFT MIB Compiler ...53
Fig. 3.4 Posição da MIB e objetos na árvore hierárquica...53
Fig. 3.5 Exemplo da macro MODULE-IDENTITY ...55
Fig. 3.6 Exemplo da macro OBJECT-TYPE...60
Fig. 3.7 Exemplo da macro NOTIFICATION-TYPE...61
Fig. 3.8 Exemplo da macro TEXTUAL-CONVENTION...64
Fig. 3.9 Exemplo da macro MODULE-COMPLIANCE ...67
Fig. 3.10 Exemplo da macro OBJECT-GROUP ...68
Fig. 3.11 Exemplo da macro NOTIFICATION-GROUP ...70
Fig. 3.12 Exemplo da macro AGENT-CAPABILITIES...73
Fig. 4.1 Estrutura de objetos da ecommerceMIB. ...77
Fig. 4.2 Definição de atributos do objeto ecommClient...79
Fig. 4.3 Definição de atributos do objeto ecommProfClient ...80
Fig. 4.4 Relacionamento entre objeto ecommProduct e objeto de tipo de produto ...83
Fig. 4.5 Definição de atributos do objeto ecommProducts...83
Fig. 4.6 Definição de atributos do objeto ecommActivity ...85
Fig. 4.7 Definição de atributos do objeto ecommProblems...88
Fig. 4.8 Definição de atributos do objeto ecommBook...90
Fig. 4.10 Definição de atributos do objeto ecommElectrical ...91
Fig. 4.11 Definição de atributos do objeto ecommCD...92
Fig. 4.12 Definição de atributos do objeto ecommDVD...93
Fig. 4.13 Definição de atributos do objeto ecommSoftware ...95
SUMÁRIO
1 - INTRODUÇÃO E MOTIVAÇÃO ... 9
2 – FUNDAMENTAÇÃO... 14
2.1 FUNDAMENTOS DE COMÉRCIO ELETRÔNICO... 14
2.1.1 TIPOS DE COMÉRCIO ELETRÔNICO ... 15
2.1.2 – MODALIDADES DE COMÉRCIO ELETRÔNICO... 16
2.1.3 – NEGÓCIOS ORIENTADOS A CONSUMIDORES – B2C ... 17
2.1.4 – CRM EM APLICAÇÕES DE COMÉRCIO ELETRÔNICO... 23
2.1.5 – INFRAESTRUTURA NECESSÁRIA PARA O SERVIÇO DE COMÉRCIO ELETRÔNICO... 24
2.2 - FUNDAMENTOS DE GERENCIAMENTO DE SISTEMAS ... 25
2.2.1 - MODELO DE GERENCIAMENTO INTERNET... 27
3. CONSTRUINDO UMA MIB SNMP ... 45
3.1 – CONHECER O SISTEMA A SER GERENCIADO... 45
3.2 – MODELAGEM DOS OBJETOS DA MIB... 47
3.3 – ORGANIZAÇÃO DA ESTRUTURA DE IDENTIFICADORES DE OBJETOS ... 48
3.4 – DEFINIR O LAYOUT E A NOMEAÇÃO DOS MÓDULOS... 48
3.5 – VERIFICAÇÃO DA CONFORMIDADE DA MIB ... 52
3.6 – ESTRUTURA DE INFORMAÇÕES DE GERENCIAMENTO – SMI ... 54
3.6.1 RFC 2578 – SMIv2... 54
3.6.2. RFC 2579 – Convenção Textual para SMIv2 ... 62
3.6.1 RFC 2580 – Declarações de Conformidade para SMIv2... 64
4 - MODELO PROPOSTO PARA GERENCIAMENTO DAS ATIVIDADES DE USUÁRIOS DE COMÉRCIO ELETRÔNICO... 74
4.1 - DETALHAMENTO DOS OBJETOS DA MIB ... 78
4.2 – CONFERÊNCIA DA MIB (Verificação de Conformidade)... 97
4.3 - CONSIDERAÇÕES SOBRE O MODELO PROPOSTO ... 97
4.4 - CONSIDERAÇÕES SOBRE A IMPLEMENTAÇÃO DA MIB ... 98
5 - CONCLUSÃO... 100
5.1 - TRABALHOS FUTUROS... 100
ANEXO 1 – ECOMMERCE-MIB ... 102
GLOSSÁRIO E ABREVIAÇÕES... 129
9
1 - INTRODUÇÃO E MOTIVAÇÃO
Desde que foi liberada para uso comercial, a Internet foi usada como meio para a comercialização de produtos, inicialmente apenas para produtos de tecnologia como softwares e manuais, porém à medida que usuários de outras áreas passaram a integrar o time dos internautas, produtos de outros segmentos começaram a ser oferecidos para aquisição através de lojas virtuais. Atualmente, é possível encontrar produtos de diferentes áreas e valores - desde livros, CDs, equipamentos de informática a automóveis.
Para possibilitar o funcionamento de um site de comércio eletrônico é necessária uma estrutura de hardware e software - link de comunicação com a Internet, servidores de aplicação e Web, ferramentas de controle de acesso, além da estrutura comercial – produtos e fornecedores, sistemas de crédito e financiamento. A estrutura de hardware e software possibilita disponibilizar a loja virtual para o acesso dos usuários, controlar as operações efetuadas e fazer a troca de informações entre as empresas e instituições envolvidas nas transações comerciais.
O formato dos dados utilizados nas transações de comércio eletrônico, teve como modelo inicial a padronização utilizada pelo EDI (Electronic Data Interchange) que é o padrão utilizado para transferências de dados comerciais há mais de 20 anos. Esta padronização é definida pelo ASC (Accredited Standards Commitee) X12, que também define os padrões para utilização do XML (eXtensible Markup Language) - uma linguagem para a Internet voltada para transferência de dados. Ao contrário do HTML que foi criado para exibir textos e imagens em páginas WEB, o XML permite a troca de dados estruturados na Internet. O ebXML – XML para negócios eletrônicos - está sendo formatado pelo ASC X12 como uma
10
estrutura para mensagens de negócios no formato XML. O modelo ASC X12 é considerado atualmente o principal padrão para transações de comércio eletrônico (ASC X12, 2002). A proposta do grupo ASC X12 trata da padronização das informações trocadas em transações comerciais, considerando principalmente os aspectos de segurança e portabilidade, porém não trata da padronização dos dados usados nas aplicações de comércio eletrônico. Nas instituições de padronização pesquisadas (ANSI, NSSN, ASC, NIST, IPB Brasil, Comitê Executivo de Comércio Eletrônico) não foram encontradas normas de padronização sobre as informações relevantes dos produtos comercializados. Por exemplo, se a loja virtual oferecer livros, quais as informações sobre os livros que devem ser armazenadas: (título, autor, editora, nr-edição, ISBN, categoria, especialidade, nr-páginas, encadernação e preço). Considerando esta situação, foram identificados como dados relevantes para armazenamento, as informações disponíveis sobre os produtos nos sites das lojas virtuais usadas como modelo. e identificadas no final deste capítulo.
Ao se efetuar um compra em uma loja virtual, observa-se que o processo apresenta algumas diferenças em relação ao sistema de compra tradicional (balcão). Neste último, existe um atendente que pode medir o grau de satisfação do cliente e identificar problemas na realização da compra. Em substituição ao atendente, é necessário criar mecanismos para monitorar as atividades do cliente durante a interação com a loja virtual, objetivando identificar as preferências e as eventuais dificuldades do cliente.
Atualmente existem aplicações desenvolvidas para o gerenciamento das atividades realizadas na Internet. O objetivo principal destas aplicações é a monitoração dos eventos para obter informações sobre o perfil do cliente e o desempenho do site. Existem algumas ferramentas de gerenciamento direcionadas para a monitoração de usuários de comércio eletrônico, como o e-Discovery produzido pela SAS e o WebTrends Intelligence Suite produzido pela NetIq,
11
porém estas aplicações são proprietárias, ou seja, o formato dos dados e a forma como as informações são coletadas não é de domínio público.
De uma maneira geral, para que possamos monitorar e controlar um recurso, precisamos identificar o que deve ser monitorado, viabilizar que estas informações sejam de alguma forma coletadas e definir as decisões em cada situação apresentada. No modelo de gerenciamento SNMP, o conjunto das informações que devem ser monitoradas compõe a MIB. No site do IETF - instituto responsável pela edição de RFCs (www.rfc-editor.org), podem ser encontradas diversas MIBs, algumas com mais de dez anos. No entanto, somente nos últimos 4 anos começaram a ser propostas MIBs para aplicações, como a RFC 2789 – Mail Monitoring MIB, desenvolvida para o gerenciamento de emails. Uma pesquisa bibliográfica nas RFC´s disponíveis sobre o assunto comércio eletrônico, apresentou como resultado apenas a RFC 3106 – ECML v1.1: Field Specifications for E-Commerce – que especifica a ECML – Eletronic Commerce Modeling Language, linguagem usada para tratar os campos de formulários de e-commerce. Esta situação, abre espaço para a proposta de uma MIB para gerenciamento das atividades de usuários de comércio eletrônico.
O ideal para o gerenciamento de um ambiente de comércio eletrônico é que a aplicação de gerenciamento das atividades do site interaja com as demais aplicações de gerenciamento, ou seja, que exista uma aplicação capaz de gerenciar a infra-estrutura e serviços - como servidores e links de comunicação - bem como as atividades realizadas no site de comércio eletrônico. De acordo com a DMTF (2002), as aplicações de gerenciamento existentes são separadas por áreas de atuação de gerenciamento: um padrão para dispositivos de redes de computadores (SNMP), um para desktops – hardware de computadores e servidores (DMI), um para telecomunicações (CMIP) e para os sistemas de aplicação são utilizadas aplicações proprietárias, que não seguem uma padronização. A DTMF propõe o framework WBEM, um modelo baseado em XML para ligação entre todos os padrões de ferramentas de
12
gerenciamento, independente do ambiente gerenciado. Porém, este modelo não define um padrão para gerenciamento de aplicações, apenas sugere um modelo de transferência entre as ferramentas de gerenciamento.
É importante que as informações disponibilizadas por este suposto sistema de gerenciamento de loja virtual integrado, possibilite a tomada de decisões tanto no nível estrutural quanto no nível de negócio. A problemática de tomada de decisão no nível estrutural encontra-se bem encaminhada, pois este foi o objetivo inicial dos sistemas de gerenciamento, e atualmente existem várias aplicações nesta área. Já no nível de negócio, ainda há muito a ser desenvolvido, principalmente quanto ao gerenciamento do relacionamento com os clientes – foco do CRM.
Neste trabalho propõe-se a definição de uma MIB para o gerenciamento das atividades dos clientes de um site de comércio eletrônico, seguindo as normas de gerenciamento do modelo Internet. É importante salientar que os sites de comércio eletrônico podem atender aos mais variados segmentos de mercado, e como conseqüência, disponibilizar diferentes produtos, condições de pagamento, entrega e suporte pós-venda, etc. Esta variada área de atuação dificulta a criação de um modelo que atenda a todos segmentos.
Considerando esta situação, para definição da área de atuação do modelo proposto, levou-se em consideração os tipos de produtos mais encontrados nos sites de comércio eletrônico. Foram consultados os seguintes endereços de lojas virtuais: www.wallmart.com, www.activeplaza.com, www.websquare.com, www.i-stores.com, www.msnbc.com, www.coolshopping.com, shopping.libero.it, www.amazon.com, www.lycos.com, www.submarino.com.br, www.americanas.com.br, shoptime.com, shopping.uol.com.br, igshopping.ig.com.br, www.terra.com.br/compras.
A definição de uma MIB para gerenciar as atividades de usuários de comércio eletrônico, tem como objetivo principal estabelecer os objetos necessários para conhecer o cliente e o
13
relacionamento que ele mantém com a loja virtual. Isto é, usar a comunicação existente para realizar a compra, também para coletar dados de CRM, realizando processos de e-CRM. Para este fim, são necessárias informações para identificação de cada cliente, quais os produtos preferenciais, quando costuma fazer as compras, quais os meios de pagamento utilizados. Conhecer o perfil do cliente possibilita aprimorar o atendimento e atingir a excelência do ponto de vista do cliente.
Um segundo objetivo do sistema de gerenciamento proposto, é a monitoração do desempenho da loja virtual sob o ponto de vista comercial. Neste caso, são necessárias informações que indiquem se os produtos ofertados atendem as expectativas, se o prazo de entrega e as formas de pagamento estão de acordo com as necessidades e também monitorar eventuais problemas no processo.
Este trabalho é estruturado na seguinte ordem: no capítulo 2, apresenta-se a fundamentação para o comércio eletrônico considerando o foco do relacionamento com o cliente e o gerenciamento de sistemas, os procedimentos e a estruturação usada para a criação de uma MIB SNMP compõem o capítulo 3, o modelo proposto a ser gerenciado juntamente com a descrição dos objetos da MIB é apresentado no capítulo 4. O capítulo 5 apresenta as considerações finais e conclusões, e o anexo 1 contém a MIB resultante.
14
2 – FUNDAMENTAÇÃO
2.1 FUNDAMENTOS DE COMÉRCIO ELETRÔNICO
O comércio eletrônico é o serviço utilizado para realizar negócios sobre a estrutura da Internet. O modelo básico é formado por um estabelecimento que vende e usuários que compram produtos ou serviços acessam através da internet. O comércio eletrônico é muito mais abrangente que apenas a compra e venda, é a interconectividade entre os vários componentes que participam do processo de compra e venda - marketing, suprimento de materiais, atendimento, venda, pagamento, entrega e suporte pós-venda.
Estes componentes podem incluir processos de marketing interativo, pedidos e pagamentos na Internet, acesso via extranet a informações pelos clientes e fornecedores, acesso por intranet a cadastros de clientes por representantes de vendas e atendimento ao consumidor. “O maior benefício deste serviço é a integração da cadeia de produção e criação de novos recursos que explorem a Internet”. (MEIRA JUNIOR, 2002).
A estrutura do serviço de comércio eletrônico é composta por equipamentos de hardware e software , através dos quais é realizados o processamento, a negociação e a comercialização. Basicamente é a mesma estrutura de controle do comércio real, acrescentando componentes de segurança, de disponibilização na internet e de entrega.
15
2.1.1 TIPOS DE COMÉRCIO ELETRÔNICO
As categorias básicas de aplicações de comércio eletrônico: são o e-commerce, que possibilita o uso da Internet para a interação direta entre vendedor e usuário final e o e-business que mantém as condições de comprador e vendedor, mas inclui também os demais participantes do negócio, ou seja é o relacionamento entre todos os componentes para a disponibilização do produto ao usuário final.
Comércio Empresa-Consumidor (E-commerce)
É o comércio entre lojas virtuais e consumidores - conhecido também como B2C (Business to Consumer). Nesta forma de comércio as empresas precisam desenvolver locais (sites) de mercado eletrônico atraentes para seduzir e vender produtos e serviços aos consumidores. Como todos os sites estão nas mesmas condições no que diz respeito à localização do consumidor, outros fatores devem ser aprimorados para fazer com que os clientes voltem à loja, tais como o desempenho, a eficiência do atendimento, aparência e impressão causada pelo site e segurança.
Comércio Empresa-a-Empresa (E-business)
Envolve mercados comerciais eletrônicos e ligações diretas de mercados entre as empresas – conhecido também como B2B (Business to Business). É o lado atacadista do processo comercial, por exemplo, se considerar-se que uma empresa deseja montar e vender um produto para outras empresas, para isto ela precisa comprar matérias-primas e serviços de outras empresas.
De acordo com (ALBERTIN 2000), as empresas acreditam que as transações de negócio-a-negócio (e-business) representam um número menor de transações, porém com valores maiores. Assim elas têm dedicado grandes
16 esforços prioritariamente no ambiente negócio-a-negócio, sem deixar de investir, no entanto, no ambiente de negócio-a-consumidor.
2.1.2 – MODALIDADES DE COMÉRCIO ELETRÔNICO
Pode-se considerar quatro modalidades de comércio eletrônico possíveis: aquisição de produtos reais, aquisição de produtos virtuais, prestação de serviços reais e prestação de serviços virtuais.
Aquisição de produtos reais
Um exemplo típico de aquisição de produtos reais é a venda de livros pela Internet. Esta situação diferencia-se do processo tradicional pelo menos em dois aspectos: a forma de interação e a integração com os recursos físicos, ou seja, o acesso é através da WWW e a entrega do produto é pelo correio ou transportadora. O que requer que a integração entre o processo de comercialização e logística seja perfeita.
Aquisição de produtos virtuais
Através dos atuais recursos tecnológicos, a comercialização de produtos virtuais tornou-se uma realidade, como no caso de informações jornalísticas. Esta modalidade requer ainda o desenvolvimento de novas tecnologias para o acompanhamento de transações envolvendo produtos virtuais.
Prestação de serviços reais
Como exemplo de prestação de serviços reais pode-se considerar a locação de fitas de vídeo através da Internet. Neste caso as restrições logísticas devem ser cuidadosamente avaliadas.
17
Prestação de serviços virtuais
A prestação de serviços virtuais é uma aplicação inovadora e o grande desafio é a manutenção e verificação da qualidade dos serviços prestados e o planejamento de capacidade. Neste caso, o fornecimento de vídeos sob demanda é serve como exemplo.
2.1.3 – NEGÓCIOS ORIENTADOS A CONSUMIDORES – B2C
Devido à expansão da estrutura da Internet e da visão dela como “marketplace”, - um espaço para realizar negócios -, as empresas já existentes no mundo físico, foram levadas a ter seu espaço também no mundo virtual, para manter seus clientes e principalmente expandir sua área de atuação. Outras empresas surgiram voltadas exclusivamente para o mercado virtual, criando estruturas e procedimentos exclusivos do mercado virtual.
O comércio eletrônico na Internet entre empresas e consumidores está acelerando o impacto da tecnologia da informação sobre o comportamento do consumidor, os processos empresariais e mercados. A tecnologia está transformando as opções do consumidor que, por sua vez transformam a dinâmica do mercado e das próprias organizações. Ela permite maior personalização no atendimento ao cliente através da adaptabilidade, a possibilidade de programação e flexibilidade. Em conjunto, elas têm criado a promessa de “qualquer coisa, de qualquer forma, a qualquer hora” (O’BRIEN, 2001).
Um aspecto de grande importância do comércio eletrônico é a redução e em alguns casos a eliminação de intermediários e a aproximação de clientes e vendedores, criando um comércio próximo da perfeição, com muita informação a um baixo custo de transação.
Toma-se como exemplo a necessidade de uma tomada de preços de determinado produto (eletrodomésticos, livros, vestuário, material de escritório, automóveis...), com muita facilidade e rapidez obtém-se preços e características do produto nos principais fornecedores. Esta agilidade atrai cada vez mais clientes, embora alguns ainda sintam-se inseguros para a
18
aquisição do produto pela Internet e usam-na apenas como meio de consulta, a maioria usa o serviço de e-commerce completo – da consulta à aquisição. De acordo com Albertin (2000) os consumidores online estão mais interessados em realizar compras com melhor informação e mais rapidamente do que necessariamente obter melhor preço.
Entre os serviços de comércio eletrônico, existe maior quantidade de sites de B2C para aquisição de produtos reais do que produtos virtuais, esta situação existe em decorrência da menor oferta de produtos virtuais, afinal esta é uma categoria nova de produtos.
Em um ambiente de comércio eletrônico de produtos reais ao consumidor, deve-se levar em consideração que a disputa por clientes torna-se mais acirrada, pois os clientes têm a seu favor a facilidade de acesso a outros fornecedores, pois a distância do cliente à loja não é mais problema. Desta forma os sites de B2C devem disponibilizar recursos que atraiam clientes e procedimentos que propiciem a sua fidelização.
Para que este serviço tenha um bom desempenho e boa aceitação entre os consumidores deve-se considerar as etapas do processo de comercialização:
Identificação da Necessidade: A primeira etapa é a identificação pelo consumidor da necessidade da aquisição de um produto. Esta demanda pode ser espontânea ou induzida por iniciativas de propaganda e marketing
Localização de Fornecedores: Uma vez que a demanda tenha sido caracterizada, o cliente deve determinar onde o produto desejado pode ser obtido.
Escolha do produto: Os clientes verificam junto aos fornecedores as opções do produto desejado, obtendo informações detalhadas sobre o mesmo, de forma a subsidiar sua opção de compra.
Negociação: A negociação consiste em determinar os termos de aquisição do produto escolhido, desde características do mesmo (por exemplo, a cor de um carro) até as formas de pagamento e entrega.
Compra: Quando o produto a ser adquirido e as condições de aquisição estão definidos, o cliente efetua a compra do produto, indicando os meios de pagamento. A etapa termina com a verificação do crédito do cliente junto a entidades financeiras (se for o caso), ou com o pagamento em espécie feito diretamente pelo cliente.
Entrega: Uma vez que a aquisição tenha sido confirmada, o cliente recebe o produto.
Suporte pós-venda: Após o consumidor receber o produto, vários tipos de questões podem surgir no contexto do suporte pós-venda como, por exemplo, dúvidas sobre o produto em si, sobre a possibilidade de troca do produto ou reparos de defeitos cobertos pela garantia. (MEIRA JUNIOR, 2002).
19
Os serviços de comércio eletrônico podem atuar em uma ou mais das etapas descritas, de acordo com o tipo de produto e a disponibilidade de recursos da loja virtual. As etapas de entrega e suporte pós-venda são mais complexas, pois envolvem a integração com processos de logística e assistência ao consumidor.
2.1.3.1 - DETALHES DO PROCESSO DE COMERCIALIZAÇÃO
Identificação da necessidade de aquisição do produto
O fortalecimento da identificação da necessidade de aquisição do produto normalmente é realizado pelo departamento de marketing da loja virtual e pode ser traduzido em procedimentos como:
Envio de mensagens por e-mail com os produtos da área de interesse para clientes já cadastrados;
Exibição de banners da loja e produtos em sites de grande visitação, como sites de busca e notícias;
Usar a loja virtual como vitrine para mostrar os produtos e as promoções;
Apresentar um formulário para preenchimento dos dados para todos os clientes que visitam a loja, para permitir o mapeamento dos usuários do site e possíveis clientes. Para incentivar o preenchimento dos dados, pode-se adotar medidas promocionais - como descontos na primeira compra.
20
Alguns procedimentos usados para que o cliente identifique a necessidade do produto são usados também para localizar a loja. Por exemplo, o envio de mensagens promocionais por e-mail e a exibição de banners - nestes veículos consta o endereço da loja. O endereço da loja deve estar presente também em sites de busca, pois estes são usados para consultas em geral, inclusive para a aquisição de produtos.
Escolha do produto
As opções para a escolha do produto devem ser bem elaboradas para facilitar o acesso do cliente ao produto desejado e à especificação detalhada do produto. Para tal finalidade, as opções de busca por produto devem atender as suas características principais, como: nome comercial, função e fabricante. Além de permitir a busca através de suas características, os produtos devem também estar disponíveis à consulta agrupados de acordo com a sua funcionalidade ou categoria. Esta consideração deve ser feita baseado nos produtos oferecidos pela loja, se oferecer apenas determinado tipo de produto, os produtos devem estar agrupados por categoria, mas se oferecer diversos tipos de produto, eles devem estar agrupados por função.
Negociação
A listagem dos produtos encontrados deve ser clara e objetiva, exibindo as características principais ou o modelo padrão, a disponibilidade e o preço. Para melhor subsidiar a decisão de compra, deve existir uma opção para maiores detalhes como: itens opcionais do produto, cor, prazo de entrega, formas de pagamento, garantia do fabricante.
Quando o cliente pesquisa determinado produto, é realizada uma consulta aos produtos cadastrados e ao estoque da empresa, caso o produto não esteja disponível no estoque, deve ser informado ao cliente o prazo de entrega para local padrão, considerando que a loja fará a aquisição junto ao fornecedor e depois encaminhará ao cliente.
21
Quando o cliente seleciona o produto para compra, deve informar a quantidade, e o local para entrega (para o cálculo do frete ou disponibilidade da revenda mais próxima).
Depois, em caso de primeira compra, os dados do cliente são solicitados para efetivação do cadastro, ou se o cliente já estiver cadastrado, é solicitada uma identificação do cliente. A listagem do(s) produto(s) selecionado(s), com o valor do frete, valor total e prazo de entrega são apresentadas - conforme figura 2.1.
Fig. 2.1 Cálculo do frete e prazo de entrega
Compra
Depois de selecionar o produto, devem ser escolhidos a forma de pagamento (a vista ou financiado) e o meio de pagamento (cartão de crédito, boleto bancário, transferência eletrônica ou em dinheiro na entrega).
Para o pagamento através de financiamento, existe um período para a aprovação do cadastro do comprador, de acordo com o valor do produto a ser adquirido este período pode levar alguns minutos ou dias e a compra será efetivada somente após esta aprovação.
Em caso de cartão de crédito os dados do cartão são passados para a administradora para a autorização - conforme a figura 2.2, posteriormente a administradora repassará o valor para a
22
loja e quando o cliente efetuar o pagamento da fatura do cartão de crédito, este valor será creditado para o banco. Em caso de transferência eletrônica é feita uma conexão com o banco virtual, os procedimentos de transferência entre contas são específicos de cada instituição financeira e não são detalhados neste trabalho. Somente após a confirmação da transferência ou a autorização do cartão de crédito dá-se a efetivação da compra.
Fig. 2.2 Autenticação de cartão de Crédito
Entrega
Quando a compra é efetivada, o depto de vendas informa ao estoque a baixa de determinado(s) produto(s) e a(s) respectiva(s) quantidade(s). Esta informação e o local de entrega é repassado para o depto de logística que de acordo com o produto, o enviará através de correio ou transportadora ou ainda enviará a ordem de venda e entrega para a revenda mais próxima do local de entrega.
Após a compra, o cliente pode monitorar o andamento da entrega do produto através do número do pedido e a loja deve informar através de mensagens por email a data de despacho da encomenda, em caso de entrega aérea, informar periodicamente onde ela se encontra, e qual a data prevista para entrega ou quando ele estará disponível na revenda mais próxima.
23
Suporte Pós-Venda
Para os produtos que necessitam de montagem ou ajustes após a entrega, a loja virtual se responsabiliza pelo atendimento gratuito em determinada área de atuação, fora desta área, o cliente deve arcar com as despesas de deslocamento de pessoal. Para estes produtos, a informação da área de abrangência do suporte pós-venda deve ser clara e estar explícita no site.
Quando o produto apresentar defeito de fabricação, estragos no envio ou produto errado, a loja deve responsabilizar-se pela troca por determinado período de tempo.
A política de pós-venda e os procedimentos de atendimento ao cliente devem estar presentes no site da loja virtual de maneira clara e objetiva.
2.1.4 – CRM EM APLICAÇÕES DE COMÉRCIO ELETRÔNICO
O CRM (Gerenciamento do Relacionamento com os clientes) trata do relacionamento entre empresas e seus clientes. Este não é um conceito novo, muitas empresas conhecedoras da importância do bom atendimento e satisfação do cliente, vem há algum tempo aprimorando as relações com seus clientes. O fator inovador neste processo e que está despertando maior interesse é a disponibilidade de novas ferramentas que facilitam esta relação.
A implantação de uma política de CRM envolve todos os departamentos da empresa, pois não se trata apenas de uma ferramenta a ser implantada, mas de uma mudança de postura, o foco da empresa deixa de ser o produto e passa a ser o cliente.
Conforme Wilson José Oliveira (2000), Em muitas empresas, o próprio conceito de avaliações funcionais está diretamente relacionada com a rentabilidade do produto e não com o cliente. Não se fala em relacionamento com clientes nas áreas de vendas. E a produção então não tem a menor idéia de quem são os clientes da empresa. Porém, um processo CRM só será bem sucedido se a empresa quiser realmente aprender mais sobre seus clientes e investir tempo, esforço e dinheiro para esta mudança de postura.
24
No processo de comércio eletrônico, a interação do cliente com a empresa dá-se através de meio eletrônico, diferente do processo tradicional de compra, onde um atendente age como interface da empresa junto ao cliente. Esta situação facilita a obtenção das características do cliente, pois a aplicação que atende o serviço de comércio eletrônico pode atuar também como ferramenta de coleta das informações do cliente.
Para tratar cada cliente de maneira adequada às suas expectativas é necessário identificar as características de cada um. As ferramentas de Tecnologia da Informação são apropriadas para a obtenção dos dados que compõem o perfil de cada cliente, seja através de sistemas de Call Center ou para os clientes de e-commerce, através da monitoração da interação do cliente com o site eletrônico da empresa.
Os sistemas de comércio eletrônico podem usar a conexão existente durante a consulta e compra de produtos para obter o perfil de cada cliente. Estes dados podem ser obtidos através da monitoração dos eventos realizados durante o acesso à loja virtual. Este processo é conhecido como E-CRM – Gerenciamento do relacionamento de clientes eletrônicos.
De posse do perfil dos clientes, a aplicação de comércio eletrônico pode oferecer atendimento personalizado ao cliente, tais como: oferecer promoções adequadas ao padrão de consumo, enviar emails sugerindo produtos sempre que o cliente passar um determinado período de tempo sem comprar e dependo do tipo de produto permitir até mesmo a personalização do produto.
2.1.5 – INFRAESTRUTURA NECESSÁRIA PARA O SERVIÇO DE COMÉRCIO ELETRÔNICO
A infraestrutura necessária para disponibilizar o serviço de comércio eletrônico é composta por:
25
Link de comunicação com a Internet – comunicação física e lógica existente entre os equipamentos que disponibilizam a aplicação e um provedor de acesso à Internet.
Servidor para a aplicação e banco de dados – um ou mais microcomputadores com características de hardware de alto desempenho para hospedar a aplicação de comércio eletrônico e o banco de dados.
Servidor de aplicação – software desenvolvido para disponibilizar e processar as informações de produtos disponíveis, formas de pagamento e entrega dos produtos e interagir com os clientes.
Servidor de banco de dados - software para controle e manutenção da base de dados
Servidor Web – software responsável pela disponibilização do site de comércio eletrônico na Internet.
2.2 - FUNDAMENTOS DE GERENCIAMENTO DE SISTEMAS
O surgimento das redes de computadores deu-se a partir da necessidade de compartilhar equipamentos sofisticados para vários usuários ou departamentos de uma companhia. À medida que as redes demonstraram a sua eficiência, seu crescimento foi vertiginoso, tanto na quantidade de redes quanto em número de nós em cada rede – até chegar ao momento atual, onde todos os equipamentos de informática estão conectados.
Com o surgimento de redes maiores e mais complexas, houve a necessidade de monitoração e controle destas redes no sentido de identificar os pontos de congestionamento e parada antes que eles ocorram, evitando assim problemas de performance e acesso. Muitas ferramentas foram desenvolvidas para facilitar a tarefa de gerenciamento, mas sem padronização e normalmente específicas para um fabricante.
26
A estrutura de gerenciamento é formada por uma estação gerente, vários nós agentes e um protocolo de comunicação entre eles. O gerente solicita informações ou envia comandos para alterações no dispositivo de determinado agente; o agente por sua vez consulta estas informações na MIB, que é o repositório de informações de cada dispositivo. Cada dispositivo possui uma MIB que armazena os dados referentes a gerenciamento (informações como a identificação, o estado, tempo de conexão...) e o agente pode ler ou alterar estas informações. O gerenciamento de sistemas foi dividido em 5 áreas funcionais pela ISO - Gerenciamento de Falhas, Gerenciamento de Contabilidade, Gerenciamento de Configuração, Gerenciamento de Performance e Gerenciamento de Segurança:
Gerenciamento de Falhas – tem como finalidade, a detecção, identificação e correção de operações anormais do ambiente que está sendo gerenciado. No âmbito de gerenciamento de falhas, é importante diferenciar erros e falhas: uma falha é uma condição anormal que deve ser reparada, enquanto que um erro é um evento isolado – uma falha pode ser causada por um ou mais erros. Para atender as exigências de performance e disponibilidade dos recursos gerenciados, as funções de gerenciamento devem ter procedimentos de detecção de falhas rápidos e confiáveis e deve ser considerada a possibilidade de redundância de componentes para os casos mais críticos – permitindo maior tolerância à falhas.
Gerenciamento de Contabilidade - tem como finalidade o rastreamento dos custos envolvidos no ambiente gerenciado. A análise de relatórios estatísticos possibilita identificar o custo de cada recurso, como quanto é gasto com impressão, ou com um link de comunicação. O controle dos custos de cada recurso evita o desperdício e o abuso de privilégios.
Gerenciamento de Configuração – trata das configurações e manutenções dos elementos gerenciados. Por exemplo, no caso de um servidor de aplicações Web, uma alteração na configuração – tanto de hardware ou software, ou uma atualização do software de uma estação de trabalho pode ser efetuada pela gerência de configuração. Os usuários dos
27
elementos gerenciados devem ser informados das manutenções, desta forma, é recomendada a geração periódica de relatórios de manutenção.
Gerenciamento de Performance – tem como objetivo determinar a qualidade do funcionamento da rede como um todo. Identifica itens chave como capacidade de processamento, tempo de resposta e disponibilidade geral do sistema. O gerenciamento de performance divide-se em duas categorias funcionais: monitoração e ajuste. A função de monitoração localiza atividades no sistema enquanto a função de ajuste altera certa variável para melhorar o desempenho do sistema. A monitoração da performance trata do desempenho de cada dispositivo e dos dispositivos como um todo.
Gerenciamento de Segurança – trata do regulamento e o gerenciamento do acesso aos recursos do sistema. A execução do gerenciamento de segurança é a aplicação das diretivas definidas pela política de segurança da empresa e pode variar de acordo com os tipos de dispositivos e os níveis de segurança. Muitos dos mecanismos de segurança, como autenticação, criptografia e certificação, estão incorporados às implementações que visam o gerenciamento de redes.
Os modelos de gerenciamento de redes padronizados são o modelo OSI e o modelo Internet. O modelo OSI é voltado para o gerenciamento de redes de telecomunicações e trata os elementos gerenciados usando a estrutura de orientação a objetos. O modelo Internet é voltado para o gerenciamento de redes de computadores, trata os elementos como objetos também, mas usa a estrutura de variáveis. O modelo Internet é usado nesta proposta de gerenciamento e é detalhado no próximo sub-capítulo.
28
Originalmente na definição do conjunto de protocolos TCP/IP não foi levado em consideração a importância do gerenciamento de redes, à medida que as redes cresceram, os administradores identificaram a necessidade de gerenciamento e criaram ferramentas com esta finalidade – inicialmente usando o protocolo ICMP. Com a expansão da Internet, as redes cresceram em número de hosts e complexidade, tornando premente a necessidade de padronização de ferramentas e protocolos de comunicação para o gerenciamento.
Stallings (1999) descreve o surgimento do protocolo SNMP: O primeiro esforço no sentido de uma ferramenta de gerenciamento específica foi o SGMP em novembro de 1987 – criado para o gerenciamento de gateways. Outras três propostas para finalidade geral surgiram:
HEMS – Sistema de Gerenciamento de Entidades de Alto Nível
SNMP – Protocolo de Gerenciamento de Redes Simples – Foi uma versão aperfeiçoada do SGMP.
CMIP over TCP/IP (CMOT) – Foi uma tentativa de incorporar, na máxima extensão possível o protocolo (CMIP), serviços e estrutura de banco de dados padronizado pela ISO para gerenciamento de redes.
O IAB definiu o SNMP como protocolo padrão para o gerenciamento de redes em 1988 e atualmente é largamente utilizado pelos fabricantes de componentes de redes - tanto de hardware quanto de software. Muitas alterações foram feitas ao modelo original do SNMP, no intuito de aperfeiçoá-lo. As versões disponíveis hoje são o SNMPv1, o SNMPv2 e o SNMPv3.
O modelo de rede Internet é composto pelos elementos:
Gerente – (estação de gerenciamento) a estação de gerenciamento age como uma interface da estrutura gerenciada com o administrador, o qual recebe as informações de estado do sistema e determina a ação que deve ser tomada.
Agente – é módulo que fica no dispositivo que está sendo gerenciado. Troca informações com o gerente. A comunicação pode ser originada a partir dele (trap) ou do gerente (polling).
29
MIB – por sua vez a MIB (Base de Informações Gerenciáveis), armazena todas as informações do dispositivo, como a identificação, as configurações, o estado. Estas informações são lidas ou alteradas pelo agente.
Protocolo de Gerenciamento – O SNMP possibilita a troca de informações entre gerentes e agentes. Na arquitetura Internet, o SNMP é implementado sobre o UDP ou seja, não é orientado à conexão - como sua função é gerenciar situações de risco, não pode depender de conexão.
A figura 2.3 ilustra os componentes do modelo Internet.
Fig. 2.3 Modelo de Gerência Internet
Basicamente, o gerenciamento de uma rede Internet é feito com um ou mais gerentes e vários nós gerenciados. Como nó gerenciado considera-se um roteador, uma placa de rede de um servidor Web, uma aplicação em execução no servidor – como o serviço de comércio eletrônico -, o número de acessos de um site, etc. As informações de cada nó são armazenadas na MIB e consultadas ou alteradas pelo módulo agente através do protocolo SNMP.
Cada recurso gerenciado é representado como um objeto e a MIB é a coleção estruturada em forma de árvore destes objetos. Para que estes objetos sejam lidos por qualquer sistema de gerenciamento, eles devem ser definidos usando uma estrutura de informações de gerenciamento (SMI) padrão. A SMI determina a estrutura para a representação,
30
armazenamento e transferência das informações de gerenciamento. À medida que novas funções foram implementadas, novas versões do SNMP e SMI foram disponibilizadas.
O modelo de informação usado para gerenciamento de redes é composto por definições para a estrutura de informações (SMI), para o protocolo e para a MIB.
A primeira versão oficial do framework de gerenciamento Internet foi o SNMPv1, definido em maio de 1990.
2.2.1.1 – Framework SNMPv1
O framework para gerenciamento de redes consiste da Estrutura e Identificação de Informações de Gerenciamento para Internets baseadas em TCP/IP (SMI) – definida na RFC 1155, a Base de Informações de Gerenciamento (MIB) para gerenciamento de redes baseadas em TCP/IP – definida na RFC 1156 e o Protocolo de Gerenciamento de Redes Simples (SNMP) – definido na RFC 1157. Apesar deste modelo ter sofrido alterações e ter sido substituído por novas versões, para fins de embasamento para as versões atuais ele é detalhado abaixo.
SNMP – Protocolo de Gerenciamento de Redes Simples
Segundo CASE (1990) O SNMP foi definido tendo como principal objetivo minimizar a quantidade e complexidade das funções de gerenciamento realizadas pelo agente. Como objetivos secundários foi proposto que o SNMP fosse suficientemente amplo para aceitar aspectos adicionais da operação de gerenciamento de redes e tanto quanto possível independente da arquitetura e mecanismos dos dispositivos gerenciados.
Originalmente era conhecido como SNMP, mas após a disponibilização de novas versões passou a ser chamado de SNMPv1.
A arquitetura do SNMPv1 indica uma solução para o gerenciamento de redes em termos de: O escopo das informações de gerenciamento comunicadas pelo protocolo, A representação das informações de gerenciamento comunicadas pelo protocolo,
31
As operações sobre as informações de gerenciamento suportadas pelo protocolo, A forma e o significado das trocas entre as entidades de gerenciamento,
A definição dos relacionamentos administrativos entre as entidades de gerenciamento,
A forma e o significado das referências para as informações de gerenciamento.
O protocolo de gerenciamento de redes é um protocolo de aplicação usado para consultar ou alterar as variáveis da MIB de um agente. A comunicação entre as entidades do protocolo é acompanhada pela troca de mensagens, representadas em um datagrama UDP usando as regras básicas de codificação do ASN.1. Uma mensagem consiste de um identificador de versão, um nome de comunidade SNMP e uma PDU (Unidade de Dados do Protocolo). Uma entidade do protocolo recebe mensagens na porta UDP 161 do host a qual é associada para todas as mensagens com exceção das mensagens de trap, ou seja, todas as mensagens menos àquelas que contém a PDU-Trap. Estas mensagens devem ser recebidas na porta 162 para melhor processamento.
Para esta versão do protocolo as PDUs disponíveis são:
GetRequest-PDU – Solicita a recuperação do valor de uma ou um conjunto de variáveis.
GetNextRequest-PDU – Solicita a recuperação do valor de uma ou um conjunto de variáveis que sucedem lexicograficamente àquelas informadas
GetResponse-PDU – Responde às operações get-request, get-next-request e set-request
SetRequest-PDU – Solicita a atribuição de valor a uma ou um conjunto de variáveis.
32
Trap-PDU – Envia um evento não solicitado para uma ou várias estações de gerenciamento.
O formato das PDUs com exceção da PDU Trap, segue o formato exibido na figura 2.4.
Fig. 2.4 Formato das PDUs SNMPv1
Os procedimentos seguidos pelo protocolo para o envio de uma mensagem seguem o esquema:
1) Constrói a PDU apropriada – a PDU Get-Request – como um objeto ASN.1
2) Envia este objeto ASN.1 com o nome da comunidade e com o endereço original e o endereço de destino para o serviço que implementa a autenticação. Este serviço retorna um outro objeto ASN.1.
3) A entidade de protocolo então constrói um objeto mensagem ASN.1, usando o nome de comunidade e o objeto resultante do passo 2.
4) Este objeto mensagem é serializado, usando as regras de codificação do ASN.1 e então é enviado usando o serviço de transporte.
33
Realiza uma análise rudimentar sobre o datagrama recebido para identificar se está no formato de mensagem ASN.1 Se o formato não for o esperado o datagrama é descartado.
Verifica o número da versão da mensagem SNMP, se houver erro a mensagem é descartada.
O nome da comunidade e o usuário do objeto mensagem juntamente com o endereço original e destino são informados para o serviço de autenticação. Este serviço retorna outro objeto ASN.1 ou em caso de falha na autenticação, envia um trap informando a falha .
A entidade do protocolo realiza uma análise rudimentar sobre o objeto resultante da autenticação para construir um objeto ASN.1 correspondente ao objeto da PDU. Se a análise falhar o datagrama é descartado, senão, usando o nome da comunidade é selecionado o perfil apropriado e a PDU é processada.
Estrutura de Gerenciamento – SMIv1
A SMI definida na RFC 1155 descreve as estruturas e o esquema de identificação para a definição das informações de gerenciamento. Os objetos da MIB são definidos usando o ASN.1, onde cada tipo de objeto tem um nome, uma sintaxe e uma codificação. O nome é representado pelo macro OBJECT IDENTIFIER, - o valor de uma macro OBJECT IDENTIFIER é um nome atribuído administrativamente. A sintaxe para um objeto define a estrutura de dados abstrata correspondente ao tipo de objeto. A codificação de um tipo de objeto é a forma como instâncias de um tipo de objeto são representados usando a sintaxe do tipo de objeto .
Um OBJECT IDENTIFIER é uma seqüência de inteiros que atravessa a árvore global de objetos. Esta árvore consiste de uma raiz conectada a um número de nós através de
34
subdivisões. Cada nó, por sua vez pode ter outras subdivisões. Cada identificação de OBJECT IDENTIFIER é associada a uma breve descrição textual e um número inteiro.
Os objetos de gerenciamento de redes são alocados abaixo do ramo internet e iniciam com o prefixo 1.3.6.1.. As subárvores abaixo deste ramo são:
directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 }
A SMI requer que o protocolo de gerenciamento defina mecanismos para identificar as instâncias de cada objeto. Nas operações SNMP, cada instância de objeto é identificada por um nome único conhecido como “nome de variável”. Normalmente, o nome de uma variável é um OBJECT IDENTIFIER na forma x.y, onde x é o nome de um tipo de objeto não agregado definido na MIB e y é um fragmento de OBJECT IDENTIFIER que identifica a instância desejada. Esta forma de nomeação é adequada à semântica da PDU GetNextRequest que identifica o conteúdo das variáveis em ordem lexicográfica contínua.
Para os tipos de objetos onde existe apenas uma instância a nomeação deve ser feita por um OBJECT IDENTIFIER da forma x.0, onde x é o nome do tipo de objeto. Por exemplo, para identificar uma instância do objeto sysName, a nomeação deste objeto é :
iso org dod internet mgmt mib system sysName
35
Neste exemplo, o tipo de objeto x deve ser 1.3.6.1.2.1.1.5, e a ele deve ser concatenado um sub-identificador 0, ou seja, 1.3.6.1.2.1.1.5.0 identifica uma e somente uma instância de sysName.
Os objetos podem ser do tipo escalar ou colunar, os objetos que compõem uma tabela são do tipo colunar. A sintaxe é usada para definir a estrutura correspondente ao tipo de objeto. Provenientes do ASN.1 os tipos primitivos, construídos e aplicação são usados para definir esta estrutura. Os tipos primitivos ASN.1 são : INTEGER, OCTET STRING, OBJECT IDENTIFIER e NULL, os tipos construídos são SEQUENCE e SEQUENCE OF e os tipos aplicação (APPLICATION) são: NetworkAddress, IPAddress, Counter, Gauge, TimeTicks e Opaque. Os tipos de objeto ASN.1 são detalhados no sub-capítulo 2.2.2.
A definição de um tipo de objeto compreende cinco campos:
OBJECT – um nome textual, chamado de OBJECT DESCRIPTOR, para o tipo de objeto correspondente ao OBJECT IDENTIFIER.
Syntax – é a sintaxe abstrata para o tipo de objeto.
Definition – é uma descrição textual das semânticas do tipo de objeto.
Access – tipo de acesso máximo para o tipo de objeto (read-only, read-write, write-only ou not-accessible).
Status – identifica se a definição do tipo de objeto é obrigatória, opcional ou obsoleta. A figura 2.5 apresenta a definição formal do objeto sysDescr.
Object
SysDescr (system 1) Syntax
DisplayString(SIZE(0..255) Definition
Uma descrição textual do agente.
Identificação completa do nome e versão do Sistema Operacional. Acess
Read-only Status
mandatory
36
Base de Informações Gerenciáveis – MIB
A MIB definida na RFC 1156 e que passou a ser conhecida como MIB-I, foi a primeira versão de definição dos objetos necessários para a monitoração e controle de componentes da Internet. A lista dos objetos gerenciados contém apenas os elementos considerados realmente essenciais, por isso, esta MIB não possui objetos opcionais – todos devem ser implementados. Os objetos estão estruturados nos seguintes grupos (MCC, 1990): “system, interfaces, address, translation, ip, icmp,tcp, udp, egp.”
A figura 2.6 exibe a árvore de grupos da MIB-I.
RESERVED (0) PROTEON (1) IBM (2) ISO (1) ORG (3) DOD (6) INTERNET (1) DIRECTORY (1) MGMT (2) EXPERIMENTAL(3) PRIVATE (4) MIB (1) SYSTEM(1) INTERFACE (2) ADDRESS TRANSLATION (3) IP (4) ICMP (5) TCP (6) UDP (7) EGP (8) ENTERPRISES[1] TOP CCITT (0) JOINT-ISO-CCITT (2) STD(0) REG AUTHORITY(1) MEMBER BODY(2)
Fig. 2.6 Árvore de objetos da MIB-I
Em março de 1991 foi apresentado a MIB-II, definida na RFC 1158 para complementar o grupo e objeto da MIB-I. A MIB-II foi formalizada como padrão na RFC 1213 em 1989 e é
37
atualmente o padrão adotado para gerenciamento Internet. Os grupos definidos na MIB-II são: system, interfaces, at, ip, icmp, tcp, udp, egp, transmission e snmp.
O processo de autenticação do SNMPv1 é considerado inseguro, porque baseia-se no nome da comunidade, que é um string enviado pela rede de maneira legível. Duas comunidades podem ser configuradas: uma para acesso de leitura e outra para leitura e gravação.
Esta versão do SNMP possui algumas limitações:
Possui limitações de performance para polling e por isso não é recomendado para gerenciar redes grandes
Autenticação insegura
Não permite comunicação gerente com gerente, apenas gerente – agente.
2.2.1.2 – Framework SNMPv2
Originalmente o SNMP foi desenvolvido como uma solução temporária enquanto o padrão OSI não era implementado, mas depois da publicação do SNMPv1 vários fabricantes de equipamentos de rede incluíram módulos SNMP em seus dispositivos, mas esta versão apresentava muitas falhas, então foi desenvolvida a versão 2 do SNMP. Não houve um consenso para a apresentação de um modelo que atendesse completamente às necessidades – principalmente sobre as questões de segurança – e o modelo publicado nas RFCs 1902 a 1908 dava sinais que precisaria ser corrigido. Em seguida, na RFC 1901 foram publicadas alterações no modelo de administração, mas quanto às questões de segurança não houve consenso e não foram implementadas nesta versão.
Uma nova estrutura de informações (SMIv2) foi definida nas RFCs 1902 – Estrutura de Informações, 1903 – Convenções Textuais e 1904 – Declarações de Conformidade e em 1999 foram atualizadas respectivamente pelas RFCs 2578, 2579 e 2580. Esta nova SMI inclui
38
novos tipos de dados, novas macros e convenções textuais. O detalhamento da SMIv2 é apresentado no capítulo 3 – Construindo uma MIB padrão SNMP.
SNMP – Protocolo de Gerenciamento de Redes Simples versão 2
O SNMPv2 foi publicado nas RFCs 1905 - Operações do Protocolo e 1906 – Mapeamentos de Transporte e apresenta três modos de acesso:
request-response (agente) – uma entidade SNMP atuando como gerente, envia uma solicitação para uma entidade agente SNMP e esta então responde a solicitação. Este acesso é usado para recuperar ou modificar informações no dispositivo gerenciado.
request-response (gerente) – uma entidade gerente envia uma solicitação para outra entidade gerente e esta então responde a solicitação. Este tipo de acesso é usado para uma entidade gerente notificar outra entidade gerente. Este tipo de acesso não existe no protocolo SNMPv1.
interação não confirmada – quando uma entidade agente envia uma mensagem não solicitada – trap – para uma entidade gerente e nenhuma resposta é retornada. Este tipo de acesso é usado para notificar um agente da ocorrência de uma situação extraordinária com o dispositivo gerenciado. (CASE, 1996a)
Duas novas PDUs foram incluídas nesta versão:
GetBulkRequest – permite ao gerente solicitar grande quantidade de dados, incluindo a recuperação rápida e eficiente dos dados de grandes tabelas.
InformRequest – permite a um gerente enviar uma notificação para outro gerente informando a visão que o primeiro tem da MIB. O gerente notificado envia uma confirmação do recebimento.
Todas as PDUs foram padronizadas e todas as mensagens possuem o mesmo formato. Esta alteração aumentou a performance na troca de mensagens entre os sistemas.
A RFC 1906 define implementações sobre outros protocolos de transporte além do UDP (originalmente definido no SNMPv1), os protocolos de transporte definidos são: OSI, DDP (appletalk) e IPX. Mesmo assim, permanece a sugestão para que os agentes sejam implementados sobre UDP, ouvindo na porta 161 e respondendo na porta 162.
39
A RFC 1908 trata das especificações para a coexistência entre o SNMPv1 e SNMPv2, uma possibilidade é o uso de um gerente que entenda as duas versões de SNMP e a outra é um proxy que recebe as mensagens em SNMPv2 e transmite para o agente em SNMPv1.
Base de Informações Gerenciáveis – MIB
Segundo CASE (1996c) foram feitas algumas alterações na MIB internet – no grupo system foram incluídos alguns objetos e no grupo snmp foram excluídos alguns objetos considerados desnecessários.
2.2.1.3 – SNMPv3
O SNMPv3 foi apresentado como uma solução para os problemas de segurança não tratados nas versões anteriores, mas ele não é considerado um protocolo completo de gerenciamento de redes, mas um modelo de características de segurança que pode ser implementado com o SNMPv1 ou SNMPv2. O SNMPv3 foi apresentado em 1998 pelas RFCs 2261, 2262, 2263, 2264 e 2265, sendo alterado nas RFCs 2271, 2272, 2273, 2274 e 2275 em 1999 sofreu novas atualizações publicadas nas RFCs 2571, 2572, 2573, 2574 e 2575.
Segundo HARRINGTON (1999), os objetivos principais para o desenvolvimento do SNMPv3 foram:
Na medida do possível usar as definições existentes. Esta versão é baseada nas versões SNMPv2u e SNMPv2* .
Corrigir a necessidade de segurança da operação SET, considerada a maior deficiência das versões SNMPv1 e SNMPv2.
Tornar possível mover partes da arquitetura em direção à padronização, mesmo sem atingir o consenso total.
40
Definir uma arquitetura que permita longevidade para o framework SNMP que já está definido e para o que ainda será definido.
Manter o SNMP tão simples quanto possível
Tornar uma implementação mínima do framework relativamente barata.
Tornar possível atualizar módulos do SNMP assim que eles estejam disponíveis, sem desestruturar o framework.
Adicionar características necessárias para suportar redes de grande porte.
O objetivo principal do desenvolvimento desta versão são os problemas de segurança não tratados nas versões anteriores. Com base nas informações de BLUMENTHAL (1999a), as ameaças de segurança a qual o SNMPv3 deve combater com eficiência são :
Modificação de informações – alguma entidade não autorizada pode alterar uma mensagem SNMP em trânsito para permitir operações não autorizadas – como a alteração do valor de algum objeto.
Mascaramento – é a ameaça que alguma entidade não autorizada assuma a identidade de outra e realize operações sem a devida autorização.
Alteração da seqüência da mensagem – é a possibilidade de alteração maliciosa da ordem de envio das mensagens, demora no envio ou reenvio.
Descoberta – é a ameaça de observação indevida do conteúdo das trocas entre agentes e gerentes.
A arquitetura do SNMPv3 define um conjunto de entidades distribuídas que interagem entre si para prover serviços. Uma entidade pode atuar como agente , gerente ou uma combinação dos dois. Cada entidade SNMP consiste de um “motor” SNMP e uma ou mais aplicações associadas. O motor SNMP fornece serviços para envio e recebimento de mensagens, autenticação e criptografia de mensagens e controla o acesso para os objetos gerenciados. A figura 2.7 mostra detalhes de uma entidade SNMP e os componentes:
41
Fig. 2.7 Entidade SNMPv3
Dispatcher – fornece suporte para múltiplas versões de mensagens SNMP. Message Processing Subsystem – é responsável pela preparação das mensagens
para envio e extração dos dados das mensagens recebidas. O subsistema de processamento de mensagens possui vários Modelos de Processamento de Mensagens. Cada modelo de processamento de mensagens define o formato de uma versão particular de uma mensagem SNMP.
Security Subsystem – fornece serviços de segurança tais como autenticação e privacidade de mensagens, contém vários Modelos de Segurança. Um modelo de segurança especifica contra quais ameaças ele protege e quais os protocolos de segurança são usados para este fim.
Access Control Subsystem – fornece serviços de autorização através de um ou mais Modelos de Controle de Acesso.
42
Command Generator – monitora e controla o acesso para o gerenciamento de dados.
Command Responders – fornece acesso para o gerenciamento de dados Notification Originators – inicializa mensagens assíncronas
Notification Receivers – processa mensagens assíncronas Proxy Forwarders – encaminha mensagens entre as entidades
As mensagens SNMPv3 são formadas por quatro grupos. O primeiro grupo é o número da versão – está na mesma posição das versões SNMPv1 e SNMPv2 – o subsistema Dispatcher verifica qual é a versão e encaminha para o modelo de processamento de mensagem apropriado. O segundo grupo identificado como global / header data, informa os parâmetros administrativos da mensagem, incluindo o modelo de segurança utilizado. O terceiro grupo informa os parâmetros de segurança que serão usados pelo modelo de segurança para a comunicação entre as entidades. O quarto grupo contém os campos da PDU de acordo com a versão SNMP utilizada – podem estar criptografados ou não.
Segundo BLUMENTHAL (1999a), no framework SNMPv3 o modelo de segurança é baseado em usuários – USM (User based Security Model), e os serviços de segurança baseiam-se em:
Integridade de Dados
Autenticação da origem dos dados Confidencialidade dos dados
Entrega de mensagens no tempo correto e proteção contra reenvio de mensagens.
O controle de acesso que nas versões anteriores era baseado em nomes de comunidade, nesta versão é baseado em visão (VACM – View based Access Control Model), e foi definido e publicado na RFC 2575. De acordo com BLUMENTHAL (1999b), este modelo de acesso
43
define um conjunto de serviços que uma aplicação - como Command Responder ou Notification Originator – pode usar para verificar os direitos de acesso para requisições e notificações. Os elementos do Modelo de Controle de Acesso baseado em Visão são:
Groups – define direitos de acesso por grupos (composto por um ou mais modelos de segurança e nome de segurança).
Security Level – diferentes direitos de acesso para membros de um grupo -podem ser definidos diferentes níveis de segurança.
Contexto – é uma coleção de informações de gerenciamento disponíveis por uma entidade SNMP. Um item de informação de gerenciamento pode existir em mais de um contexto.
MIB Views and View Families – por razões de segurança, algumas vezes é importante restringir os direitos de acesso de alguns grupos para apenas um subgrupo de informações de gerenciamento em um domínio de gerenciamento. Para permitir esta capacidade, o acesso a um contexto é feito através de uma visão da MIB que detalha um conjunto específico de tipos de objetos gerenciados dentro do contexto
Access Policy – o modelo de controle de acesso baseado em visão determina os direitos de acesso de um grupo representando zero ou mais securityNames que tem os mesmos direitos de acesso. Para um contexto particular identificado pelo
contextName, de um determinado grupo identificado pelo groupName, o acesso
é definido usando um securityModel particular e um securityLevel – os direitos de acesso de um grupo são dados por uma visão de leitura, uma visão de escrita e uma visão de notificação.
44
Para a coexistência entre as versões 1, 2 e 3 do Framework SNMP são definidas algumas regras quanto à sintaxe a ser seguida. A MIB SNMP-COMUNITY define objetos que auxiliam o relacionamento entre as três versões. A RFC 2576 detalha a sintaxe e os objetos desta MIB.
45
3. CONSTRUINDO UMA MIB SNMP
A construção de uma MIB é o processo de descrever os objetos do sistema a ser gerenciado usando uma sintaxe padrão. Esta sintaxe usa macros do padrão ASN.1 e é definida na estrutura de gerenciamento de informações (SMI).
Para a construção de uma MIB no padrão SNMP são necessários alguns passos: Conhecer detalhadamente o sistema a ser gerenciado,
Fazer a modelagem dos objetos que irão compor a MIB,
Organizar a MIB e os objetos na estrutura de Identificadores de Objetos (OIDs), Definir o layout e a nomeação dos módulos,
Verificar a conformidade da MIB, Estes passos são detalhados a seguir:
3.1 – CONHECER O SISTEMA A SER GERENCIADO
Conhecer o sistema requer um embasamento técnico dos dispositivos ou serviços que serão gerenciados e também a identificação das necessidades de gerenciamento – qual o objetivo principal do gerenciamento, quais eventos devem ser monitorados, quais informações do dispositivo ou serviço devem ser controlados. A origem e o método de extração das informações varia de acordo com o dispositivo / serviço que será gerenciado.
Tomando como exemplo o gerenciamento da atividade de comércio eletrônico de uma empresa, deve-se considerar que se trata do negócio da empresa. Este aspecto pode ser visto como uma rede se considerarmos que os múltiplos elementos que compõem esta atividade estão interligados: a empresa que disponibiliza os produtos na Internet, os fornecedores dos
46
produtos, o departamento de logística que encaminha o produto para a entrega, a empresa que realiza a entrega, o depto responsável pela cobrança da fatura e o cliente que interage com a loja e estabelece a compra formam uma rede de componentes do negócio de comércio eletrônico.
O componente principal desta rede é o cliente, e atender às suas expectativas é o objetivo de todos os componentes do processo. A captação das características da compra e de quem está comprando é feita através da monitoração dos eventos que ocorrem durante o processo de consulta e compra em uma loja virtual.
O CRM – conjunto de normas que trata do gerenciamento das relações de uma empresa com o cliente - considera fundamental para um bom relacionamento entre empresa e consumidor, que o cliente seja tratado de acordo com o seu perfil. Em outras palavras, o ideal é que, mesmo para o cliente de uma grande empresa que pode estar na mesma cidade ou do outro lado do planeta, o atendimento seja igual ao do armazém da esquina em uma pequena cidade – aquele em que o proprietário do estabelecimento conhece as preferências do cliente, quando ele faz aniversário, como ele costuma pagar suas compras ... Para permitir este relacionamento a loja virtual precisa conhecer detalhadamente quem é o seu cliente - quais são os produtos de sua preferência, quais os horários que costuma visitar a loja.
Em um ambiente de comércio como a Internet, onde o cliente não leva em consideração a localização da loja, mas a disponibilidade do produto e a qualidade do atendimento, é de extrema importância obter informações quanto à satisfação do cliente. De posse destas informações, a empresa pode usar ferramentas de marketing e fidelização do cliente apropriadas ao seu perfil de consumo e também adequar o catálogo de produtos e as características da loja ao padrão de clientes.
A interação com clientes em tempo real pode ser integrada com uma base de dados de marketing para identificar um produto específico ou conjunto de produtos, a fim de atender às necessidades de novos e atuais clientes. A natureza interativa da Internet permite que um vendedor incorpore uma série de consultas interativas com seus materiais de mercado, por meio dos quais
