Arquivo

Archive for the ‘Banco de dados’ Category

XML na Infraestrutura da Internet

Jewish law prohibited farmers from harvesting every last item from their fields.
If something was missed in the first pass, they were to leave it for the poor to harvest.
This was called gleaning. Gleaning provides a metaphor for good writing and teaching.
Don’t explain everything in complete detail. Leave something for the reader or student to harvest on their own.
From John Cook => https://plus.google.com/u/0/+JohnCook/posts/4UpWuws59oU

 

Introdução

 

Tenho insistido na ideia da aplicação de Web Semântica na Infraestrutura da Internet. Durante o, ainda em desenvolvimento desta ideia, uma questão parece evidente: o domínio da Infraestrutura da Internet é enorme e inexplorado sob a ótica da Web Semântica! Basta uma olhada na Figura 1, uma representação simplificada e parcial deste domínio, na qual, os principais agentes aparecem com algumas relações básicas. Tais agentes são os produtores das informações, isto é, dados que são produzidos e guardados em repositórios, geralmente, no formato texto com uma estrutura mínima. Há um texto em inglês, Preliminaries essays to research in Semantic Web applied to Internet Infrastructure, disponível em PDF, no qual, entre outras coisas, esclarece como os administradores de Sistemas Autônomos consomem estes dados, através de ferramentas orientadas a este fim. No “Preliminaries essays…”, a localização de alguns dos repositórios está representado em um cenário mais abrangente.

 

VisaoEntrelaçadaIPv6

Figura 1. Representação simplificada e parcial do domínio da Infraestrutura da Internet.

 

Ao procurar fixar o cenário, a maneira de pensar varia do geral para o particular e muitas vezes, também, do particular para o geral. Uma troca, sem limites usando refinamentos sucessivos, tanto no pensamento “top->down” como no “bottom->up”. Neste vai e vem da forma de pensar, o Mapa de Conceito4, exerce um papel fundamental, já que sua característica principal é a facilidade de representar o domínio do problema (ou do conhecimento), visualmente, simplificado e, direto. Existem vários mapas de conceito disponíveis, nos quais incluem os mapas mentais, que também fazem um bom trabalho. Neste texto, usamos o CMaps8 descrito sob o ponto de vista de suas aplicações. A Figura 1 e muitas outras que seguem foram, também produzidas, no CMaps.

Além das preocupações com o tamanho do domínio, a ausência de um vocabulário direto e aplicável ao domínio há outras. Entre estas outras, a linguagem para representar e permitir fácil acesso aos repositórios é um dos aspectos mais importantes. A base para tratar as aplicações de Web Semântica está na eXtensible Markup Language (XML), definida em [6] e é sobre ela que trataremos neste primeiro artigo.

 

A XML e a aplicação na delegação de IPv6

 

