implementação de uma arquitetura soa para interoperabilidade entre sistemas de comando e controle

7/25/2019 Implementao de uma arquitetura SOA para interoperabilidade entre sistemas de Comando e Controle

1/68

i

Universidade Federal do Rio de Janeiro

Escola Politcnica

MBA em Engenharia de Computao e Sistemas

Implementao de uma arquitetura SOA parainteroperabilidade entre sistemas de Comando e Controle

Autor:

_________________________________________________Jorge Eduardo Calvelli

Orientador:

_________________________________________________Prof. Flvio Luis de Mello, DSc.

Examinador:

_________________________________________________Prof. Edilberto Strauss, PhD

Examinador:

_________________________________________________Prof. Claudio Luiz Latta de Souza, MSc

Examinador:

_________________________________________________Prof. Manoel Villas Bas Jnior, MSc

Examinador:

_________________________________________________Prof. Noberto Ribeiro Bellas, MSc

Examinador:

_________________________________________________Prof. Paulo Fernando Peixoto da Costa Fazzioni, MSc

MBCA

Maro de 2016


2/68

ii

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politcnica Departamento de Eletrnica e de Computao

MBA em Engenharia de Computao e Sistemas

Centro de Tecnologia, bloco H, sala H-217, Cidade Universitria

Rio de Janeiro RJ CEP 21949-900

Este exemplar de propriedade da Universidade Federal do Rio de Janeiro, 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 estejaou 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(s) autor(es).


3/68

iii

DEDICATRIA

A minha famlia, meu alicerce, que me incentiva e me ajuda a seguir em frente.


4/68

iv

AGRADECIMENTO

A minha famlia, pelo apoio e compreenso.

Aos meus amigos do trabalho: Toms Aquino Botelho, Patrick Lara, Manuel S

e Simione Campelo, que me ajudaram de forma inestimvel, esclarecendo dvidas

tcnicas e de negcio, ampliando meus conhecimentos.

Ao meu orientador Flvio Luis de Mello, pela pacincia e apoio, fatores

fundamentais, sem os quais minha tarefa teria sido muito mais difcil.


5/68

v

Resumo

A dificuldade de integrao de dados entre sistemas informatizados de Comando

e Controle (C2) um problema atual, que afeta o setor militar de muitas naes,

incluindo o Brasil. A integrao deve levar em considerao no apenas os sistemas,

mas deve considerar tambm a existncia de processos associados operacionalizao

da troca de dados e sobre como os mesmos so usados ou descartados. A adoo de uma

Arquitetura Orientada a Servios (SOA) prov uma boa soluo para integrao de

sistemas heterogneos, possibilitando o desacoplamento entre esses sistemas e

facilitando a troca de mensagens entre eles. O presente trabalho apresenta o projeto

piloto de implementao de uma arquitetura SOA para prover uma soluo de

interoperabilidade entre Sistemas de Comando e Controle das Foras Armadas em

operaes conjuntas baseada no modelo dados Joint Consultation, Command andControl Information Exchange Data Model (JC3IEDM). No decorrer do ano de 2015,

foram construdos o prottipo do barramento de comunicao e os simuladores dos

sistemas de C2, com os quais, juntamente com o Sistema Naval de Comando e Controle

(SISNC2), foi possvel executar os testes de exequibilidade, demonstrando a viabilidade

do projeto. Diante das tecnologias analisadas, percebe-se a necessidade de um

aprofundamento no estudo da BML em funo das limitaes do ADEM e se vislumbra

uma possvel contribuio para integrao de servios de segurana pblica, defesa civile sade pblica.

Palavras-Chave: Comando e Controle, interoperabilidade, SOA, JC3IEDM, ADEM,

BML


6/68


7/68

vii

SIGLAS

ADEM -Alternate Development and Exchange MethodBBS- BML Base ServicesBML -Battle Management LanguageBPM -Business Process Management

BPMS -Business Process Management SystemC-BML - Coalition Battle Management LanguageC2 - Comando e ControleCASNAV - Centro de Anlises de Sistemas NavaisCDAS - Common Data Access ServicesCOP - Controle da Operao PlanejadaDCS -Domain Configured ServiceDEM -Data Exchange MechanismEAI -Enterprise Application IntegrationEB - Exrcito BrasileiroESB - Enterprise Service Bus

FA - Fora ArmadaFAB - Fora Area BrasileiraFcte - Fora ComponenteFFAA - Foras ArmadasFS - Fora SigularHE - Hipoteses de EmpregoHTTP -Hyper Text Transfer ProtocolIBML- Integrated BMLInterC2 - Interoperabilidade de Comando e ControleJC3IEDM - Joint Consultation, Command and Control Information Exchange DataModelJSON -Javascript Object NotationMB - Marinha do BrasilMD - Ministrio da Defesa do BrasilMIP -Multilateral Interoperability ProgramOpCj - Operao ConjuntaOpSing - Operao SingularPPC - Processo de Planejamento ConjuntoRest -Representational State TransferSIPLOM - Sistema de Planejamento Operacional MilitarSISMC2 - Sistema Militar de C2

SISNC2 - Sistema Naval de Comando e ControleSISO - Simulation Interoperability Standards OrganizationSOA - Arquitetura Orientada a ServiosSOAP - Simple Object Access ProtocolSTIC2 - Sistemas de Tecnologia da Informao para C2UDDI - Universal Description, Discovery and IntegrationURI - Uniform Resource IdentifierWSDL - Web Services Description LanguageXML -Extensible Markup Language


8/68

viii

Sumrio

INTRODUO .............................................................................................................. 1

1.1TEMA.................................................................................................................... 1

1.2JUSTIFICATIVA...................................................................................................... 1

1.3DELIMITAO....................................................................................................... 31.4OBJETIVO .............................................................................................................. 31.5METODOLOGIA..................................................................................................... 41.6DESCRIO........................................................................................................... 4

COMANDO E CONTROLE E A INTEROPERABILIDADE .................................. 5

2.1COMANDO E CONTROLE........................................................................................ 52.2INTEROPERABILIDADE........................................................................................... 92.3SISTEMAS E FRAMEWORKS EXISTENTES.............................................................. 11

2.3.1-JC3IEDM ......................................................................................................... 11

2.3.2-ADEM ............................................................................................................. 152.3.3-BML ................................................................................................................. 17

2.3.4WISE-SBML ................................................................................................... 222.3.5SITAWARE COALITION GATEWAY................................................................... 232.4PARMETROS DE INTEROPERABILIDADE ENTRE SISTEMAS DE C2 ....................... 25

ARQUITETURA ORIENTADA A SERVIOS (SOA) ........................................... 27

3.1CONCEITOS......................................................................................................... 273.2PRINCPIOS .......................................................................................................... 293.3TECNOLOGIA USADA.......................................................................................... 313.4GOVERNANA..................................................................................................... 34

PROPOSTA DE SOLUO ....................................................................................... 38

4.1ARQUITETURA DO BARRAMENTO........................................................................ 404.2AINTERFACE DE COMUNICAO........................................................................ 424.3EXEMPLIFICANDO O PROCESSO DE TROCA DE MENSAGENS.................................. 46

CONCLUSO ............................................................................................................... 54

5.1CONCLUSO........................................................................................................ 54

5.2TRABALHOS FUTUROS......................................................................................... 54

BIBLIOGRAFIA .......................................................................................................... 56


9/68

ix

Lista de FigurasFigura 2.1 - Ciclo OODA ................................................................................................. 8Figura 2.2- Evoluo da Interoperabilidade ..................................................................... 9Figura 2.3- Modelo simplificado do JC3IEDM ............................................................. 14

Figura 2.4 - Intercmbio de informaes MIP x no MIP ............................................. 16Figura 2.5 - Arquitetura JBML Viso Geral............................................................... 19

Figura 2.6 - Matriz produtor / consumidor C-BML ...................................................... 20Figura 2.7 - Arquitetura Wise-SBML............................................................................ 23

Figura 2.8 Tecnologias que compe o SitaWare ........................................................ 24Figura 3.1- Relao fornecedor x consumidor [26] ........................................................ 28Figura 3.2 Princpios de SOA [28] .............................................................................. 31Figura 3.3- Smbolos usados para representar um componente [25] ............................. 32Figura 3.4 Arquitetura Web Service [25] ..................................................................... 32Figura 4.1 Interoperabilidade entre sistemas de C2 .................................................... 39Figura 4.2- Diagrama de Arquitetura e Ativos de Software ........................................... 41

Figura 4.3- Mensagem de Registro de Objeto de Interesse ............................................ 45

Figura 4.4 - Diagrama de Sequncia OpCj ..................................................................... 45Figura 4.5 Processos iniciais do barramento ............................................................... 46Figura 4.6 XML para cadastro da operao ................................................................ 47

Figura 4.7 XML de cadastro de objeto de interesse .................................................... 48Figura 4.8 XML de adjudicao de objeto de interesse a operao ............................ 49Figura 4.9 Processo de troca de mensagens durante a operao ................................. 50Figura 4.10 XML de registro de localizao ............................................................... 51Figura 4.11 XML de registro de situao operacional ................................................ 52Figura 4.12 XML de registro de hostilidade................................................................ 53


10/68

x

Lista de Tabelas

Tabela 2.1- Entidades independentes do JC3IEDM [10] ............................................... 12Tabela 2.2- Mtricas tcnicas para soluo de interoperabilidade [8] ........................... 25


11/68

1

Captulo 1

Introduo

1.1 Tema

Este trabalho trata sobre a interoperabilidade de Sistemas de Comando e

Controle. Neste sentido, o problema a ser resolvido isolar a heterogeneidade dosdiversos sistemas empregando uma arquitetura orientada a servios.

