You are on page 1of 90

Ministrio do Planejamento, Oramento e Gesto

Secretaria de Logstica e Tecnologia da Informao


Departamento de Governo Eletrnico
www.governoeletronico.gov.br

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).

Brasil. Ministrio do Planejamento, Oramento e Gesto


Guia de Interoperabilidade: Cartilha Tcnica / Ministrio do Planejamento, Oramento e Gesto.
Braslia: MP, 2015.
90 p.; 30 cm.

Documento tcnico do governo brasileiro.

1. Interoperabilidade 2. Governo eletrnico 3.ePING

Guia de Interoperabilidade: Cartilha Tcnica Pgina 2 de 90


Esta obra est licenciada com uma Licena Creative Commons Atribuio-
NoComercial-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 Agradecimento aos colaboradores

Ana Paula Pessoa Mello - SLTI/MP Carlos E. Jimnez Gmez

Carlos Eduardo Arajo Vieira - SLTI/MP Cludia do Socorro F. Mesquita

Hudson Vincius Mesquita SLTI/MP Daniel Viero SENADO

Roberto Shayer Lyra - SLTI/MP Emerson Magnus de A. Xavier MD/CEX


Gonalo Teixeira Nunes IFCI/AECID
Jlio Csar dos Santos Nunes SRF/MF
Marcello Alexandre Kill SERPRO
Patrycia Barros de L. Klavdianos IFCI/AECID
Rachel Cristina G. M. Domingos STM
Renata Assuno de Farias SEP/PR
Yuri Fontes de Oliveira SLTI/MP

Guia de Interoperabilidade: Cartilha Tcnica 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

Guia de Interoperabilidade: Cartilha Tcnica 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

A Cartilha Tcnica de Interoperabilidade no pretende guiar os profissionais de TIC no uso de linguagens de


programao e tcnicas computacionais especficas que envolvam o projeto e a construo de sistemas
informatizados. Alm disso, no objetivo deste documento imputar a utilizao de ferramentas de trabalho
ou de realizar a divulgao de solues prontas de TIC que tratam de interoperabilidade. Por isso,
recomenda-se que os leitores possuam conhecimento adequado dos assuntos tratados em cada um dos
captulos deste documento.

Guia de Interoperabilidade: Cartilha Tcnica 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).

Guia de Interoperabilidade: Cartilha Tcnica Pgina 6 de 90


2. FUNDAMENTOS DE INTEROPERABILIDADE

2.1. Introduo
O documento de referncia da ePING aborda, inicialmente, a importncia da TIC no contexto
governamental, fornecendo as justificativas para se investir em polticas direcionadas interoperabilidade
governamental.

A ePING surge como documento definidor das polticas e padres de interoperabilidade aplicveis, em
um primeiro momento, no Governo Federal, mas de uso livre e irrestrito por outros poderes e esferas da
Administrao Pblica dos Estados e Municpios.

A ePING o marco principal de interoperabilidade do governo brasileiro, e tem como objetivo


estabelecer as condies de interao do Poder Executivo com os demais Poderes e esferas de governo e
com a sociedade em geral. Para tanto, ela organiza o seu contedo em cinco segmentos: (i) Interconexo,
(ii) Segurana, (iii) Meios de Acesso, (iv) Organizao e Intercmbio de Informaes e (v) reas de
Integrao para Governo Eletrnico.

Entretanto, sendo a ePING um documento de referncia, no est entre seus objetivos fornecer
respostas aos questionamentos tcnicos envolvendo a aplicao dos padres tecnolgicos no contexto de
execuo dos projetos e das atividades de rotina dos setores de TIC do Governo. Por isso, tornou-se
necessrio consolidar e aperfeioar as ferramentas de apoio ePING com o objetivo de dar a ela um
carter mais prtico.

Este o enfoque principal deste documento, que recebeu o nome de Cartilha Tcnica de
Interoperabilidade por representar bem o seu objetivo e estrutura interna. Trata-se de uma cartilha que
procura utilizar linguagem facilitada para descrever conceitos e aes pertinentes execuo das polticas e
prticas de interoperabilidade definidas na ePING. tambm um documento tcnico, pois embora faa uso
de uma linguagem facilitada que permite a melhor compreenso dos conceitos, no deixa de tratar as
questes tecnolgicas relacionadas ao tema Interoperabilidade no Governo.

2.2. Dimenses da Interoperabilidade


A interoperabilidade pode ser organizada em trs dimenses que se comunicam e se complementam:
organizacional, semntica e tcnica.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 7 de 90


A Figura 1 ilustra essas trs dimenses da interoperabilidade:

Figura 1: Dimenses da Interoperabilidade

A interoperabilidade organizacional diz respeito colaborao entre organizaes que desejam


trocar informaes mantendo diferentes estruturas internas e processos de negcios variados. Mesmo
contando com a padronizao de conceitos, as organizaes possuem distintos modelos de operao, ou
processos de trabalho. Isto quer dizer que elas realizam suas atividades em tempos diferentes e de
maneiras diferentes.

Assim, um desafio da interoperabilidade identificar as vantagens de cada interoperao e em que


momentos estas deveriam acontecer. Para isso, as organizaes envolvidas na interoperao precisam
conhecer mutuamente seus processos de trabalho, e isto s possvel se ambas possurem processos
modelados, e ainda mais, se estes modelos estiverem dentro do mesmo padro.

A interoperabilidade semntica a capacidade de dois ou mais sistemas heterogneos e distribudos


trabalharem em conjunto, compartilhando as informaes entre eles com entendimento comum de seu
significado (Buranarach, 2004). A interoperabilidade semntica garante que os dados trocados tenham seu
efetivo significado corretamente interpretado dentro do contexto de uma dada transao ou busca de
informao, dentro da cultura, convenes e terminologias adotadas por cada setor ou organizao e,
assim, compartilhados pelas partes envolvidas.

A interoperabilidade tcnica trata da ligao entre sistemas e servios de computao pela utilizao
de padres para apresentao, coleta, troca, processamento e transporte de dados. Esses padres podem
abranger hardware, software, protocolos e processos de negcio. Uma vez que foram estabelecidos
vocabulrios comuns, e que foram identificados os motivos e os momentos adequados para interoperar,
preciso haver tambm um padro para fazer isso, ou seja, para tratar o como fazer.

Guia de Interoperabilidade: Cartilha Tcnica 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.

Guia de Interoperabilidade: Cartilha Tcnica 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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 10 de 90


3. Especificao Tcnica dos Componentes da ePING

3.1. 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.

Interconexo Segmento 1: Estabelece as condies para que os rgos de governo se


interconectem, alm de fixar as condies de interoperao entre o governo e a sociedade.

Segurana Segmento 2: Trata dos aspectos de segurana de TIC que o governo federal deve
considerar.

Meios de Acesso Segmento 3: So explicitadas as questes relativas aos padres dos


dispositivos de acesso aos servios de governo eletrnico.

Organizao e Intercmbio de informaes Segmento 4: Aborda os aspectos relativos ao


tratamento e transferncia de informaes nos servios de governo eletrnico. Inclui padro de
vocabulrios controlados, taxonomias, ontologias e outros mtodos de organizao e recuperao
de informaes.

reas de Integrao para Governo Eletrnico Segmento 5: Estabelece a utilizao ou


construo de especificaes tcnicas para sustentar o intercmbio de informaes em reas
transversais da atuao governamental, cuja padronizao seja relevante para a interoperabilidade
de servios de Governo Eletrnico, tais como Dados e Processos, Informaes Contbeis,
Geogrficas, Estatsticas e de Desempenho, entre outras.

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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 11 de 90


Tabela 1: Padres por segmento na ePING
Segmentos da ePING Componentes da ePING Referncia na 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
Tabela 1 Aplicao
Protocolos de transferncia de arquivos
Diretrio
Sincronismo de tempo
Servios de Nomeao de Domnio
1 Interconexo
Protocolos de sinalizao
Protocolos de gerenciamento de rede
Transporte
Intercomunicao LAN/WAN
Tabela 2 Rede/Transporte
Comutao por Label
Qualidade de Servio
Rede local sem fio
Qualidade de Servio 802.1p
Tabela 3 Enlace/Fsico
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
Tabela 4 Comunicao de
Hipertexto e transferncia de arquivos
dados
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
Tabela 5 Correio Eletrnico
Identificao de e-mail
Assinatura
2 Segurana 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
Tabela 6 Criptografia
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 Tabela 7 Desenvolvimento
Principais gerenciamentos XML quando um de Sistemas
ambiente PKI utilizado
Autenticao e autorizao de acesso XML

Guia de Interoperabilidade: Cartilha Tcnica Pgina 12 de 90


Intermediao ou Federao de Identidades
Navegadores
Diretrio
DNSSEC Tabela 8 Servios de Rede
Carimbo do tempo
LAN sem fio 802.11 Tabela 9 Redes sem fio
Preservao de registros
Tabela 10 Resposta a
Gerenciamento de incidentes em redes
Incidentes de Segurana da
computacionais
Informao
Informtica Forense
Servios de tecnologia da informao,
Tabela 11 Auditoria em
conforme definidos no art. 11 da Portaria
programas e equipamentos
Interministerial MP/MC/MD n 141 de
02/05/2014
Conjunto de caracteres
Formato de intercmbio de hipertexto
Mobile
Arquivos do tipo documento
Arquivos do tipo planilha
Arquivos do tipo apresentao
Arquivos do tipo banco de dados para
estaes de trabalho Tabela 12 Meios de
Intercmbio de informaes grficas e imagens Publicao
estticas
Grficos vetoriais
Animao
3 Meios de Acesso udio
Vdeo
Compactao de arquivos
Informaes georreferenciadas
Transmisso
Codificao
Multiplexao
Receptores
Segurana Tabela 13 TV Digital
Middleware
Canal de Interatividade
Guia de Operaes
Acessibilidade
Linguagem para intercmbio de dados
Transformao de dados
Tabela 14 Tratamento e
Definio dos dados para intercmbio transferncia de Dados
4 Organizao e Informaes georreferenciadas catlogo de
Intercmbio de feies
informaes Descrio de recursos
Especificao de vocabulrios para RDF Tabela 15 Vocabulrios e
Sistemas de Organizao do Conhecimento Ontologias

Linguagem de definio de ontologias na web

Guia de Interoperabilidade: Cartilha Tcnica Pgina 13 de 90


Linguagem para Execuo de
Processos
Notao de Modelagem de
Processos
Intercmbio de Informaes
Financeiras Tabela 16 Temas Transversais
Legislao, Jurisprudncia e
5 reas de Integrao para Proposies Legislativas
Governo Eletrnico
Integrao de Dados e Processos
Interoperabilidade entre sistemas
de informao geogrfica
Infraestrutura de registro
Linguagem de definio do servio
Tabela 17 Web Services
Protocolo para acesso a Web
Service

Guia de Interoperabilidade: Cartilha Tcnica Pgina 14 de 90


3.1.1. Interconexo Segmento 1

3.1.1.1 Especificaes para Aplicao