Sistemas Autônomos6 na Internet são identificados por um número denominado ASN (Autonomous System Number). Este número é controlado e distribuído pelo IANA (Internet Assigned Numbers Authority). A IANA (http://www.iana.org/about) é um departamento do ICANN (Internet Corporation for Assigned Names and Numbers). A IANA, também controla a distribuição de números IPv4 e IPv6, entre outras funções. O mecanismo de distribuição do IANA é do tipo atacado, isto é, ela distribui os números de AS, IPv4 e IPv6 para os RIR (Regional Internet Register), que por sua vez distribuem para os NIR (National Internet Register) ou diretamente para os interessados, quando não existir um NIR. Os RIRs são em número de cinco, cada um responsável por uma região do mundo (http://www.iana.org/numbers). Os RIRs são: AfriNIC, APNIC, ARIN, LACNIC e RIPE NCC. A IANA está, também, intimamente conectado com o IETF9. ICANN, IANA, IETF, números IPv4, números IPv6, números de ASes, RIRs, NIRs, Empresas, Instituições, Países, Pessoas e muitas outras coisas são parte dos “conceitos” associados ao domínio Infraestrutura da Internet, ou em outras palavras, ao vocabulário do domínio.

Para a aplicação da XML trabalharemos sobre um sub-domínio da representação exibida na Figura 1 (em laranja). Com o CMaps obtemos facilmente a derivação que pode ser vista na Figura 2.

 

DetalheIPv6

Figura 2. Detalhe da destinação de um bloco IPv6.

 

A representação fala por si mesmo. Em resumo, uma Empresa (digamos, um provedor) recebe um bloco de IPv6 sobre o qual estamos interessados. De posse deste bloco, um /32, o provedor planeja e designa sub-blocos a seus clientes e/ou usuários. Partindo da premissa de que a empresa tem muitos clientes, há necessidade de se criar um repositório do recurso (bloco IPv6) recebido, juntamente com as informações a ele associadas. Sobre este repositório uma série de operações conhecidas devem estar disponíveis. Uma abstração deste repositório e suas relações podem ser vistos na Figura 3.

 

RepositorioAbstrato

Figura 3. Representação abstrata de um repositório de registro de designação IPv6 e suas respectivas operações.

 

A abstração indica que o tal repositório pode ser, desde folhas de papel até um local (digital), onde se pode usar processos mais so fisticados, que tenham, por exemplo, um gerenciador de banco de dados relacional (digamos, MySQL). Vamos eliminar as soluções trabalhosas, como as folhas de papel, para procurar alternativas mais apropriadas sob o ponto de vista do acesso ao repositório e proporcionais a expectativa de tamanho deste repositório.

Faremos uma incursão sobre as soluções tradicionais, para depois seguirmos as técnicas que envolvem Web Semântica, nosso objetivo neste texto. Passemos, então, à descrição do contexto do problema desejado, com alguns detalhes importantes descobertos no planejamento.

 

Planejamento da distribuição de um bloco /32

 

Então, o provedor recebeu, do Registro.br, um bloco IPv6, que iremos supor como sendo o bloco dddd:dd00::/32. Depois de ler o artigo “Preparing an IPv6 Address”5 e o RFC 59321, cuidadosamente planejou a sua distribuição. Ele trabalhou tendo em mãos o Guia didático de Endereçamento IPv6. Assim, os números envolvidos tornaram fáceis de encontrar.

Ele dividiu este /32 em 65.536 blocos /48. Em seguida, achou adequado separar os primeiros 32.768 blocos para uso futuro e passou a pensar na segunda metade. Insistente reservou a primeira metade deste conjunto de blocos /48 (16.384), também, para uso futuro e passou a pensar sobre a divisão dos outros 16.384, da segunda metade, para que fosse distribuida a seus Clientes. O provedor calculou que na sequência deste conjunto de /48s, ele teria 1.024 x 16 blocos /48. Chamou cada um destes /48 de Disponibilidades e montou o seguinte esquema de distribuição:

  • Disponibilidade 0: dddd:dd00:c000::/48 a dddd:dd00:c00f::/48
    • dddd:dd00:c000::/48 ) Uso interno
    • dddd:dd00:c001::/48 ) Liberado
    • dddd:dd00:c00f::/48 ) Liberado
  • Disponibilidade 1: dddd:dd00:c010::/48 a dddd:dd00:c01f::/48
    • dddd:dd00:c010::/48 ) Cliente/Localidade 1
    • dddd:dd00:c011::/48 ) Liberado
    • dddd:dd00:c01f::/48 ) Liberado
  • Disponibilidade 2: dddd:dd00:c020::/48 a dddd:dd00:c02f::/48
    • dddd:dd00:c020::/48 ) Cliente/Localidade 2
    • dddd:dd00:c021::/48 ) Liberado
    • dddd:dd00:c02f::/48 ) Liberado
  • Disponibilidade 3: dddd:dd00:c030::/48 a dddd:dd00:c03f::/48
    • dddd:dd00:c030::/48 ) Cliente/Localidade 3
    • dddd:dd00:c031::/48 ) Liberado
    • dddd:dd00:c03f::/48 ) Liberado
  • 

  • Disponibilidades 4 ate 511
  • Disponibilidade 512: dddd:dd00:c2f0::/48 a dddd:dd00:c2 ::/48
    • dddd:dd00:c2f0::/48 ) Cliente/Localidade 512
    • dddd:dd00:c2f1::/48 ) Liberado
    • dddd:dd00:c2 ::/48 ) Liberado
  • 

  • Disponibilidades 513 ate 1022
  • Disponibilidade 1023: dddd:dd00: f0::/48 a dddd:dd00: ::/48
    • dddd:dd00: f0::/48 ) Cliente/Localidade 1023
    • dddd:dd00: f1::/48 ) Liberado
    • dddd:dd00: ::/48 ) Liberado

Quando esta divisão foi feita, o provedor tinha em mente o RFC 61773, não deixando de pensar que um de seus clientes poderia dividir o bloco /48 em /56 ou /60. Indo um pouco mais além fez recomendações para que seus clientes distribuíssem a seus usuarios, blocos /64. Como em cada /48 estão disponveis 65.536 redes /64, ele fez as seguintes recomendacões a seus Clientes:

    

  • Usar o primeiro bloco /64 para Loopback.
  • 

  • Deixar pelo menos 15 redes contíguas ao /64 designado (da mesma forma que o /48, acima).
  • 

  • Avaliar o uso de su fíxos relativamente fáceis de lembrar, para a rede interna (por exemplo: CA5A, FACA, …).

Tudo isto está mostrado gráfi camente na Figura 4, onde P é o prefixo dddd:dd00 e, h, i, j são dígitos hexadecimais dentro dos limites escolhidos. Por outro lado, a base de um planejamento em Infraestrutura da Internet é a topologia. Neste caso usamos a topologia da Figura 2.8 do texto Topologias, Interconexões e Protocolos.

E assim, a divisão do IPv6 deixou de ser um problema. Agora, a questão é identifi car uma maneira de como controlar as informações relacionadas com a designação dos IPv6 aos Clientes. Sem dúvida, qualquer solução envolve um local de armazenamento das informações, isto é, um repositório para os dados. A visão mais abstrata capaz de ilustrar tal ambiente, onde pessoas (usuários) possuem acesso, é a mostrada na Figura 3.

 

DivisaoIPv6

Figura 4. Representando o plano de divisão do bloco /32, graficamente.

 

Construindo o repositório com a XML

 