1.2 Justificativa

A evoluo tecnolgica e a complexidade geopoltica aumentaram as

dificuldades para realizao de misses militares, em especial Operaes Conjuntas e

Multinacionais, requerendo alta capacidade de interoperabilidade entre as foras

envolvidas. Um dos desafios a serem enfrentados nesse cenrio a identificao e a

adoo de tcnicas, ferramentas e prticas que permitam aperfeioar o

compartilhamento da informao, visando acelerar dinmica na tomada de deciso.

A complexidade dos conflitos contemporneos no admite o emprego isolado de

uma nica FA (Fora Armada) em campanhas. Assim sendo, a combinao dos meios e

a convergncia de esforos tornam-se indispensveis para que seja obtido o mximo

rendimento das foras disponveis, tendo sempre como referncia as HE (Hipteses de

Emprego) que podem ocorrer no Pas [1].

Atualmente as misses so, simultaneamente, mais complexas e mais dinmicas,

o que requer a capacidade e esforo coletivos das vrias organizaes, a fim de se obter

o sucesso. Este requisito para a montagem de um conjunto diversificado de recursos e

organizaes em uma coalizo efetiva acompanhado por reduo das janelas de

oportunidade de resposta. Em fim, as abordagens tradicionais de Comando e Controle

no esto altura do desafio, de forma simplificada, elas no tm a agilidade necessria

para o sculo XXI [7].


12/68

2

Comando e Controle (C2) uma atividade fundamental para o xito das

operaes militares em todos os escales de comando. Como atividade especializada,

sua execuo se baseia em uma concepo sistmica, com mtodos, procedimentos,

caractersticas e vocabulrio que lhe so peculiares. O C2 vincula e permeia todas as

atividades operacionais e de apoio, sincronizando-as e permitindo ao comandanteadquirir e manter o indispensvel nvel de conscincia situacional para a tomada de

decises adequadas s circunstncias do ambiente operacional, para a expedio de

ordens e para o controle de sua execuo [2].

Para o sucesso das operaes so fatores indispensveis uma unidade de

comando no mais alto escalo, uma mentalidade militar unificadas nos diversos nveis

de comando e a capacidade de interoperabilidade entre as Foras empregadas. Assim, a

necessidade de troca e compartilhamento de informao entre os diversos sistemas deC2 de cada uma das FFAA, em operaes conjuntas, um indicador para a integrao

destes sistemas nas operaes. Para ser atendido em suas necessidades de

acompanhamento e planejamento, o comandante da operao precisa de informaes

dos diversos sistemas de C2 das FFAA envolvidas na ao, que devem estar

consolidadas em uma viso nica.

Felizmente, os avanos nas tecnologias de informao criaram um novo espao

no qual os indivduos e as organizaes podem operar. Esses indivduos e organizaes

que aprenderam a aproveitar as oportunidades oferecidas pela operao neste novo

espao tm percebido uma significativa vantagem competitiva sobre aqueles que tm

ignorado estas oportunidades [7].

Dentre as diversas abordagens disponveis, a adoo de uma Arquitetura

Orientada a Servios (SOA) prov uma boa soluo para integrao de sistemas

heterogneos, j que prev um baixo acoplamento entre sistemas, que necessitaro de

poucas modificaes para interagirem uns com os outros.

No ambiente militar, apesar da existncia de aspectos comuns entre cada uma

das FFAA, estas possuem caractersticas especficas ligadas a sua esfera de atuao que

as diferenciam entre si. Essas caractersticas de negcio levam a que sistemas

desenvolvidos para atender as necessidades de uma FA especfica apresentem

necessidades de informaes e funcionalidades diferentes de outro sistema desenvolvido

para outra FA.

O paradigma SOA, por proporcionar flexibilidade, escalabilidade e tolerncia a

falhas, fruto de um baixo acoplamento, apresenta-se como alternativa para cenrios

descritos anteriormente, onde os sistemas diversos, desenvolvidos em diversas


13/68

3

tecnologias, precisam atender, conjuntamente, a demanda de informao dos Centros de

Comando e Controle.

Por fim, o conhecimento dos processos de negcio permite uma melhor

definio da soluo tecnolgica a ser construda. O mapeamento destes processos

permite orientar a definio do portflio de servios da soluo SOA e ajudar a garantirque a soluo corresponda a demanda apresentada, fazendo o elo entre as necessidades

da organizao e a TI.

1.3 Delimitao

Neste trabalho abordada a questo da necessidade do compartilhamento de

informao entre sistemas de comando e controle do seguimento militar, a partir da

viso da soluo em desenvolvimento para o Ministrio da Defesa do Brasil. So

apresentados os conceitos, sendo os principais, Comando e Controle, Interoperabilidade,

Arquitetura Orientada a Servios, JC3IEDM (modelo de dados para interoperabilidade

de sistemas) e ADEM (mtodo de intercmbio de dados), necessrios para compreender

a soluo.

A proposta apresentada visa a interoperabilidade de sistemas de comando e

controle das Foras Armadas, no entanto, olhando a questo segurana de uma forma

mais ampla, o sucesso na implementao da soluo possibilitar que sistemas de outrasagncias governamentais, tais como Polcia Federal, Polcia Militar e Defesa Civil,

tambm possam ser integrados no futuro, o que viria a proporcionar uma viso de

segurana pblica nacional muito mais precisa. Da mesma forma, a experincia obtida

tambm poder ser aproveitada para integrao de sistemas ligados a Defesa Civil e

Segurana Pblica de forma a prover solues mais eficientes na resposta a crises.

1.4 Objetivo

O objetivo do presente trabalho apresentar uma proposta de soluo que

permita uma melhor integrao entre os sistemas C2 da Marinha, do Exrcito e da Fora

Area e o Sistema de C2 do Ministrio da Defesa. Neste sentido, os objetivos

especficos so:

Apresentar a aplicao da Arquitetura Orientada a Servios (SOA) e

demais componentes arquiteturais propostos para a soluo do problema;

Apresentar os modelos e mtodos de intercmbio de informaes

aplicveis a interoperabilidade de sistemas de comando e controle.


14/68


15/68

5

Captulo 2

Comando e Controle e a

Interoperabilidade

Neste captulo sero abordados conceitos de Comando e Controle (C2) e

Interoperabilidade, que fundamentam a necessidade da proposta de soluo apresentada.

2.1 Comando e Controle

Comando e Controle (C2) a cincia e a arte que trata do funcionamento de uma

cadeia de comando, envolvendo, basicamente, uma autoridade legitimamente investida,

processos decisrios e recursos [2].

Cada um desses componentes bsicos possuem caractesticas especficas, onde:

a)

A autoridade legitimamente investida, apoiada por uma organizao da qual

emanam as decises que materializam o exerccio do comando e para onde

fluem as informaes necessrias ao exerccio do controle;

b) A sistemtica de um processo decisrio, que permite a formulao de ordens,

estabelece o fluxo de informaes e assegura mecanismos destinados

garantia do cumprimento pleno das ordens; e

c) A estrutura, ou recursos, incluindo pessoal, equipamento, doutrina e

tecnologia necessrios para a autoridade acompanhar o desenvolvimento dasoperaes.

No que tange a rea militar, trata-se de uma atividade de importncia decisiva

para o xito das operaes em todos os escales de comando, baseando-se em uma

concepo sistmica, com mtodos, procedimentos, caractersticas e vocabulrio que lhe

so peculiares.

Dessa forma, pode-se entender C2 como uma disciplina que rege o

funcionamento de uma cadeia de comando, onde um comandante exercita a autoridade edireo sobre as foras sob seu comando de forma a obter xito em suas aes.


16/68


17/68

7

g) Agilidade: proporcionar rapidez ao processo decisrio. Possibilitar o acesso

imediato s informaes de interesse por todos os escales de comando;

h) Amplitude: Os meios empregados para o apoio de C2 devem se estender por

toda a rea de atuao; e

i)

Integrao: Um sistema de C2 de um determinado escalo no isolado; fazparte do sistema do escalo superior e abrange os sistemas dos escales

subordinados; e deve ter a capacidade de compartilhar informaes com foras

de mesmo nvel.

No que se refere aos STIC2, estes devem permitir que um grande volume de

informao seja disponibilizado aos diversos nveis da cadeia de comando, o que

permite aumentar a concincia situacional em que se encontram as foras componentes

da operao e, em consequncia, ajudar o comandante a tomar as decises necessriaspara o andamento das aes.

Conscincia situacional a percepo do ambiente operacional em que se atua

no decorrer do cumprimento da misso [2]. A conscincia situacional ser melhor

quanto mais apurada for a percepo da realidade operacional das aes, o que

alcanado atravs da disponibilidade da informao e impactar diretamente no ciclo de

tomada de decises.

O ciclo OODA [2], tambm conhecido como ciclo de Boyd [42], um dos

modelos aplicveis ao C2, segundo o qual qualquer ao integrante de um processo

decisrio parte de uma de suas quatro fases: Observar, Orientar-se, Decidir e Agir

(OODA).


18/68

8

Figura 2.1 - Ciclo OODA

Fonte: Ministrio da Defesa/Brasil [2]

O ciclo OODA, Figura 2.1, um processo contnuo onde suas fases ocorreroem paralelo. O comandante receber as informaes, formar sua conscincia

situacional e tomar decises sobre as operaes futuras, enquanto operaes correntes

sero executadas por meio de aes dos escales subordinados.

Os comandantes das foras oponentes tambm executam o ciclo OODA, com

isso as decises de um comandante acabam influenciando as decises do comandante

oponente, j que quem completar o ciclo antes do adversrio influencia o cenrio a