Tabela 2: Aplicao
Componente Especificao Situao
Padro de Formao de Endereos de
Endereos de caixa postal eletrnica A
Correio Eletrnico - Caixas Postais Individuais
Produtos que suportem interfaces em conformidade
Transporte de mensagem eletrnica A
com SMTP/MIME
Internet Message Access Protocol IMAP para acesso
Acesso caixa postal A
remoto caixa postal
Programas de correio eletrnico em conformidade com
Mensageria em Tempo Real A
XMPP
Implementar submisso de e-mail via porta 587/TCP
AntiSpam Gerenciamento da Porta com autenticao, reservando a porta 25/TCP apenas
R
25 para transporte entre servidores SMTP, conforme
recomendao CGI / Cert.br http://www.cert.br/
Protocolo de transferncia de
Utilizar HTTP/1.1 A
hipertexto
Protocolos de transferncia de
FTP (com reinicializao e recuperao) e HTTP A
arquivos
Diretrio LDAP v3 A
RFC 5905 IETF Network Time Protocol NTP
Sincronismo de tempo A
verso 4.0.
Servios de Nomeao de Domnio DNS. RFC 1035 A
Protocolos de sinalizao Protocolo de Inicializao de Sesso (SIP) A
Protocolos de gerenciamento de rede SNMP v3 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.

Guia de Interoperabilidade: Cartilha Tcnica 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
introduo de e-mails no solicitados;

a implementao de autenticao na submisso, incluindo aquela realizada remotamente por


usurios autorizados;

a possibilidade de implementar, futuramente, melhorias no servio de submisso.

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
Messaging Anti-Abuse Working Group (MAAWG)

Tecnologias e Polticas para Combate ao Spam - Comisso de Trabalho Anti-Spam do CGI.br.

Em seu documento o MAAWG recomenda para redes de carter residencial, alm da adoo
de Message Submission, as seguintes medidas:

requerer autenticao para a submisso de mensagens, como recomendado na RFC 4954;

configurar o software cliente de e-mail para usar a porta 587/TCP e autenticao;

Guia de Interoperabilidade: Cartilha Tcnica 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 interferir no trfego para a porta 587/TCP;

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, a comunidade Internet considera o 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.

Resoluo CGI.br/RES/2009/001/P Recomendao para a Adoo de Gerncia de Porta 25 em


Redes de Carter Residencial (CGI.br).

Devido a este fato, apesar de no constar explicitamente na recomendao do MAAWG, importante


que tambm no ocorra interferncia no trfego relacionado com outras portas que possam ser utilizadas
para submisso, como a 80/TCP e a 465/TCP.

A figura a seguir ilustra a mudana de cenrio em uma rede de carter residencial, aps a
implementao de gerncia de porta 25, ou seja, aps a adoo de Message Submission pelos provedores
de e-mail dos usurios e o bloqueio de trfego de sada com destino porta 25/TCP por parte das
operadoras de banda larga.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 17 de 90


Figura 2: mudana de cenrio em uma rede aps a implementao de gerncia de porta 25

Pode-se ver que o usurio, conectado via uma rede residencial, envia e-mails normalmente via Mail
Submission Port (587/TCP) ou via Webmail (80/TCP). Mas, os spammers, fraudadores e cdigos maliciosos
no conseguem mais fazer a entrega direta dos e-mails para os provedores de destino, pois a sada de
conexes para porta 25/TCP impedida.

Com este novo cenrio os spammers e fraudadores, provavelmente, adaptaro suas ferramentas para
furtar as credenciais do usurio e se autenticar em seu MSAs (Mail Submission Agents) para o envio
despam. Mas, mesmo ocorrendo esta mudana para uso das credenciais do usurio, outro reflexo da
implementao de Message Submission e Gerncia de Porta 25 em redes de perfil residencial que as
mensagens abusivas so mais rastreveis para os provedores de acesso. Pois, alm do provedor poder
implementar polticas de controle de vazo de e-mails, ele poder identificar mais facilmente mquinas
infectadas e usurios abusivos.

O HTTP/1.1 (Hypertext Transfer Protocol V1.1) um protocolo de comunicao utilizado para sistemas
de informao de hipermdia distribudos e colaborativos. Seu uso para viabilizar o compartilhamento de
recursos distribudos a nvel planetrio levou ao estabelecimento e evoluo da rede mundial ( World Wide
Web) como hoje a conhecemos. natural ento que esse seja o protocolo adotado pela ePING para a
transferncia de hipertexto.

Para a transferncia de arquivos, a ePING adotou o prprio protocolo HTTP/1.1, que prev
mecanismos de reinicializao do processo de transferncia sem perda dos dados j transmitidos e
recebidos, e tambm de recuperao limitada de dados em caso de erros de comunicao. Tambm

Guia de Interoperabilidade: Cartilha Tcnica 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 Especificaes para Rede/Transporte

Tabela 3: Rede/Transporte
Componente Especificao Situao
Transporte TCP e UDP A
Intercomunicao LAN/WAN IPv6 A
Comutao por Label MPLS (pelo menos quatro classes de servio) A
Qualidade de Servio DiffServ 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

Guia de Interoperabilidade: Cartilha Tcnica 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 Especificaes para Enlace/Fsico

Tabela 4: Enlace/Fsico
Componente Especificao Situao
IEEE 802.11 g A
Rede local sem fio
IEEE 802.11 n R
Qualidade de Servio 802.1p R
Virtual LAN VLAN (IEEE 802.1Q) R
Spanning tree protocol (802.1d,
Resilincia Layer2 R
802.1w, 802.1s)

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, Non-
HT 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.

Guia de Interoperabilidade: Cartilha Tcnica 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.

Figura 3: Representao das normas IEEE 802.1D, 802.1p e 802.1Q

Guia de Interoperabilidade: Cartilha Tcnica 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


7 Controle da rede Aplicaes crticas (RIP, OSPF, BGP4)
6 Voz interativa Sensveis latncia e jitter com baixa banda (Netmeeting, RAT)
5 Multimdia interativa Sensveis ao jitter com alta banda (picturetel, indeo)
4 Carga controlada Aplicaes sensveis latncia (transaes SNA)
3 Esforo excelente Trfego crtico que tolera atrasos (SAP, SQL)
2 Melhor esforo Melhor esforo
1 Default Default
0 Background Insensveis latncia (FTP, backups, pointcast)

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.

Figura 4: Quadro ethernet com TAG

Dos valores contidos dentro do campo TAG o nmero da VLAN adicionado ao campo VLAN id
permitindo a identificao da VLAN entre os Switches. Esse mecanismo de VLANs bastante flexvel, e
permite organizar os computadores em domnios de broadcast distintos, independentemente de sua
conexo fsica.

O crescimento das redes LANs, associado aos requisitos de qualidade e tolerncia a falhas cada vez
maiores, culminou em solues de rede com topologias cada vez mais robustas, como nos casos de redes
em anel. Tais implementaes, com o intuito de garantir maior disponibilidade para as solues e servios,
acabam por proporcionar redundncia de caminhos de rede e, com isso, a possibilidade de ocorrncia de
looping.

Guia de Interoperabilidade: Cartilha Tcnica 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).

Guia de Interoperabilidade: Cartilha Tcnica 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 Especificaes para Comunicao de dados

Tabela 5: Comunicao de Dados


Componente Especificao Situao
TLS. Caso seja necessrio, o protocolo TLS
Transferncia de dados em redes inseguras R
v1 pode emular o SSL v3.
RSA, Diffie-Hellman RSA, Diffie-Hellman
Algoritmos para troca de chaves de sesso,
DSS, DHE_DSS, DHE_RSA R
durante o handshake
Algoritmos para definio de chave de cifrao RC4, IDEA, 3DES e AES R
Certificado Digital X.509 v3 ICP-Brasil, SASL R
Hipertexto e transferncia de arquivos RFC 2818 (atualizada pela RFC 5785) R
Autenticao IPSec, IKE para permutao de
Segurana de redes IPv4 A
chaves, ESP como requisito para VPN
Segurana de redes IPv4 para protocolos de
S/MIME v3 A
aplicao
As especificaes do IPv6 definiram dois
mecanismos de segurana: a autenticao
de cabealho AH (Authentication Header)
Segurana de redes IPv6 na camada de rede R
RFC 4302 ou autenticao IP, e a segurana
do encapsulamento IP, ESP (Encrypted
Security Payload) RFC 4303.

Garantir a integridade e confidencialidade dos dados transmitidos por redes de comunicao ,


sobretudo, prevenir que terceiros tenham acesso indevido ou falsifiquem esses dados enquanto em trnsito.
Para dados que trafegam em redes inseguras como a Internet, indispensvel a utilizao de protocolos
criptogrficos. Esses protocolos tipicamente provm a privacidade e a integridade dos dados trafegando
entre duas ou mais aplicaes atravs de dois mecanismos bsicos: (i) autenticao das partes envolvidas,
e (ii) cifrao dos dados transmitidos entre as partes.

Guia de Interoperabilidade: Cartilha Tcnica 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 hand-
shake 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).

Guia de Interoperabilidade: Cartilha Tcnica 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 Especificaes para Correio Eletrnico

Tabela 6: Correio Eletrnico


Componente Especificao Situao
Cliente especfico com mecanismos de segurana nativos ou
Acesso a caixas postais A
HTTPS
Contedo de e-mail S/MIME v3 A
Transporte de e-mail SPF A
Identificao de e-mail DKIM R
Assinatura Padro ICP-Brasil A
Transporte seguro de e-mail SMTP seguro sobre TLS 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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 27 de 90


Para a assinatura de mensagens seguras, a ePING determina a utilizao de certificados digitais no
padro X.509 v3, emitidos por entidades pertencentes rede certificadora ICP-Brasil.

3.1.2.3 Especificaes para Criptografia

Tabela 7: Criptografia
Componente Especificao Situao
Algoritmo de cifrao 3DES ou AES R
Algoritmo para assinatura/hashing SHA-256 ou SHA-512 R
Algoritmo para transporte de chave criptogrfica
RSA A
de contedo/sesso
Algoritmos criptogrficos baseados em curvas ECDSA 256 e ECDSA 512
A
elpticas ECIES 256 e ECIES 512
Homologao da ICP-Brasil
Requisitos de segurana para mdulos
NSH-2 e NSH-3 R
criptogrficos
FIPS 140-1 e FIPS 140-2
Certificado Digital da AC-raiz para Navegadores
Padres da ICP Brasil R
e Visualizadores de Arquivos

A confiabilidade de um procedimento de cifrao depende da qualidade e robustez do algoritmo


utilizado. Para a cifrao de contedo de qualquer natureza, a ePING recomenda a utilizao dos algoritmos
3DES Triple Data Encryption Algorithm, ou DES Triplo) e AES (Advanced Encryption Standard, ou Padro
de Criptografia Avanada).

O 3DES uma variante mais robusta do DES (Data Encryption Standard), um padro institudo pelo
governo americano em 1976. O DES um mecanismo simtrico de cifrao que utiliza chaves de 56 bits,
adequadas ao panorama computacional daquela poca, mas hoje incapazes de resistir a ataques de fora
bruta com os recursos de CPU disponveis at em equipamentos de uso domstico. Para compensar essa
fraqueza, o 3DES usa trs chaves em sequncia: a informao encriptada com a primeira chave,
decriptada com a segunda, e por fim novamente encriptada com a terceira chave.

