Protocolo JC3IEDM para Integração de Sistemas C2 resume de forma concisa e relevante para o o tema central do documento, que é a proposta de um protocolo baseado no modelo JC3IEDM

MINISTRIO DA DEFESA
EXRCITO BRASILEIRO
DEPARTAMENTO DE CINCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
CURSO DE MESTRADO EM SISTEMAS E COMPUTAO
PATRICK BAPTISTA AMARAL DE LARA
UM PROTOCOLO PARA INTEGRAO DE

SISTEMAS DE COMANDO E CONTROLE
Rio de Janeiro
2014

Dissertao de Mestrado apresentada ao

Curso de Mestrado em Sistemas e Computao do
Instituto Militar de Engenharia, como requisito
parcial para obteno do ttulo de Mestre em
Sistemas e Computao.
Orientador: Prof. Ricardo Choren Noya - D.Sc.
Rio de Janeiro
2014
c2014

Praa General Tibrcio, 80 Praia Vermelha
Rio de Janeiro RJ CEP: 22290-270
Este exemplar de propriedade do Instituto Militar de Engenharia, que

poder inclu-lo em base de dados, armazenar em computador, microfilmar ou
adotar qualquer forma de arquivamento.
permitida a meno, reproduo parcial ou integral e a transmisso entre

bibliotecas deste trabalho, sem modificao de seu texto, em qualquer meio que
esteja ou venha a ser fixado, para pesquisa acadmica, comentrios e citaes, desde
que sem finalidade comercial e que seja feita a referncia bibliogrfica completa.
Os conceitos expressos neste trabalho so de responsabilidade do autor e do
orientador.
355.33041
L318p
Lara, Patrick Baptista Amaral de

Um protocolo para integrao de sistemas de comando e
controle / Patrick Baptista Amaral de Lara ; orientado por
Ricardo Choren Rio de Janeiro: Instituto Militar de Engenharia,
2014.
84p. : il.
Dissertao de Mestrado Instituto Militar de Engenharia:
Rio de Janeiro, 2014.
1. Curso de Sistemas e Computao teses, dissertaes. 2.
Comando e Controle sistemas de informao. I. Choren,
Ricardo. II. Um Protocolo para Integrao de Sistemas de
Comando e Controle. III. Instituto Militar de Engenharia.

Dissertao de Mestrado apresentada ao Curso de Mestrado em Sistemas e
Computao do Instituto Militar de Engenharia, como requisito parcial para
obteno do ttulo de Mestre em Sistemas e Computao.
Orientador: Prof. Ricardo Choren Noya D.Sc.
Aprovada em 05 de agosto de 2014 pela seguinte Banca Examinadora:
____________________________________________________________
Prof. Ricardo Choren Noya D.Sc. do IME Presidente
____________________________________________________________
Prof. Wallace Anacleto Pinheiro D.Sc. do IME
____________________________________________________________
Prof. Eduardo Bezerra da Silva D.Sc. do CEFET/RJ
Rio de Janeiro
2014
Dedico este trabalho a minha Famlia.

Ele fruto do apoio integral de vocs.
AGRADECIMENTOS
Aos professores Eduardo Bezerra da Silva e Wallace Anacleto Pinheiro por terem
aceitado participar de minha banca examinadora.
Em especial, ao meu orientador e professor Ricardo Choren Noya, pela ateno
constante e paciente orientao ao longo deste trabalho.
Aos professores Ten Cel Ronaldo Moreira Salles e Maria Claudia Reis Cavalcanti,
Coordenadores do Curso de Ps-Graduao em Sistemas e Computao do IME, por
acreditarem no meu interesse em concluir o curso, mesmo aps imprevistos pessoais.
Ao Instituto Militar de Engenharia e a todos os professores e funcionrios, que
tornaram possvel a realizao deste trabalho.
Ao Centro de Anlise de Sistemas Navais e a todos os meus colegas de trabalho,
em especial: Comte. Aquino, Luciene Carvalho, Jorge Calvelli e Manoel Pedro S,
que me apoiaram incondicionalmente para a concretizao deste trabalho.
Aos meus colegas de classe, Edgard Bernardo, Marcus Albert, Diego e Tanilson,
fiis participantes dos nossos grupos de estudo da sala 2035. Conquistar e
compartilhar o conhecimento com vocs sempre ser uma tarefa gratificante.
A Marinha do Brasil, por todas as oportunidades fornecidas para o meu
aprimoramento pessoal e profissional durante o transcurso de minha carreira militar.
Por fim, agradeo especialmente a minha famlia, pelo seu apoio incondicional.
Patrick Baptista Amaral de Lara
Os que se encantam com a prtica sem a cincia so como os timoneiros que entram
no navio sem timo nem bssola, nunca tendo certeza do seu destino.
Leonardo da Vinci
SUMRIO
LISTA DE ILUSTRAES....................................................................................................09
LISTA DE TABELAS.............................................................................................................10
LISTA DE ABREVIATURAS................................................................................................11
1
INTRODUO ............................................................................................................. 14
1.1
O Problema ............................................................................................................................... 16
1.2
Objetivos .................................................................................................................................... 17
1.3
Contribuies Esperadas ......................................................................................................... 18
1.4
Organizao do Trabalho ........................................................................................................ 18
CONCEITOS BSICOS .............................................................................................. 19
2.1
Interoperabilidade de Sistemas .............................................................................................. 19
2.2
O Modelo JC3IEDM ................................................................................................................. 21
2.3
Arquitetura Orientada a Servios .......................................................................................... 26
O PROTOCOLO PROPOSTO .................................................................................... 29
3.1
Requisitos para Interoperabilidade em Operaes Conjuntas .......................................... 29
3.2
Primeiro Nvel de Integrao: Entidades do JC3IEDM ...................................................... 34
3.3
Segundo Nvel de Integrao: Troca de Mensagens ........................................................... 42
3.4
As Mensagens do Protocolo ................................................................................................... 43
PROVA DE CONCEITO ............................................................................................. 45
4.1
Transformao dos Dados dos SC2 Legados para o JC3IEDM ......................................... 46
4.2
Mensagem de Pedido da Posio de uma Unidade ............................................................ 47
4.3
Mensagem de Pedido da Posio de Unidades em uma rea ........................................... 47
4.4
Fluxo da Mensagem de Requisio ....................................................................................... 52
4.5
Fluxo da Mensagem de Resposta ........................................................................................... 52
4.6
Roteiro para Implementao do Caso de Teste ................................................................... 53
4.7
Construo do banco de dados baseado no JC3IEDM........................................................ 53
4.8
Construo dos Artefatos ........................................................................................................ 53
4.9
Construo do Cliente ............................................................................................................. 54
4.10 Construo do Console ........................................................................................................... 54
TRABALHOS RELACIONADOS ............................................................................. 56
5.1
Utilizando Servios Web e SOA nas comunicaes militares ............................................ 56
5.2
Mtodo Alternativo de Desenvolvimento e Troca (ADEM) .............................................. 57
CONCLUSO ................................................................................................................ 60
6.1
Contribuies ............................................................................................................................ 61
6.2
Trabalhos Futuros .................................................................................................................... 61
REFERNCIAS BIBLIOGRFICAS ......................................................................... 63
APNDICES................................................................................................................... 63
LISTA DE ILUSTRAES
FIG. 2.1 Entidades Independentes do JC3IEDM (MIP, 2012) ..................................................... 22
FIG. 2.2 Servios automatizados oferecendo vrias capacidades (ERL, 2009) ......................... 27
FIG. 3.1 Viso dos Casos de Uso no Controle de uma Operao Conjunta ............................. 30
FIG. 3.2 Entidades Selecionadas do JC3IEDM (LARA; CHOREN, 2014) ................................. 36
FIG. 3.3 Especificao de ACTION-LOCATION (MIP, 2012) .................................................... 37
FIG. 3.4 Especializaes na Estrutura da Entidade LOCATION (MIP, 2012) .......................... 38
FIG. 3.5 rvore da Entidade OBJECT-TYPE (MIP, 2012) ........................................................... 39
FIG. 3.6 rvore da Entidade Independente OBJECT-ITEM (MIP, 2012) .................................. 40
FIG. 3.7 Especializaes da Entidade REPORTING-DATA (MIP, 2012) .................................. 41
FIG. 3.8 Relacionamento entre Entidades Independentes Selecionadas .................................. 42
FIG. 4.1 Entidade ACOMPANHAMENTO (SIPLOM) ............................................................... 46
FIG. 4.2 Descrio do Protocolo...................................................................................................... 52
LISTA DE TABELAS
TAB. 2.1 Requisitos para integrao de sistemas. ........................................................................ 32
TAB. 5.1 Tabela Comparativa entre os Trabalhos Relacionados ............................................... 59
10
LISTA DE ABREVIATURAS
ADEM
Alternate Development and Exchange Method
C2
Comando e Controle
C2S
Command and Control System
COI
Communities of Interest
DEM
Data Exchange Mechanism
FA
Foras Armadas
HTTP
HyperText Transfer Protocol
ICCRTS
International Command and Control Research and Technology Symposium
IDE
Integrated Development Environment
IP
Internet Protocol
JC3IEDM
Joint Consultation, Command and Control Information Exchange Data Model
MD
Ministrio da Defesa
MEM
Message Exchange Mechanism
MIP
Multilateral Interoperability Programme
OMG
Object Management Group
OODA
Observe, Orient, Decide and Act
OTAN
Organizao do Tratado do Atlntico Norte
UML
Unified Modeling Language
RNF
Requisito No Funcional
SC2
Sistema de Comando e Controle
SIPLOM
Sistema de Planejamento Operacional Militar
SOA
Service Oriented Architecture
SOAP
Simple Object Access Protocol
XML
eXtensible Markup Language
11
RESUMO
O cenrio de uma Operao Conjunta pode ser descrito como um ambiente de
guerra heterogneo, onde existe a necessidade de atualizao de uma conscincia
situacional compartilhada, baseada em uma constante troca de informaes entre as
unidades participantes. No ambiente das operaes militares no usual existir uma
grande capacidade de processamento e uma infraestrutura de redes com banda larga,
o que torna necessria a elaborao de um protocolo para troca de mensagens, que
aborde especialmente estas restries, baseado nas tecnologias de troca de
mensagens.
No mbito de uma Operao Conjunta, torna-se necessrio uma correta
coordenao, em tempo hbil, dos sistemas de conscincia situacional existentes nos
Comandos de Fora, a m de permitir uma maior interoperabilidade. Essa integrao
deve ser abordada em dois nveis, por meio de um modelo de dados consolidado,
onde utilizado o Joint Consultation, Command and Control Information Exchange Data
Model (JC3IEDM), e de um protocolo para troca de mensagens, que trata o
encaminhamento de mensagens XML, utilizando SOAP, atendendo a requisitos de
integrao. Nesse contexto, tambm utilizada uma arquitetura orientada a servios
(SOA), que considerada como adequada para a integrao de Sistemas de
Comando e Controle (SC2s).
Este trabalho apresenta um modelo de protocolo para troca de mensagens entre
os SC2 utilizados nas Operaes Conjuntas, a m de permitir a interoperabilidade
entre os sistemas de informao de comando e controle, utilizando o JC3IEDM, o
modelo de dados para a interoperabilidade de SC2s desenvolvido pelo Multilateral
Interoperability Programme (MIP).
12
ABSTRACT
A Joint Operation scenario can be described as a heterogeneous war
environment, in which there is a need to update a shared situational awareness,
based on a constant exchange of information between computer systems (the
participating units). For example, in an operation in the Brazilian Amazon, a military
aircraft will not be able to accurately perform an Aerial Fire Support mission without
knowing the position of all friendly units in the area. These units may be from the
Army or Navy or any other force. The force may have a system that indicates the
position of its units.
Under a Joint Operation, it becomes necessary proper coordination in a timely
manner, of existing situational awareness in Force Command systems, to allow
greater interoperability. This integration must be addressed on two levels, through a
consolidated data model, which is used Joint Consultation, Command and Control
Information Exchange Data Model (JC3IEDM), and a protocol for message exchange,
which handles the routing of XML messages using SOAP, considering integration
requirements. In this context, a service-oriented architecture (SOA), which is
considered suitable for the integration of Command and Control Systems (SC2s) is
also used.
This study presents a model protocol for exchanging messages between SC2s
used in Joint Operations, to allow interoperability between command and control
information systems, using JC3IEDM, the data model for interoperability of SC2s
developed by Multilateral Interoperability Programme (MIP).
13
INTRODUO
Nos diversos nveis decisrios, do poltico-estratgico ao ttico, a capacidade

dos comandantes em tomarem decises acertadas fundamental para o xito em
situaes de crise ou conflito armado. Nesse processo de tomada de deciso, so
envolvidas as tarefas de obteno de dados e a conquista e manuteno da
conscincia situacional, a fim de permitir alcanar a deciso.
Uma Operao um conjunto de combates e manobras de todas as espcies,
executados por foras terrestres, navais e/ou areas, em determinada regio, ou
tendo em vista um objeto preciso. Operaes conjuntas envolvem recursos de
mais de uma Fora Armada e so planejadas no mbito do MD. J as operaes
singulares so realizadas no mbito de uma nica Fora Armada, usando seus
prprios recursos.
As operaes conjuntas so caracterizadas conceitualmente nos diversos
manuais do Ministrio da Defesa (MD) como aquelas que envolvem ponderveis
meios de duas ou mais Foras (Marinha, Exrcito e Fora Area), sob um
comando nico (NEGRO, 2013). O manual de Doutrina de Operaes
Conjuntas (BRASIL, 2011), acrescentou a essa definio, a necessidade do
estabelecimento de um Estado-Maior Conjunto, formado por militares de duas
ou mais Foras.
O cenrio de uma operao conjunta demanda uma constante atualizao da
conscincia situacional, que a percepo dos elementos no meio existente em
um volume de tempo e espao, a compreenso de seu significado, e a projeo
de seu status no futuro prximo (ENDSLEY, 1995). Por exemplo, uma operao
na Amaznia Continental brasileira pode ser realizada com sucesso satisfatrio
sem a troca de dados entre os sistemas de comando e controle de todas as Foras
Armadas (FA) que esto atuando na regio, como a Marinha, o Exrcito e a
Aeronutica, porm, um Navio Patrulha no pode efetuar engajamentos em
alvos de superfcie desconhecidos. Da mesma forma, uma aeronave de asa fixa,
14
por exemplo, no pode realizar Apoio de Fogo Areo sem saber a localizao de
suas Foras Amigas.
Nesse contexto, o processo de Comando e Controle (C2) fundamental para
o xito das operaes militares. Sendo uma atividade especializada, o processo
de C2 de concepo sistmica, e possui mtodos, procedimentos, caractersticas
e vocabulrio peculiares. Sistemas de Comando e Controle (SC2s) visam apoiar a
esfera decisria com informaes teis tomada de deciso. Este s sistemas
apresentam informaes sobre a rea de operao em um nvel de abstrao
adequado esfera decisria.
A rapidez da atualizao das informaes influencia na execuo do
processo de C2, reduzindo o tempo necessrio tomada de deciso. Esta
reduo imprescindvel no cenrio atual, que possui reas de operao
complexas. Os SC2s so ferramentas necessrias aplicao de paradigmas
modernos de conduo da guerra (TARANTI, 2012), tais como Network Centric
Warfare (NCW) (ALBERTS et al., 1999) ou o Power to Edge (ALBERTS, HAYES,
2003), sobre deixar o poder de deciso nos escales inferiores, ficando os
escales superiores apenas com o poder de veto das aes das esferas inferiores.
Estabelecer a interoperabilidade de sistemas uma tarefa desafiadora
(TARANTI, 2012). Especificamente nos SC2s utilizados no mbito de uma
operao conjunta, torna-se crtica a integrao em tempo hbil nos Comandos
de Fora, a fim de permitir uma maior interoperabilidade entre as un idades
operativas envolvidas, e no nvel estratgico e operacional, que ocorra uma
adequada troca de informaes entre os seus Comandantes. O desafio da
integrao de sistemas ainda maior nos SC2s, devido necessidade de se
atender a diversos requisitos no funcionais (RNFs), e ainda, de se prever uma
soluo escalvel, que permita inserir e alterar conceitos com um mnimo de
impacto e indisponibilidade (TARANTI, 2012).
Alm de questes tcnicas, os processos e conhecimentos diferentes entre os
atores envolvidos dificultam o estabelecimento de uma interoperabilidade no
domnio de SC2. Outrossim, esta situao ainda agravada pelo fato de que as
15
instituies envolvidas no possuem os seus processos de C2 descritos e bem