partir do qual as decises do outro lado so tomadas. Quanto menor a durao desteciclo, mais gil o processo decisrio [2].

No entanto, a efetividade do ciclo OODA no ser garantida apenas pela sua

velocidade. A qualidade da informao ter importncia singular, pois se a percepo do

ambiente for falsa, inadequada ou incompleta, se as informaes forem analisadas

incorretamente, ou se as aes implementadas no corresponderem deciso tomada, o

ciclo no afetar o ambiente de acordo com a inteno do comandante [2].


19/68

9

Portanto, a percepo das informaes e do ambiente torna-se mais prxima da

realidade, medida que os ciclos estejam apoiados em processos e estruturas eficientes

e seguros [2].

2.2 Interoperabilidade

A Doutrina Para o Sistema Militar de Comando e Controle [2] d

interoperabilidade a seguinte definio:

a capacidade de os sistemas, unidades ou foras de

intercambiarem servios ou informaes ou aceit-los de outros sistemas,

unidades ou foras e, tambm, de empregar esses servios ou informaes,

sem o comprometimento de suas funcionalidades.

Para que a interoperabilidade possa ser vista de forma mais abrangente, deve

compreender, alm do nvel tcnico, o nvel organizacional, como pode ser observado

na figura a seguir.

Figura 2.2- Evoluo da Interoperabilidade

Fonte: Ministrio da Defesa/Brasil[2]

Na Figura 2.2, pode ser observada a convergncia dos nveis organizacional e

tcnico, constituindo a interoperabilidade de forma precisa, no que tange os sistemas de

C2.

A interoperabilidade constitui-se tambm da soma de integrao de sistemas,

integrao de redes, troca de dados entre sistemas e definio de tecnologia,


20/68

10

considerando, tambm, a existncia de um legado de sistemas, de plataformas de

hardwareesoftwareinstaladas.

Alm dos aspectos tcnicos apresentados, processos e cultura organizacional

devem ser gerenciados para maximizar oportunidades de troca e reuso de informaes.

A meta deve ser o funcionamento cooperativo entre os diversos sistemas, respeitandonormas, polticas e padres estabelecidos[16].

A fim de alcanar a plena interoperabilidade, necessrio que cada sistema

tenha um entendimento comum sobre a semntica dos dados trocados[15], unificando e

padronizando conceitos entre eles.

Em uma perspectiva histrica, trs diferentes paradigmas para troca de

informaes so considerados no contexto de defesa: Military Messaging, Common

Data Models e Tatical Data Links[15].O paradigmaMilitary Messagingremonta aos primeiros dias dos equipamentos

de teletipo quando os padres de protocolo como ACP127 foram desenvolvidos para a

camada de protocolo. Com o surgimento de padres comerciais, tais como X.400, o

mercado de defesa adotou esta norma e estendeu-a para formar ACP123 /

STANAG4406. Muitos pases tm ou esto em processo de desenvolvimento de

sistemas que so compatveis com Military Messaging. Assim, historicamenteMilitary

Messaging foi originalmente baseada em princpios de comunicao clara entre as

pessoas, em vez de sistemas, mas posteriormente tambm foi utilizada automaticamente

entre sistemas[15].

Tatical Data Links(TDLs) tm sido usados por muitos anos para o intercmbio

de funcionalidades C2 ttico, bem como para o intercmbio de informaes sobre a

conscincia situacional quase em tempo real[15]. TDLs utilizam terminais constitudos

basicamente por rdios que transmitem informaes aos outros sistemas que participam

do mesmo grupo na rede. Assim, usando TDLs no h registro histrico sobre o que

aconteceu, o que faz sentido quando a informao mais recente a nica informao

relevante[15].

O terceiro paradigma, Common Data Models, passa pela adoo do modelo de

dados Joint Consultation, Command and Control Information Exchange Data Model

(JC3IEDM), desenvolvido pelo frum multinacional Multilateral Interoperability

Program (MIP) e adotado pela OTAN com o objetivo de viabilizar a integrao entre

sistemas de C2[15]. Este trabalho se concentra no estudo deste paradigma.

Apesar do JC3IEDM fornecer um modelo de dados, estabelecendo uma

semntica comum, necessrio um mecanismo de intercmbio de dados que permita a


21/68

11

efetiva utilizao deste modelo padro entre os sistemas de C2 envolvidos. As

especificaes Alternate Development and Exchange Method (ADEM) e Battle

Management Language (BML) so alternativas que fornecem os mecanismos

necessrios e sero apresentados no decorrer deste trabalho.

2.3 Sistemas e frameworks existentes

Para a efetivao da interoperabilidade necessria adoo de propostas

arquiteturais, tecnologias e padres que permitam a conexo entre os sistemas.

Como padro principal para o estabelecimento de uma linguagem comum, no

que tange a atividade de comando e controle, a adoo do JC3IEDM permite um

entendimento sobre a semntica das informaes, visando unificar e padronizar

conceitos entre os diversos sistemas envolvidos. Complementando o JC3IEDM, as

especificaes ADEM e BML fornecem os mecanismos de troca de dados necessrios.

Ainda, dois frameworks apresentam propostas de soluo para as necessidades

dos sistemas de C2: o SitaWare, desenvolvido pela empresa Systematic Software

Engineering[15], e o Wise-SBML, um BML Server baseado no SAAB Widely

Integrated Systems Environment (WISE) um framework produzido pela SAAB Defense

Systems[17].

2.3.1 - JC3IEDM

O modelo JC3IEDM representa a viso de alto nvel da informao em termos

de conceitos gerais, como aes, organizaes, material, pessoal, recursos, instalaes,

locais e afins, representados em entidades. As propriedades, ou caractersticas, dessas

entidades so referidas como atributos, que tornaro explcitos os dados a serem

gravados para cada conceito de interesse.

A edio do JC3IEDM 3.1.4, datada de fevereiro de 2012 [10], tratada neste

estudo, contm 292 entidades. Toda a estrutura gerada a partir de 19 entidades

independentes, isto , as entidades cujas identificaes no dependem de qualquer outra

entidade. Todas as outras entidades so entidades dependentes.

A seguir so apresentadas as entidades independentes e a funo geral de cada

uma delas [10].


22/68

12

Tabela 2.1- Entidades independentes do JC3IEDM [10]

Entidade Definio Regra

ACTION

Uma atividade, ou a ocorrncia de uma atividade,que possa utilizar recursos e pode ser focada contraum objetivo. Exemplos so ordem de operao,plano de operao, ordem de movimentao, oplano de deslocamento, ordem fogo, plano de fogo,

misso fogo, misso de apoio areo aproximado,pedido de logstica, evento (por exemplo, entradaaeronaves desconhecido), ou incidente (porexemplo, ataque inimigo).

Dinmica (como, o qu, quandoalgo est a ser feito, est sendo

feito, ou foi feito).

ADDRESS Informaes precisas sobre um endereo fsico oueletrnico pode ser acessado.

Prov meios para registrarendereos postais e eletrnicos.

AFFILIATION

Uma especificao de um pas, nacionalidade, grupoetnico, grupo funcional, grupo de exerccio, oureligio a que pertena ou fidelidade pode seratribuda.

Fornece meios para atribuirfiliaes para tipos ou objetos.

CANDIDATE-TARGET-LIST

Uma lista de objetos selecionados no campo debatalha, ou tipos que tm valor potencial dedestruio ou explorao, nomeados por autoridadecompetente para a considerao no planejamentodas atividades de batalha.

Informao para apoiar umaACTION.

CAPABILITYA capacidade potencial para realizar um trabalho,executar uma funo ou misso, alcanar umobjetivo ou fornecer um servio.

Indicao da capacidadeesperada para tipos de objetos ecapacidade real de um objeto.

COMPONENT-HEADER-CONTENT

Assunto introdutrio destinado a identificar umelemento de um plano ou ordem.

Utilizado em conjunto com asespecificaes de planos eordens.

COMPONENT-TEXT-CONTENT

Uma declarao textual do assunto principal.Utilizado em conjunto com asespecificaes de planos e

ordens.CONTEXT

Uma coleo de informaes que fornece, em suatotalidade, as circunstncias, condies, meioambiente ou perspectiva para uma situao.

Mltiplas funes incluindoagrupamento de informaes.

RELATIVE-COORDINATE-SYSTEM

Uma moldura retangular de referncia definida poruma origem, eixos x e y em relao ao planohorizontal, e um eixo z. O eixo vertical z perpendicular ao plano xy com sentido positivodeterminada a partir da regra da mo direita,quando o eixo x rodado na direco do eixo y.

Suporte localizao paraespecificar geometria relativa.

GROUP-

CHARACTERISTIC

Uma referncia a um conjunto de caractersticasque podem ser usadas para a identificao de umconjunto distinto de objetos. Exemplos de

caractersticas incluem faixa etria, doena, sexo,lngua e classificao de triagem.

Suporta a contagem dos tipos depessoas de acordo com

caractersticas selecionadas.

LOCATION

Uma especificao de posio e geometria comrelao a uma determinada estrutura horizontal dereferncia e uma distncia vertical medida de umdeterminado ponto de referncia. Os exemplos so,seqncia de pontos, linhas poligonais, crculo,retngulo, elipse,fan area, rea poligonal, esfera,bloco do espao e o cone. LOCATION especificalocalizao e dimensionalidade.

Geoposicionamento de objetos ecriao de formas.

OBJECT-ITEM

Um objeto identificado individualmente, que temum significado militar ou civil. Exemplos so umapessoa especfica, um item de material especfico,uma caracterstica geogrfica especfica, umacoordenada geogrfica especfica ou uma unidadeespecfica.

Identifica as coisas

individualmente (Quem e OQue).