O AES (Advanced Encryption Standard) foi promulgado como padro criptogrfico do governo
americano em 2002, aps um longo processo conduzido pelo NIST (National Institute of Standards and
Technology), que durou cerca de cinco anos, e onde se procurou selecionar atravs de concurso pblico um
novo algoritmo de chave simtrica para proteger informaes do Governo Federal. O AES considerado
pela maioria dos especialistas o estado da arte em algoritmo criptogrfico. Ele combina com eficincia as
caractersticas de segurana, desempenho, facilidade de implementao, flexibilidade e alta resistncia a
ataques. Alm disso, ele demanda pouca memria e CPU, o que o torna adequado para utilizao em
plataformas de poder computacional relativamente baixo, como smart cards, PDAs e telefones celulares.

Em criptografia, uma funo hash um procedimento determinstico que recebe um bloco de


informao de qualquer comprimento (chamado de mensagem), e retorna uma cadeia de caracteres de
tamanho fixo (chamado de digest). Esse procedimento til para garantir a integridade de uma mensagem,
uma vez que produzir um digest diferente no evento de qualquer mudana, intencional ou acidental, na

Guia de Interoperabilidade: Cartilha Tcnica 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.

Guia de Interoperabilidade: Cartilha Tcnica 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 Especificaes para Desenvolvimento de Sistemas

Tabela 8: Desenvolvimento de Sistemas


Componente Especificao Situao
Assinaturas XML XMLsig A
Cifrao XML XMLenc R
Transformao de decifrao para
Assinatura e cifrao XML R
assinatura XML
Principais gerenciamentos XML em ambiente PKI XKMS 2.0 R
Autenticao e autorizao de acesso XML SAML R
WS-Security 1.1
Intermediao ou Federao de Identidades R
WS-Trust 1.4
Cookies apenas com a
Navegadores A
concordncia do usurio

A ePING determina que os seguintes padres de segurana sejam utilizados no desenvolvimento de


sistemas, quando houver envolvimento de componentes XML (Extensible Markup Language) e de
navegadores:

XMLsig (XML Signature) na assinatura de documentos e artefatos XML;


Cookies no controle da interao do usurio com o sistema atravs de navegadores, desde que
obtida sua concordncia.

A ePING recomenda a utilizao dos seguintes padres de segurana na utilizao de documentos e


artefatos XML em sistemas de computao:

XMLenc (XML Encryption) procedimentos a serem observados na criptao de documentos XML;


XKMS 2.0 (XML Key Management Specification) para facilitar a interoperabilidade entre
aplicaes que fazem o uso da Infraestrutura de Chaves Pblicas, atravs de dois componentes:
(i) XKISS (XML Key Information Service Specification), que diz respeito gesto da chave pblica,
e (ii) XKRSS (XML Key Registration Service Specification), que diz respeito gesto da chave
privada;
SAML (Security Assertion Markup Language) - para a troca de informao sobre autenticao e
autorizao entre domnios;
WS-Security 1.1 para o fornecimento de segurana s mensagens SOAP (Simple Object Access
Protocol), atravs da utilizao dos padres XMLsig e XMLenc;
WS-Trust 1.3 extenses ao WS-Security para a gesto de relacionamentos confiveis entre os
envolvidos na troca de mensagens seguras.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 30 de 90


3.1.2.5 Especificaes para Servios de Rede

Tabela 9: Servios de Rede


Componente Especificao Situao
Diretrio LDAP v3 e extenso para TLS R
DNSSEC Prticas de Segurana para Administradores de Redes Internet A
TSP e TSAs
Carimbo de tempo R
Normas da ICP-Brasil

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 Especificaes para Redes Sem Fio

Tabela 10: Redes Sem Fio


Componente Especificao Situao
LAN sem fio 802.11 WPA2 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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 31 de 90


3.1.2.7 Especificaes para Resposta a Incidentes de Segurana da Informao

Tabela 11: Resposta a Incidentes de Segurana da Informao

Componente Especificao Situao


Preservao de registros Guidelines for Evidence Collection and Archiving R
Gerenciamento de incidentes em Expectations for Computer Security Incident Response
A
redes computacionais Norma Complementar N o. 05/09
Guide to Integrating Forensic Techniques into Incident
Informtica Forense A
Response

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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 32 de 90


3.1.3. Meios de Acesso Segmento 3

3.1.3.1 Especificaes para Meios de Publicao

Tabela 12: Meios de Publicao

Componentes Especificao Situao


Conjunto de caracteres UNICODE, verso 7.0 e UTF-8 R
HTML, verso 5 A
Formato de intercmbio de hipertexto
XML, verses 1.0 e ou 1.1 A
W3C Mobile Web application Best Practices
R
http://www.w3.org/TR/mwabp/
W3C Geolocation API Specification
Mobile R
http://www.w3.org/TR/mediaont-api-1.0/
W3C Mobile Web Application Best Practices
R
http://www.w3.org/TR/geolocation-API/
Texto puro (.txt) A
Open Document (.odt) A
ODF 1.2 R
Arquivos do tipo documento/publicao
EPUB 3.0.1 R
PDF R
PDF verso aberta PDF/A R
Open Document (.ods) A
Arquivos do tipo planilha
ODF 1.2 R
Open Document (.odp) A
Arquivos do tipo apresentao ODF 1.2 R
HTML (.htm ou .html) R
XML, verses 1.0 ou 1.1 (.xml) R
MySQL Database (.myd, .myi) R
Arquivos do tipo banco de dados para
estaes de trabalho Texto puro (.txt) A
Texto puro (.csv) A
Arquivo do Base (.odb) R
PNG (.png) A
Intercmbio de informaes grficas e imagens SVG (.svg) R
estticas JPEG File Interchange Format (.jpeg, .jpg ou
R
.jfif)
Grficos vetoriais SVG (.svg) R
Animao SVG (.svg) R
Ogg Vorbis (.ogg, .oga) R
udio Ogg FLAC (.ogg, .oga) R
FLAC (.flac) R
Vdeo Ogg Theora (.ogg, .ogv) R
Matroska R
ZIP (.zip) R
GNU ZIP (.gz) R
Pacote TAR (.tar) R
Compactao de arquivos de uso geral Pacote TAR compactado (.tgz ou .tar.gz) R
BZIP2 (.bz2) R
Pacote TAR compactado com BZIP2
R
(.tar.bz2)

Guia de Interoperabilidade: Cartilha Tcnica Pgina 33 de 90


GML, verso 2 ou superior A
Informaes georreferenciadas ShapeFile A
GeoTIFF A

3.1.3.1.1 Codificao dos Dados (encoding)

A interoperabilidade semntica para meios de publicao envolve, primeiramente, a definio do padro


para a representao e manipulao dos dados de acordo com a lngua oficial do pas. Neste caso, a
ePING recomenda a adoo do padro UNICODE, em detrimento do padro ASCII (American Standard
Code for Information Interchange), que no mencionado no documento.

O UNICODE, que consiste na definio de pouco mais de 107 mil caracteres, permite a representao
de informaes em qualquer lngua existente no mundo. Alm da padronizao dos caracteres, o UNICODE
define toda uma metodologia para a codificao de caracteres e operaes de teclado, por exemplo,
operaes com as teclas de funes (F1 a F12).

A manuteno do padro UNICODE realizada pelo Unicode Consortium e conta com a participao
da ISO (Organizao Internacional para Padronizao). A ltima verso do UNICODE, verso 5.2.0, pode
ser consultada no stio do Unicode Consortium (UNICODE CONSORTIUM, 2010).

O UNICODE define dois mtodos de mapeamento de caracteres: UCS (Universal Character Set) e UTF
(Unicode Transformation Format). O UCS, conhecido como UCS-2, um sistema de codificao de largura
fixa, suportado apenas em sistemas obsoletos. O UTF, por sua vez, compreende os padres UTF-7, UTF-8,
UTF-16 e UTF-32. Os nmeros (7, 8, 16 e 32) representam a quantidade de bits necessrios para se
codificar uma caracter. No que diz respeito interoperabilidade semntica, importante considerar os
seguintes pontos:

UCS-2 considerado um padro obsoleto, apenas suportado em sistemas legados.


UTF-7 considerado um padro obsoleto, apenas suportado em sistemas legados.
Arquivos codificados em UTF-8 com caracteres ASCII equivalem a arquivos em padro ASCII.
UTF-16 e UTF-32 so incompatveis com arquivos codificados em ASCII.
O UTF-8 a codificao mais utilizada.

Como recomendao de boas prticas quanto ao uso de UNICODE, sugere-se:

Para codificao de mensagens de cabealho de e-mail:


Content-Type: text/plain; charset="UTF-8"
ou
Content-Type: text/plain; charset="UTF-16"

Para codificao de pginas HTML:

Guia de Interoperabilidade: Cartilha Tcnica 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).

Guia de Interoperabilidade: Cartilha Tcnica Pgina 35 de 90


3.1.3.1.4 Arquivos do tipo documento/ publicao

A interoperabilidade semntica tambm implica no intercmbio de arquivos nos mais diferentes formatos.
Isso porque a utilizao de formatos pouco conhecidos ou de uso no muito frequente dificulta ou impede
que a informao seja recebida e decifrada adequadamente.

Nesse contexto, para a troca de arquivos do tipo documento, a ePING referencia como padres
Adotados (A), arquivos no formato de texto puro (.txt) e em formato Open Document (.odt). Adicionalmente,
na impossibilidade de utilizao desses dois padres, pode-se optar pelo uso de arquivos XML (verses 1.0
e 1.1), com ou sem formatao baseada em XSL (Extensible Stylesheet Language), arquivos HMTL (verso
4.01) e arquivos no padro PDF (Portable Document Format), onde se deve optar por sua verso aberta,
PDF 1.4, quando necessria a preservao digital de documentos.

Para o intercmbio de planilhas eletrnicas e arquivos de apresentao, a ePING Adota (A),


respectivamente, os formatos Open Document (.ods e .odp).

Visando o recebimento de arquivos gerados por sistemas de banco de dados, a ePING Adota (A) como
padro obrigatrio os formatos de texto puro (.txt e .csv). Outros formatos mencionados como
Recomendados (R) so: XML (verso 1.0 e 1.1), MySQL Database (verso 4.0 ou superior) e Open Office
Base (.odb).

No que diz respeito troca de imagens no setor pblico, deve-se adotar os padres PNG (.png). Na
impossibilidade de uso desses padres, a ePING recomenda o uso dos formatos SVG (.svg) e JPEG (.jpeg,
.jpg ou jfif).

Para o tratamento de grficos vetoriais nenhum padro definido como Adotado (A) na ePING.
Entretanto, h a recomendao pelo uso do formato SVG (.svg). A ePING tambm referencia o formato
SVG (.svg) como Recomendado (R) para a definio de arquivos de animao.

No que tange ao uso de arquivos de udio e vdeo, a ePING ainda no define nenhum formato como
Adotado (A). No entanto, recomenda o uso dos seguintes padres: FLAC, Matroska, Ogg Vorbis - formato
aberto para streaming de udio (.oga) e Theora (.ogv). Os formatos que devem ser evitados, segundo a
ePING, so: Audio-Video Interleaved (.avi) com codificao divX ou Xvid, MPEG-4 e WAVE (.wav).

Para o intercmbio de informaes georreferenciadas, deve-se adotar: GML (verso 2.0 ou superior),
ShapeFile ou GeoTIFF.