XML é uma linguagem livre. São poucas as restrições (sintáticas!) sobre ela. Desta forma, o estilo, a experiência e a criatividade individuais determinam a estrutura do repositório. Para este texto, o repositório em XML foi proposto como abaixo, de forma parcial e resumida:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<empresaX>
  <designacao_ipv6>
    <ip prefixo="dddd:dd00::" masc="/32">
      <ip prefixo="dddd:dd00::" masc="/48">
        <designado_para>Livre</designado_para>
      </ip>
      <!-- ... -->
      <ip prefixo="dddd:dd00:8::" masc="/48">
        <ip prefixo="dddd:dd00:8000::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c000::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <!-- 
            Grupo dos /48 designados 
        -->
        <ip prefixo="dddd:dd00:c001::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <ip prefixo="dddd:dd00:c002::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <ip prefixo="dddd:dd00:c003::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c010::" masc="/48">      
          <designado_para>Localidade 1</designado_para>
          <fone>12-3922-xxxx</fone>
          <responsavel_t>Julião Braga</responsavel_t>
          <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
          <comentarios>Utilizado na rede Interna</comentarios>        
          <ip prefixo="dddd:dd00:c010:0000::" masc="/64">
            <designado_para>Loopback</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Borda da Localidade 1</comentarios>          
          </ip>
          <ip prefixo="dddd:dd00:c010:0001::" masc="/64">
            <designado_para>Cliente 1</designado_para>
            <fone>37-xxxx-xxxx</fone>
            <responsavel_t>Fulano de Tal</responsavel_t>
            <email>nome AT SPAMFREE exemplo DOT com DOT br</email>
            <comentarios>Cliente do Provedor</comentarios>          
          </ip>
          <!-- ... -->
          <ip prefixo="dddd:dd00:c010:CA5A:" masc="/64">
            <designado_para>Rede Local</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Utilizado na rede local</comentarios>   
          </ip>
          <!-- ... -->
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c020::" masc="/48">      
          <designado_para>Localidade 2</designado_para>
          <fone>12-3922-xxxx</fone>
          <responsavel_t>Julião Braga</responsavel_t>
          <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
          <comentarios>Utilizado na rede Interna</comentarios>        
          <ip prefixo="dddd:dd00:c020:0000::" masc="/64">
            <designado_para>Loopback</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Borda da Localidade 2</comentarios> 
          </ip>
          <!-- ... -->
        </ip>
      </ip>
    </ip>
  </designacao_ipv6>
</empresaX>

Pode-se concluir que o repositório tende-se a tornar muito grande. Entretanto, a partir da escolha inicial da estrutura (ou conjunto de marcadores), da XML, o processo é repetitivo, o que facilita o trabalho. As linguagens de programação (qualquer uma e em especial JavaScript) estão preparadas para trabalhar de maneira trivial sobre repositórios XML, o que facilitaria em muito as operações desejadas (Figura 3). Da mesma forma, os navegadores, imediatamente, representam de forma estruturada um arquivo XML, como pode ser visto na Figura 5.

 

XMLnoChrome

Figura 5. Repositório XML exibido no Chrome.

 

Não se pode esquecer que a W3C possui um recurso para validar um texto XML, bastante útil, que pode ser usado em Markup Validation Service.

Por outro lado, um banco de dados (repositório) XML possui uma organização hierárquica, como mostra a Figura 6.

 

XML-hierarquia

Figura 6. Organização hierárquica de um repositório XML.

 

A eficiência sobre um repositório com tais características depende não somente da hierarquia (ou arranjo dos marcadores) mas, também, do sistema de gerenciamento (programa) do repositório. Durante a etapa de programação, eventualmente, a hierarquia poderá ser aperfeiçoada.

 

Aperfeiçoando as ideias e, o projeto

 

Suponhamos que a ideia de um repositório XML para controlar as designações de IPv6 de um provedor tenha sido um sucesso. A notícia se espalha e um habilidoso programador, digamos, o Pedro Paulo (nosso programador fictício preferido…) resolve desenvolver um repositório para:

  • Atender a vários provedores e,
  • Controlar IPv6 e IPv4

Em uma primeira tentativa, a organização do repositório poderia ter a seguinte organização

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<repositorioIP>
    <empresaX>
        <blocoipv6 prefixo="dddd:dd00::" mascara="32" />
        <blocoipv4 prefixo="192.168.0.0/20" mascara="20" />
        <cliente id="201311281745">
            <nome></nome>
            <responsaveltecnico></responsaveltecnico>
            <fonenoc></fonenoc>
            <endereco>
                <logradouro></logradouro>
                <numero></numero>
                <complemento></complemento>
                <bairro></bairro>
                <cep></cep>
                <cidade></cidade>
                <estado></estado>
            </endereco>
            <ipv6designado></ipv6designado>
            <ipv4designado></ipv4designado>
            <observacoes></observacoes>
        </cliente>  
    
    </empresaX>
    
    <empresaY>
        <blocoipv6 prefixo="dddd:dd06::" mascara="32" />
        <blocoipv4 prefixo="192.168.16.0/20" mascara="20" />
        <cliente id="201311281754">
            <nome></nome>
            <responsaveltecnico></responsaveltecnico>
            <fonenoc></fonenoc>
            <endereco>
                <logradouro></logradouro>
                <numero></numero>
                <complemento></complemento>
                <bairro></bairro>
                <cep></cep>
                <cidade></cidade>
                <estado></estado>
            </endereco>
            <ipv6designado></ipv6designado>
            <ipv4designado></ipv4designado>
            <observacoes></observacoes>
        </cliente>  
    
    </empresaY>