23/68

13

OBJECT-TYPE

Uma classe de objetos identificada individualmente,que tem um significado militar ou civil. Soexemplos um tipo de pessoa (por exemplo,classificao), um tipo de material (por exemplo,obus motorizado), um tipo de instalao (porexemplo, aeroporto), um tipo de recurso (porexemplo, uma rea de fogo restrita), ou um tipo de

organizao (por exemplo, a diviso blindada).

Identifica uma classe de coisas(Quem e O Que).

PLAN-ORDERUm esquema planejado ou ordenado trabalhadopreviamente para a realizao de um objetivooperacional.

A entidade de alto nvel para aidentificao de um plano ouordem.

REFERENCE Identificao de um registo de informao.Aponta para uma informaoexterna em apoio doREPORTING-DATA.

REPORTING-DATAEspecificao da fonte, a qualidade e o tempo que seaplica aos dados comunicados.

O suporte para a funo dereporte.

RULE-OF-ENGAGEMENT

Especificao de orientao obrigatria para aforma como uma determinada atividade dever serexecutada.

Suporte para ACTION.

SECURITY-CLASSIFICATION

Classificao de segurana aplicvel a um recurso

de informao dentro do domnio de informaesclassificadas.

Suporte a CONTEXT,

NETWORK-SERVICEe REFERENCE

VERTICAL-DISTANCE

Uma especificao da altitude ou a altura de umponto ou um nvel conforme medido em relao aum dado de referncia especificado na direonormal ao plano que tangente ao elipside derevoluo WGS84.

Suporte para o LOCATION naespecificao altitude ou altura.

As 19 entidades independentes e seus relacionamentos so apresentados no

modelo de dados a seguir. Um ponto no final de uma linha indica "muitos". Os

relacionamentos mostrados no diagrama so ou muitos-para-muitos (linha slida comdois pontos) ou no-identificado um-para-muitos (linha a tracejado).


24/68

14

Figura 2.3- Modelo simplificado do JC3IEDM

O modelo apresentado est no padro IDEF1X[43], um mtodo para a

concepo de bancos de dados relacionais com uma sintaxe concebida para suportar as

construes semnticas necessrias no desenvolvimento de um esquema conceitual, que

permite o uso de relacionamentos muitos-para-muitos s a nvel conceitual emdiagramas explicativos. Entretanto, o modelo de dados completo deve substituir os

relacionamentos muitos-para-muitos por estruturas adequadas que admitem apenas

relacionamentos um-para-muitos. A resoluo dos relacionamentos muitos-para-muitos

levar a estruturas complexas, cujo resultado ser o modelo JC3IEDM final, com suas

292 tabelas.

Para o contexto das operaes realizadas em conjunto pelas naes que adotam o

modelo JC3IEDM, o MIP definiu o Data Exchange Mechanism (DEM), que especificacomo atravs de conexo ponto-a-ponto entre os sistemas de informao de C2 dessas


25/68

15

naes, devem ser realizadas replicao de banco de dados e trocas de mensagens.

Obviamente, a complexidade inerente do modelo JC3IEDM e suas diversas regras de

negcio, tornam a implentao do DEM em um nvel de dificuldade muito grande.

De forma a contornar os problemas de implementao do DEM, o MIP elaborou

a especificao ADEM, que define um mtodo de intercmbio de dados focado naSituao Corrente, utilizando a semntica do JC3IEDM e que oferece uma mudana de

paradigma para troca de informaes.

2.3.2 - ADEM

A especificao Alternate Development and Exchange Method (ADEM)

complementar a especificao do MIP DEM, oferecendo meio de intercmbio

alternativo ou complementar para aqueles sistemas em que no prtico, ou desejvel,

implementar uma soluo MIP DEM completa [14].

Destacam-se os principais benefcios do ADEM:

Melhorar a distribuio de informao no C2 para um conjunto mais vastode potenciais parceiros de misso1. A melhora no compartilhamento deinformaes equivale a melhora na tomada de deciso e a eficcia por umacomunidade C2 maior;

Demonstrar a flexibilidade do JC3IEDM; e

Encorajar a contribuio tcnica de parceiros externos envolvidos noprograma MIP.

Com o ADEM, possvel realizar o intercmbio de informaes de forma

simples e extensvel, usando padres abertos, facilitando a comunicao com as

Comunidade de Interesse (COI do ingls Communities of Interest), que podem no estar

dispostas, ou serem capazes, de implementar a especificao do MIP DEM. A

expectativa preencher a lacuna existente entre a comunidade MIP e os COIs, de formaa melhorar o compartilhamento de informao entre os parceiros de misso.

O ADEM tem como proposta, disponibilizar vrios padres de intercmbio de

dados, utilizando tecnologias comumente empregadas pelos desenvolvedores de

sistema, incluindo, mas no se limitando a: Publish / Subscribe, Request / Response,

Compartilhamento de Arquivos, Servios de Dados Distribudos (DDS), Web Services

e etc.

1 Como parceiros de misso podem ser includos, mas no esto limitados a, os parceiros militaressujeitos a diferentes nveis de segurana, o pessoal de emergncia civil (polcia, bombeiros, etc.) e asagncias de segurana, ONGs, outros rgos governamentais e etc.


26/68

16

A simplificao da troca de informaes pelo ADEM concentra-se em pequenas

estruturas discretas de informao, que tm valor operacional (ou seja, objetos de

batalha, eventos e associaes entre eles). Este conjunto de estruturas de informao no

finito, podendo o parceiro COI estender essas estruturas de informao com contedo

especfico.

Figura 2.4 - Intercmbio de informaes MIP x no MIP

Fonte: ADEM CONOPS [14]

Na figura 2.4 exemplificado como as informaes de C2 so trocados entre

sistemas baseados nas especificaes MIP e outros sistemas parceiros no MIP. Nessa

representao, o prestador de informaes MIP tambm implementa um mecanismo de

intercmbio ADEM para alm da sua implementao MIP DEM, de forma a interoperar

com outros sistemas da COI.


27/68

17

O ADEM subdivido em seis grupos de especificaes nas quais as aplicaes

que adotam o modelo devem ser embasar. So elas:

a) Intercmbio de Informaes, que so documentos que fornecem uma viso

tcnica geral, importante para entender o restante da especificao, explorando

cenrios especficos de intercmbio de informaes.b) Conjunto de Capacidade, que define o conjunto de informaes conhecidas que

podem ser trocadas usando as especificaes ADEM. Esto agrupadas nos

seguintes conjuntos de recursos: Capacidades de viso, Capacidade dos objetos

do campo de batalha, Capacidade de Eventos, Capacidade de Tarefas e

Capacidade de Relatrio de objetos mnimo.

c) XML Schemas, que so definies de estruturas de dados, em arquivos XSD, que

representam os documentos do conjunto de capacidades dos objetos do campode batalha. Cada mensagem, comunicada via especificao ADEM, dever

basear-se na estrutura definida em um destes arquivos de esquema.

d) Padres de intercmbio, que descrevem como documentos podem ser trocados.

Como existem casos em que um nico mecanismo de intercmbio no

suficiente, vrios padres esto definidos. Na verso atual da especificao

ADEM, so definidos os seguintes padres de intercmbio para uso pelos

desenvolvedores: publish / subscribe, request / response, arquivos e baixa

largura de banda.

e) Definies de Web Services, arquivos WSDL que contm as especificaes

tcnicas dos padres de intercmbio que so implementados usando web

services.

f) Especificao de teste, que fornecem a capacidade de medir o grau em que um

sistema capaz de definir, compartilhar, consumir e exibir informaes usando

as especificaes tcnicas ADEM.

2.3.3 - BML

ABattle Management Language(BML), e suas vrias extenses, destinam-se a

facilitar a interoperabilidade entre sistemas de Comando e Controle (C2) e sistemas de

Simulao (C2-SIM), fornecendo um formato comum para a troca de informaes, tais

como ordens e relatrios. A abordagem proposta pela BML a utilizao de um

middleware para troca de arquivos no padro Extensible Markup Language (XML)

junto com a tecnologia WebServices [21].


28/68

18

A BML comeou a ser desenvolvida durante os trabalhos do Simulation-to-C4I

Interoperability Overarching Integrated Product Team(SIMCI OIPT), patrocinado pelo

Exrcito dos EUA, cujo objetivo era mostrar a viabilidade da definio de uma

linguagem clara, sem ambigidades, com base em manuais e que capturava a doutrina

militar [19].Importante notar que a BML no foi concebida como uma soluo

exclusivamente tcnica, mas como uma abordagem para apoiar as necessidades e

exigncias do combatente operacional [22]. Assim, pode-se considerar a BML como

uma especificao de referncia que originou diversas extenses, onde se destacam

XBML, JBML e C-BML(Full e Light).

A eXtensible Battle Management Language (XBML) foi desenvolvida a partir

do trabalho iniciado com a BML, com a misso de adicionar a capacidade para atenderoperaes Conjuntas e Combinadas/Coalizo BML. Um de seus fundamentos era a

utilizao de tecnologias Web para a interoperabilidade entre sistemas, sendo seus dois

objetivos principais: (1) usar a tecnologia Service Oriented Architecture(SOA) para a

troca de informaes entre as interfaces dos sistemas e (2) usar o Command and Control

Information Exchange Data Model (C2IEDM, uma verso anterior do JC3IEDM ) do

MIP como uma base para representar as informaes a serem trocadas entre os sistemas

[19].

A implementao da Joint BML (JBML) foi o passo seguinte a XBML, tendo

como particular interesse a semntica por trs do vocabulrio de C2 comum para

intercmbio de dados, proporcionado pelo MIP, independente de sistema. Com isso