Por fim, no que diz respeito compactao de arquivos para envio, recomenda-se todos os principais
formatos atualmente em uso, quais sejam: ZIP (.zip), GNU ZIP (.gz) e pacote TAR (.tar, .tgz).

Guia de Interoperabilidade: Cartilha Tcnica Pgina 36 de 90


3.1.3.2 Especificaes para TV Digital

Tabela 13: TV Digital

Componente Especificao Situao


Transmisso Norma ABNT NBR 15601 A
Parte 1 Sistema de transmisso
Codificao Norma ABNT NBR 15602 A
Parte 1 Codificao de Vdeo
Parte 2 Codificao de udio
Parte 3 Sistema de multiplexao de sinais
Multiplexao Norma ABNT NBR 15603 A
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
Receptores Norma ABNT NBR 15604 A
Parte 1 Receptores
Segurana Norma ABNT NBR 15605 A
Parte 1 Tpicos de segurana
Middleware Norma ABNT NBR 15606 A
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
Canal de Norma ABNT NBR 15607 A
Interatividade Parte 1 Protocolos, interfaces fsicas e interfaces de software
Guia de Norma ABNT NBR 15608 A
Operao 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
Acessibilidade ABNT NBR 15610 A
Parte 1 Ferramentas de texto
Parte 2 Funcionalidades sonoras

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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 37 de 90


Uma recomendao da ePING na implementao de solues para a TV digital digna de nota a do
Ginga, um middleware aberto para o desenvolvimento de aplicativos para o SBTVD. Ele constitudo por
um conjunto de tecnologias padronizadas e de inovaes brasileiras, sendo organizado em dois
subsistemas: (i) Ginga-J, para aplicaes procedurais no ambiente de desenvolvimento Java, e (ii) Ginga-
NCL, para aplicaes declarativas escritas em NCL (Nested Context Language). O Ginga resultado de
projetos de pesquisa coordenados pelo Laboratrio de Sistemas Multimdia da PUC-Rio, em conjunto com o
Laboratrio de Aplicaes de Vdeo Digital da Universidade Federal da Paraba (GINGA, 2006).

Guia de Interoperabilidade: Cartilha Tcnica Pgina 38 de 90


3.1.4. Organizao e Intercmbio de Informaes Segmento 4

3.1.4.1 Especificaes para Tratamento e Transferncia de Dados

Tabela 14: Tratamento e Transferncia de Dados


Componentes Especificao Situao
XML
Linguagem para intercmbio de dados A
JSON
XSL
Transformao de dados A
XSLT
Definio dos dados para intercmbio XML Schema A
Estruturao de Dados
Geoespaciais Vetoriais
Informaes georreferenciadas catlogo de feies R
(EDGV) como definido pela
CONCAR

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).

Guia de Interoperabilidade: Cartilha Tcnica 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 5: XML utilizado para transportar dados dentro de uma aplicao.

Quando o XML utilizado para o transporte de informaes entre aplicaes, a ePING adota como
padro o uso da tecnologia de Web Services. Assim, a informao em formato XML transportada atravs
de mensagens SOAP. Para saber mais sobre Web Services, consulte a seo 3.6.4 neste documento, que
trata do assunto sob a tica da interoperabilidade tcnica. A Figura 6 ilustra o processo de transporte de um
arquivo XML, considerando o uso da tecnologia de Web Services.

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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 40 de 90


Figura 7: XML utilizado como conversor de dados no contexto de uma aplicao.

Quando o XML utilizado para consolidar informaes de diferentes fontes de dados, uma aplicao
(consumidor) invoca o servio de troca de dados em outra aplicao (provedor) utilizando a tecnologia de
Web Services. A aplicao de destino, por sua vez, processa a requisio utilizando-se de um conversor de
dados XML que pode se comunicar com outras partes do sistema de destino para executar o
processamento. A Figura 8 ilustra esse caso de utilizao de XML.

Figura 8: XML utilizado como conversor de dados no contexto de vrias aplicaes.

Aps o posicionamento da tecnologia XML em relao arquitetura de software utilizada, recomenda-


se a realizao da modelagem dos arquivos XML. Esta , sem dvida, a atividade mais importante para o
projeto de sistemas que interoperam atravs da tecnologia XML, pois atravs dela, que se minimizam as
chances de alterao da estrutura do arquivo XML no futuro. Logo, os profissionais de TI devem
compreender que os arquivos XML so comparveis s estruturas de bases de dados, no sentido de que
tambm mantm as informaes para uso futuro. Isso implica em dizer que, assim como os bancos de
dados necessitam de modelos, a estrutura dos arquivos XML tambm precisa ser modelada. A Figura 9
fornece uma comparao das estruturas de banco de dados com aquelas em formato XML (ERL, 2004).
Como se pode perceber, os esquemas de banco de dados representam o resultado da modelagem de
dados no contexto de um SGBD (Sistema Gerenciador de Banco de Dados). Da mesma maneira, os XML
Schemas representam o resultado da modelagem dos arquivos XML, pois ditam as regras para a validao
da estrutura de dados de acordo com os requisitos de negcio que se pretende atender.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 41 de 90


Figura 9: Comparao das tecnologias de Banco de Dados e XML
(Modificado de Erl, 2004)

Um ponto de grande importncia a ser observado pelos profissionais de TI durante a modelagem dos
arquivos XML diz respeito nomeao dos elementos que compem esse arquivo propriamente dito. Este
aspecto da modelagem em XML bastante controverso se o considerarmos sob o ponto de vista da
interoperabilidade semntica e dos requisitos tcnicos de desempenho dos sistemas. Por um lado, ter um
nome de elemento XML mais completo e consequentemente maior bom para garantir a compreenso
daquele item de dado, o que atende ao requisito da interoperabilidade semntica. Por outro lado, modelar
elementos XML muito extensos gera arquivos relativamente maiores e que exigem melhor desempenho das
aplicaes para process-los, e tambm maior banda de rede para distribu-los. Assim, essa Cartilha
Tcnica sugere as seguintes prticas para lidar com esse tipo de problema:

Identifique claramente quem sero os consumidores dos arquivos XML a serem modelados. Caso tais
arquivos sejam consumidos apenas por sistemas e no por pessoas, considere reduzir o tamanho dos
arquivos, utilizando nomes menores para os elementos XML.
Para atender aos requisitos de interoperabilidade semntica, faa uso de comentrios sempre que
identificar que alguns elementos foram nomeados de forma muito reduzida.
Utilize nomes genricos, evitando incluir nome de departamentos ou do rgo diretamente no nome dos
elementos XML.
Evite redundncias. Sempre que um elemento XML pertencer a outro elemento-pai, evite repetir o nome
do elemento-pai quando nomear o elemento filho. Por exemplo, um elemento NumCodigoItemNotaFiscal
seria melhor nomeado como NumItem ou CodItem, pois o mesmo j pertence a um elemento-pai que
corresponde aos Itens de uma Nota Fiscal.
Para distribuir arquivos XML extensos pela rede, considere a utilizao de tecnologias de compresso de
dados.

Outra questo associada aos elementos XML e que gera muita discusso diz respeito ao uso de
atributos no lugar de simples elementos XML. Esse um problema complexo que pode envolver diversas
consideraes associadas ao projeto de um sistema de informaes. Assim, a recomendao primria
dessa Cartilha Tcnica utilizar o bom senso na deciso de se representar uma informao como um
atributo ou um elemento XML. Considere, sempre que possvel, as seguintes prticas, descritas por ordem
de importncia:

Guia de Interoperabilidade: Cartilha Tcnica 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

Guia de Interoperabilidade: Cartilha Tcnica 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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 44 de 90


Quando a API selecionada no representar problemas no processamento e gerao de arquivos XML
de acordo com a especificao padro, sem a adio de extenses proprietrias.

Como se pode observar, trabalhar com arquivos XML requer muito mais do que simplesmente se
promover a estruturao da informao no formato de tags. importante considerar todos os aspectos
associados a essa nova tecnologia, sejam eles de desempenho, segurana de dados, estratgia de
desenvolvimento acelerado e padronizado de software ou da modelagem e estruturao da informao.
importante, antes de tudo, definir um planejamento, organizar os dados e tomar decises acertadas
envolvendo arquitetura de software e a utilizao de ferramentas de produtividade.

3.1.4.1.2 Linguagem para Intercmbio de Dados (JSON)

O JSON (JavaScript Object Notation) um padro baseado em texto, derivado da linguagem JavaScript, e
que tem como objetivo prover um formato aberto para a troca de dados entre plataformas de hardware e
software heterogneas. Diferentemente do padro XML, o JSON se prope a ser um padro que seja, ao
mesmo tempo, de fcil leitura e escrita para o usurio comum e passvel de ser processado por
computadores. (JSON.ORG, 2009).

O JSON foi criado por Douglas Crockford por volta de 2001 e em 2002 ele foi divulgado na Internet
atravs do stio da organizao JSON (JSON.ORG, 2009). A partir de 2005 empresas como Yahoo! e
Google aderiram ao padro como meio de promover o intercmbio de dados e em julho de 2006, aps a
grande e rpida aceitao do padro pelo mercado, Douglas Crockford formalizou a especificao do JSON
atravs da RFC 4627 (CROCKFORD, 2006).

O JSON tem sido bastante utilizado para transmitir dados entre um servidor e uma aplicao Web,
servindo assim como uma alternativa ao padro XML. Ele difere, no entanto, do XML, principalmente porque
um padro muito simplificado e no baseado na estrutura de tags, o que tambm limita a sua utilizao
em casos onde a semntica da informao deve ser garantida. Em contrapartida, a limitao apresentada
quanto semntica se traduz em ganho na representao mais reduzida da informao que se pretende
transmitir. Alguns adeptos desse padro acreditam que um documento JSON apresenta tamanho 30%
menor que o mesmo arquivo representado em XML (JSON.ORG, 2009).

Um arquivo JSON possui a extenso .json e referenciado pelos protocolos de Internet atravs do
MIME type application/json. Os tipos de dados bsicos suportados pelo JSON so: (i) nmeros (integer ou
real), (ii) texto (string), (iii) valor lgico (boolean), (iv) sequncia de valores (array), (v) coleo de dados,
definidos por pares do tipo chave e valor (object), (vi) tipos de dados vazio ou nulo (null). A Figura 10 ilustra
um exemplo de descrio dos dados de uma pessoa no padro JSON.

Guia de Interoperabilidade: Cartilha Tcnica 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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 46 de 90


As Figuras 11 e 12 apresentam respectivamente um exemplo de documento XML e XSL. A Figura 13
ilustra o resultado final da transformao XSL sobre a informao contida no documento XML.

<?xml version="1.0" encoding="iso-8859-1"?>


<catalog>
<cd>
<title>Empire Burlesque</title>
<artist>Bob Dylan</artist>
<country>USA</country>
<company>Columbia</company>
<price>10.90</price>
<year>1985</year>
</cd>
<cd>
<title>Hide your heart</title>
<artist>Bonnie Tyler</artist>
<country>UK</country>
<company>CBS Records</company>
<price>9.90</price>
<year>1988</year>
</cd>
<cd>
<title>Greatest Hits</title>
<artist>Dolly Parton</artist>
<country>USA</country>
<company>RCA</company>
<price>9.90</price>
<year>1982</year>
</cd>
<cd>
<title>Still got the blues</title>
<artist>Gary Moore</artist>
<country>UK</country>
<company>Virgin records</company>
<price>10.20</price>
<year>1990</year>
</cd>
<cd>
<title>Eros</title>
<artist>Eros Ramazzotti</artist>
<country>EU</country>
<company>BMG</company>
<price>9.90</price>
<year>1997</year>
</cd>
<cd>
<title>One night only</title>
<artist>Bee Gees</artist>
<country>UK</country>
<company>Polydor</company>
<price>10.90</price>
<year>1998</year>
</cd>
<cd>
<title>Sylvias Mother</title>
<artist>Dr.Hook</artist>
<country>UK</country>