definidos, encontrando-se em um nvel de maturidade inicial sobre o tema, o
que dificulta a definio dos processos de integrao de seus sistemas
(TARANTI, 2012).
O PROBLEMA
A integrao de SC2s, que so j existentes nas FA e em operao, uma
necessidade na rea de desenvolvimento de sistemas de conscincia situacional.
Cada SC2 de uma FA possui respectivamente um modelo de dados particular,
que atende as caractersticas tpicas de cada ambiente de guerra. Esta falta de
padronizao entre os diferentes modelos dificulta a troca de dados entre os
SC2s, pois no existe uma semntica universal entre os dados a serem
compartilhados, e no representa um modelo para intercmbio de informaes.
O estado-da-arte na integrao de SC2s tem sido alcanado atravs do
desenvolvimento de servios que consomem modelos de dados padronizados,
como o The Alternate Development and Exchange Method - ADEM (MIP, 2014) , que
fornece os meios para a troca da situao atual de uma operao utilizando a
semntica do Joint Consultation, Command and Control Information Exchange Data
Model JC3IEDM (MIP, 2012). O ADEM oferece um paradigma para o
intercmbio de informaes, e permite uma troca de informaes simples e
extensvel, permanecendo fiel ao modelo de dados JC3IEDM, onde se abre a
possibilidade de troca com as comunidades de interesse (COIs) que podem no
estar dispostos ou capazes de implementar a especificao DEM (MIP, 2012).
Entretanto o ADEM est focado na troca de informaes da situao atual de
uma operao, no sendo possvel a troca de informaes de dados histricos. A
troca de informaes sobre a situao atual de uma operao um recurso
bsico da COI do MIP, onde se pode realizar contribuies significativas para as
COIs parceiras. Diminuir a distncia entre o MIP e as COIs parceiras o que se
espera para melhorar a qualidade e o compartilhamento de informaes durante
as misses realizadas em operaes conjuntas.
16
O problema tratado neste trabalho a integrao de SC2s, em nvel de troca

de mensagens, a fim de se obter a localizao e a atualizao da posio de
Acompanhamentos no SC2 de nvel Operacional do Ministrio da Defesa (MD),
em uma Operao Conjunta realizada pelo MD. Acompanhamentos so objetos
onde existe um interesse militar ou civil envolvido para justificar que estes sejam
acompanhados. Podem ser classificados como meios operacionais, instalaes ou
feies geogrficas. Os meios operacionais representam as unidades de combate,
como por exemplo: as aeronaves, as tropas, as viaturas, os navios e os
submarinos. Os fatores fixos representam instalaes que podem ser definidas
por objetos construdos, instalados ou criados para servir a um propsito
particular. As feies de controle so divididas em feies geogrficas,
meteorolgicas e elementos de controle.
OBJETIVOS
O objetivo deste trabalho propor um modelo de protocolo para troca de
mensagens entre os sistemas de comando e controle (SC2) utilizados nas
Operaes
Conjuntas,
baseando-se
no
modelo
de
dados
para
interoperabilidade de SC2 desenvolvido para a OTAN, atravs do Multilateral

Interoperability Programme (MIP), um programa de interoperabilidade de SC2s
desenvolvidos pelos pases membros da OTAN.
Alm do objetivo geral apresentado, este trabalho possui o objetivo
especfico de apresentar um protocolo de mensagens para a integrao do SC2
de nvel operacional do MD, atravs de uma arquitetura orientada a servios
(SOA), e com a utilizao de troca de mensagens com contedo no JC3IEDM.
Foram analisados os processos envolvidos em uma Operao Conjunta, e
atravs deles, foi realizado o levantamento das necessidades encontradas em
uma operao, onde foram dados como prioridade para o estudo da
interoperabilidade dos SC2, a definio dos servios de Localizao de Foras
Amigas e Atualizao das Posies de Foras Amigas. Aps esse estudo, foram
definidos como requisitos funcionais deste trabalho:
17
Requisito Funcional n o 1: o protocolo dever permitir aos sistemas realizar

o pedido de localizao de uma unidade especfica conhecida.
Requisito Funcional n o 2: o protocolo dever permitir aos sistemas realizar
o pedido das posies de unidades em uma rea geogrfica definida.
CONTRIBUIES ESPERADAS
As contribuies esperadas pelo trabalho so:
1) Apresentar um protocolo para integrao de SC2, atravs de uma SOA, e
que utiliza o modelo de dados JC3IEDM no contedo de suas mensagens;
2) Propor uma infraestrutura SOA para apoiar a aplicao do protocolo; e
3) Apresentar um estudo de caso do barramento de comunicao.
Cabe salientar que os processos de transformao e cadastro das informaes
das operaes conjuntas em um banco de dados baseado neste modelo no faz
parte do escopo deste trabalho.
ORGANIZAO DO TRABALHO
A dissertao est estruturada da seguinte forma: no captulo 2 so
apresentados os conceitos bsicos, com o referencial terico necessrio para o
entendimento deste trabalho, o captulo 3 apresenta o Protocolo proposto,
discutindo tambm as hipteses assumidas e suas restries; o captulo 4
apresenta o cenrio de estudo e de emprego do protocolo, com o estudo de caso
de sua aplicao; no captulo 5 so discutidas as vantagens e desvantagens da
soluo apresentada e os trabalhos relacionados; e o captulo 6 apresenta a
concluso do trabalho, suas contribuies e sugestes de trabalhos futuros.
18
CONCEITOS BSICOS
INTEROPERABILIDADE DE SISTEMAS
Quanto mais organizaes perseguem os benefcios do e-business, mais elas
esto olhando para um processo chamado de integrao empresarial, ou
Enterprise Integration (EI), como um facilitador tcnico fundamental na
transformao de seus processos de negcios. Um cenrio tpico de EI envolve a
integrao de aplicaes empresariais. Por este processo, a organizao vincula se previamente a sistemas separados e isolados para dar-lhes uma maior
alavancagem.
Empresas so tipicamente compostas por centenas, se no milhares, de
aplicaes que so construdas, adquiridas de terceiros, parte de um sistema
legado, ou uma combinao destes, operando em vrios nveis de plataformas de
sistemas operacionais diferentes. No raro encontrar uma empresa que possui
trinta Web sites diferentes, trs instncias de Sistemas de Gesto Empresarial
(SAP) e solues departamentais incontveis. Para apoiar os processos de
negcio comuns, e o compartilhamento de dados entre aplicaes, essas
aplicaes precisam ser integradas. A integrao de aplicaes precisa fornecer
de forma eficiente, confivel e segura, a troca de dados entre vrias aplicaes
empresariais (HOHPE; WOOLF, 2004).
A EI no uma tarefa fcil. Por definio, a EI tem de lidar com mltiplas
aplicaes sendo executadas em vrias plataformas, e em locais diferentes.
Fornecedores de software oferecem Enterprise Application Integration (EAI) suites
que so multi-plataforma, utilizam integrao entre linguagens, bem como com
a capacidade de interagir com muitos pacotes de aplicaes empresariais
populares. No entanto, esta estrutura tcnica resolve apenas uma pequena
poro das complexidades de integrao (HOHPE; WOOLF, 2004).
Os verdadeiros desafios da integrao se estendem muito alm das questes
tcnicas e de negcios. Qualquer pessoa que tenha passado por uma
implementao de EAI pode atestar que as suas solues so um componente
19
crtico de diversas estratgias empresariais de hoje, mas que tornam a vida do

pessoal da rea de Tecnologia da Informao (TI) mais difcil, e no mais fcil.
um longo caminho entre a viso de alto nvel da empresa integrada (definida por
termos como o processamento direto e empresa gil) e as implementaes de
porcas e parafusos (HOHPE; WOOLF, 2004).
As funes compartilhadas de uma empresa so muitas vezes referidas como
servios. Um servio uma funo bem definida, que universalmente
disponvel e responde as solicitaes de consumidores de servios. Uma vez
que uma empresa rene uma coleo de servios teis, a gesto dos servios
torna-se uma funo crtica. Em primeiro lugar, a aplicao precisa de alguma
forma de servio de diretrio, que uma lista centralizada de todos os servios
disponveis. Em segundo lugar, cada servio deve descrever sua interface de tal
forma que uma aplicao possa negociar um contrato de comunicao com o
servio. Essas duas funes, de descoberta de servio e de negociao, so os
principais elementos que compe uma arquitetura orientada a servios (SOA).
SOA borra a linha entre integrao e aplicaes distribudas. Uma nova
aplicao pode ser desenvolvida utilizando servios remotos existentes que
podem ser fornecidos por outras aplicaes. Portanto, chamar um servio pode
ser considerado a integrao entre as duas aplicaes. No entanto, a maioria das
SOAs fornecem ferramentas que fazem a chamada a um servio externo quase
to simples como chamar um mtodo local (deixando de lado as consideraes
sobre o desempenho), ento o processo de desenvolvimento de uma aplicao
em cima de uma SOA assemelha-se a construo de uma aplicao distribuda
(HOHPE; WOOLF, 2004).
A partir desses conceitos sobre integrao de sistemas foi escolhida uma
SOA que suportasse uma soluo sem a interferncia, ou com a menor
interferncia possvel, nos SC2 legados das FA.
20
O MODELO JC3IEDM
A
interoperabilidade
de
dados
requer
um
vocabulrio
semntico
rigorosamente definido, que incorporado em um contexto estruturado. A

estrutura da informao expressa em um modelo de dados, desenvolvido e
documentado, de acordo com uma metodologia j aceita. O modelo define os
elementos padres de informao que formam a base para a interoperabilidade
entre os Sistemas de Informao de Comando e Controle (C2IS) automatizados,
que acomodam a estrutura de informao do modelo de dados.
A verso atual do modelo incorpora um desenvolvimento adicional e os
dados do Modelo de Referncia Corporativa da OTAN (NATO Corporate
Reference Model). Como resultado, o seu escopo aumentou e o nome foi alterado
para Joint C3 (Consultation, Command, and Control) Information Exchange Data
Model (JC3IEDM).
O JC3IEDM tem a pretenso de representar o ncleo de todos os dados
identificados como informaes para troca em um ambiente de comando e controle.
Para que isso ocorra, sua estrutura deve ser mantida genrica o suficiente para
acomodar os ambientes de ar, terra, mar e ambientes de operaes conjuntas. Todos
os objetos de interesse na esfera das operaes so definidos e descritos de forma a
inclurem
organizaes,
pessoas,
equipamentos,
instalaes,
caractersticas
geogrficas, fenmenos meteorolgicos, e medidas de controle militares (por

exemplo: as fronteiras). Os objetos de interesse so genricos em termos de uma
classe ou de um tipo, e especficos em termos de um item identificado
individualmente. Todos os objetos do tipo object item devem ser classificados como
sendo de algum tipo. Como exemplo, um tanque especfico que identificado pelo no
de srie WS62105B um item do tipo Challenger (carro de combate pesado ingls).
Um objeto deve ter a capacidade de executar uma funo ou de atingir um
fim. Assim, uma descrio da capacidade necessria para dar significado ao
valor dos objetos na esfera das operaes. A FIG. 2.1 apresenta as dezenove
entidades independentes do JC3IEDM.
21
FIG. 2.1 Entidades Independentes do JC3IEDM (MIP, 2012)
ACTION: representa uma atividade ou a ocorrncia de uma atividade,

que pode utilizar recursos, e pode ser concentrada contra um objetivo.
Representa a operao, ou tipo de operao com o qual a unidade est
envolvida ou est realizando. Exemplos: Ordem de Operao, Plano de
Operao, Ordem de Movimento, Plano de Movimento, Ordem de Tiro,
Plano de Tiro, Misso de Tiro, Apoio de Fogo Areo, Eventos (por
exemplo: aeronave desconhecida se aproximando) ou incidente (por
exemplo: ataque inimigo).
Papel no Modelo: dinmica (Como, o que, ou quando algo est para

ser realizado, est sendo realizado, ou foi realizado).
22
ADDRESS: representa as informaes precisas sobre a base da qual um

destino fsico ou eletrnico pode ser acessado.
Papel no Modelo: fornece meios para gravar endereos postais e eletrnicos.
AFFILIATION: um pas, nacionalidade, etnia, grupo funcional, grupo de

exerccio, ou religio a que pertena, ou a uma filiao que possa ser atribuda.
Papel no Modelo: fornece meios para atribuir filiaes para tipos de objetos
(OBJECT-TYPE) ou itens de objetos (OBJECT-ITEM).
CANDIDATE-TARGET-LIST: uma lista de objetos ou tipos de objetos do

campo de batalha selecionados que possuem potencial valor para destruio
ou explorao, nomeado por autoridade competente para considerao no
planejamento das atividades no campo de batalha.
Papel no Modelo: fornece informaes para apoiar a entidade ACTION.
CAPABILITY: uma potencial capacidade ou habilidade para realizar um

trabalho, executar uma funo ou cumprir uma misso, alcanar um objetivo,
ou fornecer um servio.
Papel no Modelo: indica a capacidade esperada para os OBJECT-TYPE e a

capacidade atual para os OBJECT-ITEM.
COMPONENT-HEADER-CONTENT: representa um assunto introdutrio de

valor que destina-se a identificar um elemento de um plano ou de uma ordem.
Papel no Modelo: utilizado em conjunto com especificaes de plano ou ordem.
COMPONENT-TEXT-CONTENT: representa uma declarao textual de um

assunto de valor substantivo.
Papel no Modelo: utilizado em conjunto com especificaes de plano ou ordem.
CONTEXT: uma coleo de informaes que fornece em sua totalidade as

circunstncias, condies, ambiente, ou perspectiva para uma situao.
Papel no Modelo: mltiplas funes, incluindo agrupamento de informaes.
23
RELATIVE-COORDINATE-SYSTEM: um frame retangular de referncia

definida por uma origem, eixos x e y no plano horizontal, e um eixo z. O eixo
vertical z normal ao plano xy com o sentido positivo determinado a partir da
regra da mo direita, quando o eixo x rotacionado na direo do eixo y.
Papel no Modelo: apoio entidade LOCATION especificando uma geometria

com posies relativas.
GROUP-CHARACTERISTIC:
uma
referncia
um
conjunto
de
caractersticas que podem ser utilizadas para identificar um conjunto distinto

de objetos. Exemplos de caractersticas incluem faixa etria, doena, sexo,
lngua e classificaes para triagem.
Papel no Modelo: suporta a contagem dos tipos de pessoas de acordo com as
caractersticas selecionadas.
LOCATION: uma especificao de posio e geometria em relao a um