expandiu-se para a arena de operaes conjuntas, incluindo os domnios terra, ar e mar,

bem como a guerrilha urbana. O JBML alcanou progresso tcnico considervel,

criando um esquema WebService revisado, com base em gramtica formal e projetado

para facilitar a expanso para outros domnios militares [22].


29/68

19

Figura 2.5 - Arquitetura JBML Viso Geral

Fonte [22]

A figura 2.5 apresenta uma viso geral da arquitetura de WebServices do JBML,

onde so identificadas as principais camadas da arquitetura.

A camanda mais alta, BML Domain Configured Service (DCS), representa a

linguagem de domnio especfico na forma de um esquema baseado em gramtica que

utilizado atravs da implementao do WebServices. O esquema define o DCS em

termos dos BML Base Services (BBS), camada mdia que representa os grupos de

elementos de informao que especificam objetos de informao de interesse, como as

5Ws (quem - who, o qu - what, onde - where, quando - when, porqu - why) e outras

construes de interesse [22].

J a camada mais baixa, que representa a troca de informao de elementos deinformao e que normalmente escondida do usurio, a BML Common Data Access

Services(CDAS) [22].

A Integrated BML (IBML IBML09), desenvolvida em 2009, foi uma primeira

tentativa de padronizar BML. A IBML09 tambm a base para uma verso estendida

desenvolvida no Instituto Fraunhofer (FKIE) [23]. Trata-se de uma coleo de produtos

e especificaes comuns e integradas que servem como uma base comum para o

desenvolvimento e produo de processos de C2 avanados, incluindo ordens, relatriose capacidades geoespaciais entre as partes interessadas.


30/68

20

A C-BML (Coalition Battle Management Language) uma linguagem no ambgua

para descrever a inteno do comandante em operaes simuladas ou reais. Ela define

um formato digital para as informaes de C2, tais como ordens, planos, relatrios e

solicitaes. Em um formato digital, as informaes de C2 podem ser facilmente

processadas por sistemas de C2, sistemas de simulao ou interfaces a forasautomatizadas (por exemplo, sistemas robticos). A Simulation Interoperability

Standards Organization (SISO)2 desenvolveu a C-BML como uma representao

padronizada para operaes conjuntas, combinadas e de coalizo, de acordo com

requisitos de C2 e de sistemas de simulao, com base em um modelo de referncia

comum (por exemplo, o MIP-JC3IEDM).

A figura 2.6 apresenta um conjunto de possveis relacionamentos produtor /

consumidor C-BML, representando uma viso de diversas reas de interoperabilidade.

Figura 2.6 - Matriz produtor / consumidor C-BMLFonte [24]

Caractersticas da C-BML que devem ser observadas [24]:

Interface Comum: um dos impulsos da C-BML a necessidade de uma

interface comum entre os sistemas de C2, de simulao e robticos. Isso

permite que o usurio operacional interaja com um sistema de C2 e

2O Simulation Interoperability Standards Organization(SISO) uma organizao internacional dedicada promoo da modelagem e simulao de interoperabilidade (https://www.sisostds.org/Home.aspx).


31/68


32/68

22

usurios C-BML (por exemplo, desenvolvedores) sejam especialistas

JC3IEDM.

UmBML Serverpermite a conexo de sistemas ou aplicaes em um ambiente

comum e cria um fluxo de informao entre eles, independentemente da arquitectura,

das normas e protocolos de comunicao, dando suporte a interoperabilidade atravs douso da BML e seus diversos dialetos.

A primeira gerao de BML Server foi implementada inteiramente em Java /

JAXB e provia WebServices baseados em SOAP[19].

A segunda gerao deBML Serverfoi escrita em Java e implementada em JBoss

(4.2.3). Esta verso foi conhecida como Scripted BML (SBML). Nesta verso,

processamento e mapeamento especficos para o modelo JC3IEDM eram providos por

uma linguagem de script conhecida como CSL [19].

2.3.4 WISE-SBML

O WISE-SBML, terceira gerao de servidor BML, baseado na soluo SAAB

Widely Integrated Systems Environment(WISE), um framework produzido pela SAAB

Sistemas de Defesa. A implementao BML desenvolvida em C ++ e executada sob

WISE em um servidor Windows 7[19].

As principais funcionalidades do WISE-SBML so caracterizadas pela recepoe validao de documentos BML, traduo entre diferentes dialetos BML, distribuio

de documentos para os assinantes, processamento de consultas de documentos recebidos

anteriormente que tenham sido guardados no servidor e o registo de documentos BML

recebido durante uma sesso de simulao, repassando-as com sincronizao de

tempo[20].

O servidor suporta WebServices RESTFul, recebendo documentos XML no

formato BML, em um dos quatro dialetos previstos. Os documentos BML de sada sopublicados usando o protocolo STOMP (Simple Text Oriented Messaging Protocol),

para os clientes que tenham assinado o servio, caracterizando assim a utilizao do

padro arquitetural publishsubscribe[20].

A figura 2.7 apresenta a arquitetura de um servidor WISE-SBML.


33/68

23

Figura 2.7 - Arquitetura Wise-SBML

Fonte [20]

O servidor WISE-SBML fornece suporte aos seguintes dialetos BML[19]:

IBML 2009;

IBML Fraunhofer-FKIE Variant;

C-BML Light, e

C-BML Full.

2.3.5 SitaWare Coalition Gateway

O SitaWare Coalition Gateway faz parte de uma famlia de software de C2

criados pela empresa dinamarquesa Systematic Software Engineering.Trata-se de umhub de interoperabilidade que conecta diversas solues C2. Como apresentado na

figura 2.5, o SitaWare contempla vrios padres de comunicao de dados, permitindo a

troca de informaes entre sistemas desenvolvidos em diferentes tecnologias.


34/68

24

Figura 2.8 Tecnologias que compe o SitaWare

Fonte: https://systematic.com/

No conjunto de tecnologias apresentadas na figura 2.8, possvel destacar o

suporte ao JC3IEDM. Como o SitaWare segue os princpios SOA, a adoo desta

soluo, facilita a integrao com diferentes sistemas especialistas e sistemas legados.

A robustez da proposta da soluo foi posta a prova durante as operaes da

coalizao internacional no Afeganisto, ISAF (Fora Internacional de Assistncia

Segurana). Participaram desta operao 43 naes, sendo 28 membros da OTAN, que

utilizam diferentes solues de sistemas de C2. Foram aplicados os modelos C2IEDM

(MIP Baseline 2, j descontinuado) e o JC3IEDM (MIP Baseline 3, tratado neste

trabalho). O sucesso da interoperabilidade com base nesses padres foi demonstrado a

partir da atualizao dinmica da conscincia situacional ttica, que pde ser facilmente


35/68

25

compartilhado entre o sistema de C2 do Reino Unido e os sistemas C2 dos parceiros de

coalizo [18].

2.4 Parmetros de Interoperabilidade entre Sistemas de C2Na conceituao de Comando e Controle foram apresentados os princpios de

unidade de comando, simplicidade, segurana, flexibilidade, confiabilidade,

continuidade, agilidade, amplitude e integrao. O conjunto destes conceitos forma a

base para a construo da conscincia situacional conjunta, da operao em curso, por

parte do comandante.

Levando-se em considerao, tambm, o ciclo OODA, conclui-se que esses

princpios ajudam a definir os requisitos funcionais necessrios para a

interoperabilidade em comando e controle.

A soluo de interoperabilidade deve atender a requisitos no-funcionais para

dar o suporte necessrio ao processo de obteno e compartilhamento da conscincia

situacional. Esses requisitos, que tambm representam mtricas a serem observadas,

podem ser vistos na tabela 2.2.

Tabela 2.2-Mtricas tcnicas para soluo de interoperabilidade [8]

Tipo de Requisito Descrio Exemplos

Volume Volume de dados queprecisa ser trocado entreaplicaes.

10.000 transaes/hora, 120requisies/minuto, ou500Kbytes/segundo.

Tempo de Resposta Tempos de respostamnimos para realizao detarefas do usurio tratadaspela integrao deaplicaes.

5 segundos.

Tamanho Tamanho do dado que aintegrao entre aplicaesdeve tratar (relacionado aovolume).

Tamanho de Arquivo de at10Mbytes.

Timeliness Urgncia da comunicaoou integrao entreaplicaes.

Tempo real, dentro de 2segundos, ou em at 2 horas.

Padro de Formato de Dados Formato dos dadostransferidos entreaplicaes.

Suporta formato ebXML,formato EDI ou lida comformato proprietrio.

Handshaking protocol Adeso a um protocoloparticular em relao atroca de interaes entreaplicaes.

De acordo com RosettaNETPIP 2345, ou de acordo comuma sequencia proprietria detroca de mensagens.

Infraestrutura de Comunicao Restries da infraestrutura

de comunicaes nasaplicaes a seremintegradas.

Mensagens SOAP em HTTP

ou um formato proprietrio demensagem sobre IBM MQmesssaging.


36/68

26

Resilincia e Recuperao Resilincia da estrutura de

integrao em caso de

falhas.

Garantia da entrega de

mensagens, redundncia e

downtime menor do que

cinco por cento.

Frequncia Frequncia de interaes

necessria entre aplicaes.

Tempo real, ou em uma hora,

a cada hora.

Segurana Nvel de segurana exigido

entre aplicaes.

Autenticao por usurio e

senha no HTTPS; mensagens

no-criptografadas, suporte a

certificados digitais para

autenticao, autorizao e

no-repdio.


37/68

27

Captulo 3

Arquitetura Orientada a Servios (SOA)

Neste captulo ser apresentado o conhecimento terico necessrio a

compreenso bsica de uma Arquitetura Orientada a Servios (SOA). Esse

conhecimento permitir visualizar de que forma uma soluo elaborada a partir dos

conceitos de SOA pode ajudar a atingir o objetivo pretendido para a integrao dos

sistemas de comando e controle.

3.1 ConceitosA Arquitetura Orientada a Servios (SOA do ingls Service-Oriented

Architecture) possui diversas definies, mas um ponto principal a compreenso de

que um estilo de arquitetura de software cujo princpio fundamental prega que as

funcionalidades implementadas pelas aplicaes devem ser disponibilizadas na forma

de servios.

Como uma definio formal, pode-se citar que SOA uma forma de

desenvolvimento de sistemas distribudos em que os componentes de sistema so

servios autnomos, executando em computadores geograficamente distribudos. O

suporte comunicao desses servios baseado em padres de protocolo tais como

XML, SOAP e WSDL, o que permite a conexo destes no importando sua forma de

implementao, independentemente da adoo de linguagem ou tecnologias

especificadas. Assim, os sistemas de software podem ser construdos pela composio

de servios locais e servios externos de provedores diferentes, com interao perfeitaentre os servios no sistema [39].

De forma a conceituar servio, pode-se dizer que os servios nos rodeiam em

nosso cotidiano, sendo algo trivial na histria da civilizao. Qualquer atividade

executada por uma pessoa, ou grupo de pessoas, em apoio outra atividade, ou uma

funo de negcio de uma empresa, representa um servio prestado ou fornecido [5].

Assim, nesse processo possvel estabelecer uma relao fornecedor x consumidor.

Essa relao uma das principais caractersticas da arquitetura SOA, onde


38/68

28

funcionalidades de sistemas diversos so organizados de forma lgica a fim de

proverem recursos como servios.

A Figura 3.1 ilustra a relao fornecedor x consumidor. O fornecedor do servio

aquele que implementa e tem domnio sobre um servio; o registro de servio um

repositrio onde fornecedores de servio podem registrar seus servios para que elessejam localizados pelos consumidores; e o consumidor do servio aquele que localiza

um servio e o executa. O contrato a especificao do servio que possui as

informaes necessrias para que o consumidor possa localiz-lo e invoc-lo [26].

Figura 3.1- Relao fornecedor x consumidor [26]

Ainda, segundo Erl [5], um servio pode fornecer uma coleo de capacidades,

que so reunidas de acordo com um contexto funcional estabelecido pelo servio com o

qual elas se relacionam. Funcionando como um container de capacidades, ser

composto pela lgica de execuo das capacidades e por contratos de servios, que

definem quais capacidades estaro disponveis para utilizao.

A capacidade de servio no tem implicaes sobre a forma como um servio

implementado, mas este conceito pode ser particularmente til durante a fase de

modelagem de servios quando o desenho fsico de um servio ainda no foi

determinado [5].


39/68

29

3.2 Princpios

a) Contrato de servio padronizado (Standardized Service Contract)