</repositorioIP>

 

Este segundo modelo altera a hierarquia do primeiro. O componente mais importante do repositório é o marcador <cliente>, mas exige-se que os blocos delegados de IPv6 e IPv4 estejam presentes, mas dando liberdade em relação à presença dos marcadores debaixo do marcador mais importante. Uma visão mas agradável é a do navegador, mostrada na Figura 7, logo abaixo.

 

XML-RepositorioPedroPaulo

Figura 7. O novo repositório exibido no Chrome.

 

Ou, mais agradável ainda, a visão gráfica da hierarquia mostrada na Figura 8.

 

XML-hierarquia-PedroPaulo

Figura 8. Visão gráfica da hierarquia do segundo modelo (Pedro Paulo).

 

Embora imediado é oportuno observar, que a Figura 8 representa uma árvore (estrutura de dados). Navegar nesta árvore é um processo eficiente. Por exemplo, se procuramos pelas informações da Empresa 1, basta seguir os ramos abaixo dela, ignorando o restante dos nós à sua direita. Ou seja, qualquer operação a ser feita sobre o repositório (indicadas pela Figura 3) é estritamente localizada, portanto, muitíssimo eficiente.

Há, contudo, uma questão importunando ao Pedro Paulo. Os nomes dos marcadores de cada empresa / provedor são os mesmos e isto pode causar problemas de consistência ou de conflitos. Se o repositório fosse controlado à mão (por um ser humano), certamente poderíamos trocar um marcador, sem perceber, já que eles são idênticos. Mesmo desenvolvendo procedimentos para manipular automaticamente o repositório, a inconsistência prevalecerá. A linguagem XML possui na sua especificação, um mecanismo importante para garantir a consistência dos marcadores. É a técnica denominada espaço de nomes (do inglês, namespaces). Falaremos sobre ela em seguida, mas uma ótima introdução ao conceito pode ser visto em XML Namespaces.

 

Espaço de nomes em XML

 

O objetivo do espaço de nomes em XML é eliminar conflitos entre marcadores ou, em outras palavras, estabelecer a unicidade dos marcadores. Isto é feito através do atributo xmlns que distinguirá os prefixos a serem usados nos marcadores. O formato deste atributo é, xmlns:prefixo=”URI” colocado(s) no marcador inicial (raiz). URI (Uniform Resource Identifier) é uma cadeia de caracteres que identifica um Recurso da Internet. A URL (Uniform Resource Locator), usualmente usado por nós é um caso particular da URI. Na XML, a URI é simplesmente a caracterização da unicidade e não transporta nenhuma informação adicional.

Nos artigos seguintes veremos um papel mais preponderante do espaço de nomes. Por hora, o segundo modelo do repositório proposto e, a Figura 9, ilustram como ele se transforma, ao usar espaço de nomes, que comparando com a Figura 7 torna-se o entendimento imediatamente intuitivo.

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<repositorioIP 
    xmlns:x="http://ws.org.br/empresa/X"
    xmlns:y="http://ws.org.br/empresa/Y">
    
    <x:empresa>
        <x:blocoipv6 prefixo="dddd:dd00::" mascara="32" />
        <x:blocoipv4 prefixo="192.168.0.0/20" mascara="20" />
        <x:cliente id="201311281745">
            <x:nome></x:nome>
            <x:responsaveltecnico></x:responsaveltecnico>
            <x:fonenoc></x:fonenoc>
            <x:endereco>
                <x:logradouro></x:logradouro>
                <x:numero></x:numero>
                <x:complemento></x:complemento>
                <x:bairro></x:bairro>
                <x:cep></x:cep>
                <x:cidade></x:cidade>
                <x:estado></x:estado>
            </x:endereco>
            <x:ipv6designado></x:ipv6designado>
            <x:ipv4designado></x:ipv4designado>
            <x:observacoes></x:observacoes>
        </x:cliente>  
    
    </x:empresa>
    
    <y:empresa>
        <y:blocoipv6 prefixo="dddd:dd06::" mascara="32" />
        <y:blocoipv4 prefixo="192.168.16.0/20" mascara="20" />
        <y:cliente id="201311281754">
            <y:nome></y:nome>
            <y:responsaveltecnico></y:responsaveltecnico>
            <y:fonenoc></y:fonenoc>
            <y:endereco>
                <y:logradouro></y:logradouro>
                <y:numero></y:numero>
                <y:complemento></y:complemento>
                <y:bairro></y:bairro>
                <y:cep></y:cep>
                <y:cidade></y:cidade>
                <y:estado></y:estado>
            </y:endereco>
            <y:ipv6designado></y:ipv6designado>
            <y:ipv4designado></y:ipv4designado>
            <y:observacoes></y:observacoes>
        </y:cliente>  
    
    </y:empresa>
</repositorioIP>

 

Olhando um pouco mais atentamente a XML acima, surge uma questão sobre a qual vale a pena pensar: será que o atributo id, incluído nos marcadores <cliente> faz sentido diante da presença do espaço de nomes?

 