frame horizontal especfico de referncia e a uma distncia vertical
medida a partir de um DATUM especfico.
Na parte selecionada do
modelo para este trabalho, LOCATION especifica a localizao de uma

Unidade de uma Fora que est atuando na operao conjunta. Exemplos:
pontos, sequncia de pontos, linha poligonal, crculo, retngulo, elipse,
rea poligonal, esfera, bloco de espao e cone. LOCATION especifica
localizao e dimensionalidade.
Papel no Modelo: geoposicionamento de objetos e criao de reas
(Onde?).
OBJECT-ITEM: representa um objeto individualmente identificado. Neste

trabalho, representa uma instncia do OBJECT-TYPE, como exemplo, uma
Unidade especfica, que est sendo empregada na operao conjunta.
Exemplos: uma pessoa especfica, um item especfico de material, uma
caracterstica geogrfica especfica, uma medida de coordenao especfica ou
uma unidade militar ou civil especfica.
Papel no Modelo: identificar as coisas individualmente (Quem? e O que?).
24
OBJECT-TYPE: representa as classes individualmente identificadas de objetos

de significncia militar ou civil. Na parte do modelo selecionada para este
trabalho, representa o tipo de Unidade que est sendo utilizado na operao
conjunta. Exemplos: tipo de pessoa (por exemplo: por posto), tipo de material
(por exemplo: pea de artilharia autopropulsada), tipo de instalao (por
exemplo: aeroporto), tipo de caracterstica (por exemplo: rea de tiro restrita),
ou tipo de organizao (por exemplo: Diviso de Blindados).
Papel no Modelo: identificar classes de coisas (Quem? e O que?).
PLAN-ORDER: um esquema planejado ou ordenado que foi trabalhado

previamente para a realizao de um objetivo do nvel operacional.
Papel no Modelo: entidade de mais alto nvel para a identificao de um

plano ou de uma ordem.
REFERENCE: representa a identificao do registro sobre uma informao.
Papel no Modelo: aponta para uma informao externa em apoio entidade

REPORTING-DATA.
REPORTING-DATA: representao da fonte ou origem, qualidade e tempo

que se aplica aos dados reportados. Neste trabalho, representa a data e a hora
em que a posio da Unidade est sendo reportada.
Papel no Modelo: apoio funo de relatrio.
RULE-OF-ENGAGEMENT: representa uma orientao obrigatria da forma

como uma determinada atividade deve ser executada.
Papel no Modelo: apoio entidade ACTION.
SECURITY-CLASSIFICATION: representa classificaes de segurana que

so aplicveis a um recurso de informao no domnio da segurana da
informao classificada.
Papel no Modelo: em apoio s entidades CONTEXT, NETWORK-SERVICE e

REFERENCE.
25
VERTICAL-DISTANCE: especificao da altitude ou altura de um ponto, ou

como um nvel medido em relao a um datum especfico de referncia, na
direo normal ao plano que tangente ao elipsoide de revoluo do WGS84.
Papel no Modelo: apoio entidade LOCATION, especificando elevao ou altura.
ARQUITETURA ORIENTADA A SERVIOS

De acordo com Thomas Erl (2009), o cotidiano encontrado no mundo est
rodeado de servios, que sempre foram algo trivial na histria da civilizao.
Qualquer pessoa que execute uma tarefa especfica para apoiar outras pessoas
est fornecendo um servio. Um grupo de pessoas que execute uma tarefa
coletiva para apoiar uma tarefa maior tambm est prestando ou realizando um
servio.
Um servio pode fornecer uma coleo de capacidades. Elas so reunidas de
acordo com um contexto funcional estabelecido pelo servio com o qual elas se
relacionam. Por exemplo, na FIG. 2.2, os servios tm como contexto funcional a
entrega de produtos. Ento, os conjuntos de capacidades associadas com o
processamento de produtos so fornecidos por esses servios. Um servio pode
funcionar como um continer de capacidades relacionadas. Ele composto por
uma lgica projetada para executar essas capacidades e por um contrato de
servios, que definem quais so as capacidades que esto disponveis para a sua
utilizao (ERL, 2009).
A orientao a servios como um paradigma de design, como descrito por
Thomas Erl (2009), uma abordagem de lgica de soluo. Construindo uma
lgica distribuda, as abordagens de design circulam um teoria de engenharia de
software conhecida como separao de interesses (HRSCH; LOPES, 1995). Essa
teoria demonstra que um problema maior resolvido quando for decomposto
em um conjunto de interesses menores, ou efetivamente de problemas menores.
A partir desta teoria, pode-se dividir a lgica do problema em capacidades, e ir
definindo cada capacidade para resolver um determinado interesse. As
26
capacidades que obtiverem um relacionamento entre si podem ser reunidas em

unidades de lgica.
FIG. 2.2 Servios automatizados oferecendo vrias capacidades (ERL, 2009)

De acordo com Thomas Erl (2009), o benefcio maior em tratar problemas
atravs desse tipo de soluo que vrias unidades de lgicas podem ser
definidas para resolver situaes de interesse imediato, e, ao mesmo tempo,
permanecerem agnsticas em relao ao problema maior a ser resolvido.
Esse tipo de soluo tambm permite a reutilizao das capacidades dentro
das unidades de lgica para resolver outros problemas diferentes. A lgica
distribuda possui diferentes paradigmas de design, porm o que diferencia a
orientao a servios a forma atravs da qual a separao de interesses
realizada, e a maneira como ela modela as unidades de lgica. Ao se aplicar a
orientao a servios em uma parte significativa do trabalho, o resultado pode
ser classificado como uma lgica orientada a servios, e descrito em unidades
lgicas individuais, que tem como caractersticas, os servios.
Utilizando-se a parte mais significativa do modelo de dados apresentado
anteriormente, juntamente com a tecnologia de Web Services, ou Servios Web,
27
obteve-se uma sinergia entre os dados disponveis e os servios oferecidos por

provedores especializados. Os Servios Web possibilitam forte desacoplamento
entre clientes e servidores, em virtude de suas caractersticas de independncia
de plataforma e de linguagem de programao. Ao utilizar o XML (Extensible
Markup Languague) para definies e intercmbio de informaes, os Servios
Web tambm possibilitam uma forte definio das mensagens e servios atravs
de documentos WSDL. E com a utilizao do HTTP na camada de transporte, a
passagem das mensagens por firewalls facilitada, sem a necessidade de uso de
portas especficas.
28
O PROTOCOLO PROPOSTO
Durante a elaborao do protocolo, a principal contribuio deste trabalho,

foi identificada a necessidade da abordagem de dois nveis de integrao: em um
nvel mais baixo, o modelo de dados para interoperabilidade de SC2s, o
JC3IEDM, e em um nvel mais alto, um grupo de mensagens necessrio para a
localizao de um Acompanhamento em uma operao conjunta. Tambm foram
identificados os servios que so candidatos a fazer parte de um barramento de
comunicaes, como integrantes da iniciativa de construo de uma Arquitetura
Orientada a Servios (SOA), a fim de permitir a interoperabilidade entre os SC2s
Legados das FA e o SC2 de Nvel Operacional do MD, independente da
linguagem e plataforma destes sistemas legados.
Os Servios Web esto disponveis no barramento para todos os SC2s, tanto
para os SC2s Legados das FA, como para o SC2 de Nvel Operacional do MD. As
mensagens trocadas entre os Servios Web e os SC2s esto formatadas em XML,
sendo transmitidas atravs do SOAP sobre o HTTP. Elas possuem o formato dos
dados dos Acompanhamentos baseado no padro JC3IEDM.
REQUISITOS PARA INTEROPERABILIDADE EM OPERAES CONJUNTAS

O cenrio de uma operao conjunta pode ser descrito como um ambiente de
guerra heterogneo, onde existe a necessidade de conscincia situacional
compartilhada, que baseada em uma constante troca de informaes entre as
unidades participantes. Com base na anlise dos processos de negcio do
Processo de Planejamento Conjunto (PPC), foi possvel identificar as interaes
entre os atores: SC2 de Nvel Operacional (MD) e os SC2s Legados (Foras
Componentes).
Essas interaes correspondem ao intercmbio de informao entre os SC2s
Legados (FA) e o SC2 de Nvel Operacional (MD), que so necessrias para a
correta execuo do processo de acompanhamento das operaes conjuntas.
29
A FIG. 3.1 apresenta as interaes entre estes atores, atravs dos casos de uso
levantados pela viso de negcios no controle de uma operao conjunta.
FIG. 3.1 - Viso dos Casos de Uso no Controle de uma Operao Conjunta
Com os Casos de Uso destacados possvel definir os Servios que podem
ser disponibilizados para qualquer SC2 que vise a interoperabilidade de C2.
Consultar Acompanhamento: o SC2 de Nvel Operacional utiliza os
Acompanhamentos
dos
meios
adjudicados
Operaes.
Esses
Acompanhamentos devero ser recebidos dos SC2s das Foras Singulares.

Consultar Localizao do Acompanhamento: os Acompanhamentos
relacionados tero as suas localizaes registradas continuamente a partir dos
SC2s das Foras Singulares, e o SC2 de Nvel Operacional poder recuperar essa
informao para o devido monitoramento da operao conjunta.
Consultar
Situao
do
Acompanhamento:
Acompanhamento
relacionado ter sua situao operacional registrada continuamente, a partir dos

SC2 das Foras Singulares, e o SC2 de Nvel Operacional poder recuperar essa
informao para o devido monitoramento da operao conjunta.
Com relao ao fluxo de informao nas transaes ligadas ao processo de
comando e controle no nvel operacional, foram levantados os dados para
30
localizao de meios, sendo navios ou tropas, entre os SC2 das Foras

Singulares; e o SC2 de nvel operacional.
A viso do Processo de Planejamento Conjunto, realizado no nvel
operacional durante as Operaes Conjuntas, estabelece as condies para a
efetiva interoperabilidade entre os SC2s de nvel operacional. Esta viso macro
do processo de Controle da Operao Planejada (COP), com enfoque nas
integraes entre os sistemas, apoia o processo do COP. Os subprocessos que
existem no COP so as atividades onde ocorrem as interaes entre os SC2.
Cada SC2 de uma Fora Componente possui respectivamente um modelo de
dados particular, que dever ser transformado atravs de seu respectivo
componente adaptador para o modelo JC3IEDM. O SC2 de Nvel Operacional
realiza consultas aos dados registrados, disponibilizando as informaes para o
acompanhamento da operao conjunta.
O conceito de Agilidade pode ser definido como a habilidade para efetuar,
lidar e/ou explorar com sucesso alteraes nas circunstncias (ALBERTS, 2011).
A partir desse conceito, foi definido como Requisito No Funcional (RNF) o
Tempo de Resposta, onde o protocolo deve permitir realizar consultas ao
banco de dados em uma velocidade adequada ao andamento das operaes
conjuntas, sendo a velocidade ideal considerada como sendo inferior a 5
segundos, e definida como o tempo de espera de um sistema legado para receber
a resposta de um pedido de posio de uma unidade especfica conhecida.
Tambm foi definido a partir do conceito de Agilidade o RNF de
Frequncia, onde a frequncia ideal considerada a de em tempo real, e
sendo definida como a frequncia de interaes necessria entre as aplicaes.
De
acordo
com
Wing
Lam
Venky
Shankararaman
(LAM;
SHANKARARAMAN, 2004), os requisitos para integrao de sistemas so

verificados atravs de uma lista de verificao, apresentada na TAB. 3.1.
31
TAB. 3.1 Requisitos para integrao de sistemas.

Tipo
de
Descrio
Exemplos
Requisito
Volume
Volume de dados que precisa

ser trocado entre aplicaes.
Tempo de Resposta
Tempos de resposta mnimos

para realizao de tarefas do
usurio tratadas pela
integrao de aplicaes.
Tamanho do dado que a
integrao entre aplicaes
deve tratar (relacionado ao
volume).
Urgncia da comunicao ou
integrao entre aplicaes.
Formato dos dados
transferidos entre aplicaes.
Adeso a um protocolo
particular em relao a troca
de interaes entre
aplicaes.
Tamanho
Timeliness
Padro de Formato de
Dados
Handshaking protocol
10.000 transaes/hora, 120

requisies/minuto, ou
500Kbytes/segundo.
5 segundos.
Tamanho de Arquivo de at 10Mbytes.
Tempo real, dentro de 2 segundos, ou

em at 2 horas.
Suporta formato ebXML, formato EDI
ou lida com formato proprietrio.
De acordo com RosettaNET PIP 2345,
ou de acordo com uma sequencia
proprietria de troca de mensagens.
Infraestrutura de
Restries da infraestrutura
Mensagens SOAP em HTTP ou um
Comunicao
de comunicaes nas
formato proprietrio de mensagem
aplicaes a serem
sobre IBM MQ messsaging.
integradas.
Resilincia e Recuperao
Resilincia da estrutura de
Garantia da entrega de mensagens,
integrao em caso de falhas.
redundncia e downtime menor do

que cinco por cento.
Frequncia
Segurana
Frequncia de interaes
Tempo real, ou em uma hora, a cada
necessria entre aplicaes.
hora.
Nvel de segurana exigido
Autenticao por usurio e senha no
entre aplicaes.
HTTPS; mensagens nocriptografadas, suporte a certificados

digitais para autenticao, autorizao
e no-repdio.
32
Para a abordagem do segundo nvel de integrao atravs do protocolo de

troca de mensagens, foi realizada uma anlise da tabela de requisitos de
integrao para verificar como os requisitos no funcionais afetariam a obteno
de um nvel satisfatrio de conscincia situacional em uma operao conjunta.
Os Requisitos No Funcionais (RNFs) foram analisados e definidos de maneira a
tentar garantir um intercmbio de informaes adequado entre os sistemas de
comando e controle em uma operao conjunta.
Atravs da anlise do cenrio de integrao dos sistemas legados de C2 em
uma operao conjunta, foram levantados os requisitos no funcionais, que so
necessrios para garantir uma troca de informaes adequada entre os SC2s
legados. Com o objetivo de alcanar esse nvel de conscincia situacional
compartilhada, foram definidos os seguintes RNFs para o protocolo:
Tempo de Resposta Este requisito refere-se ao tempo de resposta

mnimo para realizao de tarefas do usurio, que sero tratadas pela
integrao de aplicaes. Este requisito no funcional est associado
diretamente com a urgncia, e com a qualidade da informao a ser
requisitada pelo sistema. Quanto maior for o tempo de resposta,
menor ser a preciso da informao recebida, e consequentemente
tambm ser menor a sua relevncia no cenrio de nvel operacional.
Como exemplo, neste trabalho foi considerado o tempo de resposta
mximo de 5.000 milissegundos, ou cinco segundos (5s), para a
resposta a uma solicitao de uma informao de um sistema legado .
Resilincia e Recuperao Este requisito refere-se resilincia da

estrutura de integrao em caso de falhas. Estes requisitos no
funcionais afetam diretamente a flexibilidade e a tolerncia a falhas na
estrutura de integrao. Quando maior a sua redundncia, maior
tambm ser a garantia de entrega da mensagem. Como exemplo,
neste trabalho foi considerado como requisito no funcional a g arantia
de que cada mensagem ser entregue pelo menos uma vez.
33
Frequncia Este requisito refere-se frequncia de interaes