O contrato o artefato principal da arquitetura de um servio e expressa seus

propsitos e capacidades [5], provendo as restries tcnicas, requisitos e informaesdo servio publicado. Pode ser descrito atravs de um conjunto de documentos, por

exemplo, WSDL, quando falamos de Web Services baseados em SOAP [27].

b) Baixo acoplamento de servio (Service Loose Coupling)

O acoplamento refere-se a uma conexo ou relacionamento entre dois elementos.

Este princpio enfatiza a reduo da dependncia entre o contrato de servio, sua

implementao e os consumidores do servio[5].

O princpio do Baixo Acoplamento de Servio permite que o design e a lgica

de um servio possam evoluir independentemente de sua implementao, ao mesmo

tempo em que garante a interoperabilidade bsica com consumidores que se utilizam

das capacidades do servio [5].

c) Abstrao de Servio (Service Abstraction)

O princpio de Abstrao de Servio enfatiza a necessidade de no deixar

pblica informaes sobre um servio que no sejam absolutamente necessrias para

quem efetivamente usar esse servio [5].

A abstrao fundamental para manter um baixo nvel de acoplamento e tem um

papel significativo na composio de servios [5].

d) Capacidade de reuso de servio (Service Reusability)

O princpio da capacidade de reuso de servio enfatiza o posicionamento de

servios, como recursos corporativos com contextos funcionais agnsticos [5].

Priorizar a reutilizao implica em um cuidado maior com os demais princpios.

Um servio ser mais reutilizvel na medida em que tiver menor acoplamento, maior

abstrao, autonomia e suporte a composio [27].

e) Autonomia de servio (Service Autonomy)

Este princpio suporta o grau em que outros princpios de design podem ser

efetivamente realizados em ambientes reais de produo, favorecendo caractersticas de


40/68

30

design que aumentam a confiabilidade e a capacidade de prever o comportamento de

um servio [5].

Manter um servio autnomo permite que ele possa atuar de forma

independente. Ou seja, sem qualquer necessidade de aprovao ou acompanhamento.

Quanto maior for a autonomia de um servio quanto a seu ambiente, mais fcil ser suamanuteno e evoluo [27].

f) Independncia de estado do servio (Service Statelessness)

Excessivas informaes de estado podem comprometer a disponibilidade de um

servio e minar seu potencial de escabilidade. Idealmente, os servios devem ser

projetados para manterem informaes de estado apenas quando estas forem necessrias

[5].

g) Descoberta de servio (Service Discoverability)

O princpio de Descoberta de Servio prev o suporte a descoberta o que implica

na capacidade de determinar quais requisitos precisamos atender para poder utilizar um

servio que exista em um inventrio. Nesse sentido, os servios devem prover meta-

informao suficiente para que possam ser efetivamente descobertos e interpretados

[27].

h) Composio de servios (Service Composability)

A capacidade de compor efetivamente os servios um requisito crucial para

alcanar alguns dos objetivos mais fundamentais da computao orientada a servios

[5].

Servios devem ser participantes eficazes de composio, independentemente do

tamanho e da complexidade da composio. A capacidade de combinar as capacidades

de diferentes servios para resolver problemas maiores um dos fundamentos do SOA e

da computao distribuda [27].

A Figura 3.2 apresenta um resumo dos princpios de arquitetura orientada a

servios, mencionados anteriormente, e suas implicaes.


41/68

31

Figura 3.2 Princpios de SOA [28]

No tocante a interoperabilidade, um item que pode parecer ausente no conjunto

de princpio apresentados princpio segundo o qual os servios so interoperveis. A

razo de a interoperabilidade no aparecer como um princpio especfico decorre do fato

de que esta fundamental a cada um dos princpios que foram descritos. Portanto, em

relao a computao orientada a servios, afirmar que os servios devem ser

interoperveis quase to bsico como afirmar que os servios devem existir. Cada um

dos oito princpios suporta ou contribui para a interoperabilidade de alguma maneira[5].

3.3 Tecnologia Usada importante ter a viso da SOA como um modelo arquitetural que neutro para

qualquer plataforma. Os servios so disponibilizados em uma rede de computadores

(Internet ou Intranets), comunicando-se atravs de padres abertos. A maior parte das

implementaes de SOA se utiliza de Web Services. Entretanto, uma implementao de

SOA pode se utilizar de qualquer tecnologia web.


42/68

32

Segundo Thomas Erl [25], os servios podem ser construdos usando os padres

tecnlgicos tais como Componentes, Web Service e REST Service [25].

a) Servios como componentes

Um componente um programa de software concebido para ser parte de um

sistema distribudo. Ele fornece uma interface tcnica comparvel a uma interface de

programao de aplicativo tradicional (API), atravs do qual ele expe as capacidades

pblicas como mtodos, permitindo assim que seja explicitamente invocado por outros

programas [25].

Figura 3.3- Smbolos usados para representar um componente [25]

Na Figura 3.3, o smbolo no lado esquerdo um componente genrico que pode

ou no ter sido concebido como um servio, ao passo que o smbolo direita est

explicitamente marcado para indicar que foi concebido como um servio [25].

b) Servios como Web Services

Um Web Service um componente de soluo lgica que fornece um contrato

tcnico, fisicamente dissociado, que consiste em uma definio WSDL e uma ou mais

definies XML Schema, e tambm possveis expresses WS-Policy. O contrato do

Web Service expe recursos pblicos como operaes, estabelecendo uma interface

tcnica, mas sem qualquer ligao com um framework de comunicaes proprietrio[25].

Figura 3.4 Arquitetura Web Service [25]


43/68

33

A figura 3.4 ilustra uma tpica arquitetura Web Serviceque contm um contrato

de servio, um componente e uma lgica de processamento de mensagens composta por

agentes event-driven, de acordo com o padro de servio Service Agent[25].

O protocolo mais comumente utilizado nas implementaes dos Web Services

Simple Object Access Protocol(SOAP).SOAP um protocolo que utiliza a linguagem Web Services Description

Language (WSDL), baseada em XML, para descrever funcionalidades oferecidas por

um Web Service. O SOAP prov um padro bsico de comunicao, no qual cada

operao representada por seu terminal, descrito no documento XML enviado na

requisio, ao invs de um mtodoHyper Text Transfer Protocol(HTTP) [29].

Completando as ferramentas base dos Web Services, a especificao Universal

Description, Discovery and Integration(UDDI) tem como objetivo descrever, descobrire integrar Web Services.

c) Servios REST

Representational State Transfer (REST) fornece um meio de construo de

sistemas distribudos baseados na noo de recursos. Servios REST (ou servios

RESTful) so programas leves que so projetados com nfase na simplicidade,

escalabilidade e facilidade de uso. Servios REST podem ser moldados pela aplicao

dos princpios de orientao a servios [25].