Guia de Interoperabilidade: Cartilha Tcnica 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

Figura 13: Resultado final da transformao XSL


(Fonte: W3Schools)

Guia de Interoperabilidade: Cartilha Tcnica Pgina 48 de 90


3.1.4.1.4 Definio de Dados para intercmbio (XML Schemas)

A tecnologia de XML permite a criao de vocabulrios que podem ser utilizados pelas organizaes
pblicas para trocar informaes de maneira padronizada. Alternativamente, os documentos no formato
XML podem ser transformados em outros tipos de documento de modo a facilitar a sua exibio ou
impresso, o que de responsabilidade das tecnologias XSL. Outra tecnologia da famlia XML que merece
destaque e bastante utilizada no intercmbio de dados a tecnologia de XML Schemas.

Essa tecnologia permite a criao de documentos, denominados schemas, que tem por objetivo validar
os documentos XML. A validao em questo baseada na estrutura modelada para o documento XML, o
que envolve o atendimento s regras de negcio, tipos de dados, relacionamentos entre os elementos XML
e restries aplicadas aos dados. Em outras palavras, a tecnologia de XML Schemas define o que pode ser
includo ou no em um arquivo XML. Logo, da mesma forma que o schema de banco de dados define as
regras de estruturao dos objetos de um banco de dados, um documento XML Schema define as regras de
estruturao de um arquivo XML.

Neste contexto, importante saber diferenciar quando um arquivo XML bem formado (well-formed) e
quando vlido (valid). De um modo geral, um arquivo XML dito bem formado quando ele atende aos
requisitos de estruturao de qualquer documento XML, requisitos estes definidos pelo W3C. Uma breve
lista de verificao quanto formao de documentos XML fornecida a seguir:

Toda tag deve ser fechada; admite-se o fechamento abreviado de tags vazias.
Tags no podem se sobrepor, mas devem ser perfeitamente aninhadas.
Documentos XML s podem ter uma nica raiz.
Nomes de elementos XML devem obedecer s convenes de nomeao definida pelo W3C.
XML um documento case-sensitive.
Espaos so mantidos em documentos XML.

Os documentos XML so ditos vlidos quando atendem s regras de estruturao definidas em um


documento XML Schema. Logo, enquanto a formao do documento XML dada pelo atendimento s
regras bsicas de criao de qualquer documento XML, a validade verificada de acordo com regras de
negcio definidas pela equipe tcnica durante a etapa de modelagem do documento XML. A lista a seguir
fornece os tipos de validaes que podem ser elaboradas com o uso de XML Schemas:

Define quais elementos e atributos podem aparecer no documento XML.


Define a relao entre elementos (pai-filho).
Define a ordem em que os elementos filhos devem aparecer no documento XML e total de elementos
filhos permitidos.
Define se um elemento XML pode estar vazio ou deve incluir algum valor.
Define tipos de dados para os elementos e atributos XML.
Define valores padro ou fixo para elementos e atributos XML.

Guia de Interoperabilidade: Cartilha Tcnica 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)

Guia de Interoperabilidade: Cartilha Tcnica 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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 51 de 90


3.1.4.2 Especificaes para Vocabulrios e Ontologias

Tabela 15: Vocabulrios e Ontologias

Componentes Especificao Situao


Descrio de recursos RDF R
Especificao de vocabulrios para RDF Resource Resource Description
R
Description Framework (RDF) Schema Framework (RDF) Schema
SKOS (Simple Knowledge
Sistemas de Organizao do Conhecimento R
Organization System)
Linguagem de definio de ontologias na web OWL (Web Ontology Language) R

3.1.4.2.1 Descrio de Recursos (RDF)

O RDF (Resource Description Framework) um conjunto de especificaes desenvolvidas pelo W3C com o
objetivo de representar e intercambiar informaes na Web. Sua caracterstica principal a de facilitar a
combinao de diferentes metadados, permitindo assim, a evoluo natural e facilitada das informaes ao
longo do tempo (W3C, 2010).

O fundamento bsico do RDF a linguagem XML, que lhe fornece a sintaxe necessria para a
definio da especificao em um padro aberto. O W3C publicou a primeira especificao do RDF em
1999, e em 2004 essa verso foi atualizada para o que o W3C denomina de recomendaes e que, na
verdade, representa um conjunto de especificaes que se constitui a famlia RDF. A Tabela 17 descreve o
conjunto de especificaes ou recomendaes que compem toda a estrutura RDF:

Tabela 16: Estrutura do RDF (W3C, 2010)

Especificao Descrio
RDF: Concepts and Abstract Descreve os conceitos bsicos do RDF e define uma sintaxe abstrata
Syntax no qual o padro definido.
RDF Semantics 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
RDF Primer
pode ser utilizado e como se pode construir um vocabulrio baseado
neste padro.
Define uma linguagem de propsito geral para representar tipos
RDF Vocabulary Description
diversos de informaes na Web. Permite a definio de recursos da
Language 1.0: RDF Schema
Web atravs de classes, propriedades e valores.
RDF/XML Syntax Specification Define a sintaxe XML utilizada para descrever o RDF.
Descreve os casos de testes desenvolvidos pelo grupo de trabalho do
RDF Test Cases
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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 52 de 90


Atravs do fornecimento de um mtodo padro de referncia a elementos de metadados e tambm de
contedo, o RDF se consolida como um padro para que as aplicaes possam interoperar de maneira
mais facilitada. Ele define uma linguagem de metadados para a representao das informaes na Web e
prov tambm um modelo completo para a descrio e criao de relacionamentos entre os recursos
disponveis. Para o RDF, um recurso, tambm chamado de subject, pode ser uma coisa, uma pessoa, uma
msica ou mesmo uma pgina inteira da Web que unicamente identificado por uma URI (Uniform
Resource Identifier). Esses recursos, so associados a objetos (objects) que definem o valor ou contedo
da informao. A Figura 16 ilustra e define os elementos bsicos que compem a especificao RDF.

Figura 16: Elementos bsicos do RDF

Guia de Interoperabilidade: Cartilha Tcnica 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>
.
.
.

Figura 17: Exemplo de um documento RDF


(Fonte: W3Schools)

3.1.4.2.2 Resource Description Framework Schema

Uma ontologia define (especifica) os conceitos, relacionamentos e outras especificidades que so


relevantes para modelar um domnio. Essa definio realizada especificando um vocabulrio (classes,
relacionamentos e afins), e assim, provendo significado para o mesmo e criando restries formais para seu
uso.

O Resource Description Framework (RDF) uma linguagem geral para representar informaes na
Web. O Resource Description Framework Schema (RDFS) uma linguagem que utiliza o RDF para
descrever vocabulrios/termos em RDF. Dessa forma o RDFS uma extenso semntica do RDF.

O RDFS define uma coleo de recursos RDF que podem ser usadas para descrever propriedades de
outros recursos RDF em vocabulrios RDF especficos. O ncleo do vocabulrio definido no namespace

Guia de Interoperabilidade: Cartilha Tcnica 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 Sistemas de Organizao do Conhecimento (SKOS)

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 http://www.w3.org/2000/01/rdf-schema#
2 http://www.w3.org/1999/02/22-rdf-syntax-ns#
3 http://www.w3.org/2004/02/skos/

Guia de Interoperabilidade: Cartilha Tcnica 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" .

Guia de Interoperabilidade: Cartilha Tcnica 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-03-
12T07: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-producao-
cientifica">
<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-09-
23T07: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-producao-
cientifica"/>
</rdf:Description>

</rdf:RDF>

3.1.4.2.4 Web Ontology Language

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.

4 http://www.w3.org/TR/owl-features/

Guia de Interoperabilidade: Cartilha Tcnica Pgina 57 de 90


Exemplo da Ontologia do Oramento Federal Brasileiro 5:

<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [
<!ENTITY owl "http://www.w3.org/2002/07/owl#" >
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
<!ENTITY owl2xml "http://www.w3.org/2006/12/owl2-xml#" >
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
<!ENTITY siop "http://vocab.e.gov.br/2012/08/loa2012#" >
]>
<rdf:RDF xmlns="http://vocab.e.gov.br/2012/08/loa2012#"
xml:base="http://vocab.e.gov.br/2012/08/loa2012#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl2xml="http://www.w3.org/2006/12/owl2-xml#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:siop="http://vocab.e.gov.br/2012/08/loa2012#">
<owl:Ontology rdf:about=""/>