necessria entre as aplicaes que esto sendo integradas. Este
requisito no funcional de integrao afeta diretamente o andamento
de uma operao conjunta, pois a frequncia com que os dados sero
recebidos influencia diretamente na velocidade do andamento das
aes em uma operao conjunta. Como exemplo, neste trabalho a
frequncia em tempo real foi considerada como necessria para os
Servios do tipo Request/Response, e para os Servios do tipo
Publish/Subscribe, poderia ser definido um intervalo de frequncia.
Tamanho Este requisito refere-se ao tamanho do dado que a

integrao
entre
aplicaes
dever
tratar,
est
relacionado
diretamente ao volume de informaes a ser tratado. Este requisito

no funcional afetar diretamente a capacidade de troca de dados
entre sistemas legados, e define a estrutura fsica de integrao.
Quanto maior o tamanho do arquivo enviado atravs do protocolo,
maior tambm ser o tempo de processamento (overhead) para o
tratamento das mensagens no barramento de comunicao. Como
exemplo, neste trabalho foi considerado a troca de arquivos com um
tamanho de at dez megabytes (10MB). Este requisito deveria ser
configurado atravs de um Proxy, e est diretamente relacionado com
a infraestrutura fsica do local de operao do barramento.
PRIMEIRO NVEL DE INTEGRAO: ENTIDADES DO JC3IEDM

O JC3IEDM um modelo de dados para troca de informaes utilizado por
diversos pases em operaes conjuntas. Ele produzido pelo Conselho de
Administrao MIP-NATO (MNMB) e ratificado sob o NATO STANAG 5525. O
JC3IEDM um padro documentado para um modelo de dados para o
compartilhamento de informaes de C2.
34
O objetivo global do JC3IEDM permitir a interoperabilidade internacional

de sistemas de informao de C2 em todos os nveis de comando, ou no nvel
mais baixo possvel, a fim de apoiar as operaes multinacionais, incluindo as da
OTAN, combinadas e conjuntas, e o avano da digitalizao na arena
internacional (MIP, 2012).
De acordo com a documentao do JC3IEDM, este objetivo perseguido
especificando o conjunto mnimo de dados que precisam ser trocados em
coligao ou operaes multinacionais. Cada nao, agncia ou comunidade de
interesse livre para expandir o seu prprio dicionrio de dados para acomodar
as suas necessidades de troca de informaes adicionais com o entendimento de
que as especificaes adicionadas sero vlidas para a nao, agncia
participante ou comunidade de interesse. Qualquer adio considerada de
interesse geral pode ser apresentada como uma proposta de mudana no
controle de configurao para ser analisada e considerada para incluso na
prxima verso da especificao (MIP, 2012).
O JC3IEDM pretende representar o ncleo dos dados identificados para
troca em mltiplas reas funcionais e vrias exibies dos requisitos. Para isso,
estabelece uma abordagem comum para descrever as informaes a serem
trocadas em um ambiente de comando e controle.
Quando
se
trata
de
uma
operao
conjunta,
as
informaes
so
compartilhadas pelas Foras Singulares para uso da cadeia de comando, e

devem ser tratadas, ratificadas e publicadas para a segurana e efetividade
destas operaes.
Apesar de independentes, as Foras Singulares devem fornecer os dados
numa linguagem padronizada, que permita a interpretao e organizao das
informaes a serem consumidas pelo nvel decisrio na cadeia de comando.
A opo pelo JC3IEDM deve-se sua maturidade e ao seu amplo uso por
diversos pases para comunicao de operaes conjuntas. Desenvolvido pelo
MIP da OTAN, guarda caractersticas relacionais e hierrquicas em seu modelo,
35
definindo antecipadamente tipologias e relacionamentos dos itens utilizados nas

operaes.
Os objetos de interesse das operaes so pr-definidos por tipos (OBJECTTYPE), que determinam as caractersticas iniciais dos objetos (OBJECT -ITEM),
nomenclatura utilizada para definir os Acompanhamentos empregados nas
Operaes (ACTION). Em derivao, foram criadas rvores lgicas para tipo
(OBJECT-TYPE) e objeto (OBJECT-ITEM), que propagam as hierarquias de forma
a definir as caractersticas e associaes dos itens da operao em curso.
Das dezenove entidades independentes existentes no modelo apresentadas
na FIG. 2.1, foram selecionadas para utilizao, no primeiro nvel de integrao,
as cinco entidades que esto relacionadas diretamente com a localizao de um
Acompanhamento em uma operao conjunta. Esta simplificao foi necessria
para alcanar um nvel aceitvel de complexidade de implantao do modelo,
pois a sua utilizao completa considerada demasiadamente complexa e
custosa, pois resulta em mensagens de tamanho muito grande para interoperar
nos SC2s. Este recorte mantm o modelo flexvel e suficiente para permitir a
interoperabilidade entre os SC2 Legados em cenrios de operaes conjuntas. A
FIG. 3.2 apresenta o diagrama das entidades selecionadas do JC3IEDM.
FIG. 3.2 - Entidades Selecionadas do JC3IEDM (LARA; CHOREN, 2014)

A partir deste extrato do JC3IEDM, apresentado na FIG. 3.2, identificam-se
alguns conceitos sobre as entidades selecionadas.
36
As entidades principais do modelo de dados, e seus respectivos significados,

conforme definidos pelo MIP (2012), so:
ACTION: representa uma atividade ou a ocorrncia de uma atividade,

que pode utilizar recursos, e pode ser concentrada contra um objetivo. Na
parte selecionada do modelo ela representa a operao, ou tipo de
operao com o qual a unidade est envolvida ou est realizando.
Exemplos: Ordem
de
Operao,
Plano
de Operao,
Ordem de
Movimento, Plano de Movimento, Ordem de Tiro, Plano de Tiro, Misso

de Tiro, Apoio de Fogo Areo, Eventos (por exemplo: aeronave
desconhecida se aproximando) ou incidente (por exemplo: ataque
inimigo).
Papel no Modelo: dinmica (Como, o que, ou quando algo est para
ser realizado, est sendo realizado, ou foi realizado).
FIG. 3.3 Especificao de ACTION-LOCATION (MIP, 2012)
37
LOCATION: uma especificao de posio e geometria em relao a um

frame horizontal especfico de referncia e a uma distncia vertical
medida a partir de um DATUM especfico.
Na parte selecionada do
modelo para este trabalho, LOCATION especifica a localizao de uma

Unidade de uma Fora que est atuando na operao conjunta. Exemplos:
pontos, sequncia de pontos, linha poligonal, crculo, retngulo, elipse,
rea poligonal, esfera, bloco de espao e cone. LOCATION especifica
localizao e dimensionalidade.
Papel no modelo: geoposicionamento de objetos e criao de reas (onde?).
FIG. 3.4 Especializaes na Estrutura da Entidade LOCATION (MIP, 2012)
OBJECT-TYPE: representa as classes individualmente identificadas de objetos

de significncia militar ou civil. Na parte do modelo selecionada para este
trabalho, representa o tipo de Unidade que est sendo utilizado na operao
conjunta. Exemplos: tipo de pessoa (por exemplo: por posto), tipo de material
38
(por exemplo: pea de artilharia autopropulsada), tipo de instalao (por

exemplo: aeroporto), tipo de caracterstica (por exemplo: rea de tiro restrita),
ou tipo de organizao (por exemplo: Diviso de Blindados).
Papel no Modelo: identificar classes de coisas (Quem? e O que?).
A FIG. 3.5 apresenta a rvore com as especializaes da entidade OBJECT-TYPE.
FIG. 3.5 rvore da Entidade OBJECT-TYPE (MIP, 2012)
39
OBJECT-ITEM: representa um objeto individualmente identificado. Neste

trabalho, representa uma instncia do OBJECT-TYPE, como exemplo, uma
Unidade especfica, que est sendo empregada na operao conjunta.
Exemplos: uma pessoa especfica, um item especfico de material, uma
caracterstica geogrfica especfica, uma medida de coordenao especfica ou
uma unidade militar ou civil especfica.
Papel no Modelo: identificar as coisas individualmente (Quem? e O que?).
FIG. 3.6 rvore da Entidade Independente OBJECT-ITEM (MIP, 2012)
40
REPORTING-DATA: a especificao da fonte ou origem, qualidade e

tempo que se aplica aos dados reportados. Neste trabalho, representa a data e
a hora em que a posio da Unidade est sendo reportada.
Papel no Modelo: apoio funo de relatrio.
FIG. 3.7 Especializaes da Entidade REPORTING-DATA (MIP, 2012)
A FIG. 3.8 apresenta o relacionamento entre as entidades indepentes

selecionadas do JC3IEDM, atravs das quais conseguimos obter a localizao de
um objeto, o seu tipo, e a date e a hora em que aquela localizao foi reportada.
41
FIG. 3.8 Relacionamento entre Entidades Independentes Selecionadas
SEGUNDO NVEL DE INTEGRAO: TROCA DE MENSAGENS

O
protocolo
proposto
conta
com
um
Servio
Web
chamado
de
PositionReportWS, que permite consultar a localizao de Unidades em uma

operao atravs de dois mtodos distintos. A classe PositionReport produz o
servio atravs do emprego de anotaes em Java nas operaes dos mtodos
unitPosition e unitsInlatlongs.
O mtodo unitPosition do servio PositionReportWS permite localizar uma
Unidade atravs do fornecimento de sua identificao <id>. A sua localizao
informada pelo mtodo atravs de coordenadas geogrficas.
O mtodo unitsInlatlongs do servio PositionReportWS permite informar
quais Unidades encontram-se dentro de uma determinada rea retangular,
informada atravs de dois pontos, e retorna a caracterstica e localizao das
Unidades que esto na rea desejada.
O servio PositionReportWS tambm conta com um atributo chamado de
Entrega de Mensagem Confivel, que garante a entrega de mensagens atravs
do WS-ReliableMessaging, atributo disponvel nos Servios Web de segunda
gerao que utilizam essa garantia fsica de que as mensagens sero trocadas.
42
AS MENSAGENS DO PROTOCOLO
As mensagens do protocolo foram divididas em dois grupos: Mensagens de
Pedido de Posio e mensagens de Resposta para um Pedido de Posio. As
mensagens de Pedido de Posio por sua vez foram divididas em dos tipos:
Mensagem de Pedido de Posio de uma Unidade, e Mensagem de Pedido de
Posio de Unidades em uma rea. Segue abaixo a descrio das mensagens:
a) Mensagem de Pedido de Posio de uma Unidade: atravs dessa
mensagem possvel conhecer e manter atualizada a posio de uma
determinada unidade, ou objeto de interesse (Acompanhamento), atravs
do pedido de sua posio geogrfica. Atravs destas mensagens
consegue-se acompanhar os diversos meios de uma operao conjunta,
tanto um navio navegando na rea de operao, quanto uma tropa
progredindo no terreno. Sua especificao mais formalizada, no formato
EBNF, encontra-se no Apndice I. Na mensagem de solicitao, alm de
seu cabealho, onde dada a informao sobre para qual servio aquela
solicitao (ex: PositionReportWS), no corpo da mensagem fornecida a
informao sobre qual o objeto de interesse deseja-se obter a localizao:
<id> - Nmero Identificador do Objeto;
b) Mensagem de Pedido de Posio de Unidades em uma rea: atravs

desta mensagem possvel conhecer e manter atualizadas as posies dos
das unidades, ou objetos de interesse (Acompanhamentos), atravs de
pedidos de suas posies em uma rea geogrfica especfica. Atravs
destas mensagens consegue-se verificar quais so as unidades que esto
localizadas em uma determinada rea de operao, e tambm manter as
informaes sobre suas localizaes atualizadas naquela rea geogrfica,
possibilitando uma maior interoperabilidade entre os SC2 das Foras. Sua
especificao mais formalizada, no formato EBNF, encontra-se no
Apndice I. Na mensagem de solicitao, alm de seu cabealho, onde
dada a informao sobre para qual servio aquela solicitao (ex:
43
unitsInLatLongRequest), no corpo da mensagem so fornecidas as

informaes sobre a rea que se deseja localizar os objetos de interesse:
<lat1> - Coordenada Geogrfica de Latitude do Sudoeste (SW) da rea;
<lat2> - Coordenada Geogrfica de Latitude do Nordeste (NE) da rea;
<long1> - Coordenada Geogrfica de Longitude do SW da rea; e
<long2> - Coordenada Geogrfica de Longitude do NE da rea desejada.
c) Mensagem de Resposta para um Pedido de Posio: atravs das

mensagens de resposta, observa-se a informao fornecida atravs do
Servio solicitado pela mensagem de Pedido de Posio. Estes dados so
as posies das unidades, ou objetos de interesse (acompanhamentos),
solicitadas pelas mensagens que foram enviadas aos Servios Web. Suas
especificaes mais formalizadas, no formato EBNF, encontram-se no
Apndice I. Na mensagem de resposta, alm de seu cabealho, onde
dada
informao
de
unitsInLatLongResponse),
qual
servio
aquela
resposta
(ex:
no corpo da mensagem so fornecidas as
informaes sobre o objeto de interesse, ou acompanhamento, solicitado:

<abrev> - Abreviatura do Acompanhamento ou Objeto de Interesse;
<id> - Nmero Identificador do Objeto;
<latitude> - Coordenada Geogrfica de latitude do Objeto;
<longitude> - Coordenada Geogrfica de longitude do Objeto;
<name> - Nome do Objeto de Interesse; e
<reportTime> - Hora em que o Objeto foi reportado.
44
PROVA DE CONCEITO
Este captulo demonstra como realizado o fluxo das mensagens utilizando

o protocolo de troca de mensagens do barramento de comunicao, onde as
informaes so disponibilizadas atravs de Servios Web que esto disponveis
para os SC2 Legados fornecerem dados para o SC2 de nvel operacional do MD.
Para que estes dados estejam disponveis necessria uma transformao para o
modelo de dados JC3IEDM, que est fora do escopo deste trabalho.
O trabalho foi desenvolvido como um modelo para troca de mensagens em
um sistema de C2 para simular a troca de informaes entre SC2, onde foi
verificado qual o tipo de informao que o sistema de origem necessitaria. Aps
essa fase inicial do trabalho, foi elaborado um modelo para a troca de mensagens
do sistema de origem at o sistema de destino, atravs de um barramento, onde
ocorre fisicamente o roteamento das mesmas, desde como chegar ao seu destino,
como receber a mensagem, e verificar o que foi recuperado de informaes,
elaborando as mensagens de resposta para o sistema de origem. Esta troca de
mensagens realizada atravs de uma arquitetura orientada a servios (SOA), e
utiliza a tecnologia de Servios Web.
Este captulo descreve um exemplo em que dois SC2 Legados esto
fornecendo informaes para o SC2 de nvel operacional do MD, o SIPLOM,
atravs de um barramento de comunicao. Os SC2 Legados possuem
informaes sobre a posio atual de unidades das FA que sero consultados
pelo SIPLOM, e esto representados na arquitetura de alto nvel como SC2
Legados ligados diretamente ao barramento de comunicao. O C2 em Combate,
do Exrcito Brasileiro, e o SISNC2 da Marinha do Brasil so exemplos de SC2
Legados, que possuem seus prprios modelos de dados para armazenamento e
intercmbio de informaes em suas arquiteturas internas.
O problema de transformao desses modelos de dados proprietrios para o
padro JC3IEDM de forma automatizada est fora do escopo deste trabalho.
45
Atrves da utilizao da tecnologia de Servios Web foi possvel realizar o

intercmbio de informaes com um grande nvel de desacomplamento entre os
SC2, pois a tecnologia envolvendo a comunicao possui as caractersticas de ser
independente da linguagem de programao utilizada em cada sistema, e
tambm de ser independente das plataformas e dos sistemas operacionais com
que ir se comunicar. Servios Web esto disponveis para serem utilizados por
todos os SC2, e o SIPLOM consulta a posico de unidades atravs de um Servio
Web chamado de PositionReportWS.
TRANSFORMAO DOS DADOS DOS SC2 LEGADOS PARA O JC3IEDM

A transformao dos dados dos SC2 Legados para o JC3IEDM se dar
atravs do mapeamento das suas entidades que so utilizadas nos servios que
foram construdos e disponibilizados no barramento de comunicao. Como
exemplo, no SIPLOM, o SC2 de nvel operacional do MD, existe a entidade
ACOMPANHAMENTO que sendo mapeada para o padro JC3IEDM, observa-se
a sua relao direta com a entidade OBJECT-ITEM.
FIG. 4.1 Entidade ACOMPANHAMENTO (SIPLOM)

Na verso 4.0 do SIPLOM existem diversos tipos de Acompanhamento que
devem ser mapeados para o padro JC3IEDM antes da efetiva troca de
mensagens entre os SC2 legados: Meios (navios, tropas e aeronaves); Instalaes
46
(portos, aerdromos, cidades e vias); e Feies de Controle (reas inseridas no

sistema para controle do andamento da operao).
No JC3IEDM, existe o atributo object-type-category-code, que possui
cdigos que so correspondentes aos tipos de acompanhamento pr-definidos
no SIPLOM. Os dados precisam ser cadastrados anteriormente nos SC2s legados.
As seguintes categorias de acompanhamento devem ser mapeadas para o
JC3IEDM (object-type-category-code) para possibilitar a troca de informaes:
a) Meios;
b) Instalaes; e
c) Feies Geogrficas.
Dessa forma, assim como dever ser especificado um CATEGORY-CODE
para cada tipo de Acompanhamento correspondente no SIPLOM, devero ser
especificados identificadores para o military-organization-type-id do JC3IEDM
que identifiquem as Foras Singulares de modo nico, no contexto de uma
operao conjunta, para garantir a interoperabilidade dos SC2s legados das FA.
MENSAGEM DE PEDIDO DA POSIO DE UMA UNIDADE