Por se tratar de uma abstrao dos princpios que compe a World Wide Web

(WWW), o REST se caracteriza pela escalabilidade, onde os servios fornecidos so

identificados por um Uniform Resource Identifier (URI), a partir da utilizao de

mtodos HTTP 1.0: GET, POST, DELETE e PUT. Um URI uma forma uniforme de

identificao de recursos em rede, sendo o seu tipo mais conhecido o Uniform Resource

Location(URL) [29].

Por fim, diferentemente do protocolo SOAP, o REST se trata de um modeloarquitetural, com isso o retorno das chamadas pode ser formatado conforme os

requisitos da aplicao, por exemplo, utilizando Javascript Object Notation(JSON) ao

invs de XML [29].

Alm dos padres tecnolgicos citados, vale destacar mais duas tecnologias

aplicveis a arquitetura SOA: Enterprise Service Bus (ESB) e Business Process

Management System (BPMS).


44/68

34

d) Enterprise Service Bus (ESB)

Um Enterprise Service Bus (ESB) um middleware que tem o objetivo de

facilitar a integrao de sistemas. Geralmente um ESB possui as seguintes

funcionalidades: prover segurana, prover transparncia de localizao, transformar

mensagens, rotear e monitorar as mensagens, gerenciar os servios, entre outros [26].Existem diversos produtos de ESB disponveis no mercado atualmente dos mais

diversos fornecedores, muitos destes com background do mercado de Enterprise

Application Integration (EAI). Existem, tambm, solues open source tais como Mule,

ServiceMix (adotado na soluo apresentada neste trabalho), OpenESB e JBossESB .

e) Business Process Management System (BPMS)

Como um servio pode representar uma funo de negcio dentro de umaorganizao, estes podem ser orquestrados representando fluxos de execuo dos

processos de negcio [26].

As ferramentas de BPMS fornecem os recursos necessrios que permitem a

execuo, controle e o monitoramento dos fluxos de processo [26].

De forma geral, uma ferramenta de BPMS possui como caractersticas bsica:

Ferramenta para modelagem e desenho do processo;

Mecanismo de execuo do processo;

Orquestrao de Web Services e

Interface de workflow para usurios.

3.4 GovernanaA ltima seo deste captulo trata da governana, que uma das chaves de

sucesso na implementao de uma arquitetura SOA em uma organizao.

A governana SOA est relacionada s iniciativas que visam aumentar a

qualidade total de SOA, promovendo controle em ambientes complexos, no estandorelacionada s atividades ligadas construo dos servios.

Governana tambm est relacionada a pessoas, processos e produtos, onde:

Pessoas Para se certificar que as responsabilidades esto sendo

direcionadas corretamente, e que as pessoas estejam recebendo o devido

suporte para adquirir o conhecimento e habilidades necessrias [30].

Processos Para definir se os processos certos esto sendo aplicados

para garantir a qualidade e monitoramento dos servios [30].


45/68

35

Produtos Para cadastrar os requisitos dos servios e sua documentao;

Templates para serem usados na documentao dos servios tambm

recaem sobre essa categoria [30].

Na abordagem proposta por Schepers e Kratz [30], para que uma boa

governana SOA possa ser alcanada, seis processos devem ser executados: Estabelecera viso SOA, Criar a organizao SOA, Gerenciamento do portflio de servios,

Gerenciamento do ciclo de vida de servios, Execuo dos princpios e Gerenciamento

do Nvel de Servios.

Os primeiros dois processos mantm o foco no negcio. Os trs processos

seguintes dizem respeito ao foco dos arquitetos: gerenciamento do portflio de servios,

gerenciamento do ciclo de vida dos servios e o gerenciamento do nvel dos servios. O

ltimo processo, gerenciamento do nvel dos servios, de domnio do administradordo sistema [30].

a) Estabelecer a viso SOA

Durante o ciclo de vida da governana, o primeiro passo da iterao estipular

objetivos SOA a longo prazo ou revisar os objetivos existentes. Esse processo no s

determina a perspectiva SOA na organizao como tambm define os objetivos para a

iterao corrente dentro do ciclo de vida. A viso SOA um produto das reas de

negcio e TI, onde o alinhamento conduzido pelo arquiteto.

b) Criar a organizao SOA

Nessa etapa do processo, os papis e responsabilidades da governana SOA so

definidos. Muitas vezes isso leva a iniciao de um tipo de comit que deve ser

composto pelos responsveis pela governana; De analistas de negcio a profissionais

de TI, o comit decide como o ciclo de vida de governana SOA ser implementado.

Para a execuo da iterao corrente do ciclo de vida, as pessoas certas precisam

estar no lugar certo. Isso pode requerer, no somente um treinamento extra, como

tambm contratao ou investimento em desenvolvedores. O comit de governana

deve ajudar na adoo dos princpios SOA, defendendo-os dentro da organizao e

impondo seus padres.

c) Gerenciamento do portflio de servios

O consenso deve ser atingido junto com os representantes de negcio sobre

quais servios devero ser desenvolvidos. O arquiteto deve mostrar argumentos tcnicos


46/68

36

contra argumentos de negcio em se desenvolver servios especficos. Ao se envolver

no gerenciamento do portflio de servios desde o incio, o arquiteto deve ser capaz de

apontar os servios que so candidatos reutilizao e ento encaminh-los para serem

desenvolvidos primeiro. Um roadmap de servios, listando os servios atuais e os

planejados, possivelmente o produto do gerenciamento de portflio de servios.

d) Gerenciamento do ciclo de vida de servios

Esse processo tem o objetivo de implementar, atualizar e retirar servios da

corporao. O gerenciamento do ciclo de vida no deve estar associado a projetos, mas

algo a ser conduzido pelo comit de governana SOA, que gerencia as mudanas no

ambiente SOA. Essas mudanas esto relacionadas ao conceito de reutilizao de

servios e execuo de regras de negcio por toda a empresa. No comit de governanaSOA os arquitetos devem ajudar a garantir que todos os servios estejam sendo

direcionados ao ciclo de vida de gerenciamento, para evitar a existncia de servios no

gerenciados.

e) Execuo dos princpios

Esse processo se preocupa com os princpios de design e execuo. Por

exemplo, o arquiteto precisa garantir que as pessoas estejam disponibilizando seus

servios em um repositrio, para que estes possam ser gerenciados e reutilizados. Os

arquitetos tambm precisam prestar ateno nos princpios aplicados em tempo de

design. Princpios em tempo de design so padres utilizados para o desenvolvimento

de servios, e geralmente assumem um modelo de melhores prticas. Ao contrrio dos

princpios em tempo de execuo, os princpios em tempo de design geralmente no

podem ser monitorados automaticamente. Portanto, desenvolvedores precisam estar

convencidos de que eles devem aderir aos padres. Arquitetos devem rever a entrega

dos novos servios para a corporao, e nesse momento, a verificao da correta adoo

das definies uma importante atividade a ser cumprida.

f) Gerenciamento do Nvel de Servios

Se comparado a outras aplicaes, SOA requer um gerenciamento diferente de

outras arquiteturas de TI, devido a granularidade dos seus servios. A flexibilidade em

relao ao consumo dos servios requer um bom entendimento de seu nvel de

granularidade por parte de seus consumidores. Gerenciamento de servios uma

atividade do administrador do sistema, porm os arquitetos devem prestar ateno em


47/68

37

sua granularidade a fim de argumentar com a equipe de negcio quando um

determinado nvel ainda til para os usurios do negcio. Geralmente, ao revisar a

utilizao dos servios (possivelmente com uma ferramenta de registry), as

possibilidades de reutilizao podem aparecer.


48/68

38

Captulo 4

Proposta de Soluo

Em 2014 o Centro de Anlises de Sistemas Navais (CASNAV) deu incio a

projeto de Interoperabilidade de Comando e Controle (InterC2) para o Ministrio da

Defesa do Brasil (MD), cujo o objetivo prover a interoperabilidade entre os sistemas

de C2 das foras armadas e o Sistema de Planejamento Operacional Militar (SIPLOM),

sistema de C2 do MD [41].

A primeira etapa realizada no projeto foi a anlise e o mapeamento do processo

de C2 nas Operaes Conjuntas (OpCj), envolvendo as trs etapas do Processo de

Planejamento Conjunto (PPC) - Exame de Situao; Elaborao de Planos e Ordens e

Controle da Operao Planejada (COP) - como parte dos estudos necessrios

implementao do barramento de comunicao SOA, alvo do projeto InterC2.

A partir dos processos levantados usando a tcnica Business Process

Management(BPM) e, com foco na etapa do COP, ficaram estabelecidas as etapas do

projeto para levantar os requisitos, realizar a modelagem e construir uma primeira

verso do Barramento de Comunicao, que demonstrou a possibilidade de estabelecer

um servio de troca de dados com o Sistema Naval de Comando e Controle (SISNC2).

A escolha do SISNC2 foi baseada na proximidade das equipes de

desenvolvimento, ambas no Rio de Janeiro, e na diferena de tecnologia. O SISNC2,

desenvolvido em DELPHI, foi capaz de se conectar ao Barramento, construdo com

tecnologia Java. Essa caracterstica de distintas tecnologias se conectarem aumenta apossibilidade de conexo futura com os sistemas de C2 do Exrcito Brasileiro (EB) e da

Fora Area Brasileira (FAB), mesmo que sejam construdos com tecnologia distinta,

ratificando a correta escolha de SOA para o Barramento. A Figura 4.1 apresenta o

diagrama esquemtico da interoperabilidade visualizada entre os diversos sistemas de

C2.


49/68

39

Figura 4.1 Interoperabilidade entre sistemas de C2

No ano de 2015 foram realizados os testes de cadastramento e a troca de dados