<owl:Class rdf:about="#Esfera">
<rdfs:subClassOf rdf:resource="#Classificador"/>
<rdfs:comment rdf:datatype="&xsd;string"
>Classe nomeada cujos elementos representam os tipos de orcamento definidos para o Governo:
orcamento fiscal (10), orcamento da seguridade social (20, e orcamento de investimento
(30).</rdfs:comment>
</owl:Class>
<owl:Class rdf:about="#Orgao">
<rdfs:subClassOf rdf:resource="#Classificador"/>
<rdfs:comment rdf:datatype="&xsd;string"
>Os elementos dessa classe referem-se aos orgaos orcamentarios que possuem vinculados a si,
os elementos da classe UnidadeOrcamentaria atraves da propriedade temOrgao. Orgaos nao
correspondem necessariamente a uma estrutura administrativa, como ocorre, por exemplo, com alguns
fundos especiais e com alguns orgaos tais como (i) Transferencias a Estados, Distrito Federal e
Municipios, (ii) Encargos financeiros da Uniao, (iii) Operacoes oficiais de credito, (iv) Refinanciamento da
divida publica mobiliaria federal, e (v) Reserva de contingencia.</rdfs:comment>
</owl:Class>

<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,

5 http://vocab.e.gov.br/

Guia de Interoperabilidade: Cartilha Tcnica 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>

3.1.4.2.5 Identificador Uniforme de Recurso (URI)

O Identificador Uniforme de Recurso URI um texto que identifica um recurso abstrato ou real que
obedece um conjunto de regras para sua formao. O URI prove uma forma simples e extensvel de
identificar um recurso. Ele abrange tanto o Localizador Uniforme de Recurso - URL como o Nome Uniforme
de Recurso - URN podendo pertencer a uma dessas classes ou de ambas, conforme mostra a figura a
seguir.

Figura 18: Formao do URI

O URI permite que diferentes identificadores sejam usados no mesmo contexto inclusive com
diferentes mecanismos de acesso. Permite tambm a incluso de outros identificadores sem que os novos
interfiram com os identificadores j existentes. No contexto de URI um recurso pode ser qualquer coisa
identificvel por uma URI. Inclusive objetos fsicos, uma pessoa, livros, e abstratos como um relacionamento
de empregador-empregado.

O conjunto de regras que define um schema URI de responsabilidade da equipe envolvida com a
representao dos recursos. desejvel que as URIs sejam perenes durante um tempo e seja possvel seu
acesso nesse perodo. Exemplos de URI podem ser:

mailto:joao.da.silva@exemplo.com

tel:+55-99-9999-9999

http://localhost/

urn:oasis:names:specification:docbook:dtd:xml:4.1.2

Guia de Interoperabilidade: Cartilha Tcnica Pgina 59 de 90


Onde o primeiro identifica o email de joao.da.silva na rede exemplo.com, o segundo informa um
telefone no Brasil, o terceiro informa o endereo do localhost e a sua forma de acesso (HTTP) e o ltimo
uma URN para uma especificao Oasis.

No governo federal brasileiro h o conjunto de regras para publicao de Dados Abertos chamado
Poltica 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

Guia de Interoperabilidade: Cartilha Tcnica Pgina 60 de 90


3.1.5. reas de Integrao para Governo Eletrnico Segmento 5

3.1.5.1 Especificaes para Temas Transversais s reas de Atuao de Governo

Tabela 17: Temas Transversais s reas de Atuao de Governo

Componente Especificao Situao


Linguagem para Execuo de Processos BPEL4WS v1.1 R
Notao de Modelagem de Processos BPMN 1.0 A
Intercmbio de Informaes Financeiras XBRL A
Legislao, Jurisprudncia e Proposies Legislativas LexML 1.0 R
Integrao de Dados e Processos MGD A
WMS, WFS, WCS, CSW e
Filter Encoding verso 1.0 ou A
Interoperabilidade entre sistemas de informao geogrfica posterior
WFS-T, WKT R

3.1.5.1.1 Linguagem para Execuo de Processos (BPEL4WS);

O BPEL4WS (Business Process Execution Language for Web Services), tambm conhecido simplesmente
como BPEL, uma linguagem para a definio e execuo de processos de negcio baseada no conceito
de orquestrao de servios. Embora no seja a nica linguagem com essa finalidade, sem dvida a mais
utilizada atualmente.

Existem duas formas de representar processos de negcio, quais sejam: a forma notacional ou grfica,
voltada para comunicao entre pessoas, e utilizando-se XML (Extensible Markup Language), voltada para
processamento ou execuo automatizada. A forma notacional ou grfica definida pela especificao
BPMN (Business Process Modeling Notation). A representao de processos utilizando XML, por sua vez,
de responsabilidade da especificao BPEL4WS que possui, neste campo de atuao, alguns competidores
como, por exemplo, BPML (Business Process Modeling Language) e XPDL (XML Process Definition
Language). A verso 2.0 do BPMN, cujo estudo est sendo iniciado, tambm define a representao de
processos de negcio em XML.

A especificao BPEL considerada uma extenso dos padres existentes para a tecnologia de Web
Services. Isso porque antigamente, os Web Services eram limitados a interaes do tipo stateless, o que
significa dizer que o estado de comunicao entre consumidor e provedor no era mantido durante as
transaes. Nas chamadas de servios stateless, cada transao nica, o que dificulta o aproveitamento
de dados e o uso de mecanismos de controle de transao entre duas ou mais invocaes do mesmo
servio. Com o advento do BPEL e outras tecnologias de orquestrao e coreografia de processos, a
conversao entre processos pde ser desenvolvida utilizando a tecnologia de Web Services ao mesmo
tempo em que se faz uso dos mecanismos de chamada de servios do tipo stateful, o que permite preservar
o estado atual do processo entre as diversas chamadas. Assim, pode-se definir BPEL como sendo uma

Guia de Interoperabilidade: Cartilha Tcnica 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-a-
passo.

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

Guia de Interoperabilidade: Cartilha Tcnica Pgina 62 de 90


desempenho, reduo do retrabalho e a eliminao de atividades desnecessrias. Mas, para se construir
sistemas baseados em processos de negcio necessrio, inicialmente, se modelar o processo de forma a
represent-lo e descrev-lo de maneira padronizada. Neste cenrio, o padro BPMN (Business Process
Modeling Notation) fornece a sua contribuio.

O BPMN uma especificao que define uma notao grfica padronizada a ser utilizada pelos
analistas de processos para modelar processos. A modelagem de processos pode ser realizada em
diferentes nveis de abstrao, tambm chamados de nveis de granularidade. A literatura atual define
genericamente trs possveis nveis de granularidade: modelagem descritiva, modelagem analtica e
modelagem para execuo de processos.

A modelagem descritiva de processos aquela que define a viso mais genrica da execuo das
atividades de trabalho. Geralmente neste tipo de modelagem so ignoradas regras e validaes de dados
em um nvel mais detalhado. O objetivo simplesmente comunicar o que executado, para quem, quando
e onde. A forma de execuo das atividades, ou seja, o como fazer descrita pela sequncia das
atividades, pela presena de alguns subprocessos e tambm por descries textuais fornecidas pelo
analista de processos.

A modelagem analtica de processos mais detalhada do que a modelagem descritiva no sentido de


que j contempla a incluso de regras de negcio simples, alm da capacidade de simular a execuo do
processo utilizando cenrios de negcio definidos pelo analista de processos. Entretanto, ainda se encontra
bastante longe de atender aos requisitos para a construo de um sistema informatizado.

A modelagem para execuo dos processos, por sua vez, fornece a viso mais completa de todas, pois
alm de contemplar todos os recursos das abordagens anteriores, tambm possui a capacidade de tratar
eventos, excees, entrada de dados, processamento de dados, enfim, praticamente todas as
preocupaes inerentes implementao de um sistema informatizado completo.

Teoricamente, o BPMN pode ser utilizado para modelar quaisquer dos trs nveis de granularidade e,
por isso, obteve tanta aceitao por parte da comunidade de profissionais do setor de processos.
Entretanto, devido s complexidades existentes na modelagem para execuo de processos, o BPMN por si
s no suficiente, o que levou a criao de um novo padro denominado BPEL4WS, discutido na seo
3.5.1.

A especificao BPMN foi originalmente desenvolvida pelo BPMI (Business Process Management
Initiative) e atualmente mantida pelo OMG (Object Management Group). O BPMN baseado na notao
de fluxograma, embora fornea vrios novos elementos, principalmente para a representao de eventos,
regras de negcio e mensagens. A verso 2.0 do BPMN, cujo estudo j foi iniciado, traz evolues para
fortalecer o BPMN neste e em outros aspectos.

Guia de Interoperabilidade: Cartilha Tcnica 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.

Figura 19: Principais componentes da notao BPMN


(Fonte: OMG, 2005)

Como se pode observar na Figura 19, diversos elementos do BPMN j so conhecidos, o que nos leva
concluso de que essa especificao tem como meta padronizar a notao utilizada para modelagem de
processos entre os diversos fornecedores deste tipo de soluo.

Outra vantagem de se utilizar a especificao BPMN que ela fornece possibilidades para se mapear o
processo para o padro BPEL, propiciando assim a converso da verso grfica do processo para uma
verso executvel. A Figura 20 ilustra um processo de negcio do governo, mapeado em BPMN.

Figura 20: Exemplo de um processo de negcio mapeado em BPMN.

Guia de Interoperabilidade: Cartilha Tcnica 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 contbeis-
financeiros) 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

Guia de Interoperabilidade: Cartilha Tcnica 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.

Figura 21: Referncia a documentos jurdicos no LexML


(Fonte: TICONTROLE, 2010)

Outra forma de se consultar o LexML atravs da sua interface grfica (Figura 22), disponvel no
endereo http://www.lexml.gov.br/.

Figura 22: Interface de consulta do LexML


(Fonte: TICONTROLE, 2010)

3.1.5.1.5 Modelo Global de Dados - MGD

O Modelo Global de Dados (MGD) uma iniciativa do Ministrio do Planejamento, Oramento e Gesto
(MP), Ministrio da Fazenda (MF) e SERPRO que surgiu para simplificar e melhorar a Gesto dos Dados do
Macroprocesso de Planejamento, Oramento e Finanas. Este modelo tem como objetivo identificar o

Guia de Interoperabilidade: Cartilha Tcnica 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 entidade-
relacionamentos, 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:

Mapear os dados (Entidades) utilizados pelo Macroprocesso, as integraes atuais e as possveis


integraes;
Associar dados a processos (Viso de Negcio), favorecendo sua normalizao;
Consolidar conceitos sobre a definio dos dados entre os diferentes envolvidos;
Permitir uma viso integrada dos dados e sua utilizao nos diferentes contextos;
Minimizar impactos de mudanas nos dados que se encontram dentro dos Sistemas de Gesto
Administrativa (Estruturadores);
Sistematizar e aperfeioar a construo de novas solues, a partir do uso de padres focados na
interoperabilidade;
Permitir a prospeco de novas estruturas de dados com o objetivo de melhorar a qualidade da
informao;
Contribuir para a uma melhor Gesto Publica por meio de solues mais eficientes, capazes de
prover informaes mais confiveis e precisas para a tomada de deciso;
Promover o reuso dos dados, evitando assim possveis redundncias;
Favorecer a implementao de Modelos Corporativos de Dados.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 67 de 90


O que o MGD conseguiu demonstrar para o Macroprocesso de Planejamento, Oramento e Finanas
sobre a tica de Dados, e mais tarde sobre a viso de processos, serviu para que ele fosse incorporado
ePING em Dezembro de 2010 com um objetivo maior: Ampliar a viso integrada e detalhada dos dados e
processos que suportam os macroprocessos de Governo. Desta forma foi colocado na ePING como a
arquitetura de interoperabilidade de dados e processos.

Atualmente o MGD operacionalizado pelo SERPRO, que a cada etapa de evoluo do modelo
publica um compndio que apresenta as informaes necessrias ao entendimento do negcio, as
entidades relacionadas ao negcio e tambm os principais processos de negcio. Assim, o MGD gera como
resultado uma documentao direcionada ao negcio e aos profissionais de TIC responsveis pela
construo de solues integradas envolvendo os Macroprocessos do Governo Federal.

Cabe aos rgos fazer uso do MGD como uma ferramenta que auxilie a definio de demandas de
evoluo dos sistemas de informao permitindo que os Gestores dos Sistemas busquem a no replicao
das informaes no Governo Federal fortalecendo a interoperabilidade e a capacidade de integrao dos
sistemas. Desta forma o Governo passa a contar com uma capacidade maior de gerar sistemas e solues
que forneam informaes teis para a tomada de deciso dos rgos da Administrao Pblica Federal
melhorando a Gesto Pblica.

Mais informaes sobre o projeto MGD podem ser consultadas no stio


http://modeloglobaldados.serpro.gov.br.

3.1.6.1.6 Interoperabilidade entre sistemas de informao geogrfica

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.

Guia de Interoperabilidade: Cartilha Tcnica 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 Especificaes para Web Services

Tabela 18: Web Services

Componente Especificao Situao


Infraestrutura de registro UDDI v3.0.2 R
Linguagem de definio do servio WSDL 1.1 A
SOAP v1.2
Protocolo para acesso a Web Services A
HTTP/1.1 (REST)

3.1.5.2.1 Arquitetura de Software e Interoperabilidade Tcnica

A interoperabilidade entre sistemas diferentes a chave para a comunicao envolvendo ambientes de