O protocolo trata a mensagem de Pedido de Posio de uma Unidade
especfica com as seguintes regras de execuo: a solicitao da posio de uma
Unidade conhecida realizada atravs do nmero de identificao do objeto,
que deve ser nico para cada Acompanhamento cadastrado no barramento de
comunicao.
MENSAGEM DE PEDIDO DA POSIO DE UNIDADES EM UMA REA

O protocolo trata a mensagem de Pedido de Posio de Unidades em uma
rea com as seguintes regras de execuo: a solicitao da posio de Unidades
em uma determinada rea ser realizada atravs de dois pontos geogrficos, que
servem para definir os vrtices sudoeste e nordeste da rea retangular desejada.
47
A) MENSAGEM DE REQUISIO
Como exemplo de parmetros enviados, apresenta-se 2 pontos geogrficos:
- Ponto1: Lat1=50 e Long1=40 (Ponto Sudoeste de uma rea retangular); e
- Ponto2: Lat2=100 e Long2=100 (Ponto Nordeste de uma rea retangular).
O mtodo unitsInLatLongRequest do Servio Web PositionReportWS receber
esses dois pontos como parmetros, e far a comparao com as latitudes e
longitudes dos objetos que esto no banco de dados baseado no JC3IEDM.
Atravs das tags em negrito da mensagem XML, observa-se no exemplo da
mensagem de Localizao de Acompanhamentos em uma rea, o Servio Web e
o seu mtodo que foram solicitados, e os parmetros enviados para esse mtodo.
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<To
xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/jc3svc/PositionReportWS</To>
<Action xmlns="http://www.w3.org/2005/08/addressing"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
S:mustUnderstand="1">http://ws.svc.jc3.example/SvcWsUnitPosition/unitsInLat
LongRequest</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:73cc64de8daf-45d6-8b8c-40564fd6dce7</MessageID>
...
<wsa:ReplyTo xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>http://docs.oasis-open.org/wsrx/wsmc/200702/anonymous?id=5598fb43-f857-44cb-949230515e4e0942</wsa:Address>
</wsa:ReplyTo>
<wsa:FaultTo xmlns:wsa="http://www.w3.org/2005/08/addressing">
</wsa:FaultTo>
</S:Header>
<S:Body>
<ns2:unitsInLatLong xmlns:ns2="http://ws.svc.jc3.example/">
48
<lat1>50</lat1>
<lat2>100</lat2>
<long1>40</long1>
<long2>100</long2>
</ns2:unitsInLatLong>
</S:Body>
</S:Envelope>
B) MENSAGEM DE RESPOSTA
Atravs das tags em negrito da mensagem XML, observa-se no exemplo da
mensagem de Resposta da Localizao de Acompanhamentos em uma rea, os
dados fornecidos atravs da resposta do Servio.
<S:Header>
LongResponse</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:dbdbe21fb84d-4ae4-848d-e4ffade834ba</MessageID>
<RelatesTo xmlns="http://www.w3.org/2005/08/addressing">uuid:73cc64de8daf-45d6-8b8c-40564fd6dce7</RelatesTo>
...
<To xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasisopen.org/ws-rx/wsmc/200702/anonymous?id=5598fb43-f857-44cb-949230515e4e0942</To>
<MessagePending xmlns="http://docs.oasis-open.org/ws-rx/wsmc/200702"
xmlns:ns2="http://www.w3.org/2005/08/addressing" pending="false"/>
</S:Header>
<S:Body>
<ns2:unitsInLatLongResponse xmlns:ns2="http://ws.svc.jc3.example/">
<return>
<abrev>UIE5 ATB</abrev>
<id>1010</id>
<latitude>55.000000</latitude>
49
<longitude>70.000000</longitude>
<name>Unidentified AntiTank Battery 5</name>
<reportTime>12:00:00</reportTime>
<reportType>reported</reportType>
</return>
<return>
<abrev>UIE9 FA</abrev>
<id>1017</id>
<name>Unidentified FA Battalion 9</name>
</return>
</ns2:unitsInLatLongResponse>
</S:Body>
</S:Envelope>
No exemplo da mensagem de resposta, o Servio Web PositionReportWS

retornou dois objetos do banco de dados baseado no JC3IEDM que esto
localizados dentro da rea retangular definida pelos pontos 1 e 2. Os dados
informados so relativos s seguintes Unidades cadastradas no banco de dados:
Objeto 1010
a) Abreviatura: UIE5 ATB;

b) Nome: Unidentified AntiTank Battery 5;
c) Posio: latitude 550000N e longitude 700000W; e
d) Localizao reportada s 12h00m.
Objeto 1017
a) Abreviatura: UIE9 FA;

b) Nome: Unidentified FA Battalion 9;
50
c) Posio: latitude 551200N e longitude 890000W; e

d) Localizao reportada s 12h00m.
A mensagem de pedido de posio enviada de um cliente para o Servio

Web chamado de PositionReportWS. Entende-se como cliente, qualquer sistema
legado solicitante que ir consumir a informao, conforme apresenta a FIG. 4.2.
No incio do funcionamento do protocolo de troca de mensagens realizada
uma solicitao de ativao do WS-ReliableMessaging, que permite que as
mensagens SOAP possam ser entregues de forma confivel. Nessa solicitao
tambm enviada a Identificao da Mensagem (UUID). Aps o envio dessa
mensagem de solicitao do WS-ReliableMessaging, o servidor envia uma
resposta para o cliente com a mensagem de aceitao, que confirma,
implicitamente, que o WS-ReliableMessaging suportado pelo Servio Web.
Em seguida, enviada outra mensagem do servidor para o cliente, com
a resposta solicitao do Servio Web, onde realizado o incio da
conversao, e enviado o endereo do Servio Web PositionReportWS.
As tags das mensagens XML que dizem respeito apenas ao SOAP e ao XML,
que no possuem relevncia para as informaes que esto sendo transmitidas, e
nem para os requisitos no funcionais abordados pelo protocolo de integrao,
foram suprimidas do texto e substitudas por trs pontos (...), a fim de facilitar o
entendimento das mensagens que esto sendo transmitidas entre os sistemas.
51
FIG. 4.2 Descrio do Protocolo

FLUXO DA MENSAGEM DE REQUISIO
Aps a conversao inicial enviada a mensagem do cliente para o
servidor, com a solicitao do Servio Web PositionReportWS, enviando os
parmetros de latitude e longitude para o Servio. As palavras cliente e
servidor so apresentadas no texto entre aspas, pois este papel se altera de
acordo com o sentido em que est ocorrendo o fluxo das mensagens.
FLUXO DA MENSAGEM DE RESPOSTA

Aps a mensagem de solicitao do Servio Web
PostionReportWS
informando os seus parmetros, enviada uma mensagem do servidor para o

cliente, com a resposta sobre a solicitao efetuada. Essa apenas uma
mensagem inicial de aceitao do Servio, que recebida pelo cliente.
52
Logo aps a confirmao da aceitao do servio, finalmente enviada a

mensagem do servidor para o cliente com a resposta da solicitao realizada
ao servio PositionReportWS.
O mtodo unitsInLatLongResponse do Servio Web PositionReportWS retorna
quais so os objetos que esto dentro da rea definida pelos pontos geogrficos 1
e 2 (Lat1 e Long1; Lat2 e Long2), e as suas respectivas localizaes reportadas,
conforme esto representadas no banco de dados baseado em JC3IEDM.
ROTEIRO PARA IMPLEMENTAO DO CASO DE TESTE

Esta seo apresenta um breve roteiro para a construo do exemplo
descrito. Para facilitar a implementao do exemplo utilizado de caso de teste, os
seguintes softwares so considerados como pr-requisitos:
PostgreSQL Tools (pgAdmin III); e
NetBeans IDE 7.4, com o servidor de aplicao Glassfish 3.
CONSTRUO DO BANCO DE DADOS BASEADO NO JC3IEDM

A construo do banco de dados baseado no JC3IEDM foi realizada atravs
do PostgreSQL, com o nome do banco de dados chamado de jc3iedm. Foi
realizada a importao de dados de um banco baseado no JC3IEDM prexistente, atravs do arquivo JC3IEDM.sql 1 . Este um banco de dados
concebido para simulao, com dados sintticos existentes de acordo com o
modelo do JC3IEDM. O Multilateral Interoperability Programme disponibiliza em
sua documentao sobre o JC3IEDM um script para criao de um banco de
dados baseado em JC3IEDM, porm sem conter dados populados.
CONSTRUO DOS ARTEFATOS

A construo dos artefatos foi realizada atravs da ferramenta NetBeans IDE
7.4, com o servidor de aplicao Glassfish 3 tambm instalado. A sequncia de
construo foi seguida conforme descrito nas prximas subsees.
1
JC3IEDM.sql um script do Multilateral Interoperability Programme, disponibilizado na pgina: https://mipsite.lsec.dnd.ca.
53
A) ARTEFATO DAO
A construo do Data Acess Object (DAO) foi realizada atravs do NetBeans
7.4, onde foi criado o artefato jc3-entities. Este artefato realiza o mapeamento
das entidades do banco JC3IEDM em classes Java, para que as informaes do
banco possam ser processadas.
A classe VWUnitPosition.java foi criada para facilitar o uso do JC3IEDM,
criando uma viso mais intuitiva do JC3IEDM, ou seja, uma view mais simples.
B) ARTEFATO DO SERVIO
A construo do artefato do servio (artefato SVC) foi realizada atravs do
NetBeans 7.4, onde foi criado o artefato jc3-svc. A classe PositionReport produz
o servio atravs do emprego de anotaes em Java nas operaes dos mtodos
unitPosition e unitsInlatlongs. Aps ser implantado no Servidor, o artefato foi
exposto como um Servio Web para consumo.
Dentro do artefato jc3-svc, em sua pasta denominada Web Services,
dentro do servio PositionReportWS foi implementada a Entrega de
Mensagem Confivel, como um atributo do Servio Web. Neste momento o
Servio est pronto, faltando apenas o cliente para consumi-lo.
A descrio do Servio Web (WSDL) est disponvel no endereo:
http://localhost:8080/jc3-svc/PostionReportWS?WSDL.
CONSTRUO DO CLIENTE
A construo do cliente do servio foi realizada atravs do NetBeans 7.4,
onde foi criado o artefato jc3-ws-cli. Foi realizada a gerao de um artefato
Java para clientes do servio a partir do WSDL do servio.
CONSTRUO DO CONSOLE
O console representa o solicitante do servio, equivalente ao SC2
Legado. A construo do console tambm foi realizada atravs do NetBeans
54
7.4, onde foi criado o artefato jc3-ws-console. Em caso de necessidade de

controle das respostas dos servios, pode ser construda uma nova fila, entre o
cliente e o console, para controle das mensagens de resposta dos servios.
55
TRABALHOS RELACIONADOS
Neste captulo so apresentados trabalhos relacionados utilizao de uma

arquitetura orientada a servios (SOA), que comumente realizada atravs de
Servios Web, utilizando documentos em formato XML atravs de mensagens
SOAP, mas que geralmente projetada para ser usada em redes de banda larga,
e no em redes militares com capacidade limitada de banda. Documentos XML
tendem a ser grandes e a ter um overhead significativo durante a sua leitura.
UTILIZANDO SERVIOS WEB E SOA NAS COMUNICAES MILITARES

Lund et al. (LUND et al., 2007) discutem os diferentes aspectos de como
utilizar Servios Web para construir uma arquitetura orientada a servio (SOA)
nas operaes com capacidades de redes ativadas. Lund et al. afirmam que a
implementao mais comum de SOA a de servios web baseados em XML e
SOAP, mas que projetada principalmente para o uso na Internet, ou seja, em
redes com alta taxa de dados. Ento, o foco do seu trabalho foi a forma de
aplicar esta tecnologia em ambientes com capacidade de rede desfavorecida.
Eles investigaram diferentes formas de reduzir a sobrecarga no XML e sugeriram
o uso do protocolo S4406 ao invs do HTTP para o transporte de mensagens
SOAP no nvel ttico, devido grande quantidade de mensagens que so
trafegadas e a baixa capacidade das redes tticas militares. Eles sugerem uma
SOA para aumentar a interoperabilidade dentro de Foras aliadas. No entanto,
esta soluo foi adotada para ambientes com grande capacidade de comunicao
de dados, o que no uma caracterstica comum nas redes de dados militares
utilizadas em operaes conjuntas. Os seus estudos tambm recomendam
princpios de arquitetura e tecnologias que so mais adequados para serem
implementados nesta infraestrutura de troca de informao. Tambm
recomendado o uso do protocolo IP, por ser considerado um protocolo de uso
comum para todos os tipos de tecnologias de redes, sendo, desta forma, o
56
protocolo de rede escolhido para facilitar a integrao, tornando-a mais fcil

para todos os tipos de rede de dados.
Lund et al. tambm sugeriram outras formas de melhorar o desempenho do
sistema, tais como, a utilizao de compresso, optimizao de representao da
mensagem e de seu contedo, e tambm, pela utilizao de proxies. No entanto,
eles mostram que adaptar Servios Web para uso em redes desfavorecidas uma
tarefa desafiadora, e ainda h muito trabalho antes que se possa tirar o mximo
de proveito dos benefcios prometidos pela SOA no nvel ttico de uma guerra.
Finalmente, Lund et al. afirmam que importante ter em mente que os
Servios Web nunca ser a tecnologia para troca de informaes mais eficiente.
Dessa maneira, a interoperabilidade e a flexibilidade adquirida atravs da
utilizao de Servios Web devem ser balanceadas com a reduo de eficincia
da comunicao, no nvel ttico. Eles afirmam que possa existir um limite
inferior de largura de banda, abaixo do qual os Servios Web no so mais
viveis, e onde outros mecanismos devem ser empregados para alcanar a SOA.
MTODO ALTERNATIVO DE DESENVOLVIMENTO E TROCA (ADEM)

