Joint Battle Management Language JBML Project Web Service Architecture

1
Joint Battle Management Language (JBML)
ProjectWeb Service Architecture
SISO C-BML Meeting at ARL-UT 17-19 Jan 07 Mark
Pullen and Stan Levine
2
Background

• GMU-ACS-VMASC team developed DMSO XBML
• Starting point Army BML prototype (CAPES-OTB)
• Added Web Services and C2IEDM to Ground system
• Worked with Gestalt to demonstrate Ground-Air
  operation, adding TBMCS and JSAF
• Successfully linked with French APLET system
  using CAPES-JSAF over WS/C2IEDM
• GMU-ACS-VMASC-JATTL(Gestalt)-NPS funded for JBML
  phase 1 under Army/TEC (Sep 06 Jun 07)
• Support SISO C-BML standard effort with inputs
  open source code
• Ground-Air-Maritime BML proof of principle
• Support NATO MSG-048 process

3
JBML Vision
4
JBML Definition

• BML - an unambiguous language to
• Command and control live and simulated forces
  conducting military operations, and
• Provide for situational awareness and a shared,
  common operational picture.

Shared Semantics between C2 and MS via a Common
Tasking Description
5
C2IEDM / JC3IEDM and BML

• BML represents C2 orders and status in a way that
  is
• Unambiguous, so it can be processed by computers
• Human understandable, so it can be read and
  expressed by users
• JC3IEDM represents C2 data in a way that is
  concise and detailed
• Can be extended to represent any needed C2 data
• Can express the content of any BML message
• But is virtually impossible for humans to read
  and comprehend quickly
• Also, experience shows different groups find
  different, incompatible ways to express a given
  set of data in JC3IEDM
• We treat these names as interchangeable

6
JBML and Grammar

• BML projects to date (even XBML) have focused on
  point-to-point interfaces
• Later ones have been implemented in XML/SOAP
• But there has been no overall design to create a
  general, flexible BML that can grow to encompass
  the whole projected scope of BML
• We need a rational and extensible approach to
  expressing BML information
• C-BML Study Group recommended that the future
  standard be based on a lexical grammar
• We intend to get a start on this approach

7
Hieb and Schade BML Grammar

• As a first step toward rationalizing BML, Ulrich
  Schade and Mike Hieb analyzed the existing ground
  BML
• They concluded that any statement in ground BML
  can be expressed using the construct
• B ? Verb Tasker Taskee (Affected Action)
• Where Start-When (End-When) Why Label
  (Mod)
• Where is a location phrase
• the Whens are time phrases
• Why gives the purpose of the action
• Label is a label given to the task in order
  allow it to be referred in other basic
  expressions.
• This grammar is easy to represent in XML
• For example the Tasker is tagged ltTaskerWhogt

8
JBML Web Service Infrastructure

• Currently Web Services are the communication
  means of choice for distributed system
  development
• BML can be passed between C2 and simulation Web
  services in two ways
• Synchronous connection direct real-time path
  between C2 and Simulation, pairwise
• Asynchronous connection BML messages are
  buffered in one or more intermediate systems that
  store system state
• Synchronous is more responsive but asynchronous
  is more flexible
• One repository serves multiple C2 and Simulation
  systems
• Not necessary for all systems to be continuously
  available
• Particularly good for development,
  experimentation, and distributed operation where
  it is hard to keep all systems responding
  constantly

9
BML Demo Environment Architecture from ACS
XML
Sim Specific Interface
JSAF
BML Sim Interface
BML Web Service
XML
Other Simulation
Sim Specific Interface
USMTF
C2 Specific Interface
GCCS
BML C2 Interface
Development Infrastructure
JC3IEDM GUI
BML C2 GUI
XML
C2 Specific Interface
CSE
Web Service Interface
10
JBML Web Service Infrastructure

• Using a Web service repository will simplify JBML
  and C-BML development
• Enables distributed development over Internet
• Each participant can test interactions
  asynchronously
• The same BML interfaces can be used synchronously
  later
• To support a standards effort, the Web service
  software needs to be fully exposed
• Serves as Reference Implementation, available as
  open source for all to understand
• Ideally, configurable by standards developers
  without creation of new software
• This was our target in creating the JBML Service
  Architecture
• This does not imply that future systems that
  comply with the standard must use a repository
• They could use synchronous interfaces

11
Need for Initialization Standard