hardware e software heterogneos. Entretanto, como no se pode mudar o hardware a todo o momento,
modifica-se o software e seus componentes internos, o que requer que este software seja construdo com
base em uma arquitetura que favorea a interoperabilidade desejada.

A arquitetura de software define a estrutura de um sistema ou programa de computador de modo a


ressaltar seus elementos, os relacionamentos entre eles e as interfaces de comunicao do sistema com o
mundo exterior (BASS, CLEMENTS e KAZMAN, 2003). No padro IEEE 12207.0-1996 que define os
processos da Engenharia de Software, o tema Arquitetura de Software utilizado para se descrever a
estrutura de alto nvel dos componentes do sistema computacional, o que implica em dizer que as interfaces
de comunicao internas e externas devem ser enfatizadas. Como se pode perceber atravs dessas duas

Guia de Interoperabilidade: Cartilha Tcnica 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).

Guia de Interoperabilidade: Cartilha Tcnica 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

O desenvolvimento de software baseado na abstrao do mundo real, ou seja, cada elemento da


realidade observado e analisado sob determinados pontos de vista. Segundo Josuttis (2007), SOA baseia-
se na abstrao de um problema do ponto de vista do negcio das organizaes e o servio um conceito
essencial nessa abordagem.

Servios representam funcionalidades ou partes de uma ou mais funcionalidades que podem ser
descobertas e utilizadas por outras aplicaes ou outros servios. Os servios so independentes de
plataformas e linguagens de programao, o que garante a sua plena utilizao em ambientes de software e
hardware heterogneos.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 71 de 90


3.1.5.2.3 Opo por Web Services

Web Services so tipicamente APIs baseadas em tecnologias de Internet. Essas APIs so acionadas
atravs de HTTP ou, menos frequentemente, atravs do protocolo SMTP. Web Services podem ser
classificados em dois grupos: (i) Web Services baseados no protocolo SOAP (Simple Object Access
Protocol), e (ii) Web Services em conformidade com a arquitetura REST (Representational State Transfer).

A ePING recomenda tanto a utilizao de Web Services que usam mensagens XML seguindo o padro
SOAP, quanto a utilizao do protocolo HTTP para projetos baseados em REST. Em sistemas dessa
natureza, a descrio das operaes do servio feita em arquivo WSDL, de modo que possa ser lida e
tratada diretamente pelos aplicativos com quem vai interagir. Independentemente da tecnologia utilizada
(SOAP ou REST), indispensvel que cada Web Service implementado seja documentado com preciso e
clareza.

Antes do advento da tecnologia de Web Services, a comunicao entre sistemas pela Internet
baseava-se na troca de informao atravs de brokers centralizados ou conectores desenvolvidos para a
troca de dados entre aplicaes especficas. Isso dificultava, ou mesmo inviabilizava, o crescimento de
atividades como o comrcio eletrnico, uma vez que solues particulares, circunscritas a um domnio
limitado, precisavam ser desenvolvidas cada vez que duas ou mais empresas necessitavam trocar dados
eletronicamente.

A tecnologia de Web Services representou, ento, o estado da arte em tecnologia de sistemas


distribudos, uma vez que permitia a troca de informaes atravs de aplicativos modulares, reutilizveis,
baseados em padres abertos e acessveis pela Internet. A tecnologia de Web Services tem a vantagem de
permitir a construo de aplicativos em qualquer plataforma, utilizando-se de qualquer paradigma de
desenvolvimento de software e linguagem de programao, e possibilitando a qualquer sistema comunicar-
se com outros sistemas atravs de mensageria baseada em XML.

Essa a questo fundamental envolvendo Web Services: o advento de uma gramtica comum, no-
proprietria e universalmente aceita que significou, por si s, uma enorme mudana na maneira como
aplicativos distintos conversam entre si atravs de uma rede de comunicao de dados. Entre os principais
ganhos a serem auferidos com a utilizao de Web Services como soluo de interoperabilidade, pode-se
enumerar:

Longevidade o fato de operarem atravs de redes pblicas e no-proprietrias, aliado ao seu


carter ecumnico no que tange a paradigmas de desenvolvimento, ambientes e linguagens de
programao, garante que os servios desenvolvidos com Web Services tenham vida longa, muito
alm das solues proprietrias com que hoje dividem o cenrio de interoperabilidade de TIC;
Facilidade Web Services permitem que a lgica negocial de qualquer sistema possa ser
expostas na Web. Analistas de negcio e desenvolvedores podem construir solues para
situaes particulares combinando os Web Services adequados e utilizando, nesse processo, no

Guia de Interoperabilidade: Cartilha Tcnica Pgina 72 de 90


apenas suas linguagens de programao prediletas, mas tambm a estratgia de implementao
de sua escolha. Com Web Services, o compartilhamento de funcionalidades atravs da Web pode
ser feita sem qualquer conhecimento de detalhes operacionais especficos dos sistemas
envolvidos, sendo necessria apenas a aderncia aos padres publicados;
Reuso o modelo baseado em Web Services garante a reutilizao sempre que necessrio. Esse
modelo viabiliza ainda que o cdigo legado possa ser estendido e exposto na Internet, sem o
carter de intratabilidade comum a esses casos;
Universalidade a tecnologia de Web Services foi desenvolvida para ser facilmente acessvel
tanto a seres humanos (atravs, por exemplo, de um aplicativo Web) como a computadores
(atravs, por exemplo, de uma API). Sua aderncia ao ambiente de Internet e aos padres abertos
para comunicao entre sistemas distribudos, garantem que eles possam ser acessados
praticamente de qualquer lugar, utilizando infraestrutura j existente e respeitando sistemas de
segurana j instalados, como firewalls e filtros.

3.1.5.2.4 Papel do SOAP (Simple Object Access Protocol)

SOAP um protocolo que define uma maneira uniforme para o


trnsito de dados codificados como documentos XML. SOAP
define tambm um modo de execuo de RPCs (Remote
Procedure Calls), quase sempre se utilizando de HTTP como
mecanismo de comunicao subjacente. Embora venha
sofrendo forte concorrncia da arquitetura REST, ainda hoje o
mecanismo de preferncia no desenvolvimento e invocao de
Web Services. As mensagens SOAP so documentos XML, e
como tal, devem aderir especificao formal dessa linguagem.

Figura 23: Estrutura do SOAP


(Fonte: Wikipedia)

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;

Guia de Interoperabilidade: Cartilha Tcnica Pgina 73 de 90


Modelo de extensibilidade define os conceitos e mdulos SOAP;
Protocolo subjacente de enlace descreve as regras para o enlace com protocolos de transporte
subjacente a serem usados na troca de mensagens entre ns SOAP;
Modelo de mensagem define a estrutura de uma mensagem SOAP.

Desses elementos, o mais relevante o modelo de processamento, que descreve um modelo


distribudo, seus participantes e tambm como uma mensagem SOAP deve ser processada. Esse modelo
de processamento define os seguintes ns:

SOAP sender um n que transmite uma mensagem SOAP;


SOAP receiver um n que aceita uma mensagem SOAP;
SOAP message path o conjunto de ns atravs dos quais trafega uma mensagem SOAP;
SOAP originator o remetente de origem de uma mensagem (o ponto de incio de um SOAP
message path);
SOAP intermediary enderevel de dentro de uma mensagem SOAP, pode ser tanto um SOAP
receiver como um SOAP sender. Processa os blocos de cabealho que se destinam a ele e
retransmite a mensagem para que possa chegar a seu destinatrio final;
Ultimate SOAP receiver destinatrio final de uma mensagem SOAP, responsvel pelo
processamento do corpo da mensagem e dos blocos de cabealho a ele endereados.

As Figuras 24 e 25 apresentam, respectivamente, exemplos de requisio e resposta SOAP.

POST /InStock HTTP/1.1


Host: www.example.org
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:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>

</soap:Envelope>

Figura 24: Exemplo de uma requisio SOAP


(Fonte: W3Schools)

Guia de Interoperabilidade: Cartilha Tcnica 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.

Guia de Interoperabilidade: Cartilha Tcnica 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 GET PUT POST DELETE


Coleo de elementos URI Lista (List) Substitui Cria (Create) um Destri
(http:/exemplo.com/recursos/) dados dos (Replace) a novo elemento (Delete) a
elementos da coleo inteira na coleo coleo
coleo por outra
Elemento URI individual Obtm Atualiza Trata o elemento Remove
(http:/exemplo.com/recursos/123) (Retrieve) a (Update) o especificado (Delete) da
representao elemento como uma coleo o
do elemento especificado coleo e cria elemento
especificado, ou, se (Create) nela um especificado
expresso em inexistente, novo elemento
um MIME type cria (Create)
apropriado um novo
elemento

Guia de Interoperabilidade: Cartilha Tcnica Pgina 76 de 90


3.1.5.2.6 Papel do WSDL (Web Services Description Language)

A especificao WSDL define um


formato XML para documentos onde
servios e mensagens so descritos
de maneira abstrata, independente de
seu uso ou implementao.
Essas definies esto livres para
serem reutilizadas em situaes e
contextos distintos. Documentos
WSDL referem-se a servios, que so
descritos como uma coleo de pontos
(endpoints ou, na verso inicial, ports)
em uma rede de computao
distribuda.

Figura 26: Conceitos definidos nas WSDL 1.0 e 2.0


(Fonte: Wikipedia)

Um port consiste na associao entre um endereo na rede e um mecanismo de enlace reutilizvel


(binding), enquanto colees de ports definem servios. Mensagens (messages) so descries abstratas
dos dados sendo transmitidos, e interfaces (na verso inicial, port types) so colees abstratas das
operaes suportadas. O protocolo concreto e o formato da mensagem para um port type em particular
constituem um enlace reutilizvel, que promove a ligao entre o port type e as mensagens e operaes.
atravs dessas abstraes que o WSDL descreve a interface pblica de um Web Service.

Uma mensagem WSDL contm a informao necessria execuo de uma operao, e consiste
logicamente de uma ou mais partes. Cada parte associada a um atributo que tipifica a mensagem,
podendo ser entendida com uma descrio lgica do contedo da mensagem, ou mesmo representar um
parmetro na mensagem. As mensagens foram excludas na verso mais recente, que determina que, na
definio de corpos de inputs e outputs, se faa uma referncia direta a um documento XML Schema.

Em 2007, o WSDL 2.0 tornou-se uma recomendao oficial do W3C. Os objetos que fazem parte da
verso atual dessa especificao so:

1. service um service pode ser entendido como um recipiente para um conjunto de funes
de um sistema que foram expostas aos protocolos da Web;
2. endpoint define o endereo ou ponto de conexo para um Web Service, sendo
tipicamente representado por uma simples url;

Guia de Interoperabilidade: Cartilha Tcnica Pgina 77 de 90


3. binding - especifica a interface e define o estilo do enlace SOAP, o tipo de transporte
(protocolo SOAP) e as operaes pertinentes;
4. interface o elemento <interface> define um Web Service, as operaes que podem ser
executadas e as mensagens a serem utilizadas na execuo das operaes;
5. operation uma operao pode ser comparada a um mtodo, procedimento ou funo de
uma linguagem de programao;
6. 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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 78 de 90


3.1.5.2.8 Enterprise Service Bus (ESB)