de posio dos meios, fatores fixos e feies de controle, empregados em uma operao

conjunta, bem como a atualizao da hostilidade e da situao operacional dos meios e

instalaes.

O Barramento de Comunicao com tecnologia SOA um sistema intermedirio

(middleware) baseado no JC3IEDM que permite a troca de dados automtica entre

sistemas por meio de mensagens ADEM. O seu funcionamento eficaz depende da

construo de interfaces em cada um desses sistemas, para que eles se comuniquem com

o Barramento, enviando e recebendo informaes dos servios disponibilizados.O sucesso do projeto dar continuidade ao processo de interligao e

interoperabilidade entre os centros de C2 que compem o Sistema Militar de Comando

e Controle (SISMC2), conforme consta na Poltica do SISMC2 [4].

Nas Operaes Conjuntas (OpCj) j ocorre a integrao das etapas de

Elaborao de Planos e Ordens e do COP na prtica. Essa integrao precisa ser

acompanhada pela interoperabilidade entre os sistemas de C2 das FS e o SIPLOM.

Finalmente, a construo do Barramento de Comunicao contribui para oatendimento de uma das capacidades desejadas para as Foras Armadas, constante na

Estratgia Nacional de Defesa [3], que possui como uma de suas diretrizes a

Interoperabilidade nas OpCj.


50/68

40

4.1 Arquitetura do Barramento

De modo a garantir a interoperabilidade presente e futura, a arquitetura do

INTERC2 segue padres de entidades com autoridade normativa. Dentre esses,

podemos destacar:MIP: JC3IEDM e ADEM; e

W3C e OASIS: XML, XSD, WSDL.

A tecnologia na qual est baseada a implementao da camada central da

arquitetura do Barramento Java. As principais justificativas para essa escolha so a sua

maturidade, portabilidade, ausncia de custo de licenciamento (baixo custo de

aquisio) e disponibilidade de mltiplos fornecedores.

O modelo de operao do software do Barramento, eminentemente baseado em

intercmbio de informao por meio de troca de mensagens, determina a sua forma de

organizao. Essa organizao favorece ao padro arquitetural de um processamento em

estgios encadeados [31]. Mensagens so recebidas pelo sistema, verificadas,

processadas e encaminhadas ao destinatrio. Essa forma de organizao condiz com a

Arquitetura Orientada a Servios.

O fundamento da SOA o desacoplamento entre as partes que se comunicam,

permitindo flexibilidade para adaptao a novos requisitos ou integrao a novos

sistemas [32]. Essa modalidade de arquitetura o alicerce do Barramento.

De modo a no incorrer em custo de implementao da infraestrutura, o projeto

INTERC2 adotou um Barramento de Servios Corporativo (Enterprise Service Bus

ESB) com base em SOA. A equipe do projeto INTERC2 realizou uma anlise

comparativa entre seis produtos ESB de software livre e decidiu empregar o Apache

ServiceMix [33]. O ServiceMix formado, principalmente, por quatro projetos Apache:

Karaf a plataforma OSGi [9], ActiveMQ os componentes de mensageria, CXF os

componentes WS-*, e Camel Domain Specific Language (DSL) e componentes de

integrao.

Esses mdulos realizam as funes de comunicao webservices, filas para

mensagens, acesso e transformao de dados. O padro OSGi, facilita a implementao

de componentes versionados com interfaces bem definidas e dependncias explcitas. A

possibilidade de coexistncia de componentes em verses distintas torna possvel tanto

a evoluo dos componentes quanto das interfaces de servios.

Os artefatos finais, especficos ao mbito do Barramento, constituemcomponentes OSGi. A configurao e integrao destes componentes ocorre por meio


51/68

41

de blueprints XML que fazem referncia a webservices, filas e componentes de

persistncia. Os componentes favoreceram o emprego da linguagem DSL Apache

Camel para sua implementao. As vantagens do uso da DSL so clareza e facilidade

para implementao das regras de C2. Os casos de maior complexidade foram

codificados em Java.O diagrama de arquitetura da Figura 4.2 apresenta uma viso funcional em

mdulos com os ativos de software utilizados.

Os webservices do Barramento, baseados no ADEM, so descritos em WSDL e

empregam a API Java JAX-WS para servios. H servios de solicitao e resposta que

podem ser tratados em portas distintas. Os webservices empregam nas mensagens

objetos ADEM normatizados, com algumas extenses especficas aos sistemas de C2 do

MD.

Figura 4.2- Diagrama de Arquitetura e Ativos de Software

Todas as mensagens do Barramento so mapeadas e persistidas em um banco de

dados baseado no JC3IEDM. O JC3IEDM inteiramente relacional, motivo pelo qual

emprega-se um SGBD relacional para sua implementao. O SGBD escolhido foi o

PostgreSQL [35].


52/68

42

O SO utilizado o CentOS [36], uma distribuio estvel e livre do Linux para

projetos corporativos.

De modo a garantir o baixo acoplamento entre os mdulos, a tolerncia a falhas

e o processamento estvel durante um perodo de intercmbio intenso, o Barramento

emprega filas de mensagens persistentes do tipo Java Message Service (JMS) [37]. OJMS uma interface de programao de aplicaes (API) na plataforma Java Enterprise

Edition (Java EE), para middleware orientado mensagens. Por meio da API JMS, duas

ou mais aplicaes podem se comunicar por mensagens.

O fator de segurana para a arquitetura est presente em todas as camadas,

havendo destaque para o aspecto de comunicao do Barramento. A segurana ponto a

ponto das Mquinas Virtuais (VM) realizada pelo firewall j presente no kernel do

Sistema Operacional Linux. A possibilidade de conexo ocorre apenas nos endereos deIP conhecidos e nas portas autorizadas. Os firewalls esto baseados no Apache HTTP

Server, configurado em modalidade proxy.

A separao das funes por camadas permite que o Barramento adote a

virtualizao, onde mltiplas VM podem ser especializadas por funo. Esse arranjo

permite, se necessrio, que seja adotado clustering de servios. A verso 1.0 do

Barramento emprega uma VM para dados, uma para integrao e outra para

monitoramento.

O monitoramento dos servios e da situao operacional das outras VM est

centrado no Zabbix [38]. O Zabbix o software para aplicaes corporativas, projetado

para o monitoramento em tempo real de mtricas coletadas a partir de servidores,

mquinas virtuais e dispositivos de rede, sendo de licena Open Source.

4.2 A Interface de ComunicaoCom o objetivo de divulgar a forma de conexo entre os sistemas foi publicada,

em maro de 2015, a interface para intercmbio de dados do Barramento de

Comunicao entre o sistema de C2 do Ministrio da Defesa e os sistemas de C2 das

Foras Singulares (FS), visando interoperabilidade, com enfoque no levantamento de

necessidades de informaes para a tomada de deciso, nos nveis

operacional/estratgico.

O ADEM decompe o JC3IEDM, mantendo a sua semntica em pequenas

mensagens discretas que podem ser utilizadas individualmente ou agregadas,

permitindo a troca de um conjunto mnimo de informaes. Cada uma das mensagens

discretas completa em si e no depende de informaes previamente trocadas ou


53/68

43

fornecidas no futuro. Assim, as informaes das mensagens ADEM so atemporais e

podem ser mapeadas em entidades JC3IEDM.

Como exemplo, uma mensagem que tramita informao sobre uma Unidade

(Unit), inclui informao sobre as seguintes entidades JC3IEDM:

UNIT UNIT-TYPE

LOCATION

ORGANISATION-STATUS

OBJECT-ITEM-HOSTILITY

OBJECT-ITEM

OBJECT-TYPE

AFFILIATION-GEOPOLITICAL REPORTING-DATA

REPORTING-DATA-ABSOLUTE-TIMING

SECURITY-CLASSIFICATION

O subconjunto de mensagens ADEM escolhido para a atual verso do

Barramento de Comunicao permite ao SIPLOM receber informaes dos sistemas de

C2 das FS sobre a Unidade e seu tipo (UNIT e UNIT-TYPE), a localizao

(LOCATION), hostilidade (OBJECT-ITEM-HOSTILITY) e a situao operacional

(ORGANISATION-STATUS) dos objetos de interesse empregados nas OpCj.

As mensagens transmitidas pelos sistemas de C2 das FS e recebidas pelo

barramento adotam os esquemas XML (XSD) padronizados pelo ADEM na verso

1.0.2. Esses esquemas representam o modelo segundo o qual as informaes devero ser

codificadas como mensagens XML. Essas mensagens sero dirigidas para os Servios

Web. Os esquemas XML so disponibilizados como arquivos individuais.

Mensagens vlidas so registradas no arquivo de Log, as informaes

necessrias so armazenadas no Banco de Dados do Barramento e retransmitidas para o

SIPLOM. Mensagens invlidas geram um recibo de no conformidade que ser

devolvido para o sistema de C2 de cada FS.

Como j mencionado, o ADEM utiliza a semntica do JC3IEDM, porm, devido

a sua natureza informacional, cujo objetivo o intercmbio da situao corrente, alguns

tipos de objetos definidos pelo JC3IEDM no so contemplados pela especificao do

ADEM. Como a possibilidade de extenses prevista na especificao do ADEM, esse

recurso utilizado, garantindo, assim, a troca de informaes adaptada realidade

brasileira.


54/68

44

A comunicao entre o Barramento e os sistemas de C2 padronizada por

contratos de servios baseados em documentos no formato WSDL. Os WSDL

empregados pelo Barramento esto baseados no mtodo ADEM, do mesmo modo que

os esquemas XML

implementação de uma arquitetura soa para interoperabilidade entre sistemas de comando e controle

Documents