O grupo de pesquisa do MIP (MIP, 2014) publicou em seu site oficial no final
do ms de maio deste ano o Alternate Development and Exchange Method (ADEM),
um trabalho que fornece os meios para a troca da situao corrente utilizando a
semntica do JC3IEDM. O ADEM oferece uma mudana de paradigma no
intercmbio de informaes. Ele permite a troca de informaes simples e
extensveis, permanecendo fiel ao modelo JC3IEDM, mas utilizando padres
abertos existentes. Assim, abre-se a possibilidade para intercmbio com
comunidades de interesse (COI), que podem no estarem dispostas ou capazes
de implementarem a especificao Data Exchange Mechanism (DEM) do MIP.
Estas so as vantagens para as COI do MIP, onde podem ser realizadas
contribuies significativas para os seus parceiros.
A especificao ADEM (MIP, 2014) identifica estruturas de informao e
padres de troca a serem utilizados pelos implementadores de sistemas para
57
construo de interfaces que objetivem a troca de informaes entre SC2s e

outros parceiros. As especificaes ADEM so prestadas comunidade de
Integrao de SC2s, que, em seguida, empregam essas especificaes para
construir uma interface ADEM compatvel em seus respectivos sistemas. Para
aqueles familiarizados com a especificao do MIP (MIP, 2012), uma interface
ADEM fornece um meio alternativo para trocar informaes de C2. A
especificao ADEM aproveita a linha de base de dados do MIP modelo 3.1
(JC3IEDM) e outras normas para fornecer a semntica das estruturas de dados
fundamentais. Em comparao com uma interface baseada na especificao MIP,
o ADEM simplifica muito o uso da semntica JC3IEDM e as suas regras de
negcios. Ele focado sobre a situao atual, e no os contextos passados ou
futuros de uma operao. O seu mtodo extensvel, modular e baseado em
padres comercialmente disponveis de intercmbio de dados.
A especificao do ADEM beneficia as COI, contribuindo com (MIP, 2014):
Melhoria do compartilhamento de informaes no C2 para um

conjunto mais amplo de potenciais parceiros de misses.
Demonstrao da flexibilidade do JC3IEDM.
Incentivo s contribuies tcnicas de grupos engajados no C2 que

esto de fora do programa MIP.
Resumidamente, o programa MIP se beneficia da incluso de parceiros

adicionais de troca de dados, da flexibilidade de troca de informaes e da
infuso de novas ideias (MIP, 2014). A especificao ADEM um conjunto
completo de documentao que define uma srie de construes de informao e
padres de troca, teis para o compartilhamento automtico de informaes.
A construo da informao reusa a semntica do JC3IEDM, mas ela
simplificada para facilitar a implementao, enquanto cobre as partes mais
usadas do JC3IEDM. A construo da informao empacotada de uma forma
que mais fcil para as COI compreenderem, ampliarem e incorporarem o
modelo em seus sistemas (MIP, 2014).
58
A especificao ADEM oferece aos seus implementadores vrios padres de

troca, utilizando tecnologias comumente empregadas pelos desenvolvedores de
sistemas. A sua inteno no prescrever um mecanismo de intercmbio nico
mas sim, incentivar a troca de informaes pelos meios mais adequados para o
implementador (MIP, 2014). A principal desvantagem da especificao ADEM
que o seu modelo de dados abrange somente a parte da situao atual.
TAB. 5.1 Tabela Comparativa entre os Trabalhos Relacionados
TRABALHOS
RELACIONADOS
Usa Semntica Usa Protocolo de Capacidade de

do JC3IEDM
Rede Especfico
Pontos Histricos
ADEM (MIP, 2014)
Sim
No
No
LARA e CHOREN
Sim
No
Sim
No
Sim
No se aplica
(2014)
LUND et al. (2007)
A TAB. 5.1 apresenta os trabalhos relacionados com esta dissertao. Pode-se

observar que somente o trabalho de Lund et al. (LUND et al., 2007) no utiliza a
semntica do JC3IEDM em suas mensagens, o que no padroniza um modelo de
dados nico para o intercmbio de dados entre os SC2s. Porm, esse trabalho
sugere o uso de um protocolo de rede especfico para a utilizao em redes
tticas militares de baixa capacidade de transmisso de dados. O ADEM (MIP,
2014) no possui capacidade para armazenar pontos histricos, pois trata
somente da situao corrente de uma operao, enquanto esta funcionalidade
pode ser alcanada por este trabalho atravs da utilizao dos reportes antigos.
O trabalho apresentado nessa dissertao prope requisitos para definir um
protocolo de troca de mensagens, e mensagens em formato XML para reduzir o
overhead causado pelo uso de Servios Web em um ambiente de redes militares.
A ideia principal tornar a SOA possvel de ser adotada por todos os nveis de
operaes militares, desde o nvel estratgico at as redes de nvel ttico, tanto
de situaes passadas quanto a atual, e tambm, iniciar o estudo dos processos
de comando e controle no nvel operacional de uma operao conjunta.
59
CONCLUSO
Este trabalho props o estudo dos requisitos de um protocolo e os exemplos

de mensagens em formato XML que devem ser manipuladas pelo protocolo,
para permitir um desempenho satisfatrio durante o processo de integrao dos
sistemas de comando e controle. A soluo tem duas abordagens principais,
igualmente importantes, para o estabelecimento de um protocolo. A primeira
abordagem o modelo de dados JC3IEDM, que supostamente conhecido,
comum e consolidado por todos os sistemas de C2. A segunda abordagem a
tecnologia de integrao usada para permitir a manipulao da mensagem, onde
geralmente so utilizados Servios Web, apesar do overhead esperado durante o
processo de leitura das mensagens.
SOA permite um forte desacoplamento entre clientes e servidores e
apoiada pela existncia de vrias ferramentas para o desenvolvimento do
projeto. O uso da tecnologia de Servios Web permite um maior desacoplamento
entre os sistemas de C2, o que leva independncia de linguagem de
programao e plataforma dos sistemas de C2 existentes nas FA.
O modelo de dados JC3IEDM define um padro para a modelagem de
informao, permitindo a utilizao de um mesmo vocabulrio para todos os
sistemas. Os dados so encaminhados atravs de objetos em mensagens tratadas
pelo
protocolo,
utilizando-se
os
paradigmas
de
Request/Response
Publish/Subscribe, o que fornece aos sistemas a capacidade de atualizar os dados

por demanda, ou atualiz-los periodicamente. Os requisitos do protocolo e os
exemplos de mensagens listados foram definidos para reduzir o impacto nas
operaes conjuntas, e permitir alcanar o sucesso no campo de batalha.
Esta soluo apresentada para o problema um passo inicial, utilizando um
conjunto de mensagens e regras para gerir o trfego entre SC2, usando os
requisitos do protocolo listados na seo 3 para minimizar o overhead causado
pelo uso de Servios Web. Estes requisitos foram baseados em experincias
anteriores de especialistas em sistemas de conscincia situacional martima e no
60
conhecimento das doutrinas de comando e controle contidas nas publicaes

listadas na seo 7.
CONTRIBUIES
Entre as principais contribuies deste trabalho, destacam-se:
Especificao de um protocolo para integrao de sistemas de

comando e controle, que possibilitou a utilizao de uma arquitetura
orientada a servios com a utilizao de troca de mensagens.
Artigo apresentado na ICEIS 2014 (LARA e CHOREN, 2014a), onde foi

desenvolvido um estudo do protocolo de integrao de sistemas de
comando e controle, sendo levantados alguns exemplos de mensagens
para este protocolo.
Artigo exposto no ICCRTS 2014 (LARA e CHOREN, 2014b), onde foi

apresentado o trabalho realizado durante o mestrado, com os
resultados alcanados at aquele momento para a elaborao de um
protocolo para troca de mensagens na integrao de sistemas de
comando e controle, utilizando o JC3IEDM.
TRABALHOS FUTUROS
Os trabalhos futuros sero baseados no projeto de uma arquitetura completa
para o protocolo do barramento de comunicao, que permita a manipulao de
mensagens entre os SC2s em tempo de execuo desses sistemas, e a elaborao
de uma camada de criptografia nas mensagens, o que tambm desejvel. Esta
camada deve ser forte o suficiente para garantir a realizao de exerccios de
operaes conjuntas sem qualquer interferncia, interna ou externa s FA.
Ressalta-se que esta camada de segurana deve ser definida e desenvolvida de
modo a no comprometer o desempenho do protocolo de troca de mensagens.
Durante o desenvolvimento deste trabalho foram levantadas vrias questes
a serem tratadas, e, devido s limitaes de tempo, elas no foram estudadas e
61
observadas mais profundamente, permanecendo como sugestes para trabalhos

futuros. Dentre estas questes, podemos citar:
Definir a especificao de uma arquitetura completa para o protocolo

de troca de mensagens, que possibilite o gerenciamento de mensagens
em tempo de execuo nos SC2s Legados. Para aumentar o
desempenho, pretende-se utilizar um middleware no barramento de
comunicao para o gerenciamento das filas de mensagens; e
Incluir na especificao do protocolo uma camada de criptografia, que

dever ser forte o suficiente para assegurar a conduo de operaes
conjuntas sem nenhuma interferncia, interna ou externa aos rgos
participantes. Essa camada de segurana deve ser especificada e
desenvolvida sem comprometer o desempenho de seu protocolo.
62
REFERNCIAS BIBLIOGRFICAS
ALBERTS, D. S. The Agility Advantage: A Survival Guide for Complex Enterprises

and Endeavors. The Command & Control Research Program. USA, 2011.
BRASIL. Doutrina de Operaes Conjuntas. Ministrio da Defesa, 2011.
ENDSLEY, M. R. Toward a theory of situational awareness in dynamic systems.
Human Factors: The Journal of the Human Factors and Ergonomics Society, v. 37,
p. 3264, mar. 1995.
ERL, T. SOA: Principles of Service Design. [s.l.] Pearson Prentice Hall, 2009.
HOHPE, G.; WOOLF, B. Enterprise integration patterns: Designing, building, and
deploying messaging solutions. 1. ed. [s.l.] Addison-Wesley Longman Publishing
Co., 2004.
HRSCH, W. L.; LOPES, C. V. Separation of Concerns. College of Computer Science.
Boston University, 1995.
LAM, W.; SHANKARARAMAN, V. An Enterprise Integration Methodology. IT
Professional, v. 6, n. 2, p. 4048, mar. 2004.
LARA, P.; CHOREN, R. A Message Exchange Protocol in Command and Control
Systems Integration, using the JC3IEDM. Proceedings in 19th International
Command and Control Research and Technology Symposium. DoD, Command
and Control Research Program. Virginia, USA, 2014.
LUND, K. et al. Using Web Services to Realize Service Oriented Architecture in
Military Communication Networks. Comm. Mag., v. 45, n. 10, p. 4753, out. 2007.
MIP. The Joint Consultation, Command and Control Information Exchange Data
Model. Multilateral Interoperability Programme. Germany, 2012.
MIP. Alternate Development and Exchange Method. Multilateral Interoperability
Programme. Germany, 2014.
NEGRO, T. O Ensino de Operaes Conjuntas nas Escolas de Altos Estudos das
Foras Armadas. Coleo Meira Mattos, v. 7, n. 28, p. 4754, jan. 2013.
63
TARANTI, P.-G. Um Roteiro para Projetos de Interoperabilidade em Sistemas de

C2: Como implantar um programa de interoperabilidade. Escola de Guerra
Naval. Rio de Janeiro, 2012.
64
APNDICES
65
APNDICE 1 - ESPECIFICAO DAS MENSAGENS NO FORMATO EBNF

A especificao dos RNFs das mensagens foi realizada atravs do
formalismo de Backus-Naur estendido, tambm conhecido como BNF (BackusNaus Form) estendido, ou EBNF, que uma meta-sintaxe utilizada para
expressar gramticas livres de contexto. A forma de Panini-Backus estendida
um modo formal de descrever linguagens formais.
Foram especificados trs tipos de mensagem atravs da forma normal de
Backus estendida:
1. Mensagem de Pedido da Posio de uma Unidade;
2. Mensagem de Pedido da Posio de Unidades em uma rea; e
3. Mensagem de Resposta para um Pedido de Posio.
66
1. MENSAGEM DE PEDIDO DA POSIO DE UMA UNIDADE

Esta mensagem realiza a solicitao da posio de uma Unidade conhecida,
utilizando a entidade associativa chamada OBJECT-ITEM-LOCATION, que
relaciona OBJECT-ITEM com LOCATION.
a) Formalismo da mensagem, utilizando o EBNF da ISO/IEC 14977
(* nvel 1: mensagem de pedido da posio de uma unidade (pelo
identificador) *)
qry_by_id = xml_prefix_min ,
soap_stag ,
soap_header_void ,
soap_body_stag ,
qry_unit_id_info ,
soap_body_etag ,
soap_etag ;
qry_unit_id_info = qry_info_stag , unit_position_req , qry_info_etag ;
unit_position_req = number ;
b) XML do Envelope SOAP do Pedido da Posio de uma Unidade

<?xml version="1.0"?>
<soapenv:Envelope xmlns:typ="http://ws.svc.jc3.example/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<To
<ns2:Sequence xmlns="http://www.w3.org/2005/08/addressing"
xmlns:ns2="http://docs.oasis-open.org/ws-rx/wsrm/200702"
xmlns:ns3="http://docs.oasis-open.org/ws-rx/wsmc/200702"
xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd" xmlns:ns5="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:ns6="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext1.1.xsd" xmlns:ns7="http://schemas.microsoft.com/ws/2006/05/rm"
xmlns:ns8="http://schemas.xmlsoap.org/soap/envelope/"
ns8:mustUnderstand="true">
<ns2:Identifier>uuid:1f17ff52-7489-4e75-b5ced61347e8c655</ns2:Identifier>
<ns2:MessageNumber>1</ns2:MessageNumber>
</ns2:Sequence>
<ns2:AckRequested xmlns="http://www.w3.org/2005/08/addressing"
xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd" xmlns:ns5="http://docs.oasis-
67
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:ns6="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext1.1.xsd" xmlns:ns7="http://schemas.microsoft.com/ws/2006/05/rm">
</ns2:AckRequested>
<ns2:SequenceAcknowledgement
xmlns="http://www.w3.org/2005/08/addressing" xmlns:ns2="http://docs.oasisopen.org/ws-rx/wsrm/200702" xmlns:ns3="http://docs.oasis-open.org/wsrx/wsmc/200702" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns5="http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
<ns2:Identifier>uuid:b0142f46-8913-4fab-a511ba89585be688</ns2:Identifier>
<ns2:None/>
</ns2:SequenceAcknowledgement>
</wsa:ReplyTo>
</wsa:FaultTo>
</S:Header><soapenv:Body><typ:unitPosition>1010</typ:unitPosition></soapenv
:Body>
</soapenv:Envelope>
68
2. MENSAGEM DE PEDIDO DA POSIO DE UNIDADES EM UMA REA