Um ESB (Enterprise Service Bus) uma infraestrutura de software que facilita a interoperabilidade entre
aplicaes heterogneas. O ESB uma pea importante na implantao da SOA, pois prov a troca
facilitada de mensagens, executa e controla transaes complexas, orquestra servios, e fornece recursos
de notificao baseado no modelo publish-subscribe, alm de outras facilidades.

A tecnologia de ESB foi desenvolvida para atender as demandas de integrao entre aplicaes
distribudas e em plataforma heterognea de hardware e software, de modo a se evitar os problemas
inerentes s plataformas de integrao baseadas na tecnologia de EAI (Enterprise Application Integration).
No modelo mais comum de EAI, conhecido como hub and spoke, as aplicaes trabalham atravs de um
nico e centralizado broker, que constitui o canal de comunicao entre elas. Esse nico broker ou
middleware, como tambm conhecido, embora apresente uma arquitetura mais simplificada e fcil de
manter, tambm representa um nico ponto de falha para toda a arquitetura. O ESB, por outro lado,
introduziu a capacidade de distribuio do middleware provendo a possibilidade de se elaborar
diversificadas configuraes do ambiente tecnolgico que passou a ser composto por diversos brokers
interconectados. Outra diferena entre a tecnologia de ESB e a EAI consiste no fato de que o primeiro
facilita o desacoplamento dos sistemas e o uso de padres abertos para interoperabilidade, nem sempre
atendidos pelos produtos baseados no ltimo.

Essa Cartilha Tcnica apresenta na Tabela 20 uma descrio das principais funcionalidades
encontradas em arquiteturas ESB de pequeno, mdio e grande porte.

Tabela 20: Funcionalidades do ESB


Funcionalidade Descrio Observao
Suporte a protocolos sncronos e
assncronos, alm do recurso de Deve estar presente nas configuraes
Invocao
mapeamento de servios (locating e bsicas de ESB.
binding)
Endereamento e roteamento de
mensagens atravs das tcnicas de
Deve estar presente nas configuraes
Roteamento roteamento esttico, baseado em
bsicas de ESB.
contedo, baseado em regras e
baseado em polticas de uso.
O recurso de adaptadores para
Uso de adaptadores e protocolos comunicao com sistemas legados
especficos para a troca de dados, pode nem sempre estar disponvel.
Mediao
com ou sem recurso de Alguns ESB tambm podem no
transformao dos dados. fornecer recursos para transformao de
dados.
Processamento, transformao e Deve estar presente nas configuraes
Mensageria
tratamento das mensagens. bsicas de ESB.
Este recurso geralmente no est
presente no ESB, mas ele deve prover
Coreografia de Implementao de processos de
um mecanismo de acionamento dos
Processos negcio.
processos de negcio implementados
em outras ferramentas.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 79 de 90


Este recurso pode ou no estar presente
no ESB. Algumas configuraes de ESB
Orquestrao de
Coordenao de servios. proveem o mecanismo de comunicao
Servios
com ferramentas especializadas em
orquestrar servios.
Este recurso pode ou no estar presente
no ESB. Algumas configuraes de ESB
Processamento
Processamento de Eventos proveem o mecanismo de comunicao
Complexo de Eventos
com ferramentas especializadas em
processamento complexo de eventos.
Segurana, gerenciamento de
QoS (Qualidade de Deve estar presente nas configuraes
transaes, controle de qualidade
Servio) bsicas de ESB.
dos servios publicados no ESB
Monitoramento, auditoria, logging e Deve estar presente nas configuraes
Gerenciamento
console de administrao. bsicas de ESB.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 80 de 90


4. Ferramentas de apoio interoperabilidade

4.1. Catlogo de Interoperabilidade

Como forma de promoo da interoperabilidade, a ePING disponibiliza aos rgos de governo o Catlogo
de Interoperabilidade, que uma ferramenta composta pelo Catlogo de Servios Interoperveis e pelo
Catlogo Padro de Dados (CPD).

O Catlogo de Servios Interoperveis tem por objetivo tornar pblicas as interfaces (pontos de
integrao) de sistemas que apoiem a oferta de servios de Governo Eletrnico (E-PING, 2014). Quem
deseja se conectar a um sistema, ou dele obter informaes, deve consultar o catlogo no sitio
http://catalogo.governoeletronico.gov.br, onde encontram-se registrados tanto Web Services como FTPs e
outras modalidades de troca de informaes.

J o CPD tem por objetivo estabelecer padres de tipos e itens de dados que se aplicam s interfaces
dos sistemas que fazem parte do setor pblico.

O objetivo da ePING com essas duas iniciativas a divulgao dos servios de governo, assim como
dos padres das informaes fornecidas e consumidas pelas instituies pblicas. A Figura 27 mostra o
Catlogo de Servios Interoperveis.

Figura 27: Busca no Catlogo de Servios Interoperveis

Guia de Interoperabilidade: Cartilha Tcnica Pgina 81 de 90


4.2. Padro de Metadados para o Governo Eletrnico (ePMG)

O ePMG (Padro de Metadados para o Governo Eletrnico) estabelece um conjunto mnimo de elementos
que contm dados necessrios para a recuperao e gerenciamento de informaes. Cada elemento
contm informaes relacionadas a um aspecto especfico do recurso, como por exemplo, Ttulo ou
Criador.

O objetivo do ePMG assegurar que as pessoas que pesquisam as informaes do governo brasileiro
na Web tenham acesso rpido e eficiente nas descries dos recursos. Os elementos do ePMG tm o
propsito de facilitar as pessoas localizarem os recursos que precisam, mesmo sem possuir conhecimento
detalhado da localizao ou da entidade responsvel pelos mesmos.

O ePMG foi desenvolvido com base no Padro Dublin Core (DC) do Dublin Core Metadata Initiative
(DCMI), uma organizao engajada no desenvolvimento de um padro de metadados interopervel. O
ncleo do DC um conjunto mnimo de elementos para descrever recursos eletrnicos, composto por 15
elementos principais com as suas respectivas definies.

O conjunto de elementos do ePMG consiste em 20 elementos: 15 elementos do DC e 5 elementos


adicionais identificados como necessrios para o contexto do governo eletrnico brasileiro.

O ePMG difere do padro DC em outros pontos importantes:

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.);

pretende descrever mais do que recursos informacionais, podendo descrever servios


disponveis na Web;

a adoo de qualificadores adicionais; e

diferentes critrios na obrigatoriedade ou no do uso de elementos e qualificadores.

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:

Nome: Termo atribudo ao elemento em portugus

Identificador: Termo atribudo ao elemento de acordo com o padro originrio.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 82 de 90


Definio: Uma descrio do que se trata o elemento.

Obrigatoriedade: Define o grau de uso do elemento, divididos em:

obrigatrio: este elemento deve obrigatoriamente ter um valor;

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.

Objetivo: Fornece a informao essencial sobre a aplicabilidade do elemento.

Comentrios: Informao adicional para a compreenso e utilizao do elemento ou dos


qualificadores do elemento.

No confundir com: Fornece informaes comparativas com elementos que eventualmente


possam gerar dvidas ou semelhanas no nome e suscitar uso inadequado.

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.

Sintaxe de HTML: Usualmente os metadados aparecem em forma de tag em um arquivo


HTML. Este campo visa facilitar a forma de uso dos elementos ePMG para pginas da Web.
Por exemplo: <meta name=dc.element content="valor">.

Esquemas: Os esquemas indicam a fonte que especifica a forma ou informa os valores


possveis para um elemento. Incluem vocabulrios controlados, normas brasileiras e
internacionais.

Mapeamento: Correlao com elementos de outros padres de metadados como:

e-GMS: Government Metadata Standard;

AGLS: Australian Government Locator Service;

GILS: Government Locator Service;

Guia de Interoperabilidade: Cartilha Tcnica Pgina 83 de 90


FGDC: Federal Geographic Data Committee (FGDC) Metadata;

MARC: MAchine-Readable Cataloging; etc.

Para mais informaes, acesse a pgina do ePMG no stio do governo eletrnico:


http://governoeletronico.gov.br/acoes-e-projetos/e-ping-padroes-de-interoperabilidade/padrao-de-
metadados-do-governo-eletronico-e-pmg.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 84 de 90


4.3. Vocabulrio Controlado de Governo Eletrnico (VCGE)

Uma informao pode ser definida e descrita de diversas formas, sendo a rea de estudo desse tema
denominada de Representao do Conhecimento. Um dos mtodos mais bsicos utilizados pelo ser
humano para descrever os objetos ao seu redor , sem dvida, a classificao. Classificar objetos, coisas
ou mesmo conceitos, consiste em agrup-los de acordo com suas similaridades.

O VCGE (Vocabulrio Controlado do Governo Eletrnico) um vocabulrio controlado organizado


como uma taxonomia criado pelo governo brasileiro com o objetivo de organizar assuntos do governo. A
primeira verso da taxonomia ficou conhecida como LCG (Lista de Categorias de Governo), que passou a
ser a LAG (Lista de Assuntos do Governo), e agora denominada VCGE que, alm de associar os
elementos taxonmicos com o ePMG (Padro de Metadados do Governo Eletrnico), tem o foco no cidado
e, por isso, apresenta um esquema mais intuitivo e abrangente.

O VCGE composto de dois nveis e representam as reas de atuao do governo. Ele possui
informaes como termos includos, cdigos numricos e outros campos. Os termos e a quantidade de
nveis, termos includos podem mudar e evoluir, afinal o VCGE um vocabulrio e precisa se adaptar as
necessidades de evoluo dos rgos. A Figura a seguir exibe um trecho do VCGE e o detalhamento de um
item do primeiro nvel.

Figura 28: Estrutura do VCGE

O VCGE tem como meta principal auxiliar na organizao das informaes governamentais de modo a
beneficiar o cidado que necessita realizar, por exemplo, consultas aos stios e portais informatizados do
governo. Por isso, a ePING adota o VCGE como padro taxonmico para a organizao de informaes

Guia de Interoperabilidade: Cartilha Tcnica 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 a pgina do ePMG no stio do governo eletrnico:


http://governoeletronico.gov.br/acoes-e-projetos/e-ping-padroes-de-interoperabilidade/vcge.

Guia de Interoperabilidade: Cartilha Tcnica 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 em:
<http://www.cgi.br/regulamentacao/resolucao2008-008.htm>. Acesso em: 2 de Maio de 2014.

COMPRASNET. Especificao de Referncia - Switches de Borda e Central Mdio e Pequeno. Portal de


Compras de TIC, 2010. Disponvel em:
<https://www.comprasnet.gov.br/PortalCompras/portais/tic/livre/download_espec_switch.asp>. Acesso em: 2
de Maio de 2014.

CROCKFORD, D. Network Working Group. RFC 4627, 2006. Disponvel em:


<http://tools.ietf.org/html/rfc4627>. Acesso em: 2 de Maio de 2014.

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.

Guia de Interoperabilidade: Cartilha Tcnica 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-ping-
padroes-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. Disponvel em:


<http://www.unicode.org/versions/Unicode5.2.0/>. Acesso em: 2 de Maio de 2014.

W3C. Mobile Web Best Practices. W3C Recommendation, 2008. Disponvel em:
<http://www.w3.org/TR/mobile-bp/>. Acesso em: 2 de Maio de 2014.

Guia de Interoperabilidade: Cartilha Tcnica 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.

Guia de Interoperabilidade: Cartilha Tcnica Pgina 89 de 90

You might also like