• A great deal of the information needed for BML
  comes before the orders and status reports start
• A live force is initialized by common experience,
  SOP, training, etc.
• But a simulation requires initial state for
  anything that can change
• We are very happy the MSDL PDG is working on this
  it is essential for C-BML success
• And we need it to use compatible representations
• Were already using one of their drafts
• Need more soon!

12
JBML Phase 1 Plan
Demo Planning GMU,JATTL
Web Service Development GMU,ACS,VMASC
Air Maritime BML Definition Gestalt,NPS
JSAF Interface Update ACS
C2 Translator Development JATTL
Demo Preparation all
Reports all
Aug Sep Oct Nov Dec Jan
Feb Mar Apr May Jun 2006

2007

13
JBML Service Architecture Overview
14
Introduction

• These slides summarize the latest draft of the
  document JBML Web Services which describes the
  architecture developed by the JBML architecture
  team GMU, ACS, VMASC.
• The current version of this document and all
  documentation and open source code from the JBML
  project are available at
• http//netlab.gmu.edu/JBML
• The lower two layers of our implementation were
  developed starting from open source code provided
  to GMU by VMASC

15
JBML Service Architecture
16
BML to C2IEDM Mappingfrom ACS XBML
17
Domain-Configured ServiceDomain Layer

• The Domain-Configured Service (DCS) implements
  BML in a domain context.
• In the case of an OPORD, the transaction at this
  layer would specify all information about a given
  task (i.e., who, what, when, where, and why).
• For a Position Report, the transaction at this
  layer would include all information about the
  updated location (e.g. who, where, when-valid,
  precision, etc)
• The DCS is designed to serve as infrastructure
  for a growing BML standards effort.
• It is built to be configurable by an XML Schema
  Definition (XSD) and based on the layering
  concepts VMASC has put forward in various papers
• Also supports Poll command to retrieve an order
• JBML Phase 2

18
Foundation of BML-DCS

• Implemented in the Document-Literal XML mode
• Generic Web service driven by an XML schema
  called Domain Knowledge Schema (DKS)
• Basis for standard to define all possible C-BML
  orders
• Based on the concept of Schade and Hieb
• the entire existing BML grammar can be described
  in terms of a few primitives
• ltcommandgt lttasker-whogt lttaskee-whogt
  ltaffected-whogt ltwhatgt (action) ltwheregt
  ltstart-whengt ltend-whengt ltwhygt ltlabelgt
  ltmodifiergt
• JBML is defining an XML format that can be used
  by every BML order based on these tags plus a
  small number of extensions
• The current version of the schema implements the
  tags above and is available on the JBML website

19
DCS Order Example (1 of 2)

• lt?xml version"1.0"?gt
• ltMessage "gt
• ltOrdergt
• ltOrderIssuedWhengt
• ltDTGgt011200ZMAY2006lt/DTGgt
• lt/OrderIssuedWhengt
• ltTaskerWhogtMORT/UIE2lt/TaskerWhogt
• ltTaskOrganizationgt
• ltUnitgt
• ltHQgtMORT/UIE2lt/HQgt
• ltSubunitgtMORT/UIE3lt/Subunitgt
• lt/Unitgt
• lt/TaskOrganizationgt
• ltControlMeasuresgt
• ltControlMeasuregt
• ltWhereLabelgtINITIAL_PL_MORTlt/WhereLabelgt
• ltWhereClassgtPOINTlt/WhereClassgt
• ltWhereValuegt
• ltmsdlGDCgt

20
DCS Order Example (2 of 2)
ltWheregt ltWhereLabelgtINITIAL_PL_MORTlt/WhereLabelgt
ltWhereClassgtPOINTlt/WhereClassgt
ltWhereValuegt ltmsdlGDCgt
ltmsdlLatitudegt77.0lt/msdlLatitudegt
ltmsdlLongitudegt61.00lt/msdlLongitudegt
ltmsdlElevationAGLgt100000.0lt/msdlElevationAGLgt
lt/msdlGDCgt lt/WhereValuegt
lt/Wheregt ltStartWhen modifier"AT"gt
ltDTGgt020700ZMAR2006lt/DTGgt lt/StartWhengt
ltEndWhen modifier"AT"gt
ltDTGgt020700ZAPR2006lt/DTGgt lt/EndWhengt
ltWhygt ltWhyAffectedgtBREAKUPlt/WhyAffectedgt
lt/Whygt ltLabelgtINITIAL_ATTACK_MORTlt/Labe
lgt lt/Commandgt ltCommandersIntentgtForce
contact with enemy.lt/CommandersIntentgt lt/Ordergt lt/
Messagegt
21
DCS Order Details Order of Battle