Esta mensagem realiza a solicitao da posio de Unidades conhecidas em
uma determinada rea retangular, utilizando as entidades LOCATION e
OBJECT-ITEM, atravs da associao OBJECT-ITEM-LOCATION.
a) Formalismo da mensagem, utilizando o EBNF da ISO/IEC 14977
(* nvel 1: mensagem de pedido da posio de unidades em uma rea *)
qry_by_latlong = xml_prefix_min ,
soap_stag ,
soap_header_void ,
soap_body_stag ,
qry_unit_latlong_info ,
soap_body_etag ,
soap_etag ;
qry_unit_latlong_info = qry_unit_latlong_info_stag ,
lat1_info ,
lat2_info ,
long1_info ,
long2_info ,
qry_unit_latlong_info_etag ;
lat1_info = lat1_info_stag ,
long1_info = long1_info_stag
latlong_num ,
, latlong_num
latlong_num ,
, latlong_num
lat1_info_etag ;
, long1_info_etag ;
lat2_info_etag ;
, long2_info_etag ;
qry_unit_latlong_info_stag = '<ns2:unitsInLatLong ' , xns_example , '">' ;

qry_unit_latlong_info_etag = '</ns2:unitsInLatLong>' ;
lat1_info_stag = '<lat1>' ;
lat1_info_etag = '</lat1>' ;
lat2_info_stag = '<lat2>' ;
lat2_info_etag = '</lat2>' ;
long1_info_stag = '<long1>' ;
long1_info_etag = '</long1>' ;
long2_info_stag = '<long2>' ;
long2_info_etag = '</long2>' ;
b) XML do Envelope SOAP no Pedido da Posio de Unidades de uma rea

<S:Header>
<To
69
</ns2:Sequence>
</ns2:AckRequested>
<ns2:None/>
</wsa:ReplyTo>
</wsa:FaultTo>
</S:Header>
<S:Body>
<ns2:unitsInLatLong xmlns:ns2="http://ws.svc.jc3.example/">
<lat1>50</lat1>
<lat2>100</lat2>
<long1>40</long1>
<long2>100</long2>
</ns2:unitsInLatLong>
</S:Body>
</S:Envelope>
70
3. MENSAGEM DE RESPOSTA PARA UM PEDIDO DE POSIO

Esta mensagem responde a solicitao da posio de Unidades conhecidas,
seja ela uma Unidade especfica, ou Unidades em uma determinada rea
retangular, utilizando as entidades LOCATION e OBJECT-ITEM, atravs da
associao OBJECT-ITEM-LOCATION.
a) Formalismo da mensagem, utilizando o EBNF (ISO/IEC 14977)
(* nvel 1: resposta latlong (j) sem envelope soap *)
srv_resp = xml_prefix , unit_position ;
unit_position = unit_position_stag , unit_position_body ,
unit_position_etag ;
unit_position_body = unit_abrev , unit_id , unit_lat , unit_long ,
unit_name , unit_report_time, unit_report_type ;
unit_abrev = unit_abrev_stag , string , unit_abrev_etag ;
unit_name = unit_name_stag , string , unit_name_etag ;
unit_id = unit_id_stag , number , unit_id_etag ;
unit_lat = unit_lat_stag , latlong_num , unit_lat_etag ;
unit_long = unit_long_stag , latlong_num , unit_long_etag ;
unit_report_time = unit_report_time_stag , report_time ,
unit_report_time_etag ;
unit_report_type = unit_report_type_stag , report_type ,
unit_report_type_etag ;
latlong_num = 2 * digit , '.' , ( digit , [ digit ] ) ;
report_time = 2 * digit , ':' , 2 * digit , ':' , 2 * digit ;
report_type = string ;
unit_position_stag = '<typ:unitPosition ' , xns_example , '">' ;
unit_position_etag = '</typ:unitPosition>' ;
unit_position_stag = '<vwUnitPosition>' ;
unit_position_etag = '</vwUnitPosition>' ;
unit_abrev_stag = '<abrev>' ;
unit_abrev_etag = '</abrev>' ;
unit_id_stag = '<id>' ;
unit_id_etag = '</id>' ;
unit_lat_stag = '<latitude>' ;
unit_lat_etag = '</latitude>' ;
unit_long_stag = '<longitude>' ;
unit_long_etag = '</longitude>' ;
unit_name_stag = '<name>' ;
unit_name_etag = '</name>' ;
unit_report_time_stag = '<reportTime>' ;
unit_report_time_etag = '</reportTime>' ;
unit_report_time_stag = '<reportType>' ;
unit_report_time_etag = '</reportType>' ;
uri = urn | url ;
number = digit { digit } ;
string = { [ lowalpha | hialpha | digit | ' ' ] } ;
71
b) XML do Envelope SOAP da Resposta a um Pedido de Posio

<S:Header>
LongResponse</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:dbdbe21fb84d-4ae4-848d-e4ffade834ba</MessageID>
<RelatesTo xmlns="http://www.w3.org/2005/08/addressing">uuid:73cc64de8daf-45d6-8b8c-40564fd6dce7</RelatesTo>
</ns2:Sequence>
</ns2:AckRequested>
<ns2:AcknowledgementRange Upper="1" Lower="1"/>
<To xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasisopen.org/ws-rx/wsmc/200702/anonymous?id=5598fb43-f857-44cb-949230515e4e0942</To>
<MessagePending xmlns="http://docs.oasis-open.org/ws-rx/wsmc/200702"
xmlns:ns2="http://www.w3.org/2005/08/addressing" pending="false"/>
</S:Header>
<S:Body>
<ns2:unitsInLatLongResponse xmlns:ns2="http://ws.svc.jc3.example/">
<return>
<abrev>UIE5 ATB</abrev>
72
<id>1010</id>
<name>Unidentified AntiTank Battery 5</name>
</return>
<return>
<abrev>UIE9 FA</abrev>
<id>1017</id>
<name>Unidentified FA Battalion 9</name>
</return>
</ns2:unitsInLatLongResponse>
</S:Body>
</S:Envelope>
73
APNDICE 2 - DESCRIO DO SERVIO WEB

O texto XML abaixo apresenta uma Web Service Description Language (WSDL),
que
define
interface
produtor/consumidor,
ou
seja,
contratode
comunicao, onde so estabelecidos o valor do tempo de resposta mximo de

cinco segundos (5000ms), e a garantia de entrega da mensagem de pelo menos
uma vez, parmetros configurados atravs da especificao WS-Policy como
RNFs do Servio Web.
<?xml version='1.0' encoding='UTF-8'?><definitions
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd" xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://ws.svc.jc3.example/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="http://ws.svc.jc3.example/" name="PositionReportWS">
<wsp:Policy xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702"
xmlns:net35rmp="http://schemas.microsoft.com/ws-rx/wsrmp/200702"
wsu:Id="SvcWsUnitPositionPortBindingPolicy">
<wsrmp:RMAssertion>
<wsp:Policy>
<wsrmp:DeliveryAssurance>
<wsp:Policy>
<wsrmp:AtLeastOnce/>2
</wsp:Policy>
</wsrmp:DeliveryAssurance>
</wsp:Policy>
</wsrmp:RMAssertion>
<net35rmp:InactivityTimeout Milliseconds="5000"/>3
<wsam:Addressing/>
</wsp:Policy>
<wsp:Policy xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702"
wsu:Id="SvcWsUnitPositionPortBinding_MCSupported_Policy">
<wsmc:MCSupported/>
</wsp:Policy>
<wsp:Policy xmlns:wsat200410="http://schemas.xmlsoap.org/ws/2004/10/wsat"
wsu:Id="SvcWsUnitPositionPortBinding_unitPosition_Policy">
<wsat200410:ATAssertion
xmlns:ns1="http://schemas.xmlsoap.org/ws/2002/12/policy"
wsp:Optional="true" ns1:Optional="true"/>
</wsp:Policy>
<types>
<xsd:schema>
<xsd:import namespace="http://ws.svc.jc3.example/"
schemaLocation="http://localhost:8080/jc3-svc/PositionReportWS?xsd=1"/>
2
3
Requisito No Funcional de Resilincia: Garantia de Entrega da Mensagem de pelo menos uma vez.
Requisito No Funcional de Tempo de Resposta: Tempo Mximo de Inatividade = 5000ms (5 segundos).
74
</xsd:schema>
</types>
<message name="unitPosition">
<part name="parameters" element="tns:unitPosition"/>
</message>
<message name="unitPositionResponse">
<part name="parameters" element="tns:unitPositionResponse"/>
</message>
<message name="unitsInLatLong">
<part name="parameters" element="tns:unitsInLatLong"/>
</message>
<message name="unitsInLatLongResponse">
<part name="parameters" element="tns:unitsInLatLongResponse"/>
</message>
<portType name="SvcWsUnitPosition">
<operation name="unitPosition">
<input
wsam:Action="http://ws.svc.jc3.example/SvcWsUnitPosition/unitPositionReques
t" message="tns:unitPosition"/>
<output
wsam:Action="http://ws.svc.jc3.example/SvcWsUnitPosition/unitPositionRespon
se" message="tns:unitPositionResponse"/>
</operation>
<operation name="unitsInLatLong">
<input
wsam:Action="http://ws.svc.jc3.example/SvcWsUnitPosition/unitsInLatLongRequ
est" message="tns:unitsInLatLong"/>
<output
wsam:Action="http://ws.svc.jc3.example/SvcWsUnitPosition/unitsInLatLongResp
onse" message="tns:unitsInLatLongResponse"/>
</operation>
</portType>
<binding name="SvcWsUnitPositionPortBinding" type="tns:SvcWsUnitPosition">
<wsp:PolicyReference
URI="#SvcWsUnitPositionPortBinding_MCSupported_Policy"/>
<wsp:PolicyReference URI="#SvcWsUnitPositionPortBindingPolicy"/>
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"/>
<operation name="unitPosition">
<wsp:PolicyReference
URI="#SvcWsUnitPositionPortBinding_unitPosition_Policy"/>
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
</output>
</operation>
<operation name="unitsInLatLong">
<soap:operation soapAction=""/>
<input>
</input>
<output>
</output>
</operation>
</binding>
<service name="PositionReportWS">
75
<port name="SvcWsUnitPositionPort"
binding="tns:SvcWsUnitPositionPortBinding">
<soap:address location="http://localhost:8080/jc3-svc/PositionReportWS"/>
</port>
</service>
</definitions>
Observa-se na descrio do Servio Web, as operaes unitPosition e

unitsInLatLong, que so os mtodos implementados atravs dos quais se permite
a realizao do processo de Consultar a Localizao do Acompanhamento.
76
APNDICE 3 - FORMALISMO DO WEB SERVICE RELIABLE MESSAGE

(* wsrm EBNF segundo a gramtica ISO/IEC 14977
*)
(*
(*
(*
(*
(*
(*
(*
(*
(*
(*
(*
(*
*)
*)
*)
*)
*)
*)
*)
*)
*)
*)
*)
*)
entidades em comunicao: cli <-> rms <-> rmp <-> srv

cli: Client Application
srv: Server (Provider)
rms: ReliableMessageSource (camada)
rmp: ReliableMessageProvider (camada)
origin = cli | rms |
dir = to | from ;
msg = origin , dir ,
soap = soap_header ,
comm = origin , soap
rmp | srv ;
soap ;
soap_body ;
;
(* mensagens nvel 2 *)
wsrm = { dialog } ;
dialog = cli_req ,
rms_create_seq ,
rmp_create_seq_resp ,
rms_cli_req_with_seq ,
srv_cli_req ,
srv_srv_resp ,
rmp_create_seq_with_seq_ack ,
rms_create_seq_resp ,
rmp_srv_resp_with_seq ,
cli_srv_resp ,
rms_seq_ack ;
cli_req = cli , to , ( qry_by_id | qry_by_lat_long ) ;
(* nvel 1 *)
cli_srv_resp = cli , from , srv_resp ;
(* nvel 1 *)
rms_create_seq = rms , to , create_seq ;
rms_cli_req_with_seq = rms , to , cli_req_with_seq ;
rms_create_seq_resp = rms , to , create_seq_resp ;
rms_seq_ack = rms , to , seq_ack ;
rmp_create_seq_resp = rmp , from , create_seq_resp_sm ;
rmp_create_seq_with_seq_ack = rmp , from , create_seq_with_seq_ack ;
rmp_srv_resp_with_seq = rmp , from , resp_with_seq ;
rmp_create_seq_resp = rmp , from , create_seq_resp ;
seq_ack = wsrm_seq_ack_stag , wsrm_seq_ack , wsrm_seq_ack_etag ;
create_seq = create_seq_header , create_seq_body ;
create_seq_header = soap_header_void ;
create_seq_body = soap_body_stag , wsrm_create_seq , soap_body_etag ;
create_seq_resp_sm = xml_prefix , from , soap_stag , create_seq_resp ,
soap_etag ;
create_seq_resp = create_seq_resp_header , create_seq_resp_body ;
create_seq_resp_header = soap_header_void ;
create_seq_resp_body = soap_body_stag , wsrm_seq_resp , soap_body_etag ;
77
wsrm_seq_resp = wsrm_create_seq_resp_stag ,
wsrm_identifier ,
wsrm_create_seq_resp_etag ;
wsrm_create_seq = wsrm_create_seq_stag , wsrm_ack_to , wsrm_create_seq_etag
;
wsrm_ack_to = wsrm_ack_to_stag , wsa_address , wsrm_ack_to_etag ;
wsrm_seq_ack = wsrm_identifier , wsrm_ack_range ;
wsrm_identifier = wsrm_identifier_stag , urn , wsrm_identifier_etag ;
wsa_address = wsa_address_stag , uri , wsa_address_etag ;
wsa_to = wsa_to_stag , url , wsa_to_etag ;
wsa_msg_id = wsa_msg_id_stag , urn , wsa_msg_id_etag ;
wsa_action = wsa_action_stag , uri , wsa_action_etag ;
(* prefixo xml *)
xml_prefix_min = ts , qm , xml , xml_version , qm , tc ;
xml_prefix = ts, qm, xml , xml_version , xml_encoding , xml_standalone , qm
, tc ;
xml_version = sp , 'version' , eq , quote , '1.0' , quote ;
xml_encoding = 'encoding' , eq , quote , 'UTF-8' , quote ;
xml_standalone = 'standalone' , eq , quote , 'yes' , quote ;
(* tags *)
soap_stag = ts , soapenv , n_envelope , xns_example , xns_soap , tc ;
soap_etag = te, soapenv , ns_sep, n_envelope , tc ;
soap_header_void = ts , soapenv , ns_sep , n_header , tf ;
soap_header_stag = ts , soapenv , ns_sep , n_header , tc ;
soap_header_etag = te , soapenv, ns_sep , n_header , tc ;
soap_body_stag = ts , soapenv , ns_sep , n_body , tc ;
soap_body_etag = te , soapenv , ns_sep , n_body , tc ;
wsa_to_stag = ts , wsa , ns_sep , n_to , tc ;
wsa_to_etag = te , wsa , ns_sep , n_to , tc;
wsa_address_stag = ts , wsa , ns_sep , n_address , tc ;
wsa_address_etag = te , wsa , n_address , tc ;
wsrm_seq_ack_stag = ts , wsrm , ns_sep , n_sequence_acknowledgement ,
xns_wsrm , soapenv , wsrm_must_understand , tc ;
wsrm_must_understand = sp , 'mustUnderstand' , eq , quote , '1' , quote ;
wsrm_seq_ack_etag = te , wsrm , ns_sep , n_sequence_acknowledgement' , tc;
wsrm_ack_range = ts , wsrm , ns_sep , n_acknowledgement_range ,
wsrm_ack_lower_range , wsrm_ack_upper_range , tf ;
wsrm_ack_lower_range = sp , n_lower ,
wsrm_ack_upper_range = sp , n_upper ,
wsrm_ack_to_stag = ts , wsrm , ns_sep
wsrm_ack_to_etag = te, wsrm, ns_sep ,
eq , quote , number , quote ;

