Professional Documents
Culture Documents
Padres de Interoperabilidade de
Governo Eletrnico
Guia de Interoperabilidade
Cartilha Tcnica
Verso 2015
Este documento parte integrante do Guia de Interoperabilidade do Governo Brasileiro, que compreende a
Cartilha Tcnica de Interoperabilidade e o Manual de Gesto de Interoperabilidade. Este documento foi
elaborado pelo Ministrio do Planejamento, Oramento e Gesto com a consultoria da Agncia Espanhola
de Cooperao para o Desenvolvimento (AECID) e da Fundao Instituto para o Fortalecimento das
Capacidades Institucionais (IFCI).
Pgina 2 de 90
Esta obra est licenciada com uma Licena Creative Commons AtribuioNoComercial-CompartilhaIgual 4.0 Internacional.
http://creativecommons.org/licenses/by-nc-sa/4.0/
Presidente da Repblica
Dilma Rousseff
Ministrio do Planejamento, Oramento e Gesto
Miriam Belchior
Secretaria de Logstica e Tecnologia da Informao SLTI
Loreni F. Foresti
Departamento de Governo Eletrnico DGE
Andrea Thalhofer Ricciardi
Coordenao-Geral de Normas e Padres de Governo Eletrnico- CGPGE
Fernanda Hoffmann Lobato
ePING
Coordenador: Andrea Thalhofer Ricciardi
GT 1: Marcus Vincius Paizante
GT 2: Jorilson da Silva Rodrigues
GT 3: Paulo Maia da Costa
GT 4: Carlos Eduardo Arajo Vieira
GT 5: Marcus Vincius da Costa
Equipe de Elaborao
Pgina 3 de 90
SUMRIO
1 INTRODUO.............................................................................................................................................. 5
1.1.Assuntos no contemplados.................................................................................................................. 5
2.FUNDAMENTOS DE INTEROPERABILIDADE............................................................................................. 7
2.1.Introduo.............................................................................................................................................. 7
2.2.Dimenses da Interoperabilidade.......................................................................................................... 7
2.3.Interoperabilidade e Conformidade........................................................................................................ 9
3.Especificao Tcnica dos Componentes da ePING...................................................................................11
3.1.Segmentao....................................................................................................................................... 11
3.1.1.Interconexo Segmento 1.......................................................................................................... 15
3.1.1.1 Especificaes para Aplicao...........................................................................................15
3.1.1.2 Especificaes para Rede/Transporte................................................................................20
3.1.1.3 Especificaes para Enlace/Fsico.....................................................................................21
3.1.2.Segurana Segmento 2............................................................................................................. 25
3.1.2.1 Especificaes para Comunicao de dados.....................................................................25
3.1.2.2 Especificaes para Correio Eletrnico..............................................................................27
3.1.2.3 Especificaes para Criptografia........................................................................................ 28
3.1.2.4 Especificaes para Desenvolvimento de Sistemas...........................................................30
3.1.2.5 Especificaes para Servios de Rede..............................................................................31
3.1.2.6 Especificaes para Redes Sem Fio..................................................................................31
3.1.2.7 Especificaes para Resposta a Incidentes de Segurana da Informao........................32
3.1.3.Meios de Acesso Segmento 3................................................................................................... 33
3.1.3.1 Especificaes para Meios de Publicao..........................................................................33
3.1.3.2 Especificaes para TV Digital...........................................................................................37
3.1.4.Organizao e Intercmbio de Informaes Segmento 4..........................................................39
3.1.4.1 Especificaes para Tratamento e Transferncia de Dados..............................................39
3.1.4.2 Especificaes para Vocabulrios e Ontologias.................................................................52
3.1.5.reas de Integrao para Governo Eletrnico Segmento 5.......................................................61
3.1.5.1 Especificaes para Temas Transversais s reas de Atuao de Governo.....................61
3.1.5.2 Especificaes para Web Services.....................................................................................69
4.Ferramentas de apoio interoperabilidade.................................................................................................81
4.1.Catlogo de Interoperabilidade............................................................................................................ 81
4.2.Padro de Metadados para o Governo Eletrnico (ePMG).................................................................82
4.3.Vocabulrio Controlado de Governo Eletrnico (VCGE).....................................................................85
Pgina 4 de 90
1 INTRODUO
A Secretaria de Logstica e Tecnologia da Informao SLTI do Ministrio do Planejamento, Oramento e
Gesto tem, entre suas atribuies, a competncia de planejar, coordenar, supervisionar e orientar,
normativamente, as atividades do Sistema de Administrao de Recursos de Tecnologia da Informao
SISP, propondo polticas e diretrizes de Tecnologia da Informao, no mbito da Administrao Pblica
Federal direta, autrquica e fundacional.
A Arquitetura ePING Padres de Interoperabilidade de Governo Eletrnico define um conjunto de
premissas, polticas e especificaes tcnicas que regulamentam sua utilizao, com o objetivo maior de
possibilitar um nvel adequado de interoperabilidade entre os servios disponibilizados pelo governo
eletrnico, tornando-se o marco referencial para as atividades de TIC (Tecnologia da Informao e
Comunicao) no Governo. A SLTI a responsvel pela institucionalizao e pela definio do formato
jurdico da Coordenao da ePING.
O Guia de Interoperabilidade do Governo apresenta orientaes para o desenvolvimento de solues
de TIC aderentes Arquitetura ePING como forma de incentivar a interoperabilidade no Governo Federal e
deste com os demais entes da Federao. Ele organizado em dois volumes: o Manual do Gestor de
Interoperabilidade e a Cartilha Tcnica de Interoperabilidade.
O Manual do Gestor de Interoperabilidade tem como pblico-alvo os gestores de TI (Tecnologia da
Informao) dos rgos do Governo. Esse documento possui diretrizes de gesto, assim como indicaes
de aes promovidas em nosso pas com o objetivo de propiciar uma gesto de servios governamentais
direcionada interoperabilidade.
A Cartilha Tcnica de Interoperabilidade, por sua vez, tem como pblico-alvo os profissionais
tcnicos que atuam na rea de TI. A Cartilha Tcnica apresenta os requisitos tcnicos e indica melhores
usos de tecnologias de mercado, que proporcionam a melhoria da interoperabilidade governamental, sua
melhor qualidade e abrangncia.
1.1.
Assuntos no contemplados
Pgina 5 de 90
importante salientar, tambm, que este documento discorrer somente sobre o uso dos padres
publicados na ePING como Adotado (A) e Recomendado (R). Isso porque os demais padres ou esto em
processo de substituio (T Em Transio) ou sero tratados em futuras verses deste documento (E
Em Estudo).
Pgina 6 de 90
2. FUNDAMENTOS DE INTEROPERABILIDADE
2.1.
Introduo
2.2.
Dimenses da Interoperabilidade
Pgina 7 de 90
Pgina 8 de 90
importante, portanto, que as reas de Tecnologia busquem utilizar padres tecnolgicos comuns
para implementar a interoperabilidade. Alguns destes padres so encontrados na arquitetura ePING
Padres de Interoperabilidade de Governo Eletrnico.
2.3.
Interoperabilidade e Conformidade
O termo conformidade est associado ideia de qualidade e tem como objetivo avaliar a semelhana ou
correlao entre as coisas. Assim, quando se diz que um produto est em conformidade com um protocolo,
por exemplo, significa afirmar que esse produto prov um determinado nvel de semelhana aos padres
definidos no protocolo.
No que tange prtica de interoperabilidade no governo brasileiro, a conformidade de produtos e
solues tecnolgicas aos padres definidos na ePING condio sine qua non para se desenvolver as
polticas de e-Gov.
Logo, segundo a viso de conformidade da ePING, os padres tecnolgicos a serem aplicados no
governo passam por quatro nveis, a saber: Adotado (A), Recomendado (R), Em Transio (T) e Em Estudo
(E).
Um padro identificado como Adotado (A) na ePING implica em esforos prioritrios, por parte do
setor de TI dos rgos de governo, no sentido de atender recomendao. Esses padres foram, de fato,
homologados em um processo formal e aprovados pela Coordenao da ePING. Seu uso obrigatrio para
os rgos do Poder Executivo do governo brasileiro.
Um padro tido como Recomendado (R) caracteriza-se por atender s polticas tcnicas da ePING,
podendo ser utilizado no mbito das instituies de governo. Entretanto, ainda necessria a sua
homologao e aprovao formais. Geralmente, os padres identificados como Recomendados (R) so
oriundos de prticas de interoperabilidade bem sucedidas e de uso comum, mas que carecem da
formalizao por parte dos membros da ePING.
Os padres Em Transio (T) correspondem aos itens que o governo no recomenda, seja porque
no atendem aos requisitos estabelecidos nas polticas gerais e tcnicas da ePING, ou porque se
encontram em processo de substituio nas instituies de governo, tendendo descontinuao de seu uso
no futuro. possvel que um item Em Transio (T) passe a ser considerado Recomendado (R). Isso
porque as dificuldades em se estabelecer polticas viveis para sua substituio justificariam a sua
permanncia. Entretanto, a ePING recomenda enfaticamente evitar-se o uso dos padres Em Transio (T).
Por fim, os padres Em Estudo (E) so aqueles que ainda esto em avaliao por parte dos membros
da ePING e que, por isso, no podem ser classificados em outros nveis de conformidade.
Pgina 9 de 90
O Guia de Interoperabilidade de Governo, conforme relatado anteriormente, dar nfase aos padres
Adotado (A) e Recomendado (R), por razes bvias de concordncia com as polticas e interesses
pblicos do governo discutidos durante as reunies de trabalho da ePING.
Pgina 10 de 90
Segmentao
A arquitetura ePING foi segmentada em cinco partes, com a finalidade de organizar as definies dos
padres. Para cada um dos segmentos, foi criado um grupo de trabalho, composto por profissionais
atuantes em rgos dos governos federal, estadual e municipal, especialistas em cada assunto. Esses
grupos foram responsveis pela elaborao desta verso da arquitetura, base para o estabelecimento dos
padres de interoperabilidade do governo brasileiro.
Segurana Segmento 2: Trata dos aspectos de segurana de TIC que o governo federal deve
considerar.
A Tabela 1 descreve os padres no contexto de cada um dos segmentos mencionados, de modo a fazer
referncia aos componentes identificados como Adotados (A) e Recomendados (R) pelo governo brasileiro.
Inclui-se tambm nessa tabela a referncia s sees da ePING onde se podem localizar os padres
citados.
Pgina 11 de 90
1 Interconexo
2 Segurana
Componentes da ePING
Endereos de caixa postal eletrnica
Transporte de mensagem eletrnica
Acesso caixa postal
Mensageria em Tempo Real
AntiSpam Gerenciamento da Porta 25
Protocolo de transferncia de hipertexto
Protocolos de transferncia de arquivos
Diretrio
Sincronismo de tempo
Servios de Nomeao de Domnio
Protocolos de sinalizao
Protocolos de gerenciamento de rede
Transporte
Intercomunicao LAN/WAN
Comutao por Label
Qualidade de Servio
Rede local sem fio
Qualidade de Servio 802.1p
Virtual LAN
Resilincia Layer2
Transferncia de dados em redes inseguras
Algoritmos para troca de chaves de sesso,
durante o handshake
Algoritmos para definio de chave de cifrao
Certificado Digital
Hipertexto e transferncia de arquivos
Transferncia de arquivos
Segurana de redes IPv4
Segurana de redes IPv4 para protocolos de
aplicao
Segurana de redes IPv6 na camada de rede
Acesso a caixas postais
Contedo de e-mail
Transporte de e-mail
Identificao de e-mail
Assinatura
Transporte seguro de e-mail
Algoritmo de cifrao
Algoritmos para assinatura/hashing
Algoritmo para transporte de chave
criptogrfica de contedo/sesso
Algoritmos criptogrficos baseados em curvas
elpticas
Requisitos de segurana para mdulos
criptogrficos
Certificado Digital da AC-raiz para
Navegadores e Visualizadores de Arquivos
Assinaturas XML
Cifrao XML
Assinatura e cifrao XML
Principais gerenciamentos XML quando um
ambiente PKI utilizado
Autenticao e autorizao de acesso XML
Referncia na ePING
Tabela 1 Aplicao
Tabela 2 Rede/Transporte
Tabela 3 Enlace/Fsico
Tabela 4 Comunicao de
dados
Tabela 6 Criptografia
Tabela 7 Desenvolvimento
de Sistemas
Pgina 12 de 90
3 Meios de Acesso
4 Organizao e
Intercmbio de
informaes
Tabela 14 Tratamento e
transferncia de Dados
Tabela 15 Vocabulrios e
Ontologias
Pgina 13 de 90
Legislao, Jurisprudncia e
Proposies Legislativas
Integrao de Dados e Processos
Interoperabilidade entre sistemas
de informao geogrfica
Infraestrutura de registro
Linguagem de definio do servio
Protocolo para acesso a Web
Service
Pgina 14 de 90
3.1.1.
3.1.1.1
Interconexo Segmento 1
Especificaes para Aplicao
Tabela 2: Aplicao
Componente
Endereos de caixa postal eletrnica
Transporte de mensagem eletrnica
Acesso caixa postal
Mensageria em Tempo Real
AntiSpam Gerenciamento da Porta
25
Protocolo de transferncia de
hipertexto
Protocolos de transferncia de
arquivos
Diretrio
Especificao
Padro de Formao de Endereos de
Correio Eletrnico - Caixas Postais Individuais
Produtos que suportem interfaces em conformidade
com SMTP/MIME
Internet Message Access Protocol IMAP para acesso
remoto caixa postal
Programas de correio eletrnico em conformidade com
XMPP
Implementar submisso de e-mail via porta 587/TCP
com autenticao, reservando a porta 25/TCP apenas
para transporte entre servidores SMTP, conforme
recomendao CGI / Cert.br http://www.cert.br/
Situao
A
A
A
A
Utilizar HTTP/1.1
LDAP v3
RFC 5905 IETF Network Time Protocol NTP
Sincronismo de tempo
verso 4.0.
Servios de Nomeao de Domnio
DNS. RFC 1035
Protocolos de sinalizao
Protocolo de Inicializao de Sesso (SIP)
Protocolos de gerenciamento de rede SNMP v3
A
A
A
A
R
Os nomes das caixas postais de correio eletrnico devem seguir os padres estabelecidos no
documento Padro de Formao de Endereos de Correio Eletrnico, disponvel no endereo
http://www.eping.e.gov.br. Esse documento estabelece regras para a formao de nomes e composio de
endereos eletrnicos (e-mail) e tm como base de referncia, padres internacionais definidos pela ITU
(International Telecommunications Union).
O protocolo SMTP (Simple Mail Transfer Protocol) deve ser utilizado por servidores de correio
eletrnico e aplicativos de transferncia de mensageria para enviar e receber mensagens, enquanto que os
aplicativos diretamente acionados pelos usurios finais devem utilizar esse protocolo apenas para enviar as
mensagens ao servidor a que estejam diretamente conectados, que ento assume a tarefa de dar
prosseguimento ao trfego dessas mensagens, para que cheguem a seu destino final.
Para receber mensagens, os aplicativos de usurios finais devem usar o protocolo IMAP (Internet
Message Access Protocol), que apresenta inmeras vantagens quando comparado ao protocolo POP3
(Post Office Protocol V. 3), no momento declarado em desuso. Aqui vale lembrar que a ePING restringe a
utilizao de tecnologias proprietrias para acesso s caixas postais de um servidor de correio eletrnico,
embora no vede a utilizao de sistemas proprietrios para esse fim.
Pgina 15 de 90
Para mensagens instantneas, deve-se utilizar o protocolo XMPP (Extensible Messaging and Presence
Protocol), em substituio ao protocolo IMPP (Instant Messaging and Presence Protocol), hoje em
obsolescncia.
A regulamentao para a troca de mensagens curtas, SMS (Short Message Service), que contenham
no mais que 160 caracteres de competncia da ANATEL (Agncia Nacional de Telecomunicaes),
cabendo ePING fomentar servios governamentais prestados ao cidado utilizando essa tecnologia, hoje
amplamente suportada pelo mercado, e acessvel grande maioria da populao.
A gerncia de porta 25 o nome dado ao conjunto de polticas e tecnologias, implantadas em redes de
usurios finais ou de carter residencial, que procura separar as funcionalidades de submisso de
mensagens, daquelas de transporte de mensagens entre servidores.
A definio do padro para o protocolo de submisso de 1998, sendo sua ltima reviso de 2011, no
documento "RFC 6409: Message Submission for Mail". Este protocolo, chamado de "Message
Submission", fornece um meio para distinguir uma submisso do transporte de mensagens, permitindo
assim:
a aplicao de polticas diferentes para cada tipo de conexo, impedindo relays no autorizados ou
usurios autorizados;
A adoo do protocolo de Message Submission uma boa prtica reforada na RFC 5068 / BCP
134: Email Submission Operations: Access and Accountability Requirements e que tem sido
recomendada por diversos fruns de combate ao spam, cabendo destacar as seguintes recomendaes:
Managing Port 25 for Residential or Dynamic IP Space: Benefits of Adoption and Risks of Inaction
Em seu documento o MAAWG recomenda para redes de carter residencial, alm da adoo
de Message Submission, as seguintes medidas:
Pgina 16 de 90
bloquear acesso de sada para porta 25/TCP a partir de todas as mquinas que no sejam MTAs ou
explicitamente autorizadas.
No primeiro draft do SSL v3.0, a Netscape recomendava a utilizao da porta 465/TCP para submisso
de mensagens via SMTPS. O uso desta porta para submisso de mensagens nunca tornou-se um padro.
Atualmente,
comunidade
Internet
considera
seu
status
como
"deprecated",
porm,
alguns softwares clientes de e-mail e alguns servidores de submisso ainda utilizam esta porta.
A porta 465/TCP, segundo registro do IANA, est reservada para o uso do protocolo URD (URL
Rendesvous Directory for SSM). A lista de portas registradas junto ao IANA pode ser econtrada
em:http://www.iana.org/assignments/port-numbers.
Pgina 17 de 90
Pgina 18 de 90
aceito o protocolo FTP (File Transfer Protocol) desde que utilizado com esses recursos de reinicializao e
recuperao.
Para a pesquisa e atualizao de diretrios, a ePING determina a utilizao do protocolo LDAP
(Lightweight Directory Access Protocol), verso 3. O termo diretrio utilizado para definir uma estrutura
que permite o armazenamento sistemtico, para posterior localizao, de informaes sobre organizaes,
pessoas e outros recursos como arquivos e dispositivos em uma rede, seja na Internet pblica ou em uma
intranet corporativa.
Outro servio de rede a ser mencionado o que trata a intercomunicao, em tempo real, entre
computadores em todo o mundo, o que exige um mecanismo de sincronizao de relgios que leve em
conta os fusos horrios, e que possa compensar e corrigir erros de marcao de tempo. Para tanto, foi
criado ainda em 1985 o protocolo NTP (Network Time Protocol). Hoje em sua verso 4, o NTP pode garantir
uma preciso entre relgios da ordem de 10 milissegundos (1/100 s) na rede pblica Internet, podendo
chegar a 200 microssegundos (1/5000 s) em redes locais. Quando uma preciso dessa ordem no se faz
necessria, pode-se utilizar a verso simplificada desse protocolo conhecida com SNTP (Simple Network
Time Protocol), de mais fcil administrao. Os padres NTP v3.0 e SNTP v4.0 so ambos recomendados
pela ePING.
Quanto aos servios de nomeao de domnio, deve-se seguir a RFC 1035, que descreve os detalhes
do sistema de domnio e o respectivo protocolo.
O CGI (Comit Gestor da Internet no Brasil) o responsvel por coordenar e integrar todas as
iniciativas de servios de Internet no pas. No contexto de governo, o CGI definiu o uso das extenses .gov
e .mil para identificar os stios governamentais e militares, respectivamente. Alm disso, ele regulamentou
tambm os procedimentos de registro de domnio sob a raiz .gov.br que, alm de serem isentos do
pagamento de taxas, devem possuir autorizao formal do Ministrio do Planejamento, Oramento e Gesto
para a sua criao (CGI, 2008).
No caso de servios de conferncias multimdia envolvendo muitos participantes, necessrio que se
possa sinalizar o estabelecimento, mudana ou trmino da sesso de maneira independente do tipo de
mdia em utilizao, tais como texto, udio ou vdeo. Alm disso, preciso que seja possvel adicionar ou
remover participantes dinamicamente numa sesso multicast. O SIP (Session Initiation Protocol) foi
desenvolvido e publicado pela IETF (Internet Engineering Task Force) em meados da dcada de 1990 para
atender essas necessidades, em chamadas e conferncias atravs de redes e via protocolo IP. A ePING
determina a adoo do SIP como o protocolo de sinalizao a ser utilizado nesses casos.
importante lembrar tambm que uma rede de computadores precisa ser permanentemente
monitorada para a deteco e correo de problemas que possam dificultar, ou mesmo impossibilitar, a
comunicao entre os vrios pontos que a integram. Com a grande diversidade e heterogeneidade de
elementos de hardware e software hoje encontrados, o estabelecimento de um protocolo padro a ser
Guia de Interoperabilidade: Cartilha Tcnica
Pgina 19 de 90
seguido pelos programas de gerenciamento de redes essencial para a eficincia e eficcia desse
monitoramento. O SNMP (Simple Network Management Protocol) possibilita o intercmbio de informao
entre os diversos dispositivos de rede, como placas e comutadores, permitindo assim aos administradores
gerenciar o desempenho da rede, encontrar e resolver seus eventuais problemas, e ainda coletar dados em
tempo real que possam ser teis no planejamento de sua expanso. A ePING recomenda a utilizao da
verso 3 desse protocolo.
3.1.1.2
Tabela 3: Rede/Transporte
Componente
Transporte
Intercomunicao LAN/WAN
Comutao por Label
Qualidade de Servio
Situao
Especificao
TCP e UDP
IPv6
MPLS (pelo menos quatro classes de servio)
DiffServ
A
A
A
A
O TCP (Transmission Control Protocol) e o IP (Internet Protocol) formam o ncleo de uma sute de
protocolos conhecida como TCP/IP. Enquanto o TCP normatiza o servio de troca confivel de dados entre
dois servidores, o IP trata do endereamento e roteamento de mensagens atravs de uma ou mais redes de
comunicao de dados. Com o advento da Internet, que deles faz uso em larga escala, esses protocolos
passaram a fazer parte da rotina dos profissionais e dos setores responsveis pela infraestrutura de TIC.
Praticamente todos os protocolos e aplicativos da Web (pginas web, transferncia de arquivo, correio
eletrnico etc.) utilizam o TCP como mecanismo de transporte subjacente. Nos casos em que o aplicativo
no requeira um servio confivel de fluxo de dados, o protocolo UDP (User Datagram Protocol) pode ser
utilizado. O UDP fornece um servio de datagramas, enfatizando latncia sobre confiabilidade.
O IPv4 (Internet Protocol version 4) ainda hoje a verso mais utilizada da sute de protocolos IP,
embora a verso que a suceder, inicialmente chamada de SIPP (Simple Internet Protocol Plus) e agora
conhecida simplesmente como IPv6 (Internet Protocol version 6), venha ganhando aceitao crescente. A
principal diferena entre essas duas verses dizem respeito estrutura de endereamento utilizada:
endereos de 32 bits no caso do IPv4, e de 128 bits no caso do IPv6.
Devido ao esgotamento da oferta de endereos IPv4 pblicos, os rgos da APF devero planejar sua
futura migrao para IPv6. Novas contrataes e atualizaes de redes interopervies devero implementar
ambos os protocolos IPv4 e IPv6.
No caso de redes de telecomunicao onde se necessita de alto desempenho, a ePING determina o
uso do MPLS (Multiprotocol Label Switching), um mecanismo altamente eficiente e escalvel para
direcionamento e transporte de dados entre duas redes. O MPLS opera com o conceito de CoS (Class of
Service, ou Classe de Servio), utilizado para organizar o trfego de dados em filas de prioridade. A ePING
Pgina 20 de 90
requer que as implementaes do MPLS trabalhem com pelo menos quatro classes de servio. Por ltimo,
cabe ressaltar que a adoo do MPLS preclui a utilizao das tecnologias alternativas, como ATM
(Asynchronous Transfer Mode, ou Modo de Transferncia Assncrona) e Frame-Relay.
Nos casos em que no h a necessidade de implementao de MPLS (redes locais, por exemplo),
possvel obter Qualidade de Servio (QoS) com a implementao de DiffServ. Este protocolo permite um
melhor aproveitamento do uso das redes atravs da priorizao de pacotes, evitando casos em que uma
simples aplicao ou servio consuma o canal de comunicao e prejudique outros servios oferecidos por
aquela rede.
3.1.1.3
Tabela 4: Enlace/Fsico
Componente
Rede local sem fio
Qualidade de Servio 802.1p
Virtual LAN
Resilincia Layer2
Situao
Especificao
IEEE 802.11 g
IEEE 802.11 n
VLAN (IEEE 802.1Q)
Spanning tree protocol (802.1d,
802.1w, 802.1s)
A
R
R
R
R
As WLAN (Wireless Local Area Network, ou Redes Locais Sem Fio) devem seguir o conjunto de
padres conhecido como IEEE 802.11, na verso g, que normatizam a comunicao entre computadores
utilizando a frequncia de 2.4 GHz. O IEEE a sigla do Institute of Electrical and Electronic Engineers, uma
organizao internacional dedicada evoluo e aplicabilidade de tecnologias ligadas eletricidade de
maneira geral, e responsvel pela criao e manuteno de um grande nmero de padres tcnicos.
O padro IEEE 802.11n que foi criado pelo grupo TGn em 2003 teve sua aprovao no segundo
semestre de 2009 e recomendado pela ePING. As metas iniciais do padro eram aumentar as taxas de
transmisso ao nvel das redes locais e assegurar a compatibilidade do novo padro com os padres
antigos. O 802.11n tem como principal caracterstica o uso de um esquema chamado Multiple-Input
Multiple-Output (MIMO), capaz de aumentar consideravelmente as taxas de transferncia de dados por
meio da combinao de vrias vias de transmisso (antenas). Com isso, possvel, por exemplo, usar dois,
trs ou quatro emissores e receptores para o funcionamento da rede.
Para ser aprovado o padro IEEE 802.11n, o TGn definiu modos de operaes para promover
compatibilidade com os padres 802.11 anteriores. Foram divididos em trs modos de operaes: HT, NonHT e HT Mixed Mode.
- Um AP 802.11n usando o modo High Throughput (HT) - tambm conhecido como modo de Greenfield
assume que no existem estaes legadas prximas usando a mesma faixa de frequncia. Se estaes
legadas no existem, elas no podem se comunicar com o AP 802.11n. Modo de HT opcional.
Pgina 21 de 90
- Non-HT (Legacy) Mode - um AP 802.11n usando o modo no-HT envia todos os quadros utilizando o
antigo formato dos padres 802.11a / g para que as estaes legadas possam entend-las. Todos os
produtos tm de suportar este modo a garantir compatibilidade com verses anteriores. Mas usar um AP
802.11n Non-HT no oferece nenhuma melhora de performance com relao 802.11a / g.
O HT mixed mode obrigatrio e ser o mais comum de funcionamento em APs 802.11n. Nesse
modo, melhorias HT podem ser utilizadas simultaneamente com os mecanismos de proteo HT que
permitem comunicao com estaes legadas. HT modo misto fornece compatibilidade com verses
anteriores, mas o padro 802.11n tem perdas significativas na taxa de transferncia em relao ao modo de
Greenfield.
A utilizao das tecnologias IEEE 802.11g e IEEE 802.11n devem tambm seguir as determinaes do
Wi-Fi Alliance, uma associao entre fabricantes de equipamentos de WLANs para certificao de produtos
que atendam um conjunto de requisitos de interoperabilidade definidos por essa associao. Sempre que
aplicveis, as normas da ANATEL e da ANEEL (Agncia Nacional de Energia Eltrica) tambm devem ser
respeitadas.
O protocolo IEEE 802.1p uma tcnica para priorizao de trfego em redes locais, sendo
especificado na norma IEEE 802.1D LAN Bridges. Atravs dessa tcnica, possvel utilizar aplicaes
sensveis a tempo em redes locais (LANs).
A norma IEEE 802.1D inclui as extenses 802.1p e 802.1Q, adicionando 4 bytes ao formato do
cabealho MAC das redes Ethernet e Token Ring. A extenso 802.1Q utiliza dois bytes desse espao,
sendo que 12 bits so reservados para identificao de VLAN (Virtual LAN) e 3 bits so definidos pela
norma IEEE 802.1p a fim de determinar a prioridade no nvel 2 do modelo OSI, conforme mostra a figura a
seguir.
802.1p e 802.1Q
Pgina 22 de 90
Os 3 bits da norma IEEE 802.1p definem 8 classes de trfego, como mostra a tabela a seguir.
Prioridade
Nome
Caractersticas e exemplos
Controle da rede
Voz interativa
Multimdia interativa
Carga controlada
Esforo excelente
Melhor esforo
Melhor esforo
Default
Default
Background
Um padro IEEE para provimento de capacidade de LAN virtual em uma rede, usada em conjunto com
protocolos de LAN do IEEE, como Ethernet e Token Ring.
A utilizao de VLAN (Virtual Local Area Network) permite que uma rede fsica seja dividida em vrias
redes lgicas dentro de um Switch. A partir da utilizao de VLANs, uma estao no capaz de
comunicar-se com estaes que no pertencem a mesma VLAN (para isto, necessrio a utilizao de uma
sub-rede por VLAN e que o trfego passe primeiro por um roteador para chegar a outra rede.
A marcao efetuada (chamada de TAG) adiciona aos quadros Ethernet 4 bytes no frame original e
calculam um novo valor de checagem de erro para o campo FCS.
Pgina 23 de 90
Desse modo, surgiram alguns protocolos com o objetivo de garantir a resilincia na camada 2, alm
de otimizar a comunicao e os tempos de convergncia quando da ocorrncia de falhas:
802.11d
Para prevenir os congestionamentos broadcast e outros efeitos colaterais indesejados das ligaes em
loop, a empresa Digital Equipment Corporation criou o protocolo spanning tree (STP), que foi padronizado
como a especificao 802.1d pelo IEEE - Institute of Electrical and Electronic Engineers. O protocolo
spanning tree utiliza um algoritmo spanning tree (STA), que percebe que o switch tem mais de uma maneira
de se comunicar com um n de destino. Este protocolo determina o melhor caminho e bloqueia os outros
(que ficam como caminho alternativo para o caso de falha no caminho principal), de modo a evitar looping.
802.11w
Em 2001 foi desenvolvido o Rapid Spanning Tree Protocol (RSTP), norma 802.1w, com a finalidade de
acelerar o processo de alterao da rvore de suporte quando h alterao da topologia da rede, de modo
que este processo de convergncia possa acontecer num tempo muito mais curto, na casa dos
milissegundos.
802.11s
O IEEE 802.1s Multiple Spanning Tree Protocol (MSTP), proposto em 2002, uma evoluo do IEEE
802.1d Spanning Tree Protocol (STP). Com o crescente nmero de problemas associados ao aparecimento
constante de esquemas mais complexos para as redes baseadas na camada 2 do modelo de OSI (Open
Systems Interconnection), especialmente referentes redundncia e ao balanceamento de carga, foi
desenvolvido o MSTP, tendo sempre em vista obter o menor impacto possvel em termos de desempenho.
Este novo protocolo veio trazer vrias vantagens, fazendo uso de vrios aspectos de outros protocolos
como o Rapid Spanning Tree Protocol (RSTP) e Per-Vlan Spanning Tree (PVST).
Um exemplo representativo da utilizao das diretrizes e recomendaes da ePING para componentes
de infraestrutura de rede pode ser encontrado no processo de aquisio de comutadores (switches) pelo
Ministrio do Planejamento, Oramento e Gesto, conduzido no stio do Comprasnet, com a publicao de
trs especificaes de referncia para diferentes famlias de dispositivos de comutao (COMPRASNET,
2010).
Pgina 24 de 90
3.1.2.
Segurana Segmento 2
A ePING estabelece que os dados, informaes e sistemas de informao do governo devem ser protegidos
contra ameaas de forma a reduzir riscos e garantir sua integridade, confidencialidade, disponibilidade e
autenticidade. Para tanto, indispensvel que os dados e informaes sejam mantidos com o mesmo nvel
de proteo, independentemente do meio em que estejam sendo processados e armazenados, ou pelos
quais estejam trafegando. Assim, as informaes sensveis que trafegam em redes inseguras, incluindo as
redes sem fio, devem ser criptografadas de modo adequado, conforme os componentes de segurana por
ela especificados.
A poltica de segurana da ePING enfatiza a necessidade de que essa questo seja tratada de forma
preventiva e global. Por ser preventiva, a segurana requer a elaborao de planos de continuidade para
sistemas que apoiam processos crticos, de forma a garantir nveis mnimos de produo. Por ser global, a
segurana deve ser considerada em todas as etapas do ciclo de desenvolvimento de um sistema.
3.1.2.1
Especificao
TLS. Caso seja necessrio, o protocolo TLS
v1 pode emular o SSL v3.
RSA, Diffie-Hellman RSA, Diffie-Hellman
DSS, DHE_DSS, DHE_RSA
Situao
R
R
R
R
R
S/MIME v3
Pgina 25 de 90
A autenticao busca garantir que um agente envolvido em uma interlocuo ou troca de mensagens
de fato quem ele diz ser. A cifrao, com o emprego de algoritmos matemticos e parmetros de controle
chamados de chaves criptogrficas, busca tornar a mensagem incompreensvel e intil para todos os
efeitos, enquanto no for submetida ao processo inverso de decifrao. So dois os mecanismos bsicos
de cifrao/decifrao hoje em utilizao: (i) criptografia simtrica (ou de chave secreta), e (ii) criptografia
assimtrica (ou de chave pblica). Os algoritmos simtricos utilizam uma mesma chave tanto na cifrao
como na decifrao, enquanto os algoritmos assimtricos utilizam chaves distintas em cada processo.
O esforo mais bem sucedido de construo de um protocolo criptogrfico para a Internet foi o SSL
(Secure Socket Layer) ou Protocolo Seguro da Camada de Socket, que utiliza PKI (Public Key
Infrastructure) ou ICP (Infraestrutura de Chaves Pblicas), um mtodo assimtrico que emprega pares de
chaves (uma pblica, de acesso universal, e outra privada, de conhecimento exclusivo de seu proprietrio)
para garantir que (i) apenas o destinatrio poder conhecer o contedo da mensagem, e (ii) o destinatrio
estar seguro de que a mensagem originou-se do emitente declarado.
Com as modificaes introduzidas na verso 3.1, o SSL passou a ser chamado de TLS (Transport
Layer Security) ou Segurana da Camada de Transporte. A ePING recomenda a utilizao do TLS v1 com
todos os protocolos de transporte subjacentes que se baseiam no protocolo TCP, tais como HTTP, LDAP,
IMAP, POP3 e Telnet. Uma vantagem do TLS v1, destacada na ePING, sua capacidade de emular o SSL
v3, til em situaes que requeiram esse nvel de compatibilidade.
Quanto aos certificados digitais, a ePING recomenda o padro X.509 v3, um padro internacional para
a Infraestrutura de Chaves Pblicas que garante uma autenticao forte (em outras palavras, uma
vinculao segura entre um certificado, seu emitente e seu destinatrio). Esses certificados devem ser
emitidos por entidades pertencentes rede de entidades certificadoras conhecida como ICP-Brasil.
Quanto aos mecanismos internos inerentes utilizao do TLS v1, a ePING recomenda mltiplas
alternativas de algoritmos, para cada caso: RSA, Diffie-Hellman RSA, Diffie-Hellman DSS, DHE_DSS e
DHE_RSA (definio de chaves de cifrao), RC4, IDEA, 3DES e AES (troca de chaves durante o handshake de uma sesso), SHA-256 ou SHA-512 (implementao de funes de hash).
Para a complementao dos servios oferecidos pelo TLS v1, a ePING recomenda a utilizao do
SASL (Simple Authentication and Security Layer). O SASL possibilita o desacoplamento entre mecanismos
de autenticao e protocolos de aplicao, e tambm viabiliza um procedimento conhecido com proxy
authorization (um usurio assume a identidade de outro, em um contexto de alta confiabilidade).
Pgina 26 de 90
A ePING especifica que a segurana de redes IPv4 e IPv6 em suas mltiplas camadas deve ser
implementada com os seguintes componentes:
IPSec Authentication Header autenticao de cabealhos IP;
IKE (Internet Key Exchange) negociao entre duas entidades para a troca de material de
chaveamento;
ESP (Encapsulating Security Payload) implementao de redes privadas virtuais (VPNs) e
autenticao e segurana de encapsulamento de pacotes IP;
S/MIME (Secure/Multipurpose Internet Mail Extensions) cifrao genrica de mensagens
MIME com criptografia de chave pblica;
AH (Authenticaton Header) autenticao de cabealho com o protocolo Ipv6.
3.1.2.2
Especificao
Cliente especfico com mecanismos de segurana nativos ou
HTTPS
S/MIME v3
SPF
DKIM
Padro ICP-Brasil
SMTP seguro sobre TLS
Situao
A
A
A
R
A
R
A ePING especifica que o acesso seguro a caixas postais eletrnicas pode ser feito atravs de dois
mecanismos, considerados individualmente ou combinados: (i) utilizao de aplicativos-cliente especficos
que disponham de mecanismos de segurana nativos, e (ii) utilizao do protocolo HTTPS (HyperText
Transfer Protocol Secure). Esse protocolo permite a criao de um canal seguro na Internet pela
combinao dos protocolos HTTP e SSL/TLS, esse ltimo descrito na seo 3.4.1.
As mensagens de correio eletrnico seguro devem ser protegidas atravs do padro S/MIME v3. Esse
padro disponibiliza os seguintes servios de segurana criptogrfica: (i) autenticao, (ii) integridade de
contedo (iii) privacidade e (iv) no-repdio da origem declarada. Esse ltimo e importante servio garante
que o autor de uma mensagem assim protegida no conseguir contestar com sucesso a alegada origem
dessa mensagem, no podendo assim repudiar sua validade.
Para evitar a falsificao da origem de mensagens de correio eletrnico, a ePING recomenda que o
transporte dessas mensagens utilize o sistema de validao conhecido como SPF (Sender Policy
Framework). O objetivo do SPF impedir que domnios da internet enviem mensagens personificando
outros domnios sem a devida autorizao, bloqueando assim uma prtica com enorme potencial para
fraudes.
Pgina 27 de 90
Tabela 7: Criptografia
Componente
Algoritmo de cifrao
Algoritmo para assinatura/hashing
Algoritmo para transporte de chave criptogrfica
de contedo/sesso
Algoritmos criptogrficos baseados em curvas
elpticas
Requisitos de segurana para mdulos
criptogrficos
Certificado Digital da AC-raiz para Navegadores
e Visualizadores de Arquivos
Especificao
3DES ou AES
SHA-256 ou SHA-512
Situao
RSA
R
R
A
R
R
Pgina 28 de 90
mensagem original. As propriedades consideradas essenciais para esse tipo de procedimento so: (i)
facilidade de computao do digest para mensagens de qualquer natureza, (ii) impossibilidade prtica de
obteno de uma mensagem a partir de um digest, (iii) impossibilidade prtica de modificao de uma
mensagem com a manuteno do mesmo digest e (iv) impossibilidade prtica de obteno de duas
mensagens distintas com o mesmo digest.
O SHA-2 (Secure Hash Algorithm, version 2) uma famlia de funes hash desenvolvidas pela
agncia do governo norte-americano NSA (National Security Agency), com quatro variantes: SHA-224,
SHA-256, SHA-384 e SHA-512 (que produzem digests de 224, 256, 384 e 512 bits, respectivamente).
Enquanto todas essas variantes atendem as propriedades arroladas no pargrafo anterior, a ePING
recomenda a utilizao das variantes hoje mais usadas, SHA-256 e SHA-512.
Sistemas de criptografia simtricos, tais como 3DES e AES, so muito mais rpidos do que os
assimtricos. Na prtica, as mensagens so criptadas com um algoritmo simtrico, e as chaves utilizadas,
em geral muito mais curtas do que as mensagens, so criptadas com um algoritmo assimtrico, tornando
seguro o transporte das chaves entre os interlocutores. A ePING determina a utilizao do algoritmo RSA
(sigla construda a partir dos sobrenomes de seus inventores, Ronald Rivest, Adi Shamir e Leonard
Adleman) como mecanismo criptogrfico de chaves.
Publicado em 1978, o RSA at hoje o mais bem sucedido mecanismo de criptografia assimtrica, e
a base para a Infraestrutura de Chaves Pblicas. O RSA utiliza pares de chaves de comprimento varivel, e
quanto maior esse comprimento, maior a segurana proporcionada. Com o aumento de poder dos recursos
computacionais disponveis, e concomitante queda nos custos envolvidos, chaves cada vez maiores so
necessrias para o mesmo nvel de segurana. Hoje, o RSA tipicamente utilizado com chaves de
comprimento entre 1024 e 2048 bits, enquanto comprimentos inferiores a 512 bits j so considerados
inseguros.
Em muitas situaes, necessrio que a mesma segurana propiciada por algoritmos como RSA seja
obtido com a utilizao de nmeros bem menores. Para essas situaes, a ePING especifica que: (i) para
assinaturas digitais, deve-se utilizar o ECDSA (Elliptic Curve Digital Signature Algorithm, ou Algoritmo de
Assinatura Digital de Curvas Elpticas), nas variantes ECDSA 256 e ECDSA 512, e (ii) para cifrao e
transporte seguro de chaves criptogrficas, deve-se utilizar o ECIES (Elliptic Curve Integrated Encryption
Scheme, ou Esquema Integrado de Criptao com Curvas Elpticas), nas variantes ECIES 256 e ECIES
512.
O ECDSA uma modificao do algoritmo DSA (Digital Signature Algorithm, ou Algoritmo de
Assinatura Digital), enquanto o ECIES uma variante do IES (Integrated Encryption Scheme, ou Esquema
Integrado de Criptao). Tanto o ECDSA quanto o ECIES notabilizam-se por serem implementaes da
famlia ECC (Elliptic Curve Cryptography, ou Criptografia de Curvas Elpticas), uma rea da criptografia que
hoje desfruta de intenso interesse acadmico e comercial.
Pgina 29 de 90
A ePING recomenda que os mdulos criptogrficos utilizados, tais como equipamentos e sistemas de
certificao digital, atendam os Nveis de Segurana de Homologao 2 e 3 (NSH-2 e NSH-3) da ICP-Brasil
(ICP-BRASIL, 2009), ou os requisitos de segurana para mdulos criptogrficos publicados pelo National
Institute of Standards and Technology (NIST, 2001).
3.1.2.4
Situao
Especificao
XMLsig
A
XMLenc
R
Transformao de decifrao para
R
assinatura XML
XKMS 2.0
R
SAML
R
WS-Security 1.1
R
WS-Trust 1.4
Cookies apenas com a
A
concordncia do usurio
Pgina 30 de 90
3.1.2.5
Especificao
LDAP v3 e extenso para TLS
Prticas de Segurana para Administradores de Redes Internet
TSP e TSAs
Normas da ICP-Brasil
Carimbo de tempo
Situao
R
A
R
A ePING recomenda que a segurana de diretrios seja implementada com a extenso para TLS do
LDAP v3. Para a transferncia segura de arquivos, a ePING recomenda o protocolo HTTPS, que permite a
criao de um canal seguro na internet pela combinao dos protocolos HTTP e SSL/TLS.
Para a resoluo segura de endereos na internet, a ePING determina aos administradores
implementar o padro DNSSEC (DNS Secure Extensions, ou Extenses de Segurana do DNS), uma
extenso do DNS (Domain Name System, ou Sistema de Nomes de Domnios) que reduz o risco de
manipulao de dados e de utilizao de domnios forjados.
O protocolo TSP (Time-Stamp Protocol, ou Protocolo de Carimbo de Tempo) deve ser utilizado sempre
que houver a necessidade de se garantir que um artefato eletrnico existia antes de, ou em um momento
particular de tempo. Esses carimbos de tempo usam certificados X.509 e a Infraestrutura de Chaves
Pblicas, e devem ser emitidos por TSAs (Time-Stamping Authorities, ou Autoridades Emissoras de
Carimbo de Tempo), segundo procedimentos definidos pelo IETF, responsvel pela manuteno desses
dois padres. Alm disso, devem ser observadas as normas da ICP-Brasil sobre o assunto (ICP-BRASIL,
2008).
3.1.2.6
Especificao
WPA2
Situao
R
A ePING recomenda que a segurana de redes sem fio seja implementada com a utilizao do padro
WPA2 (Wi-Fi Protected Access, version 2), uma evoluo do padro anterior WPA. O WPA2 requer testes e
certificao pelos autores do padro, a Wi-Fi Alliance, antes que um dispositivo possa se declarar em
conformidade com ele.
Pgina 31 de 90
3.1.2.7
Especificao
Guidelines for Evidence Collection and Archiving
Expectations for Computer Security Incident Response
Norma Complementar N o. 05/09
Guide to Integrating Forensic Techniques into Incident
Response
Situao
R
A
A
Os administradores devem estar preparados a dar respostas adequadas aos incidentes de segurana
da informao que possam vir a ocorrer, quaisquer que sejam sua natureza ou origem. Para tanto, a ePING
recomenda que sejam seguidas as orientaes contidas em textos de referncia internacional sobre
preservao de registros (IETF, 2002) e informtica forense (NIST, 2006), bem como em Normas
Complementares especficas editadas pelo Gabinete de Segurana Institucional da Presidncia da
Repblica (PRESIDNCIA DA REPBLICA, 2010). Em particular, so destacadas duas linhas de atuao:
(i) criao de equipes especializadas no tratamento e resposta a incidentes, e (ii) organizao de uma
capacidade fornsica para a identificao, coleta, exame e anlise de dados, mantendo a integridade da
informao e a estrita cadeia de custdia desses dados.
Pgina 32 de 90
3.1.3.
3.1.3.1
Mobile
Especificao
UNICODE, verso 7.0 e UTF-8
HTML, verso 5
XML, verses 1.0 e ou 1.1
W3C Mobile Web application Best Practices
http://www.w3.org/TR/mwabp/
W3C Geolocation API Specification
http://www.w3.org/TR/mediaont-api-1.0/
W3C Mobile Web Application Best Practices
http://www.w3.org/TR/geolocation-API/
Texto puro (.txt)
Open Document (.odt)
ODF 1.2
EPUB 3.0.1
PDF
PDF verso aberta PDF/A
Open Document (.ods)
ODF 1.2
Open Document (.odp)
ODF 1.2
HTML (.htm ou .html)
XML, verses 1.0 ou 1.1 (.xml)
MySQL Database (.myd, .myi)
Texto puro (.txt)
Texto puro (.csv)
Arquivo do Base (.odb)
PNG (.png)
SVG (.svg)
JPEG File Interchange Format (.jpeg, .jpg ou
.jfif)
SVG (.svg)
SVG (.svg)
Ogg Vorbis (.ogg, .oga)
Ogg FLAC (.ogg, .oga)
FLAC (.flac)
Ogg Theora (.ogg, .ogv)
Matroska
ZIP (.zip)
GNU ZIP (.gz)
Pacote TAR (.tar)
Pacote TAR compactado (.tgz ou .tar.gz)
BZIP2 (.bz2)
Pacote TAR compactado com BZIP2
(.tar.bz2)
Situao
R
A
A
R
R
R
A
A
R
R
R
R
A
R
A
R
R
R
R
A
A
R
A
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
Pgina 33 de 90
Informaes georreferenciadas
A
A
A
Pgina 34 de 90
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
ou
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-16">
Para codificao de arquivos XML:
<?xml version="1.0" encoding="ISO-8859-1"?>
ou
<?xml version="1.0" encoding="UTF-8"?>
ou
<?xml version="1.0" encoding="UTF-16"?>
Recomenda-se verificar o tipo de codificao que melhor atenda aos requisitos da informao
que se deseja transmitir ou receber. Verifique a presena de acentuao e de caracteres
estrangeiros, pois esse requisito pode significar a necessidade de se utilizar um tipo de UNICODE
especfico.
3.1.3.1.2 Formato de Intercmbio de hipertexto
Outro aspecto relacionado interoperabilidade semntica em meios de publicao envolve a transferncia
de dados em formato de hipertexto. A ePING adota como padro o HTML (verso 5) e o XML (verses 1.0 e
1.1).
3.1.3.1.3 Especificaes para Mobilidade
A ePING entende como um grande desafio para o governo possibilitar sociedade o acesso aos
produtos e servios do governo eletrnico a partir de dispositivos mveis ou portteis. A crescente aceitao
desses dispositivos os torna canais privilegiados de comunicao com o cidado, permitindo que se
impulsione a incluso digital via mobilidade. Entre esses dispositivos destacam-se notebooks, smartphones
e, sobretudo, os telefones celulares.
O conceito fundamental que deve ser aplicado aos servios a serem disponibilizados por meio dos
dispositivos mveis o da web universal: a internet disponvel para todos, em qualquer lugar,
independentemente do dispositivo de acesso. Sob essa perspectiva, a ePING recomenda a aderncia s
melhores prticas de implementao da web mvel definidas pelo Consrcio World Wide Web (W3C, 2008).
Pgina 35 de 90
Pgina 36 de 90
3.1.3.2
Multiplexao
Receptores
Segurana
Middleware
Canal de
Interatividade
Guia de
Operao
Acessibilidade
Especificao
Norma ABNT NBR 15601
Parte 1 Sistema de transmisso
Norma ABNT NBR 15602
Parte 1 Codificao de Vdeo
Parte 2 Codificao de udio
Parte 3 Sistema de multiplexao de sinais
Norma ABNT NBR 15603
Parte 1 Servios de informao do sistema de radiodifuso
Parte 2 Sintaxes e definies da informao bsica de SI
Parte 3 Sintaxe e definio da informao estendida do SI
Norma ABNT NBR 15604
Parte 1 Receptores
Norma ABNT NBR 15605
Parte 1 Tpicos de segurana
Norma ABNT NBR 15606
Parte 1 Codificao de dados
Parte 2 Ginga-NCL para receptores fixos e mveis
Linguagem de aplicao XML para codificao de aplicaes
Parte 3 Especificao de transmisso de dados
Parte 5 Ginga-NCL para receptores portteis
Linguagem de aplicao XML para codificao de aplicaes
Parte 6 Java DTV 1.3
Parte 7 Ginga-NCL Diretrizes Operacionais para
as ABNT NBR15606-2 e 15606-5
Norma ABNT NBR 15607
Parte 1 Protocolos, interfaces fsicas e interfaces de software
Norma ABNT NBR 15608
Parte 1 Sistema de Transmisso Guia para implementao da ABNT
NBR 15601
Parte 2 Codificao de vdeo, udio e multiplexao Guia para
implementao da ABNT NBR 15602
Parte 3 Multiplexao e servio de informao (SI)
Guia de implementao da ABNT NBR 15603
ABNT NBR 15610
Parte 1 Ferramentas de texto
Parte 2 Funcionalidades sonoras
Situao
A
A
A
A
A
A
A
O SBTVD (Sistema Brasileiro de Televiso Digital), ora em implantao e com cobertura nacional
prevista para dezembro de 2016, alm de propiciar som e imagem digitais de superior qualidade tcnica,
permite ao usurio (ou telespectador) interagir com o aparelho de televiso atravs de seu controle remoto.
Isto traz televiso a possibilidade de torn-la meio de acesso a servios como compras, acesso a bancos
e opes diversas de recreao e lazer. Mais importante ainda, isso a transforma em canal de grande
potencial de relacionamento entre governo e sociedade. Atividades como tele-educao, consultas ao
FGTS, ao PIS e a outros programas sociais do governo, dentre outras, faro com que os cidados passem
de uma atividade essencialmente passiva para uma atividade participativa. A ePING adota, s
implementaes de interatividade para a TV digital, a aderncia s normas pertinentes publicadas pela
ABNT (Associao Brasileira de Normas Tcnicas), o rgo responsvel pela normalizao tcnica no pas.
Pgina 37 de 90
Pgina 38 de 90
3.1.4.
3.1.4.1
Especificao
XML
JSON
XSL
XSLT
XML Schema
Estruturao de Dados
Geoespaciais Vetoriais
(EDGV) como definido pela
CONCAR
Situao
A
A
A
R
Para a criao da informao que ser enviada a outro sistema ou unidade de processamento
computacional, a ePING adota, como formato padro, o XML. Para a verificao das regras de formao
dos dados, adota-se o padro XML Schema. Finalmente, para a transformao dos dados com o objetivo de
apresentao ao usurio final, adota-se o XLS.
3.1.4.1.1 Linguagem para Intercmbio de Dados (XML)
O uso de XML como linguagem para representao de dados uma pea fundamental no contexto da
interoperabilidade semntica, pois representa tanto os aspectos conceituais quanto tecnolgicos associados
a uma arquitetura de software que se preocupa em organizar a informao, ao mesmo tempo em que
promove o seu intercmbio. Entretanto, lidar com essa tecnologia no tarefa trivial. Pelo contrrio, exige
planejamento e estratgias de projeto elaboradas pela equipe de arquitetos, projetistas e desenvolvedores
de software.
Logo, recomendam-se os seguintes passos para o uso adequado de XML nas instituies pblicas:
Posicione a tecnologia XML no conjunto de componentes da arquitetura de software adotada.
Realize a etapa de modelagem dos arquivos XML.
Defina padres para nomear os elementos do arquivo XML.
Escolha a API correta (DOM, SAX ou Data Binding).
Quanto ao posicionamento da tecnologia XML a uma arquitetura de software definida, sugerem-se
quatro abordagens: (i) utilizar XML para o transporte de informaes dentro da prpria aplicao a ser
desenvolvida; (ii) utilizar XML para o transporte de informaes entre aplicaes; (iii) utilizar XML como
conversor de dados no contexto de uma aplicao; e (iv) utilizar XML como conversor de dados no contexto
de vrias aplicaes (ERL, 2004).
Pgina 39 de 90
Quando o XML utilizado para o transporte de informaes dentro da prpria aplicao a ser
desenvolvida, importante que se identifique as camadas da aplicao onde a informao ser originada e
onde a informao ser recepcionada. Com isso, verifica-se a consistncia do fluxo de dados dentro da
prpria aplicao e evita-se o excesso de trfego de informaes desnecessrias. A Figura 5 ilustra esse
uso do XML, considerando duas camadas de uma arquitetura MVC (Model-View-Controller).
Figura 6: XML utilizado para transportar dados com a tecnologia de Web Services.
Quando o XML utilizado como conversor de dados no contexto de uma aplicao, devem-se utilizar
ferramentas especficas para realizar a converso. A escolha do conversor mais adequado deve considerar
o uso de APIs (Application Programming Interfaces) especficas para o tratamento de arquivos no formato
XML (DOM, SAX ou Data Binding). A Figura 7 ilustra o processo de utilizao de XML como conversor de
dados no contexto de uma aplicao.
Pgina 40 de 90
Pgina 41 de 90
Pgina 42 de 90
Se a informao uma parte essencial (importante) para o negcio que se pretende comunicar,
represente-a como um elemento XML. Caso contrrio, se a informao for perifrica ou incidental,
puramente utilizada para auxiliar o processamento dos dados, represente-a como um atributo XML. Um
exemplo prtico o identificador ou ID. Caso este seja apenas um recurso utilizado para
apropriadamente processar a informao, represente-o como um atributo e no como um elemento XML.
Lembre-se que: Dados so representados como elementos e Metadados como atributos.
Se a informao pode sofrer alteraes em sua estrutura no futuro, represente-a como um elemento.
Caso contrrio, se a informao atmica, no podendo ser desmembrada em diversas estruturas no
futuro, considere represent-la como um atributo. Como exemplo, pode-se citar o nome de uma pessoa
representado como um atributo. Neste caso, alteraes futuras seriam afetadas se fosse necessrio
representar esse nome como sendo a composio de primeiro nome, nomes intermedirios e nome de
famlia.
Se a informao que se pretende transmitir ser lida por pessoas, represente-a como um elemento. Caso
contrrio, se a informao for processada unicamente por mquinas, utilize atributos.
Alm da modelagem dos arquivos XML, outra atividade importante a ser executada pelos profissionais
de TI a escolha da API a ser utilizada no processamento das informaes contidas no arquivo XML. As
opes atuais so: DOM (Document Object Model), SAX (Simple API for XML) e Data Binding.
DOM a interface de programao tradicional favorecida pelo W3C. Uma das caractersticas dessa
API e tambm a sua maior desvantagem que, ao se processar o arquivo XML, todo o seu contedo
carregado para a memria do computador. Isso permite o acesso completo em toda a rvore de elementos
do XML, mas ao custo de um grande consumo de memria, o que pode significar srios problemas de
desempenho e falta de memria quando do processamento de arquivos XML mais extensos.
Como forma de contornar os problemas causados pelo DOM, surgiu o SAX, uma alternativa mais leve
para o processamento de arquivos XML de qualquer tamanho. A API SAX teve origem em um grupo de
discusses chamado XML-DEV promovido pelo OASIS (Organization for the Advancement of Structured
Information Standards) com o objetivo de solucionar problemas de incompatibilidade entre os diferentes
parsers de XML existentes no mercado. Essa API alcanou uma rpida popularidade por ter sido
originalmente criada para atender comunidade de programadores Java. Entretanto, atualmente j existem
vrias implementaes dessa API em diversas linguagens de programao, incluindo verses open-source
e proprietrias.
importante salientar que a especificao e implementao da API SAX so mantidas atualmente por
um grupo de programadores independentes. A ideia da API SAX bem simples, se comparada com o DOM.
Enquanto o DOM monta toda a rvore de elementos XML de uma nica vez, a API SAX prov uma
arquitetura mais dinmica que permite que os elementos XML sejam encontrados e retornados em resposta
a situaes predeterminadas. Assim, na arquitetura SAX, em vez de pedir ao parser XML que retorne toda a
Pgina 43 de 90
estrutura do arquivo XML, requisita-se ao parser disparar um evento quando a informao de interesse for
encontrada. Maiores informaes sobre essa API podem ser consultados no stio http://www.saxproject.org.
Outra abordagem para o processamento de arquivos XML a utilizao de APIs que implementam o
conceito de Data Binding. Essa nova abordagem surgiu da necessidade de se relacionar automaticamente
as informaes de um arquivo XML com os elementos representados em campos de tabelas de banco de
dados ou em atributos/propriedades de classes implementadas em diversas linguagens de programao.
Assim, em vez de utilizar uma abordagem centrada na estrutura do arquivo XML, como o caso do DOM e
SAX, as APIs que utilizam o conceito de Data Binding aplicam uma abordagem centrada nos dados e no
seu mapeamento adequado. Com isso, pretende-se economizar cdigo de programao, ao mesmo tempo
em que se produz solues mais padronizadas, uma vez que mesmo utilizando DOM e SAX algum tipo de
mapeamento de dados deve ser fornecido.
Solues de processamento de arquivos XML baseadas em Data Binding podem fornecer tambm
outras vantagens, como por exemplo, a converso de dados e a gerao em tempo de execuo de classes
de negcio baseadas nos modelos XML Schemas associados ao arquivo XML. Essa abordagem,
entretanto, tambm traz algumas limitaes. Dependendo da API utilizada, podem ocorrer problemas tanto
na interpretao correta dos elementos do arquivo XML, quanto na gerao de arquivos XML como
resultado de um processamento.
Como se pode observar, a escolha da melhor abordagem para o processamento de arquivos XML
depende de diversos fatores e deve ser uma atividade discutida entre os membros tcnicos da equipe de
arquitetura. Como forma de direcionar essas discusses, so relacionadas a seguir algumas
recomendaes prticas envolvendo esse tema (ERL, 2004):
Utilize DOM:
Quando se tratar de arquivos XML de pequeno ou mdio porte (com menos de 1000 elementos).
Quando houver necessidade de modificar a estrutura do documento XML em tempo de execuo.
Quando houver necessidade de acesso imediato toda estrutura do arquivo XML.
Utilize SAX:
Quando se tratar de arquivos XML grandes (com mais de 1000 elementos).
Quando o processamento por DOM for muito lento.
Quando houver necessidade de acessar apenas parte do contedo do arquivo XML.
Utilize APIs baseadas em Data Biding:
Quando houver requisitos claros de se construir uma interface orientada a objetos para o
processamento de arquivos XML.
Quando houver a necessidade de simplificar a lgica de programao para acesso e mapeamento de
dados.
Pgina 44 de 90
Pgina 45 de 90
{
"primeiroNome": "Maria",
"ultimoNome": "Silva",
"endereco":
{
"logradouro": "Rua 11 de Novembro",
"cidade": "Sao Paulo",
"estado": "SP",
}
}
Figura 10: Exemplo de um arquivo JSON
3.1.4.1.3 Transformao de Dados (XSL)
Outro padro da famlia XML o XSL, utilizado para criar folhas de estilo e, com isso, formatar um
documento XML para apresentao. A ideia de aplicao do XSL bastante simples: um programa
processador de XSL, tambm chamado de engine XSL, transforma o documento XML em outro tipo
documento, pronto para exibio. Neste novo documento, a informao associada com diferentes tipos de
formatao, cores e leiautes atrativos.
Um ponto de discusso bastante interessante associado tecnologia de XSL a sua diferenciao de
outro
padro,
tambm
da
famlia
XML,
denominado
XSLT
(Extensible
Stylesheet
Language
Transformations). O padro XSL puro, como conhecido, compreende o uso de dois padres: XSLT e o
XSL-FO (XSL Formatting Objects). O XSLT define uma linguagem para a converso de um documento XML
em outro formato de documento. O XSL-FO, por sua vez, define uma linguagem para formatar um
documento XML para exibio ou impresso independentemente de plataforma. Isso pode ser um pouco
confuso de se compreender, pois os dois padres constituem o XSL, porm, importante entender que
cada padro pode ser utilizado de forma independente.
Uma aplicao XSL clssica aquela que utiliza XSLT para ler um arquivo XML e, a partir dele, criar
um documento do tipo XSL-FO. Em seguida, esse arquivo XSL-FO tratado por um engine especfico para
tratamento de arquivos XSL que gera, como resultado final do processamento, um arquivo formatado para
impresso ou para visualizao, por exemplo, em formato PDF. Como as etapas deste processo so
independentes, possvel que o documento XSL-FO seja criado atravs de outro mtodo, e no pela
utilizao de XSLT. Alternativamente, possvel tambm utilizar XSLT para a criao de outros tipos de
documentos, no necessariamente de arquivos XSL-FO. Essa ltima alternativa mais comumente
utilizada, principalmente para a gerao de documentos do tipo HTML, texto simples e outros formatos
como o SVG (Scalable Vector Graphics) e WML (Wireless Markup Language).
Como o uso de XSLT tem sido bastante difundido e a tecnologia tem provado ser madura o suficiente
para justificar sua adeso por parte dos profissionais de TI, seu uso no desenvolvimento de aplicaes
governamentais recomendado, seja para a converso de um formato de documento em outro, ou para
padronizar a forma de apresentao das informaes.
Pgina 46 de 90
Pgina 47 de 90
<company>CBS</company>
<price>8.10</price>
<year>1973</year>
</cd>
</catalog>
Figura 11: Exemplo de um documento XML
(Fonte: W3Schools)
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<h2>My CD Collection</h2>
<table border="1">
<tr bgcolor="#9acd32">
<th>Title</th>
<th>Artist</th>
</tr>
<xsl:for-each select="catalog/cd">
<tr>
<td>
<xsl:value-of select="title"/>
</td>
<td>
<xsl:value-of select="artist"/>
</td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Figura 12: Exemplo de um documento XSL
Pgina 48 de 90
Pgina 49 de 90
Entretanto, o padro XML Schema tambm possui algumas limitaes, e conhec-las essencial para
criar solues de intercmbio de dados mais eficientes, alm de abrir a possibilidade de elaborao de
estratgias adicionais para contornar possveis problemas de validao de dados. A lista abaixo relaciona
as mais conhecidas limitaes de validao do XML Schema. Entretanto, importante lembrar que no
escopo desta Cartilha Tcnica discutir ou elaborar solues tcnicas para contornar os problemas
resultantes destas limitaes.
No trata restries condicionais.
No possibilita a definio de dependncias entre elementos distintos.
No prov mecanismos para validao cruzada de documentos XML distintos.
No permite a definio de valores nulos para atributos.
No prov mecanismos para validao de valores numricos grandes.
Exige grande esforo para manter um cdigo relativamente complexo, o que demanda o uso de
ferramentas de produtividade.
Pode gerar problemas de desempenho nas aplicaes devido necessidade de transmitir arquivos
relativamente grandes.
Outros padres para validao de documentos XML tm surgido com o objetivo de contornar as
limitaes do XML Schema, por exemplo: SAF (Schema Adjunct Framework), Schematron, RELAX and
RELAX NG, SOX (Schema for Object Oriented XML) e DSDL (Document Schema Definition Languages
Interoperability Framework). Entretanto, nenhuma dessas novas tecnologias recomendada ou adotada
pela ePING.
A Figura 14 apresenta um exemplo de um arquivo XML Schema enquanto que a Figura 15 ilustra como
referenciar esse documento XML Schema a partir de um arquivo XML.
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Figura 14: Exemplo de um XML Schema
(Fonte: W3Schools)
Pgina 50 de 90
<?xml version="1.0"?>
<note
xmlns="http://www.w3schools.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3schools.com note.xsd">
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
Figura 15: Referencia a um XML Schema a partir do XML
(Fonte: W3Schools)
3.1.4.1.5 Estruturao de Dados Geoespaciais Vetoriais (EDGV)
A demanda por informao geoespacial na atual sociedade tem crescido exponencialmente. Com a
multiplicidade de geotecnologias existentes no mercado, a produo de dados geoespaciais e sua
distribuio vm se tornando cada vez mais geis. Portanto, fundamental que os dados sejam gerados
segundo padres e especificaes tcnicas para possibilitar a interoperabilidade dos dados. Atenta s
necessidades brasileiras, a Comisso Nacional de Cartografia (CONCAR) constituiu um comit
especializado para elaborar um catlogo de feies para o Sistema Cartogrfico Nacional (SCN).
Um catlogo de feies um modelo de dados geoespaciais com o objetivo de obter a
interoperabilidade semntica por meio de um padro de compartilhamento. A EDGV (Estruturao de Dados
Geoespaciais Vetoriais) uma especificao tcnica que define um modelo conceitual para dados vetoriais
garantindo sua consistncia lgica. Esta especificao objetiva padronizar as estruturas de dados
geoespaciais de forma a viabilizar o compartilhamento, a interoperabilidade e a racionalizao de recursos
entre os produtores e consumidores de dados georreferenciados. A EDGV uma das especificaes da
Infraestrutura Nacional de Dados Espaciais (INDE).
O modelo da EDGV composto por um diagrama que contm as classes e seus relacionamentos, e de
um dicionrio de dados, que apresenta em detalhes a estrutura e atributos de cada uma das classes que
compem o modelo. Estas classes esto divididas atualmente em treze categorias: Hidrografia, Relevo,
Vegetao, Sistema de transporte, Energia e comunicaes, Abastecimento de gua e saneamento bsico,
Educao e cultura, Estrutura econmica, Localidades, Pontos de referncia, Limites, Administrao
pblica, Sade e servio social.
A EDGV se destina a desenvolvedores de sistemas de informaes geogrficas (SIG), produtores e
usurios de dados geoespaciais. Seu modelo para dados geoespaciais vetoriais de referncia, tambm
conhecidos como cartografia bsica, permite o uso de uma interface comum tanto para produtores como
para usurios. A adoo deste modelo essencial para o sucesso da INDE.
Maiores informaes sobre a EDGV podem ser encontradas no Portal SIG Brasil em
http://www.inde.gov.br.
Pgina 51 de 90
3.1.4.2
Especificao
Situao
RDF
Resource Description
Framework (RDF) Schema
SKOS (Simple Knowledge
Organization System)
OWL (Web Ontology Language)
R
R
R
R
Descrio
Descreve os conceitos bsicos do RDF e define uma sintaxe abstrata
no qual o padro definido.
Define precisamente a semntica do RDF.
Descreve uma linguagem para a representao de informaes a
respeito de recursos encontrados na Web. Descreve como o RDF
pode ser utilizado e como se pode construir um vocabulrio baseado
neste padro.
Define uma linguagem de propsito geral para representar tipos
diversos de informaes na Web. Permite a definio de recursos da
Web atravs de classes, propriedades e valores.
Define a sintaxe XML utilizada para descrever o RDF.
Descreve os casos de testes desenvolvidos pelo grupo de trabalho do
W3C.
Os padres XML e RDF so considerados a fundao bsica da Web Semntica que, por sua vez,
compreende um grupo de mecanismos e tecnologias que permitiro aos computadores compreenderem
como as informaes se relacionam e se interconectam no ambiente heterogneo e vasto da World Wide
Web. Neste contexto, o RDF prov o mecanismo ideal para, formalmente, definir os recursos disponveis no
ambiente da Web Semntica.
Pgina 52 de 90
Pgina 53 de 90
A Figura 17 mostra um exemplo de documento RDF, assim como o seu contedo exibido na Web.
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cd="http://www.recshop.fake/cd#">
<rdf:Description
rdf:about="http://www.recshop.fake/cd/Empire Burlesque">
<cd:artist>Bob Dylan</cd:artist>
<cd:country>USA</cd:country>
<cd:company>Columbia</cd:company>
<cd:price>10.90</cd:price>
<cd:year>1985</cd:year>
</rdf:Description>
<rdf:Description
rdf:about="http://www.recshop.fake/cd/Hide your heart">
<cd:artist>Bonnie Tyler</cd:artist>
<cd:country>UK</cd:country>
<cd:company>CBS Records</cd:company>
<cd:price>9.90</cd:price>
<cd:year>1988</cd:year>
</rdf:Description>
.
.
.
Pgina 54 de 90
chamado de rdfs1 e rdf2 possuindo definies de Classes como: rdfs:Resource, rdfs:Class, rdfs:Literal entre
outros e Propriedades como: rdf:type, rdfs:subClassOf, rdfs:comment. A especificao do RDFS utiliza de
uma forma abreviada para representar uma URI. Por exemplo um rdf:type deve ser lido como
http://www.w3.org/1999/02/22-rdf-syntax-ns#type.
O quadro abaixo mostra um exemplo de utilizao do RDFS.
Em portugus:
Cachorro1 um animal
Gato1 um gato
Gatos so animais
Zoologicos abrigam animais
Zoologico1 abriga o Gato2
Em RDF/Turtle:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex: <http://example.org/> .
@prefix zoo: <http://example.org/zoo/> .
ex:cachorro1 rdf:type
ex:animal .
ex:gato1
rdf:type
ex:gato .
ex:gato
rdfs:subClassOf ex:animal .
zoo:abriga
rdfs:range
ex:animal .
ex:zoo1
zoo:abriga
ex:gato2 .
3.1.4.2.3
A tecnologia Simple Knowledge Organization System (SKOS) um conjunto de linguagens formais voltado
para a representao de conhecimentos de uma organizao atravs de um thesauri, taxonomia ou outro
tipo de vocabulrio controlado. Um dos focos a interoperabilidade de informaes e conceitos de uma
forma passvel de automao de mquina. Uma leitura recomendada o do SKOS 3 para entender os
conceitos bsicos do SKOS e suas aplicaes.
importante ressaltar que o SKOS no representa axiomas e fatos e, portanto, no uma linguagem
que descreve uma ontologia formal.
Como um exemplo da notao formal h o RDF/N3 que um tipo de notao no baseada em XML
que preza a leitura e seu tamanho reduzido. SKOS utilizado pelo VCGE tanto em sua notao RDF/N3
como na notao RDF/XML, disponvel no endereo http://vocab.e.gov.br.
1
2
http://www.w3.org/2000/01/rdf-schema#
http://www.w3.org/2004/02/skos/
http://www.w3.org/1999/02/22-rdf-syntax-ns#
Pgina 55 de 90
Exemplo em RDF/N3
@prefix dc: <http://purl.org/dc/terms/> .
@prefix ns1: <http://purl.org/dc/elements/1.1/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
<http://vocab.e.gov.br/2011/03/vcge#abastecimento-agua>a
<http://www.w3.org/2004/02/skos/core#Concept>;
dc:created "20090312T07:29:42"^^
<http://www.w3.org/2001/XMLSchema#dateTime>;
skos:broader
<http://vocab.e.gov.br/2011/03/vcge#usos-multiplos-recursos-hidricos>;
skos:inScheme <http://vocab.e.gov.br/2011/03/vcge#esquema>;
skos:narrower <http://vocab.e.gov.br/2011/03/vcge#abastecimento-agua>;
skos:prefLabel "Abastecimento de gua" .
<http://vocab.e.gov.br/2011/03/vcge#acesso-divulgacao-producao-cientifica>a
<http://www.w3.org/2004/02/skos/core#Concept>;
dc:created "2008-09-23T07:02:39"^^
<http://www.w3.org/2001/XMLSchema#dateTime>;
skos:broader <http://vocab.e.gov.br/2011/03/vcge#fomento-pos-graduacao>;
skos:inScheme <http://vocab.e.gov.br/2011/03/vcge#esquema>;
skos:narrower
<http://vocab.e.gov.br/2011/03/vcge#acesso-divulgacao-producao-cientifica>;
skos:prefLabel "Acesso e divulgao da produo cientifica" .
Pgina 56 de 90
Exemplo em RDF/XML
<rdf:RDF>
<rdf:Description rdf:about="http://vocab.e.gov.br/2011/03/vcge#abastecimento-agua">
<rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
<skos:prefLabel>Abastecimento de gua</skos:prefLabel>
<dc:created
rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2009-0312T07:29:42</dc:created>
<skos:inScheme rdf:resource="http://vocab.e.gov.br/2011/03/vcge#esquema"/>
<skos:broader rdf:resource="http://vocab.e.gov.br/2011/03/vcge#usos-multiplos-recursos-hidricos"/>
<skos:narrower rdf:resource="http://vocab.e.gov.br/2011/03/vcge#abastecimento-agua"/>
</rdf:Description>
<rdf:Description
rdf:about="http://vocab.e.gov.br/2011/03/vcge#acesso-divulgacao-producaocientifica">
<rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
<skos:prefLabel>Acesso e divulgao da produo cientifica</skos:prefLabel>
<dc:created
rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2008-0923T07:02:39</dc:created>
<skos:inScheme rdf:resource="http://vocab.e.gov.br/2011/03/vcge#esquema"/>
<skos:broader rdf:resource="http://vocab.e.gov.br/2011/03/vcge#fomento-pos-graduacao"/>
<skos:narrower rdf:resource="http://vocab.e.gov.br/2011/03/vcge#acesso-divulgacao-producaocientifica"/>
</rdf:Description>
</rdf:RDF>
3.1.4.2.4
A Web Ontology Language (OWL) uma famlia de linguagens utilizadas para representar conhecimento
atravs de ontologias. OWL direcionando quando a informao contida em um documento tem como alvo
ser interpretada por aplicaes e no somente interpretada por pessoas. OWL pode ser utilizada para
representar explicitamente o significado dos termos de um vocabulrio e os relacionamentos entre os
mesmos4.
O OWL representa conhecimento utilizando de uma semntica precisa com relacionamento de
superclasses e subclasses. J o SKOS representa uma organizao do conhecimento apresentando
conceitos e seus relacionamentos atravs de um vocabulrio, thesauri ou taxonomia.
http://www.w3.org/TR/owl-features/
Pgina 57 de 90
<owl:Class rdf:about="#Programa">
<rdfs:subClassOf rdf:resource="#Classificador"/>
<rdfs:comment rdf:datatype="&xsd;string"
>Os elementos dessa classe sao programas orientados para a realizacao dos objetivos
estrategicos definidos para o periodo do PPA (Plano Plurianual), ou seja, quatro anos. Programas podem
ser tematicos (que retratam no PPA a agenda de governo e orienta a acao governamental), ou de gestao,
http://vocab.e.gov.br/
Pgina 58 de 90
manutencao e servicos (instrumentos do PPA que classificam um conjunto de acoes destinadas ao apoio,
gestao e manutencao da atuacao governamental).</rdfs:comment>
</owl:Class>
<owl:Class rdf:about="#Projeto">
<rdfs:subClassOf rdf:resource="#Acao"/>
<rdfs:comment rdf:datatype="&xsd;string"
>Os elementos dessa classe sao acoes limitadas no tempo e das quais resulta um produto que
concorre para a expansao ou aperfeicoamento da acao do governo.</rdfs:comment>
</owl:Class>
</rdf:RDF>
Pgina 59 de 90
de
URIs
para
Publicao
de
Dados
no
Governo
disponvel
em:
http://www.governoeletronico.gov.br/biblioteca/arquivos/Politica-URIs-Publicacao-Dados-Governo.
Alguns exemplos de URIs no governo federal brasileiro so:
http://vocab.e.gov.br/2011/03/vcge#agricultura-extrativismo-pesca Que identifica o termo
'Agricultura Extrativismo e Pesca' do VCGE
http://vocab.e.gov.br/2013/09/loa Que identifica o modelo ontolgico da LOA de 2013
Pgina 60 de 90
3.1.5.
3.1.5.1
Especificao
BPEL4WS v1.1
BPMN 1.0
XBRL
LexML 1.0
MGD
WMS, WFS, WCS, CSW e
Filter Encoding verso 1.0 ou
posterior
WFS-T, WKT
Situao
R
A
A
R
A
A
R
Pgina 61 de 90
linguagem rigorosa, baseada na tecnologia de Web Services, e que possibilita a interao entre processos
utilizando chamadas do tipo stateful.
A definio completa de processos baseada em BPEL utiliza dois tipos de arquivos: WSDL (Web
Services Description Language) e BPEL. Os arquivos WSDL especificam as interfaces de servios. Maiores
detalhamentos envolvendo WSDL so fornecidos na seo 3.6 que trata de servios baseados na
tecnologia de Web Services. Os arquivos BPEL, como descritos anteriormente, contm a especificao do
processo para execuo, incluindo a descrio de execuo de suas atividades, variveis, eventos,
tratamentos de exceo, detalhamento de rotas de deciso, etc. Assim, quando o BPEL combinado com o
WSDL, gera como resultado um completo fluxo de controle do processo de negcio que pode ser invocado
atravs de uma interface bem definida e padronizada como um servio. Outro ponto importante em relao
a essa tecnologia que um processo, representado em BPEL, necessita para ser executado de um engine
BPEL, um software capaz de entender a especificao e fazer o processo de negcio executar passo-apasso.
Alguns fornecedores de soluo para modelagem de processos disponibilizam, em seus produtos, uma
interface visual para que os profissionais modelem um processo diretamente em BPEL. Entretanto, a
notao neste caso no deve ser confundida com a notao BPMN. A notao BPMN representa o
processo de forma que o usurio ou o dono do negcio possa compreender. O BPEL, por sua vez, sendo
provido por interface visual ou no, gera documentos no formato XML e em conformidade com a linguagem
BPEL, que representam a execuo do processo em um nvel de detalhamento que os usurios comuns
geralmente no compreendem. Para um maior detalhamento envolvendo BPMN, consulte a seo 5.1.3
neste documento.
Outro ponto de confuso entre os profissionais de TI, usurios e vendedores de ferramentas de
produtividade, diz respeito etapa de transio do modelo BPMN para o modelo BPEL. importante
salientar que embora a especificao BPMN fornea mecanismos de mapeamento com BPEL, essa
atividade em nada ir substituir o trabalho de engenharia de software que deve ser executado pelos
profissionais de TI. Isso significa dizer que ter apenas uma equipe de analistas de processos e uma boa
ferramenta BPMN-BPEL no garantia de gerar um sistema completo ao final da etapa da modelagem.
verdade que as novas tecnologias associadas gesto por processos tenham diminudo a distncia
entre a rea de TI e a rea de negcios. Entretanto, os esforos de ambos os lados para o desenvolvimento
de sistemas mais robustos e eficientes imprescindvel e, com certeza, a diferena entre a obteno de
bons resultados e resultados pobres ou mesmo indesejveis.
3.1.5.1.2 Notao de Modelagem de Processos (BPMN)
O tema envolvendo modelagem de processos no novo, mas tem recebido muita ateno por parte da
comunidade de TI nos ltimos anos. Isso porque a idia de se construir sistemas compatveis, ou at
mesmo que imitem a maneira que os processos de trabalho so executados, promete ganhos em
Pgina 62 de 90
Pgina 63 de 90
O principal elemento do BPMN o BPD (Business Process Diagram) que pode conter diversos
elementos grficos, tais como: atividades, eventos, deciso, indicador de sequncia, indicador de
mensagem, entre outros. A Figura 19 ilustra os principais componentes da notao BPMN.
Pgina 64 de 90
3.1.5.1.3 XBRL
XBRL (eXtensible Business Reporting Language) um padro baseado no XML para comunicar dados
financeiros a partir de um conjunto de metadados estabelecidos nas taxonomias. Uma taxonomia XBRL
um dicionrio estruturado que explica o conjunto de conceitos utilizados por um pas (ex. EUA), um grupo de
pases (ex. Unio Europeia) ou um domnio particular (bancos, seguradoras, bolsa de valores). Estas
taxonomias permitem criar os documentos XBRL, as instncias, que contm factos (os dados contbeisfinanceiros) que so assim trocados pelas empresas e as organizaes envolvidas (bancos, bolsas,
seguradoras, organismos de controle financeiros e organizaes estatsticas).
A primeira taxonomia XBRL para o governo brasileiro foi criada no ano de 2014 pela Secretaria do
Tesouro Nacional, para ser utilizada no Sistema de Informaes Contbeis e Fiscais do Setor Pblico
Brasileiro (Siconfi), e est disponvel para download no Portal Siconfi (siconfi.tesouro.gov.br).
3.1.5.1.4 LexML
O LexML um portal especializado em informao jurdica e legislativa, cujo objetivo reunir leis, decretos,
acrdos, smulas, projetos de leis e outros documentos das esferas federal, estadual e municipal, dos
Poderes Executivo, Legislativo e Judicirio de todo o Brasil. O LexML pode ser considerado como uma rede
de informaes legislativas e jurdicas que visa organizar, integrar e dar acesso s informaes
disponibilizadas nos diversos portais de rgos do governo na Internet (TICONTROLE, 2010).
Para os profissionais de TI que trabalham no fornecimento de solues informatizadas, o LexML pode
ser utilizado para se referenciar, em pginas Web, documentos jurdicos armazenados em sua base de
dados. A vantagem de se utilizar o endereamento do LexML est no fato de que ele fornece uma
identificao padronizada dos documentos jurdicos, evitando-se assim, a ocorrncia do chamado link
quebrado. O link quebrado identificado pelo retorno do erro HTTP 404 no navegador do usurio, e
consequncia da referncia a uma pgina na Internet que no mais se encontra disponvel. Muitas vezes, o
que ocorre realmente que o endereo de referncia mudou, mas o hiperlink na pgina Web no foi
atualizado (TICONTROLE, 2010).
Com o uso do LexML esse problema pode ser contornado, uma vez que os documentos jurdicos so
referenciados e descritos atravs de uma metodologia semntica para catalogao de dados e de uma
identificao dos documentos por uso de URN (Uniform Resource Name, ou Nome Uniforme de Recurso). A
catalogao de documentos do LexML baseada em vocabulrio controlado, utilizado para classificao, e
XML Schemas utilizados para validao das regras de formao dos documentos armazenados. A
identificao dos documentos no LexML, por sua vez, utiliza o recurso de URN, recomendado pelo W3C.
Assim, um desenvolvedor de sistemas que queira referenciar a Lei n o. 8.666 em uma pgina da Web,
poderia utilizar-se do seguinte endereo fornecido pelo LexML (TICONTROLE, 2010):
http://www.lexml.gov.br/urn/urn:lex:br:federal:lei:1993-06-21;8666
Pgina 65 de 90
Observe que o endereo do documento jurdico formado pela juno de uma URL padro da Internet,
no caso http://www.lexml.gov.br/, acrescida de uma URN, urn:lex:br:federal:lei:1993-06-21;8666, que
identifica a Lei a que se deseja fazer referncia. Da mesma maneira, um usurio de Internet poderia copiar
e colar o endereo acima na caixa de endereos do browser para ter acesso ao documento citado. A Figura
21 mostra o resultado da consulta ao documento, na pgina de referncia do LexML.
Pgina 66 de 90
contexto atual e as aes necessrias para a integrao, modernizao e desenvolvimento de solues que
suportem a operao e a tomada de deciso deste Macroprocesso.
O MP, MF e SERPRO compem o Comit do Macroprocesso de Planejamento, Oramento e Finanas
(MPOF). Este Comit composto de dois Grupos de Trabalho Interministerial (GTIs) e quatro outros Grupos
de Trabalho onde destes destacamos o GTI2 que trata da Simplificao e Gesto da Informao do MPOF.
Dentro deste GTI, o SERPRO coordena a parte que trata a Simplificao e Gesto da Informao dos
Dados deste Macroprocesso.
O MGD uma inciativa de interoperabilidade tcnica porque um modelo de dados do tipo entidaderelacionamentos, semntica porque objetiva harmonizar dados num significado comum ou interopervel e
organizacional porque traz, em sua viso de negcio, um modelo de processos que leva a um entendimento
comum dos processos executados pelos rgos de governo.
A medida em que foi modelando os dados do MP, percebeu-se a necessidade de deixar de ser um
modelo baseado apenas nos sistemas de informao e se alinhar ao negocio a partir da viso de processos.
Desta forma o Modelo baseado em 3 etapas: Modelagem dos Dados, Refinamento dos Dados e
levantamento da viso de negcio (Processos). A viso de negcio permite ao MGD apontar os possveis
Gestores da Informao que sero os donos da informao de Governo como tambm mapear dados que
servem ao processo e que no existem nos atuais sistemas de informao. Como consequncia possvel
compreender mais rapidamente qual o rgo do governo responsvel por disponibilizar informaes
afetas a sua competncia e quais os rgos esto interessados em seu consumo, visto sua relevncia para
o seu negcio, desonerando-os assim dos custos de manter informaes que no esto sob sua outorga.
O MGD possui as seguintes metas:
Pgina 67 de 90
informaes
sobre
projeto
MGD
podem
ser
consultadas
no
stio
http://modeloglobaldados.serpro.gov.br.
3.1.6.1.6
O Open Geospatial Consortium (OGC) um consrcio internacional formado por mais de 450 empresas,
universidades e agncias governamentais. Seu objetivo promover o desenvolvimento de tecnologias que
promovam a interoperabilidade entre sistemas que utilizam a informao geogrfica. Nesta subseo so
apresentadas seis especificaes publicadas pelo OGC e que constam no documento de referncia da
ePING. So adotados na arquitetura os padres de servios WMS (Web Map Service), WFS (Web Feature
Service), WCS (Web Coverage Service) e CSW (Catalogue Services for the Web). Constam como
recomendados os padres WFS-T (Web Feature Service Transactional) e WKT (Well-Known Text).
O WMS um servio Web que permite obter mapas (dados geogrficos editados) ou imagens na
Internet. Este servio resolve a principal demanda de informao geogrfica: quero ver o mapa. Esta
especificao tambm o padro internacional ISO 19128:2005.
O WFS um servio Web que permite obter as feies geogrficas (dados vetoriais) de acordo com
um conjunto de parmetros. As consultas podem envolver predicados escalares (booleanos, de comparao
etc.) e/ou geomtricos (toca, cruza etc.). O WFS-T um WFS bsico com mtodos que permitem alterar os
dados via Web, com operaes do tipo INSERT e DELETE. O WFS (bsico e transactional) tambm o
padro internacional ISO 19142:2010.
Pgina 68 de 90
O propsito do servio WCS prover informao geoespacial que tem valores definidos em todo o
espao, tambm conhecida como dado matricial. Uma imagem de satlite ou uma fotografia area so
exemplos de dados matriciais que podem ser publicados num servidor WCS.
O CSW um servio que define uma interface para publicar, acessar, navegar e consultar metadados
sobre informaes georreferenciadas na Internet, via HTTP. A partir desta interface os produtores de dados
geoespaciais podem publicar seus produtos e os usurios podem encontr-los. Um servidor CSW faz o
papel de um diretrio UDDI (Universal Description, Discovery and Integration), usado em servios Web
convencionais.
Para que servios no-geogrficos possam trafegar coordenadas geogrficas via servios
convencionais, o formato WKT segue recomendado na arquitetura ePING para suprir essa necessidade.
Este formato faz parte da especificao OGC Simple Features Access (SFA).
No contexto de servios Web geogrficos, um usurio desses sistemas pode acessar um servio CSW
e descobrir a informao geogrfica de seu interesse por meio de uma consulta aos metadados publicados.
Este usurio pode navegar pelos mapas disponveis utilizando o servio WMS para visualizao. Aps
encontrar algum geodado que seja do seu interesse, o usurio pode obter as feies a partir de uma
consulta a um servio WFS. Caso esta informao seja uma imagem, este usurio pode baix-la por meio
de uma consulta a um servio WCS.
3.1.5.2
Situao
UDDI v3.0.2
WSDL 1.1
SOAP v1.2
HTTP/1.1 (REST)
R
A
Componente
Infraestrutura de registro
Linguagem de definio do servio
Protocolo para acesso a Web Services
Pgina 69 de 90
definies, definir uma arquitetura de software adequada o primeiro passo para se atingir a
interoperabilidade entre sistemas.
A ePING enfatiza o uso da tecnologia de Web Services para propiciar a interoperabilidade entre
sistemas heterogneos o que implica tambm na busca por uma arquitetura de software mais alinhada aos
conceitos de servios em ambientes distribudos. Nesse contexto, a Arquitetura Orientada a Servios ou
simplesmente SOA (Service-Oriented Architecture) oferece diversas vantagens aderncia aos padres
tecnolgicos propostos pela ePING.
3.1.5.2.2 Arquitetura SOA
Um sistema distribudo aquele que executa processos em um conjunto de mquinas sem memria
compartilhada, que representam um nico computador para seus usurios (TANEMBAUM, 2003). Alm
disso, seus componentes de hardware e software localizados em computadores em rede comunicam-se e
coordenam suas aes atravs de troca de mensagens. Nesse contexto, SOA representa um conceito
importante no mbito dos sistemas distribudos, pois um paradigma para a realizao e manuteno de
processos de negcio que so suportados por sistemas distribudos complexos (JOSUTTIS, 2007).
O ambiente distribudo de sistemas geralmente contempla sistemas legados que representam
estabilidade e operacionalizao segura, bem como vrios anos de investimento em pessoas, infraestrutura,
softwares, etc. (POTTS e KOPACK, 2003). Alm disso, cada organizao opta por diferentes fornecedores,
delineando ambientes que contemplam linguagens de programao, bancos de dados, tecnologias e
paradigmas de programao bem distintos.
Ao longo do tempo, a indstria de TI disponibilizou algumas alternativas como soluo para o problema
de interoperabilidade entre diferentes ambientes tecnolgicos e de negcios cada vez mais integrados com
parceiros comerciais e consumidores. Como exemplos de tais solues podem ser citados: (i) CORBA
(Common Object Request Broker Architecture), (ii) RMI (Remote Method Invocation), (iii) DCOM (Distributed
Common Object Model), e (iv) Servlets/JSP (Java Server Pages).
Esses padres ainda podem estar sendo utilizados, mas apresentam desvantagens no que diz respeito
aos requisitos tcnicos associados ao desenvolvimento de sistemas distribudos mais complexos. Algumas
das dificuldades encontradas com o uso de tais padres so: (i) a falta de padronizao de dados e
interfaces, (ii) a dificuldade na localizao e reuso dos objetos, (iii) necessidade de uso de portas especiais
para a comunicao adequada entre cliente e servidor (CORBA e RMI), (iv) restrio de linguagem (RMI e
Servlets/JSP apenas utilizam a linguagem Java), (v) restrio de plataforma (DCOM apenas funciona sob
plataforma Microsoft), (vi) uso de padres muito especficos (CORBA possui uma linguagem prpria, a IDL
(Interface Definition Language)) e (vii) dificuldade de reuso na forma de servio interopervel (falta de
registro ou diretrio para localizar Servlets/JSP e de especificaes de interface para comunicao com os
Servlets/JSP) (POTTS e KOPACK, 2003).
Pgina 70 de 90
Nesse cenrio, SOA surge como uma nova abordagem para se projetar softwares mais fortemente
reutilizveis e aderentes aos processos de negcio das organizaes.
No intuito de definir SOA, diversos autores consideram diferentes dimenses ou pontos de vista, tais
como: (i) uma evoluo da arquitetura baseada em componentes e orientao a objetos, (ii) um conjunto de
melhores prticas, princpios e padres relacionados aos servios das instituies e no contexto de
aplicao da computao distribuda, ou (iii) como um estilo arquitetural que busca o alinhamento entre
negcios e TI.
Sob o ponto de vista de evoluo da arquitetura, SOA introduz o conceito de servios como uma
unidade executvel que encapsula aspectos tcnicos e negociais, e que permite que tais servios sejam
acessados de vrias mquinas, pela Internet ou Intranet, atravs de interfaces consistentes e publicadas em
consonncia com padres abertos.
Como um conjunto de melhores prticas, princpios e padres, SOA um modelo de arquitetura
orientada a servios que tem sido apontado como uma alternativa de sucesso para o alcance da
interoperabilidade entre sistemas e agilidade nas prticas de negcio das instituies (LEWIS, MORRIS, et
al., 2007). Tal desafio reflexo do mundo atual, cada vez mais globalizado e exigente quanto evoluo
dos processos e dos sistemas institucionais. De acordo com este novo paradigma, esses dois elementos
devem evoluir em um conjunto, o que muitas vezes resulta em um complexo e intrincado conjunto de
sistemas distribudos e interoperveis.
Sob o ponto de vista do alinhamento estratgico que envolve os objetivos das instituies pblicas e da
TI adotada por elas, SOA prov a capacidade dos processos de negcios conduzirem o desenvolvimento de
solues informatizadas atravs de servios flexveis e de mecanismos que gerenciam e divulgam os
servios das organizaes (ZHAO, 2006).
3.1.5.2.2.1
Servios
Pgina 71 de 90
Pgina 72 de 90
de
comunicao
subjacente.
Embora
venha
Vale ressaltar que no se trata de um protocolo de acesso a objetos, razo pela qual a utilizao do
nome SOAP como acrnimo encontra-se em desuso. Atualmente, a manuteno e evoluo desse padro
so de responsabilidade do grupo da W3C chamado de XML Protocols Working Group. Isso garante ao
padro SOAP um grau satisfatrio de confiabilidade, uma vez que, como parte do largo espectro de padres
W3C, ele permanece estvel e inalterado at a publicao de uma nova reviso dessa especificao por
aquele grupo.
A especificao SOAP define um framework de mensageria consistindo dos seguintes elementos:
Modelo de processamento define as regras para o processamento de uma mensagem SOAP;
Pgina 73 de 90
Pgina 74 de 90
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>
Figura 25: Exemplo de uma resposta SOAP
(Fonte: W3Schools)
3.1.5.2.5 Papel do REST (Representational State Transfer)
A expresso Transferncia de Estado Representacional foi criada e definida em 2000 por Roy Fielding, um
dos arquitetos da verso 1.1 do protocolo HTTP, em uma dissertao para seu ttulo de PhD. Ao contrrio
do SOAP, REST uma arquitetura, e no um protocolo. Os Web Services construdos em conformidade
com essa arquitetura so chamados de RESTful. Tambm diferentemente do SOAP, no h um padro
oficial para RESTful Web Services.
Para que um servio seja considerado RESTful, preciso que se submeta a um conjunto de seis
restries, e siga um conjunto de quatro princpios. A discusso dessas restries e princpios merece um
captulo especfico, e foge ao escopo do presente documento. Em seu lugar, uma viso til, embora
simplificada, da arquitetura REST apresentada nos pargrafos seguintes.
O padro de arquitetura REST consiste de clientes e servidores: clientes fazem solicitaes a
servidores; servidores processam solicitaes de clientes e retornam a resposta apropriada. Solicitaes e
respostas so construdas tendo em vista a transferncia de representaes de recursos". Um recurso, ou
elemento de informao, qualquer conceito coerente e significativo que possa ser referido no processo. A
representao de um recurso tipicamente um documento que captura o estado atual ou pretendido
desse recurso.
Em qualquer momento definido no tempo da interao, um cliente pode estar em transio entre
estados, ou em repouso (at rest). O cliente comea a enviar solicitaes quando est pronto para fazer a
transio para um novo estado. Enquanto uma ou mais solicitaes estiverem pendentes, o cliente
considerado como em transio. A representao de cada estado contm links que podem ser utilizados na
prxima vez que o cliente decida iniciar uma nova transio de estado.
Pgina 75 de 90
Um RESTful Web Service, tambm chamado de um RESTful Web API, um simples servio Web
implementado utilizando-se HTTP e os princpios e restries do REST. Consiste em uma coleo de
recursos, com trs aspectos muito bem definidos:
a URI base para o Web Service (por exemplo, http://www.exemplo.com/recursos/);
o MIME type do dado suportado pelo Web Service (pode ser XML ou qualquer outro MIME type
vlido);
o Conjunto de Operaes suportado pelo Web Service, representados por verbos padronizados
(List, Retrieve, Replace, Update, Create, Delete), utilizando necessariamente os mtodos HTTP
(POST, GET, PUT, DELETE).
A Tabela 19 ilustra como os verbos e mtodos HTTP so usados na implementao de um RESTful
Web Service:
Tabela 19: RESTful Web Services - mtodos e verbos HTTP
Recurso
Coleo de elementos URI
(http:/exemplo.com/recursos/)
Elemento URI individual
(http:/exemplo.com/recursos/123)
GET
Lista (List)
dados dos
elementos da
coleo
Obtm
(Retrieve) a
representao
do elemento
especificado,
expresso em
um MIME type
apropriado
PUT
Substitui
(Replace) a
coleo inteira
por outra
Atualiza
(Update) o
elemento
especificado
ou, se
inexistente,
cria (Create)
um novo
elemento
POST
Cria (Create) um
novo elemento
na coleo
DELETE
Destri
(Delete) a
coleo
Trata o elemento
especificado
como uma
coleo e cria
(Create) nela um
novo elemento
Remove
(Delete) da
coleo o
elemento
especificado
Pgina 76 de 90
distintos.
Documentos
uma
rede
de
computao
distribuda.
service um service pode ser entendido como um recipiente para um conjunto de funes
Pgina 77 de 90
3.
interface o elemento <interface> define um Web Service, as operaes que podem ser
types so usados para a descrio dos dados, por meio de um XML Schema.
A importncia do WSDL na prtica tem a ver com a possibilidade de se construir aplicativos a partir da
integrao ou montagem de servios de terceiros atravs da Internet. Antes, esses aplicativos eram
necessariamente construdos, por assim dizer, a partir do zero. Para essa montagem se tornar possvel,
necessrio que os desenvolvedores obtenham algumas informaes sobre esses servios, tais como
assinatura dos mtodos a serem invocados, argumentos de entrada e sada, protocolos a serem utilizados,
endereo do servio na rede e formato dos dados. So essas as informaes que a linguagem WSDL define
em formato XML.
3.1.5.2.7 Infraestrutura de registro (UDDI)
O uso extensivo da tecnologia de Web Services para implementar servios de negcio gerou a necessidade
de se estruturar mecanismos para o seu gerenciamento, consolidando assim, a ideia de que os servios so
tambm ativos computacionais existentes nas organizaes. Sendo um ativo computacional, da mesma
forma que a organizao mantm o registro do seu patrimnio (produtos, equipamentos, etc.), ela tambm
deve manter o registro sobre os servios que disponibiliza. Assim, em 2001 surgiram as primeiras
publicaes para se definir padres de registro, localizao e recuperao de servios eletrnicos a partir de
um catlogo ou diretrio centralizado. Essas publicaes deram origem a duas especificaes que se
tornaram padro de mercado, conhecidas como UDDI (Universal Description, Discovery and Integration) e
ebXML (Electronic Business using Extensible Markup Language).
A especificao UDDI mais difundida por se tratar de um padro simplificado que disponibiliza um
conjunto restrito de metadados sobre o servio, alm de fornecer diversas APIs que facilitam a publicao e
busca automtica dos servios. O objetivo do UDDI servir como um servio de diretrio centralizado onde
possvel publicar informaes tcnicas e de descrio dos Web Services que se deseja divulgar.
Atravs de servios de registro UDDI, as partes interessadas em obter servios pela Internet podem
descobrir, comparar, contratar e invocar servios, baseados em critrios tcnicos e negociais tais como
interfaces do servio, nveis de disponibilidade, direitos autorais, custos, etc. O servio de repositrio do
UDDI, por outro lado, se presta a ser interrogado por mensagens SOAP, provendo acesso a documentos
WSDL que descrevem protocolos e formatos exigidos para a utilizao dos servios listados no diretrio.
Pgina 78 de 90
Roteamento
Descrio
Suporte a protocolos sncronos e
assncronos, alm do recurso de
mapeamento de servios (locating e
binding)
Endereamento e roteamento de
mensagens atravs das tcnicas de
roteamento esttico, baseado em
contedo, baseado em regras e
baseado em polticas de uso.
Mediao
Mensageria
Processamento, transformao e
tratamento das mensagens.
Coreografia de
Processos
Implementao de processos de
negcio.
Observao
Deve estar presente nas configuraes
bsicas de ESB.
Pgina 79 de 90
Orquestrao de
Servios
Coordenao de servios.
Processamento
Complexo de Eventos
Processamento de Eventos
QoS (Qualidade de
Servio)
Gerenciamento
Segurana, gerenciamento de
transaes, controle de qualidade
dos servios publicados no ESB
Monitoramento, auditoria, logging e
console de administrao.
Pgina 80 de 90
Pgina 81 de 90
pode ser utilizado para descrever tanto recursos eletrnicos (por exemplo, pginas web,
arquivos ou outros objetos digitais) quanto recursos no eletrnicos (por exemplo, livros, acervos de
museu, pinturas, documentos impressos etc.);
disponveis na Web;
Os rgos do governo precisam avaliar os seus principais objetivos e o pblico-alvo a fim de decidir
quais os recursos que devem ser descritos prioritariamente com o uso do ePMG. Recomenda-se a
identificao dos recursos com maior frequncia de utilizao para que estes tambm sejam
prioritariamente descritos.
Para cada elemento do ePMG haver os seguintes dados:
Pgina 82 de 90
obrigatrio se aplicvel: a este elemento deve ser fornecido um valor se o tipo de recurso
assim o requerer;
opcional: a este elemento pode ser fornecido um valor se o dado estiver disponvel e
apropriado ao recurso.
A obrigatoriedade aplica-se ao elemento e a seus qualificadores quando for o caso.
Qualificadores: Usado para tornar o significado de um elemento mais especfico, podendo ser
utilizado para informao adicional de um recurso.
Exemplos: Indica como os elementos podem ser acrescentados para diferentes situaes. Os
exemplos so fictcios, pois so destinados somente para demonstrar a forma de utilizao do
elemento ou qualificador.
Pgina 83 de 90
mais
informaes,
acesse
pgina
do
ePMG
no
stio
do
governo
eletrnico:
http://governoeletronico.gov.br/acoes-e-projetos/e-ping-padroes-de-interoperabilidade/padrao-demetadados-do-governo-eletronico-e-pmg.
Pgina 84 de 90
Pgina 85 de 90
eletrnicas, principalmente nos casos em que a informao direcionada ao cidado atravs de portais na
Internet.
O VCGE est disponvel em diversos formatos incluindo documentos PDF, SQL, JSON, SKOS e CSV.
Novos formatos podem vir a ser incorporados. Um dos arquivos PDF o VCGE Detalhado que contm
descries completas da histria, propsitos e caractersticas do VCGE.
Para
mais
informaes,
acesse
pgina
do
ePMG
no
stio
do
governo
eletrnico:
http://governoeletronico.gov.br/acoes-e-projetos/e-ping-padroes-de-interoperabilidade/vcge.
Pgina 86 de 90
REFERNCIAS BIBLIOGRFICAS
ARMS, W. Y. Thoughts about Interoperability in the NSDL. Cornell University. [S.l.]. 2000.
BAIRD, S. A. Government Role and the Interoperability Ecosystem. ICEGOV2007, Macao, Dezembro 2007.
219-290.
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software architecture in practice. 2. ed. Boston, MA: Pearson
Education, Inc, 2003.
CGI. Resoluo CGI.br No. 08, 28 de novembro de 2008. CGI, 2008. Disponvel
<http://www.cgi.br/regulamentacao/resolucao2008-008.htm>. Acesso em: 2 de Maio de 2014.
em:
4627,
2006.
Disponvel
em:
E-PING. ePING: Programa de Governo Eletrnico Brasileiro. Governo Eletrnico, 2014. Disponvel em:
<http://www.eping.e.gov.br>. Acesso em: 2 de Dezembro de 2014.
ERL, T. Service-Oriented Architecture: A field Guide to Integrating XML and Web Services. New Jersey:
Prentice Hall PTR, 2004.
GINGA. TV Interativa. Ginga Digital TV Middleware, 2006. Disponvel em: <http://www.ginga.org.br/>.
Acesso em: 2 de Maio de 2014 .
ICP-BRASIL. Resoluo N 58. Viso Geral do Sistema de Carimbos do Tempo na ICP-Brasil, 2008.
Disponvel em: <http://www.iti.gov.br/images/icp-brasil/legislacao/Resolucoes/Resolucao_58.pdf>. Acesso
em: 2 de Maio de 2014.
ICP-BRASIL. Resoluo N 65. Padres e Algoritmos Criptogrficos da ICP-Brasil, 2009. Disponvel em:
<http://www.iti.gov.br/images/icp-brasil/legislacao/Resolucoes/resolucao65.pdf>. Acesso em: 2 de Maio de
2014.
IETF. RFC 3277: Guidelines for Evidence Collection and Archiving. Network Working Group, 2002.
Disponvel em: <http://www.ietf.org/rfc/rfc3227.txt>. Acesso em: 2 de Maio de 2014.
JOSUTTIS, N. M. SOA In Pratice. [S.l.]: O'Reilly, 2007.
JSON.ORG. JSON, 2009. Disponvel em: <http://json.org/>. Acesso em: 2 de Maio de 2014.
LEWIS, G. A. et al. Common misconception about Service-Oriented Architecture. Sixth International IEEE
Conference on Commercial off the shelf Based Software Systems. [S.l.]: [s.n.]. 2007.
MCGOVERN, J. et al. Enterprise Service Oriented Architectures: concepts, challenges, recommendations.
[S.l.]: Springer, 2006.
NEWCOMER, E.; LOMOW, G. Understanding SOA with Web Services. Massachusetts: Addison Wesley,
2005.
Pgina 87 de 90
NIST. FIPS 140-1/2: Security Requirements For Cryptographic Modules. National Institute of Standards and
Technology,
2001.
Disponvel
em:
<http://csrc.nist.gov/publications/fips/fips1401.htm,
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>. Acesso em: 2 de Maio de 2014.
NIST. Guide to Integrating Forensic Techniques into Incident Response. National Institute of Standards and
Technology
Special
Publication
800-86,
2006.
Disponvel
em:
<http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf>. Acesso em: 2 de Maio de 2014.
OASIS. Reference Model for Service Oriented Architecture 1.0. OASIS SOA Reference Model TC, 2006.
Disponvel em: <http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf>. Acesso em: 2
de Maio de 2014.
OMG.
BPMN
Graphical
Elements.
BPMN
Core
Elements,
2005.
Disponvel
em:
<http://www.omg.org/bpmn/Samples/Elements/Core_BPMN_Elements.htm>. Acesso em: 2 de Maio de
2014.
PAPAZOGLOU, T. A.; RIBBERS, P. M. A. E-business: Organizational and technical foundation. West
Sussex, UK: John Wiley & Sons, 2006.
POTTS, S.; KOPACK, M. Web Services in 24 hours. [S.l.]: Sams Publishing, 2003.
PRESIDNCIA DA REPBLICA. Resoluo 07. Resoluo no. 07, julho de 2002, 2002. Disponvel em:
<https://www.planalto.gov.br/ccivil_03/Resoluo/2002/RES07-02web.htm>. Acesso em: 2 de Maio de 2014.
PRESIDNCIA DA REPBLICA. Normas Complementares N 4 a 7, 2010. Disponvel em:
<http://dsic.planalto.gov.br/documentos/nc_04_grsic.pdf;
http://dsic.planalto.gov.br/documentos/nc_05_etir.pdf; http://dsic.planalto.gov.br/documentos/nc_6_gcn.pdf;
http://dsic.planalto.gov.br/documentos/nc_7_controle_acesso.pdf>. Acesso em: 2 de Maio de 2014.
GOVERNO ELETRNICO. Regra de Formao de Nomes para a composio dos endereos eletrnicos
(e-mail) 2011, ISSN S/N. Disponvel em: <http://www.governoeletronico.gov.br/acoes-e-projetos/e-pingpadroes-de-interoperabilidade/arquivo>. Acesso em: 2 de Maio de 2014.
SECRETARIA DE LOGSTICA E TECNOLOGIA DA INFORMAO, MINISTRIO DO PLANEJAMENTO,
ORAMENTO E GESTO. Portal Brasileiro de Dados Abertos. Portal Brasileiro de Dados Abertos, 2014.
Disponvel em: <http://dados.gov.br/>. Acesso em: 2 de Maio de 2014.
TANEMBAUM, A. S. Sistemas Operacionais Modernos. [S.l.]: Prentice Hall, 2003.
TEECE, D. J.; PISANO, G.; SHUEN, A. Dynamic Capabilities and Strategic Management. Strategic
Management Journal, v. 17, Agosto 1997. ISSN 7.
TICONTROLE. Rede de Informao Legislativa e Jurdica: Projeto LexML Brasil. LexML, 2010. Disponvel
em: <http://projeto.lexml.gov.br/>. Acesso em: 2 de Maio de 2014.
TRIPATHI, R.; GUPTA, M. P.; BHATTACHARYA, J. Selected Aspects of Interoperability in One-Stop
Government Portal of India. Computer Society of India, New Delli, India, 2008. 1-11.
UNICODE
CONSORTIUM.
UNICODE
4.2.0.
Padro
UNICODE,
2010.
<http://www.unicode.org/versions/Unicode5.2.0/>. Acesso em: 2 de Maio de 2014.
Disponvel
em:
W3C.
Mobile
Web
Best
Practices.
W3C
Recommendation,
<http://www.w3.org/TR/mobile-bp/>. Acesso em: 2 de Maio de 2014.
Disponvel
em:
2008.
Pgina 88 de 90
W3C. Semantic Web Standards. RDF, 2010. Disponvel em: <http://www.w3.org/RDF/>. Acesso em: 2 de
Maio de 2014.
ZHAO, Y. Enterprise Service Oriented Architecture (ESOA) Adoption Reference. IEEE International
Conference on Services Computing. Washington, DC: [s.n.]. 2006.
Pgina 89 de 90