• lt?xml version"1.0"?gt
• ltMessage "gt
• ltOrdergt
• ltOrderIssuedWhengt
• ltDTGgt011200ZMAY2006lt/DTGgt
• lt/OrderIssuedWhengt
• ltTaskerWhogtMORT/UIE2lt/TaskerWhogt
• ltTaskOrganizationgt
• ltUnitgt
• ltHQgtMORT/UIE2lt/HQgt
• ltSubunitgtMORT/UIE3lt/Subunitgt
• lt/Unitgt
• lt/TaskOrganizationgt

22
DCS Order Details Control Measures

• ltControlMeasuresgt
• ltControlMeasuregt
• ltWhereLabelgtINITIAL_PL_MORTlt/WhereLabelgt
• ltWhereClassgtPOINTlt/WhereClassgt
• ltWhereValuegt
• ltmsdlGDCgt
• ltmsdlLatitudegt
• 32.00
• lt/msdlLatitudegt
• ltmsdlLongitudegt
• 84.00
• lt/msdlLongitudegt
• ltmsdlElevationAGLgt
• 100000.0
• lt/msdlElevationAGLgt
• lt/msdlGDCgt
• lt/WhereValuegt
• lt/ControlMeasuregt
• lt/ControlMeasuresgt

23
DCS Order Details Command What-Where

• ltCommandgt
• ltDomaingtGROUNDBMLlt/Domaingt
• ltTaskeeWhogtMORT/UIE3lt/TaskeeWhogt
• ltWhatgtSUPPORTlt/Whatgt
• ltWheregt
• ltWhereLabelgtINITIAL_PL_MORTlt/WhereLabelgt
• ltWhereClassgtPOINTlt/WhereClassgt
• ltWhereValuegt
• ltmsdlGDCgt
• ltmsdlLatitudegt
• 77.0
• lt/msdlLatitudegt
• ltmsdlLongitudegt
• 61.00
• lt/msdlLongitudegt
• ltmsdlElevationAGLgt
• 100000.0
• lt/msdlElevationAGLgt
• lt/msdlGDCgt

24
DCS Order Details When-Why

• ltStartWhen modifier"AT"gt
• ltDTGgt020700ZMAR2006lt/DTGgt
• lt/StartWhengt
• ltEndWhen modifier"AT"gt
• ltDTGgt020700ZAPR2006lt/DTGgt
• lt/EndWhengt
• ltWhygt
• ltWhyAffectedgtBREAKUPlt/WhyAffectedgt
• lt/Whygt
• ltLabelgtINITIAL_ATTACK_MORTlt/Labelgt
• lt/Commandgt
• ltCommandersIntentgt
• Force contact with enemy.
• lt/CommandersIntentgt
• lt/Ordergt
• lt/Messagegt
• Note an order can have many commands.

25
DCS Poll Example

• lt?xml version"1.0"?gt
• ltMessage xmlnsp1"http//netlab.gmu.edu/JBML/MSDL
  "
• xmlnsxsi
• "http//www.w3.org/2001/XMLSchema-instance"gt
• ltPollgt
• ltTaskeeWhogtCOA/ASlt/TaskeeWhogt
• ltTaskerWhogtsample/sample1lt/TaskerWhogt
• ltOrderIssuedWhengt
• ltDTGgt011200ZMAY2006lt/DTGgt
• lt/OrderIssuedWhengt
• lt/Pollgt
• lt/Messagegt

26
BML Base ServiceComposite Layer

• The BML Base Service (BBS) provides primitive BML
  elements such as Who, What, When, Where, and Why.
• Other elements may be introduced for new and
  existing BML domains as required.
• The BBS accesses all of the database tables
  affected by the primitive elements, through the
  Common Data Access software.
• We believe the standard at this layer should
  identify the database tables to be updated for
  each BML primitive and the validation conditions
  to be applied.
• Standardizing the composite avoids the confusion
  inherent in multiple implementers taking
  different interpretations of the C2IEDM/JC3IEDM
• BBS Interfaces
• Upwards XML-based API interface (4) to the DCS.
• Downwards uses the BML Common Data Access API.
• In order to expose the BBS externally, access
  will be provided through the DCS using a pass
  through tag.