eq , quote , number , quote ;
, n_acks_to , tc ;
n_acks_to , tc ;
78
wsrm_create_seq_stag = ts, wsrm , ns_sep , n_create_sequence , xns_wsrm ,

tc ;
wsrm_create_seq_etag = te, wsrm , ns_sep , n_create_sequence , tc ;
wsrm_create_seq_resp_stag = ts, wsrm , ns_sep , n_create_sequence_response
, xns_wsrm , tc ;
wsrm_create_seq_resp_etag = te , wsrm , ns_sep , n_create_sequence_response
, tc ;
wsrm_identifier_stag = ts , wsrm, ns_sep, n_Identifier , tc ;
wsrm_identifier_etag = te , wsrm, ns_sep , n_identifier , tc;
(* namespaces *)
xns_soap = sp , xmlns , soapenv, eq , quote , ns_soap , quote ;
xns_wsrm = sp , xmlns , wsrm , eq , quote, ns_wsrm , quote ;
xns_example = sp , xmlns , typ , eq , quote , ns_example , quote ;
s_soap = 'http://schemas.xmlsoap.org/soap/envelope/' ; (* fixo *)
ns_wsrm = 'http://docs.oasis-open.org/ws-rx/wsrm/200702' ; (* fixo *)
ns_example = 'http://ws.svc.jc3.example/' ; (* fixo *)
(* abreviao para namespaces *)

soapenv = 'soapenv' ;
typ = 'typ' ;
wsa = 'wsa' ;
wsrm = 'wsrm' ;
xmlns = xml, 'ns' , ns_sep ;
xml = 'xml' ;
(* nomes de elementos *)
n_create_sequence_response = n_create_sequence , n_response ;
n_create_sequence = n_create , n_sequence ;
n_sequence_acknowledgement = n_sequence , n_acknowledgement ;
n_acknowledgement_range = n_acknowledgement , n_range ;
n_acknowledgement = 'Acknowledgement' ;
n_create = 'Create' ;
n_range = 'Range' ;
n_response = 'Response' ;
n_sequence = 'Sequence' ;
n_envelope = 'Envelope' ;
n_header = 'Header' ;
n_body = 'Body' ;
n_address = 'Address' ;
n_acks_to = 'Acks' , n_to ;
n_to = 'To' ;
n_lower = 'Lower' ;
n_upper = 'Upper' ;
n_identifier = 'Identifier' ;
79
(* pontuao/delimitadores *)
te = ts , tn ;
tf = tn , tc ;
ts = '<' ;
tc = '>' ;
tn = '/' ;
qm = '?' ;
ns_sep = colon ;
dot = '.' .
colon = ':' ;
quote = '"' ;
eq = '=' ;
(* marcadores para auxiliar leitura *)

cli = ; (* mensagem produzida pelo cliente *)
srv = ; (* mensagem produzida pelo servidor *)
rms = ; (* mensagem produzida pelo pelo rms *)
rmp = ; (* marcador para indicar que essa mensagem produzida pelo pelo
rmp *)
to = ; (* para indicar o sentido do cliente para o servidor *)
from = ; (* para indicar o sentido do servidor para o cliente *)
(* nvel 1: mensagem de pedido da posio de unidades em uma rea *)

qry_by_latlong = xml_prefix_min ,
soap_stag ,
soap_header_void ,
soap_body_stag ,
qry_unit_latlong_info ,
soap_body_etag ,
soap_etag ;
qry_unit_latlong_info = qry_unit_latlong_info_stag ,
lat1_info ,
lat2_info ,
long1_info ,
long2_info ,
qry_unit_latlong_info_etag ;
qry_unit_latlong_info_stag =
xns_example , tc ;
qry_unit_latlong_info_etag =
lat1_info_stag = ts , n_lat1
lat1_info_etag = te , n_lat1
lat2_info_stag = ts , n_lat2
lat2_info_etag = te , n_lat2
latlong_num , lat1_info_etag ;
, latlong_num , long1_info_etag ;
latlong_num , lat2_info_etag ;
, latlong_num , long2_info_etag ;
ts , ns2 , ns_sep , n_units_in_latlong ,
te ,
, tc
, tc
, tc
, tc
ns2 , ns_sep , n_units_in_latlong , tc;

;
;
;
;
80
long1_info_stag = ts , n_long1 , tc ;
long1_info_etag = te , n_long1 , tc;
long2_info_stag = ts , n_long2 , tc ;
long2_info_etag = te, n_long2 , tc ;
n_units_in_latlong = 'unitsInLatLong' ;
n_lat1 = n_lat , '1' ;
n_lat2 = n_lat , '2' ;
n_long1 = n_long , '1' ;
n_long2 = n_long , '2' ;
lat = 'lat' ;
long = 'long' ;
(* nvel 1: mensagem de pedido da posio de uma unidade (pelo

identificador) *)
qry_by_id = xml_prefix_min ,
soap_stag ,
soap_header_void ,
soap_body_stag ,
qry_unit_id_info ,
soap_body_etag ,
soap_etag ;
qry_unit_id_info = qry_info_stag , unit_position_req , qry_info_etag ;
unit_position_req = number ;
(* nvel 1: resposta latlong sem envelope soap *)

srv_resp = xml_prefix , unit_position ;
unit_position = unit_position_stag , unit_position_body ,
unit_position_etag ;
unit_position_body = unit_abrev , unit_id , unit_lat , unit_long ,
unit_name , unit_report_time, unit_report_type ;
unit_abrev = unit_abrev_stag , string , unit_abrev_etag ;
unit_name = unit_name_stag , string , unit_name_etag ;
unit_id = unit_id_stag , number , unit_id_etag ;
unit_lat = unit_lat_stag , latlong_num , unit_lat_etag ;
unit_long = unit_long_stag , latlong_num , unit_long_etag ;
unit_report_time = unit_report_time_stag , report_time ,
unit_report_time_etag ;
unit_report_type = unit_report_type_stag , report_type ,
unit_report_type_etag ;
latlong_num = 2 * digit , dot , ( digit , [ digit ] ) ;
report_time = 2 * digit , colon , 2 * digit , colon , 2 * digit ;
unit_position_stag = ts , typ , np_sep , n_unit_position , xns_example , tc
;
unit_position_etag = te , typ , ns_sep , n_unit_position , tc ;
unit_position_stag = ts , n_vw_unit_position , tc ;
unit_position_etag = te , n_vw_unit_position , tc ;
unit_abrev_stag = ts , n_abrev , tc;
unit_abrev_etag = te , n_abrev , tc ;
unit_id_stag = ts , n_id , tc ;
81
unit_id_etag = te , n_id , tc ;
unit_lat_stag = ts , n_latitude , tc ;
unit_lat_etag = te , n_latitude , tc ;
unit_long_stag = ts , n_longitude , tc ;
unit_long_etag = te , n_longitude , tc ;
unit_name_stag = ts , n_name , tc ;
unit_name_etag = te , n_name , tc ;
unit_report_time_stag = ts , n_report_time
unit_report_time_etag = te , n_report_time
unit_report_time_stag = ts , n_report_type
unit_report_time_etag = te , n_report_type
n_vw_unit_position = 'vwUnitPosition' ;
n_unit_position = 'unitPosition' ;
n_abrev = 'abrev' ;
n_id = 'id' ;
n_name = 'name' ;
n_latitude = 'latitude' ;
n_longitude = 'longitude' ;
n_report_time = report , 'Time' ;
n_report_type = report , 'Type' ;
n_report = 'report' ;
report_type = string ;
,
,
,
,
tc
tc
tc
tc
;
;
;
;
(* auxiliar *)
uri = urn | url ;
number = digit { digit } ;
sp = sp , sz ;
sz = { [ ' ' ] } ;
string = { [ lowalpha | hialpha | digit | ' ' ] } ;
(* urn RFC 2141 ------------------------------------------------------- *)

urn = "urn:" , nid , ":" , nss ;
nid = let_num , 31 * [ let_num_hyp ] ;
let_num_hyp = hialpha | loalpha | digit | "-" ;
let_num = hialpha | loalpha | digit ;
nss = urn_chars ;
urn_chars = trans | "%" , hex hex ;
trans = hialpha | loalpha | number | other | reserved_urn ;
other = "(" | ")" | "+" | "," | "-" | "." | ":" | "=" | "@" | ";" | "$" |
"_" | "!" | "*" | "'" ;
reserved_urn = '%" | "/" | "?" | "#" ;
(* url RFC 1738 ------------------------------------------------------- *)

url
= httpurl | ftpurl | mailtourl | fileurl | otherurl ;
otherurl
= genericurl ;
genericurl
= scheme , ":" , schemepart ;
scheme
= { [ lowalpha | digit | "+" | "-" | "." ] } ;
82
schemepart
ip-schemepart
login
hostport
host
hostname
domainlabel
alphadigit ;
toplabel
alphadigit
hostnumber
port
user
password
urlpath
=
=
=
=
=
=
=
{ xchar } | ip-schemepart ;
"//" , login , [ "/" , urlpath ] ;
[ user , [ ":" , password ] , "@" ] , hostport ;
host , [ ":" , port ] ;
hostname | hostnumber ;
{ [ domainlabel , "." ] } , toplabel ;
alphadigit | alphadigit { [ alphadigit | "-" ] } ,
=
=
=
=
=
=
=
alpha | alpha { [ alphadigit | "-" ] } , alphadigit ;

alpha | digit ;
digits , "." , digits , "." , digits , "." , digits ;
digits ;
{ [ uchar | ";" | "?" | "&" | "=" ] } ;
{ [ uchar | ";" | "?" | "&" | "=" ] } ;
{ xchar } ;
(* ftp (RFC959) *)
ftpurl
fpath
fsegment
ftptype
=
=
=
=
"ftp://" , login , [ "/" , fpath [ ";type=" , ftptype ]] ;

fsegment , { [ "/" , fsegment ] } ;
{ [ uchar | "?" | ":" | "@" | "&" | "=" ] } ;
"A" | "I" | "D" | "a" | "i" | "d" ;
(* file *)
fileurl
= "file://" , [ host | "localhost" ] , "/" , fpath ;
(* http *)
httpurl
hpath
hsegment
search
=
=
=
=
"http://" , hostport , [ "/" , hpath , [ "?" , search ]] ;

hsegment , { [ "/" , hsegment ] } ;
{ [ uchar | ";" | ":" | "@" | "&" | "=" ] } ;
{ [ uchar | ";" | ":" | "@" | "&" | "=" ] } ;
(* MAILTO (RFC822) *)
mailtourl
= "mailto:" , encoded822addr ;
encoded822addr = { xchar } ;
(* misc *)
lowalpha
= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |

"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
83
"y" | "z" ;
hialpha
= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |

"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ;
alpha
digit
;
safe
extra
= lowalpha | hialpha ;
= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
national
punctuation
reserved
= "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`" ;

= "<" | ">" | "#" | "%" | <"> ;
= ";" | "/" | "?" | ":" | "@" | "&" | "=" ;
= "$" | "-" | "_" | "." | "+" ;

= "!" | "*" | "'" | "(" | ")" | "," ;
hex
= digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" |
"c" | "d" | "e" | "f" ;
escape
unreserved
uchar
xchar
digits
=
=
=
=
=
"%" , hex , hex ;

alpha | digit | safe | extra ;
unreserved | escape ;
unreserved | reserved | escape ;
digit ;
(* fim *)
84

Protocolo JC3IEDM para Integração de Sistemas C2 resume de forma concisa e relevante para o o tema central do documento, que é a proposta de um protocolo baseado no modelo JC3IEDM

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Protocolo JC3IEDM para Integração de Sistemas C2 resume de forma concisa e relevante para o o tema central do documento, que é a proposta de um protocolo baseado no modelo JC3IEDM

Diunggah oleh

Hak Cipta:

Format Tersedia

MINISTRIO DA DEFESA

PATRICK BAPTISTA AMARAL DE LARA

UM PROTOCOLO PARA INTEGRAO DE

INSTITUTO MILITAR DE ENGENHARIA

PATRICK BAPTISTA AMARAL DE LARA

UM PROTOCOLO PARA INTEGRAO DE

Dissertao de Mestrado apresentada ao

INSTITUTO MILITAR DE ENGENHARIA

Este exemplar de propriedade do Instituto Militar de Engenharia, que

permitida a meno, reproduo parcial ou integral e a transmisso entre

Lara, Patrick Baptista Amaral de

INSTITUTO MILITAR DE ENGENHARIA

PATRICK BAPTISTA AMARAL DE LARA

UM PROTOCOLO PARA INTEGRAO DE

Aprovada em 05 de agosto de 2014 pela seguinte Banca Examinadora:

Dedico este trabalho a minha Famlia.

Patrick Baptista Amaral de Lara

Contribuies Esperadas ......................................................................................................... 18

Organizao do Trabalho ........................................................................................................ 18

CONCEITOS BSICOS .............................................................................................. 19

Interoperabilidade de Sistemas .............................................................................................. 19

O Modelo JC3IEDM ................................................................................................................. 21

Arquitetura Orientada a Servios .......................................................................................... 26

O PROTOCOLO PROPOSTO .................................................................................... 29

Requisitos para Interoperabilidade em Operaes Conjuntas .......................................... 29

Primeiro Nvel de Integrao: Entidades do JC3IEDM ...................................................... 34

Segundo Nvel de Integrao: Troca de Mensagens ........................................................... 42

As Mensagens do Protocolo ................................................................................................... 43

PROVA DE CONCEITO ............................................................................................. 45

Transformao dos Dados dos SC2 Legados para o JC3IEDM ......................................... 46

Mensagem de Pedido da Posio de uma Unidade ............................................................ 47

Mensagem de Pedido da Posio de Unidades em uma rea ........................................... 47

Fluxo da Mensagem de Requisio ....................................................................................... 52

Fluxo da Mensagem de Resposta ........................................................................................... 52

Roteiro para Implementao do Caso de Teste ................................................................... 53

Construo do banco de dados baseado no JC3IEDM........................................................ 53

Construo dos Artefatos ........................................................................................................ 53

Construo do Cliente ............................................................................................................. 54

4.10 Construo do Console ........................................................................................................... 54

TRABALHOS RELACIONADOS ............................................................................. 56

Utilizando Servios Web e SOA nas comunicaes militares ............................................ 56

Mtodo Alternativo de Desenvolvimento e Troca (ADEM) .............................................. 57

Trabalhos Futuros .................................................................................................................... 61

REFERNCIAS BIBLIOGRFICAS ......................................................................... 63

Alternate Development and Exchange Method

Command and Control System

Data Exchange Mechanism

HyperText Transfer Protocol

International Command and Control Research and Technology Symposium

Integrated Development Environment

Joint Consultation, Command and Control Information Exchange Data Model

Message Exchange Mechanism

Multilateral Interoperability Programme

Object Management Group

Observe, Orient, Decide and Act

Organizao do Tratado do Atlntico Norte

Unified Modeling Language

Sistema de Comando e Controle

Sistema de Planejamento Operacional Militar

Service Oriented Architecture

Simple Object Access Protocol

eXtensible Markup Language

Nos diversos nveis decisrios, do poltico-estratgico ao ttico, a capacidade