XML-NS-RepositorioPedroPaulo

Figura 9. O segundo modelo, com a unicidade dos marcadores garantida pelo espaço de nomes, visto pelo Chrome.

 

Considerações finais

 

Nada foi dito no artigo sobre as técnicas de programação para manipular repositórios em XML. Foge do escopo do texto, que se preocupou em mostrar algumas facilidades para planejar o uso dos recursos de numeração (IPv6 / IPv4) e a alternativa de estrutura-los em um repositório usando XML. A XML é uma linguagem orientada, principalmente, ao entendimento computador-computador (ou melhor, programa-programa), muito embora ela seja acessível a humanos. Dada à sua forma livre de expressão, presta-se a inúmeras aplicações úteis, como a do exemplo, documentar a distribuição de IPv6.

Sob o ponto de vista da Web Semântica, a XML é muito restrita para a necessária expressividade semântica, apesar de ser a base para as alternativas que serão abordadas nos próximos textos.

 

Referências

  1. S. Kawamura amd M. Kawashima. A Recommendation for IPv6 Address Text Representation. RFC5952. December 2008. Disponível em: http://www.rfc-editor.org/rfc/rfc5952.txt. Acessado em 02/10/2013.
  2. IHMC. Cmap tools. http://ftp.ihmc.us/. Acessado em 02/10/2013.
  3. T. Narten and G. Huston ant L. Roberts. IPv6 Address Assignment to End Sites, March 2011. RFC6117.
  4. Joseph D. Novak and D. Bob Gowin. Learning how to learn. Cambridge University Press, Cambridge, UK, 1 edition, 1984.
  5. SurfNet. Preparing an IPv6 Address Plan. Disponível em: https://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf. Acessado em: 02/10/2013.
  6. BRAY, T. et al. Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C, 26 November 2008. Disponivel em: http://www.w3.org/TR/REC-xml/. Acesso em: 22 maio 2013.
  7. BRAGA, J. Sistemas Autonomos, Empresas Autônomas. Infraestrutura da Internet, 03 mar. 2006. Disponivel em: https://ii.blog.br/2006/03/03/sistemas-autonomos-empresas-autonomas/. Acesso em: 22 maio 2013.
  8. CAÑAS, A. J. et al. A Summary of Literature Pertaining to the Use of Concept Mapping Techniques and Technologies for Education and Performance Support. The Institute for Human and Machine Cognition. Pensacola, FL: The Chief of Naval Education and Training. 2003. p. 108.
  9. BRAGA, J. A ISOC, o IETF e a infraestrutura da Internet. Infraestrutura da Internet, 03 Janeiro 2013. Disponivel em: https://ii.blog.br/2013/01/03/a-isoc-o-ietf-e-a-infraestrutura-da-infraestrutura-da-internet/. Acesso em: 22 maio 2013.

Anúncios

Semantic Web x Internet Infrasctruture

CMapProject1

English:

 

I wrote some preliminary ideas about a project of medium / long-term application of Semantic Web Infrastructure on the Internet named Preliminaries essays to research in Semantic Web applied to Internet Infrastructure.

The text is available in PDF (English): here.

Other useful information about the IETF is here.

I’m looking for researchers interested in this area. E-mail to: juliao SPAM FREE AT braga eti DOT DOT br.

Português:

 

Escrevi algumas ideias preliminares sobre um projeto de médio / longo prazos de Web Semântica aplicada a Infraestrutura da Internet, com o nome Preliminaries essays to research in Semantic Web applied to Internet Infrastructure.

O texto, em pdf está disponível (em inglês) aqui

Outras informações úteis sobre o IETF encontra-se em aqui.

Tenho grande interesse em contatos com pesquisadores interessados nesta área. E-mail para juliao AT SPAM FREE braga DOT eti DOT br.

 

Uma classe PHP-MySQL usando mysqli:__constructor e __destructor

 

Introdução

Programar é uma tarefa difícil. Difícil e trabalhosa. É uma arte, que exige experiência, dedicação, conhecimento, habilidade, criatividade, etc. O presente texto mostra, aos interessados, como preparar uma classe para manipular tabelas em bases de dados.

Há três recomendações para tornar a difícil arte, menos traumática:

  1. Refinamentos sucessivos
  2. Programação estruturada
  3. Programação Orientada a Objetos

Além das recomendações acima, a disciplina e o conhecimento das técnicas associadas a linguagens específicas são fundamentais. E as ferramentas, finalmente. Para base de dados uso o MySQL Workench e o MySQL Administator. Para editar os programas em PHP, uso o PHPDezigner e o Enterprise Architect para modelar meus projetos de desenvolvimento, em UML (Unified Modeling Language). Uso UML, também, para modelagem de negócios e modelagem de topologias de redes, de longa distância ou complexas, sobre as quais aplica-se os protocolos BGP, OSPF, RIP e associados (MPLS, por exemplo). A UML é ótima para modelar, inclusive, os componentes dinâmicos envolvidos em tais protocolos. Falo sobre tais ferramentas não porque sejam as melhores. As melhores ferramentas são aquelas com as quais você projeta e desenvolve seu estilo, de forma gratificante.