27
BBS Example

• BBSCommand_push(
• 1027, // ID of TaskerWho MORT/UIE2
• 011200ZMAY2006, // OrderIssuedWhen
• 1028, // ID of TaskeeWho MORT/UIE3
• SUPPORT, // What
• 41XMF4978747627, // Where (GDC-gtMGRS per
  OpenMap)
• 020700ZMAR2006, // StartWhen
• BREAKUP, // Why-WhyAffected
• INITIAL_ATTACK_MORT,// CommandLabel
• // null AffectedWhoID

28
BML Common Data Access ServiceAtomic Layer

• The CDAS provides mechanisms to
• inspect database tables externally, via Web
  service
• both read and update the database tables directly
• The CDAS will support inspection of every
  database table used in any domain of BML, in
  order to support understanding of system behavior
  during development.
• Open-source GUI available on the JBML website
• Changes to the database do not overwrite the
  previous values but instead mark them invalid and
  provide new valid values.
• There are two higher level interfaces to the
  CDAS
• Internal interface (6), defined as an XML-based
  API
• active in both directions (write and read)
• External interface (5) defined using a WSDL
  (XML/SOAP based)
• One way interface intended to be used for
  inspecting (reading) tables
• Lower level interface (7) is SQL based.

29
CDAS Example

• String tableName act
• String columnName act_id
• String keyValue 2265
• String result getTable(tableName,columnName,ke
  yValue)
• There are 21 tables that must be accessed using
  the CDAS
• act, act_task, act_res, act_res_item, act_effect,
  act_effect_item, act_objve, act_objve_item,
  obj_item, feat, ctrl_feat, obj_item_loc,
  loc,point, abs_point, ver_dist, act_ref, doc,
  org_act_assoc, unit, act_task_activity_cd,
  act_affect_description
• To ensure consistency, a composite BBS
  transaction such as what must complete all CDAS
  updates before the next transaction is served

30
CDAS Implementation

• GMU has implemented the CDAS in open source Java
  code, based on original VMASC development
• Available on JBML website
• Amounts to a wrapper that translates get and put
  of tables to SQL
• A single module supports any number of tables
• Provides error control
• Filters to limit access to those tables intended
  for BML use
• Automatically moves overwritten table rows to a
  backup database, forming history of data state
• Implemented a simple Java-based GUI that allows
  inspection of the C2IEDM / JC3IEDM tables
• Also on the website

31
Another Way of Looking at the Foregoingfrom VMASC
32
Our View of What Needs Standardized

• At the Domain Layer, the grammar containing all
  possible orders
• XML tagset for the primitives of the grammar
  (nouns, verbs, adjectives, )
• Schema defining the configurations in which the
  tags (primitives) may occur
• Narrative definitions of their meaning
• At the Composite Layer, the set of basic BML
  operations (who, what, when, where, why)
• Each defined by the JC3IEDM tables/columns
  modified
• And validation conditions when they are invoked
• At the Atomic Layer, the JC3IEDM tables used to
  represent BML and a standard XML format to access
  them, whether as a database or for other exchange
• There are differences of opinion in JBML team
  here
• Andreas will explain why he has different
  thoughts, later
• Definition of the Internet/Web standards to be
  used for communication

33
Status of Our Implementation

• CDAS (bottom layer) is up and running
• Thanks to bootstrap from VMASC
• BBS (middle layer) is running too
• But the definitions of tables changed is based on
  XBML implementation
• Needs to be reviewed in detail by C-BML group
• Probably will grow with Air and Maritime domains
• DCS (top layer) is running, for orders that
  contain a single command
• Working on JC3IEDM identification of multiple
  commands
• Poll is working in a limited way
• Some order identification data missing from the
  order returned
• BBS write-through/read-through not yet
  implemented

34
Conclusion

• The Web Service Architecture developed by the
  JBML project provides a solid foundation for
  development of C-BML
• Top-down development based on computational
  grammar
• Three-layer structure based on VMASC work
• Protocol will support either synchronous
  (directly coupled) or asynchronous (database
  coupled) C2-Simulation interfaces
• Open-source database implementation supports use
  of C2IEDM/JC3IEDM data models with external
  inspection
• We will be learning a lot more about the
  effectiveness of this approach as we
• Integrate Air and Maritime BML
• Demonstrate in Joint environment