Professional Documents
Culture Documents
Padres de Interoperabilidade de
Governo Eletrnico
Guia de Interoperabilidade
Cartilha Tcnica
Verso 2015
Este documento parte integrante do Guia de Interoperabilidade do Governo Brasileiro, que compreende a
Cartilha Tcnica de Interoperabilidade e o Manual de Gesto de Interoperabilidade. Este documento foi
elaborado pelo Ministrio do Planejamento, Oramento e Gesto com a consultoria da Agncia Espanhola
de Cooperao para o Desenvolvimento (AECID) e da Fundao Instituto para o Fortalecimento das
Capacidades Institucionais (IFCI).
Presidente da Repblica
Dilma Rousseff
ePING
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.
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.
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.
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.
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.
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.
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.
Segurana Segmento 2: Trata dos aspectos de segurana de TIC que o governo federal deve
considerar.
A Tabela 1 descreve os padres no contexto de cada um dos segmentos mencionados, de modo a fazer
referncia aos componentes identificados como Adotados (A) e Recomendados (R) pelo governo brasileiro.
Inclui-se tambm nessa tabela a referncia s sees da ePING onde se podem localizar os padres
citados.
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.
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 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 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)
Em seu documento o MAAWG recomenda para redes de carter residencial, alm da adoo
de Message Submission, as seguintes medidas:
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.
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.
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
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).
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
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.
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.
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.
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.
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.
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.
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).
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.
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).
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.
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
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.
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.
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.
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).
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.
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.
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:
ou
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-16">
ou
ou
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.
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).
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.
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).
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.
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.
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:
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.
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.
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:
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
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.
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.
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.
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.
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.
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.
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>
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).
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.
Maiores informaes sobre a EDGV podem ser encontradas no Portal SIG Brasil em
http://www.inde.gov.br.
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:
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.
<?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>
.
.
.
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
Em portugus:
Cachorro1 um animal
Gato1 um gato
Gatos so animais
Zoologicos abrigam animais
Zoologico1 abriga o Gato2
Em RDF/Turtle:
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/
<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>;
<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" .
<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>
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.
4 http://www.w3.org/TR/owl-features/
<?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/
<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>
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.
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
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.
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
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.
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.
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
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 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.
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.
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).
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
Outra forma de se consultar o LexML atravs da sua interface grfica (Figura 22), disponvel no
endereo http://www.lexml.gov.br/.
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
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.
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.
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.
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.
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.
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).
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).
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.
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
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.
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.
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:
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.
<?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>
<?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>
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.
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.
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;
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.
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.
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.
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.
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.
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.);
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.
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.
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.
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 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.
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
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.
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.
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.
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.
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.
NEWCOMER, E.; LOMOW, G. Understanding SOA with Web Services. Massachusetts: Addison Wesley,
2005.
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.
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.
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.
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.
W3C. Mobile Web Best Practices. W3C Recommendation, 2008. Disponvel em:
<http://www.w3.org/TR/mobile-bp/>. 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.