O principal objetivo deste trabalho é o desenvolvimento de programação orientada a objetos, em PHP. Usaremos o método direto, onde a didática tem valor significativo. Não é um texto para programadores muito experientes. É um texto para os iniciantes ou aqueles experientes interessados no aperfeiçoamento pessoal.

Construção da classe

Inicio as classes, usualmente, com três componentes: a propriedade (variável) que irá identificar o número de instâncias abertas, e os métodos construtor e destrutor. O método construtor conta as instâncias. E, um pequeno programa serve para testar cada etapa do processo de refinamento sucessivo. Eis a primeira versão, abaixo:

<?php
// Versão 1
class BancodeDados extends mysqli {
    
    static $idBancodeDados = 0;
    
    /**
     * Construtor:
     * 
     * 1. Conta o número de instâncias.
    */
    
    public function __construct() {
        self::$idBancodeDados++;        
    }
    
    public function __destruct() {
        --self::$idBancodeDados;
    }
}

Eis o teste e respectivo resultado:

<?php
// Versão 1
require_once ('../includes/funcoesgerais.phpm');
require_once ('../includes/db.phpm');

$db_faleok = new db();
echo "
Instâncias abertas: " . BancodeDados::$idBancodeDados; $db_faleok1 = new db(); echo "
Instâncias abertas: " . BancodeDados::$idBancodeDados; ?> Instâncias abertas: 1 Instâncias abertas: 2

O interessante a observar acima são os seguintes pontos:

  • A propriedade estática $idBancodeDados é incrementada no método __construtor, que como sabemos é executado na criação de uma instância da classe BancodeDados.
  • Uma propriedade estática é referenciada externamente como NomedaClasse::$NomedaPropriedade, pois ela pertence à própria classe.
  • A classe BancodeDados, herda métodos e funções da classe msqli, do PHP, uma vez que estamos usando extends mysqli, na sua declaração.
  • É bom lembrar, que o método __constructor não pode retornar valores. Esta noção será muito útil mais à frente. Entretanto pode-se observar que o exemplo acima ele altera o valor de uma propriedade estática, isto é, $idBancodeDados, que é como se fosse uma variável global.
  • O trecho:
    /**
     * Construtor:
     *
     * 1. Conta o número de instâncias.
    */
    

    é a documentação da classe. Como uso o phpdoc esta tarefa torna-se, em particular, muito importante.

Não se pode esquecer do registro de atividades. Foi construída uma classe chamada Mensagens que possui dois métodos. Um método exibe uma mensagem na tela, como acima, e o outro, grava a mensagem em um arquivo de “log”. Embora a classe Mensagens não seja exibida aqui (assim como outras que não a classe BancodeDados), o contexto a deixa claro. Eis como fica a versão 2 e seu resultado:

<?php
$db_faleok1 = new BancodeDados();
Mensagem = "Instâncias abertas: " . BancodeDados::$idBancodeDados;
$msg->Exibe();
$msg->LogFaleOK();

$db_faleok2 = new BancodeDados();
$msg->Mensagem = "Instâncias abertas: " . BancodeDados::$idBancodeDados;
$msg->Exibe();
$msg->LogFaleOK();

?>

20120121 11:55:43 - Instâncias abertas: 1
20120121 11:55:43 - Instâncias abertas: 2

As observações sobre a Versão 2 do teste são:

  • Aperfeiçoamos o nome das instâncias da classe BancodeDados, dando mais consistência visual ($db_faleok1 e $db_faleok2).
  • A mensagem é exibida com a data. Fica mais claro o exemplo, além do fato de que elas estão sendo registradas no “log”, para eventuais acessos futuros.

Melhor ficaria, se a saída fosse aperfeiçoada, como a versão 3 do teste:

<?php
Mensagem = "Teste da classe db, Versão 3";
$msg->Exibe();

$db_faleok1 = new BancodeDados();
$msg->Mensagem = "Instâncias abertas: " . BancodeDados::$idBancodeDados;
$msg->Exibe();
$msg->LogFaleOK();

$db_faleok2 = new BancodeDados();
$msg->Mensagem = "Instâncias abertas: " . BancodeDados::$idBancodeDados;
$msg->Exibe();
$msg->LogFaleOK();

?>

20120121 12:09:30 - Teste da classe db, Versão 3
20120121 12:09:30 - Instâncias abertas: 1
20120121 12:09:30 - Instâncias abertas: 2

O método direto exige algumas anotações sobre a Versão 3 do teste:

  • Retiramos o comentário // Teste x do início e deixamos somente na mensagem a ser exibida na tela. Evitamos duas alterações de versões.
  • A mensagem da versão só é exibida na tela. Não é registrada no “log”.
  • Já percebe-se que o método construtor executa, imediatamente, ao se definir uma instância da classe. Mas, não temos noção do momento no qual o método destrutor é executado. Geralmente é depois que o programa principal termina (no nosso caso, o testegeral.php), ou logo depois da execução de algumas instruções após a última instrução que atua sobre a instância de uma classe.

A fim de fixar bem a questão do destrutor, abaixo está a versão 2, da classe, na qual adicionamos comentários e alteramos o método __destruct incluindo dois comandos. O primeiro, subtraindo 1 da propriedade estática $idInstanciaDB, pois ela representa o número de instâncias. Destruir significa, também, não possuir nenhuma instância! Incluímos uma saída na tela, para imprimir o momento da destruição e somente mostramos os trechos importantes:

<?php

      .
      .
      .
class db extends mysqli {
    
    static $idBancodeDados = 0;
      .
      .
      .    
    public function __construct() {
        self::$idBancodeDados++;
    }
    
    public function __destruct() {
        --self::$idBancodeDados;
        echo '
Executou a destrutora as ' . date("Ymd H:i:s"); } } Mensagem = "Teste da classe db, Versão 4"; $msg->Exibe(); $db_faleok1 = new BancodeDados(); $msg->Mensagem = "Instâncias abertas: " . BancodeDados::$idBancodeDados; $msg->Exibe(); $msg->LogFaleOK(); $db_faleok2 = new BancodeDados(); $msg->Mensagem = "Instâncias abertas: " . BancodeDados::$idBancodeDados; $msg->Exibe(); $msg->LogFaleOK(); ?> 20120121 17:19:01 - Teste da classe db, Versão 4 20120121 17:19:01 - Instâncias abertas: 1 20120121 17:19:01 - Instâncias abertas: 2 Executou a destrutora as 20120121 17:19:01 Executou a destrutora as 20120121 17:19:01

Os comentários sobre o código acima:

  • Duas instâncias foram abertas, portanto, duas execuções de destrutores.
  • Os métodos destrutores foram executados em algum momento após o término do programa.

A versão final, completa e bem ilustrativa seria:

<?php

/**
 *  @author     JB 
 *  @version    2.0 (última revisão: Janeiro 18, 2012)
 *  @copyright  (c) 2005-2012 Julião Braga
 *  @license    No licence
 *  @package    Banco de dados
 *
 * 
 * Classe BandodeDados:
 * 
 */

class BancodeDados extends mysqli {
    
    static $idBancodeDados = 0;
    
    public $nome_da_base;
    
    /**
     * Construtor:
     * 
     * 
    */
    
    public function __construct() {
        self::$idBancodeDados++;        
    }
    
    public function __destruct() {
        --self::$idBancodeDados;    
    }
}

?>

Mensagem = "Teste da classe BancodeDados, Versão 4";
$msg->Exibe();

$db_faleok1 = new BancodeDados();
$db_faleok2 = new BancodeDados();

$msg->Mensagem = "1 Instâncias abertas: " . BancodeDados::$idBancodeDados;
$msg->Exibe();
$msg->LogFaleOK();

$db_faleok1 = NULL;

$msg->Mensagem = "2 Instâncias abertas: " . BancodeDados::$idBancodeDados;
$msg->Exibe();
$msg->LogFaleOK();

$db_faleok2 = NULL;

$msg->Mensagem = "3 Instâncias abertas: " . BancodeDados::$idBancodeDados;
$msg->Exibe();
$msg->LogFaleOK();
?>

20120122 14:20:25 - Teste da classe db, Versão 4
20120122 14:20:25 - 1 Instâncias abertas: 2
20120122 14:20:25 - 2 Instâncias abertas: 1
20120122 14:20:25 - 3 Instâncias abertas: 0

Eis as observações sobre o código acima:

  • A forma de executar o destrutor, para uma determinada instância da classe é: $nome_da_Instância->NULL;.
  • Executar ou não o destrutor é uma decisão do programador. Se o programador gosta de exercer o controle total sobre seu código, então ele mesmo destrói.

 

O próximo método

Uma questão aparece, imediatamente está relacionada com o velho dilema: “quem veio primeiro? O ovo ou a galinha? No nosso contexto:

  1. As informações sobre Bases de Dados remotas, geralmente são repassadas e há alguma dificuldade para alterar a senha original. Mas, o desejável, sob o ponto de vista da segurança é que a senha não seja conhecida nem mesmo pelo usuário da base. Em outras palavras, não se deseja ver a senha ou, na melhor das hipóteses, o menor número de pessoas deveriam ver a senha.
  2. Neste sentido, a senha pode ser complicada e deverá ser gerada automaticamente pela classe e alterada automaticamente pela classe, preferencialmente.
  3. Na mesma linha de raciocínio, as informações deveriam ser incluídas pela classe, devidamente criptografada, como é o desejo inicial.

Assim, o próximo método a ser criado é o insereDB, cujo objetivo é inserir na base as informações que serão passadas pelo usuário da classe. Eis o cabeçalho de tal método:

public function insereBD($nomeBD, $usuarioBD, $senhaBD, $hostBD, $portaBD, $descricaoBD, $email_criadorBD) {

// corpo do método
}

Os primeiros cinco parâmetros são autoexplicativos. O parâmetro $descricaoDB é uma descrição sucinta da base de dados e o parâmetro $email_criadorBD identifica o e-mail do “dono” da base, que será usado, para contato automático, em oportunidades sensíveis à segurança. O código abaixo é o refinamento preliminar, que antecederia o tratamento dos dados entrantes e a inclusão na tabela:

class BancodeDados extends mysqli {
    
    static $idBancodeDados = 0;
    static $BancodeDadosAbertos = array();
    
    private $_cripto;
    
    private $_caracteres;
    private $_maximo;
    private $_passwd;
    private $_nome; 
    private $_usuario;
    private $_senha;
    private $_host;
    private $_porta;
    private $_descricao;
    private $_email_criador;
    private $_senha_alternativa;
    private $_senha_alternativaBD;
    
    private $_bd;
    
    /**
     * Construtor:
     * 
     * 1. Verifica se o banco de dados já existe
     * 2. Se não existir cria, sem popular
     * 3. Se existir, abre
     * 4. {@usa: throw new DBConnectException($this->connect_error, $this->connect_errno);}
     *    para cobrir exceções
     * 
    */
    
    public function __construct() {
        self::$idBancodeDados++; 
                       
    }
    
    /**
        *   @author      JB 
        *   @version     1.0 (última revisão: Janeiro 18, 2012)
        *   @copyright   (c) 2005 - 2012 Julião Braga
        *   @license     No licence
        *   @package     funcoesgerais.phpn
        *   @nome        criaDB($nomeBD) 
        *   @funcao      Cria dados criptografados na tabela `basesdedados` da base faleok
        * 
        *   @Colunas:
        *       id_bd: INT
        *       nome_bd: VARCHAR
        *       usuario_bd: VARCHAR
        *       senha_bd: VARCHAR
        *       host_bd: VARCHAR
        *       porta_bd: VARCHAR
        *       descricao_bd: VARCHAR
        *       email_criador_bd: VARCHAR
        *       senha_alternativa: VARCHAR
        * 
    */
    public function insereBD($nomeBD, 
                             $usuarioBD, 
                             $senhaBD, 
                             $hostBD, 
                             $portaBD, 
                             $descricaoBD, 
                             $email_criadorBD) {
        
        $this->_cripto        = new cripto; 
        
        $this->_caracteres = 'abcdxywzABCDZYWZ0123456789@#*'; 

        $this->_maximo = strlen($this->_caracteres)-1;  
        $this->passwd = null; 
        mt_srand(make_seed()); 
        for($i=0; $i passwd .= $this->_caracteres{mt_rand(0, $this->_maximo)}; 
        }
        $this->_senha_alternativaBD = $this->passwd;
        
        $this->_nome          = $this->_cripto->encrypt($nomeBD); 
        $this->_usuario       = $this->_cripto->encrypt($usuarioBD);
        $this->_senha         = $this->_cripto->encrypt($senhaBD);
        //$this->_senha_alternativaBD = base_convert(mt_rand() , 10 , 16);
        $this->_host          = $this->_cripto->encrypt($hostBD);
        $this->_porta         = $this->_cripto->encrypt($portaBD);
        $this->_descricao     = $this->_cripto->encrypt($descricaoBD);
        $this->_email_criador = $this->_cripto->encrypt($email_criadorBD);
        $this->_senha_alternativa = $this->_cripto->encrypt($this->_senha_alternativaBD);
        
        // Tratamento dos dados
        
        echo "Aqui entra o código para imprimir o resultado apresentado na figura, logo abaixo";
            
        self::$BancodeDadosAbertos[self::$idBancodeDados] = $this->_cripto->decrypt($this->_nome);
        echo '
Indice do vetor de BancodeDadosAbertos: ' . self::$idBancodeDados . "...pre..."; print_r(self::$BancodeDadosAbertos); echo ".../pre..."; return true; } /** * * listaBDs() */ public function listaBDs() { return $bds; } public function __destruct() { --self::$idBancodeDados; //$this->_bd->close(); } } function make_seed() { list($usec, $sec) = explode(' ', microtime()); return (float) $sec + ((float) $usec * 100000); } <?php require_once ($_SERVER['DOCUMENT_ROOT'] . "faleok/includes/funcoesgerais.phpm"); $bd_faleok = new BancodeDados(); $nomeBD = "nomedoBD"; $usuarioBD = "usuarioautorizado"; $senhaBD = "teste"; $hostBD = "127.0.0.1"; $portaBD = "3306"; $descricaoBD = "BD de teste"; $email_criadorBD = 'usuario@exemplo.com.br'; echo '
Retorno do método; ' . $bd_faleok->insereBD($nomeBD, $usuarioBD, $senhaBD, $hostBD, $portaBD, $descricaoBD, $email_criadorBD); ?>

O resultado do programa acima pode ser visto na figura abaixo:


 

Os comentários são os seguintes:

  1. Uma outra propriedade estática foi incluída motivada pelo interesse em saber, para efeitos de gerenciamento e eficiência, quais as bases estão abertas em um determinado instante. É um “array” e sua atribuição é feita dentro do método insereBD:
    static $BancodeDadosAbertos = array();
    

    Já é possível antever um método listaDB, lembrado no códito, que informaria quais as bases abertas até o momento.

  2. Insistentemente, declaramos propriedades. Sempre que possível escondendo informações para outros componentes (encapsulamento), através do uso de private.
  3. A senha alternativa, isto é, aquela desconhecida de todos é gerada aleatoriamente, e com 15 caracteres, já que o ser humano não a manipula. Os algoritmos para isto estão disponíveis na Internet. Para aumentar a dificuldade, além dos 15 caracteres foi seguida a sugestão de usar um “alimentador” (‘make_seed’), para a função ‘mt_rand’, disponível no sítio do PHP. A função ‘make_seed’ está isolada no programa principal para, oportunamente, definir seu destino.

%d blogueiros gostam disto: