XMSF Profile SG Final Report 05FSIW013 2005 Fall SIW Submitted by: Katherine L. Morse, PhD

1
XMSF Profile SG Final Report05F-SIW-0132005
Fall SIWSubmitted byKatherine L. Morse, PhD
2
XMSF
Visualization Layer using SOFVIZ
Data Storage Layer
Terrain UOB I/F
Common Client Side Web I/F
Server Platform
Client Platform
Dynamically Updated Entity Status
XML Control Messages
Client Federate
RTI
Terrain UOB Initialization Data
ltunitgt ltposgt32UCD4314311lt/posgt
lttypegttanklt/typegt ltsidegtredlt/sidegt lt/unitgt
RTI Ambassador Stub Remote Federate Ambassador
Federate or Federation
Federate Ambassador Stub Remote RTI Ambassador
RTI API
RTI API
SOAP Services
SOAP Services
SOAP/BEEPCommunicationsover Internet
Web Service
HLA to XML (Service)
DIS to XML (Service)
C4I to XML (Service)
XML I/F
XML I/F
BEEP Communications
BEEP Communications
Terrain Server
Terrain Server
Simulation
GIG ES
Different Views
XMSF is a set of web based technologies and
services, applied within an extensible framework,
described by XML based profiles, that enables a
new generation of modeling simulation (MS)
applications to emerge, develop and interoperate.
3
Introduction / Overview

• The specification of XMSF will be in the form of
  a collection of profiles detailing how to
  interoperate with XMSF compliant systems. These
  profiles will enable inter- and intra-domain
  interoperability. At a macro level, a profile
  will consist of
• Applicable web technologies and protocol
  standards
• Applicable data and metadata standards
• A tailoring of the set of selected standards
  (e.g. tailoring of authentication standards
• Recommendations and guidelines for implementation
• Composability guidelines
• Technology application guidance
• Hardware configuration recommendations,
  requirements, and constraints, e.g. network
  bandwidth, minimum processing capability
• Software configuration recommendations,
  requirements, and constraints, e.g. browser
  support for specific applications
• Specialization of design methodologies
• For profiles to successfully enable
  interoperability their initial content and
  structure must be agreed on. As the underlying
  technologies and standards evolve the profiles
  and their implementations will need to be
  upgraded in an iterative fashion to maintain
  interoperability. The purpose of this SG is to
  determine the required scope for XMSF profiles
  and to define their structure.

4
SG Officers and Member List

• Officers
• Katherine L. Morse (Chair)
• Ryan Brunton, Curt Blais (Vice Chairs)
• Previously Andreas Tolk
• No current secretary
• Previously Johnny Garcia
• Member List

5
Task Descriptions from the TOR

• Develop profile definition including objectives
• Develop profile conops
• Identify candidate exemplar test cases
• Survey profiles from other domains
• First pass culling of obviously non-applicable
  profiles
• Determine applicability of other profiles
• Review exemplar test cases to identify necessary
  interoperability information
• Define XMSF-specific requirements
• Identify applicable documentation mechanisms
• Draft XMSF profile standard/review potential
  change to PDG status or request for extension

6
XMSF Profile SG Process
Complete
Develop definition and objectives
Develop conops and roles and responsibilities
Survey profiles from other domains
In process
Outside scope
Define XMSF- specific requirements
Experimentation informs the profile standard
development process
Identify necessary interoperability information
Identify candidate exemplars
content
structure
Identify applicable documentation mechanisms
Draft standard
7
Product Descriptions

• Profile definition
• Defines the scope and objectives of the profile
  standard
• The structure and content of the profile standard
  must enable the objectives in the definition
• Profile conops
• Describes the stakeholders roles and
  responsibilities relative to profiles, the
  profile standard, and each other
• One step in the identification of structure and
  content requirements, i.e. the profile standard
  must enable each of the stakeholders
  responsibilities
• FEDEP overlay
• Because many existing simulation capabilities are
  HLA compliant and the FEDEP to develop these
  capabilities, we chose the FEDEP as an excellent
  source of process guidance
• Identifies FEDEP activities that may be supported
  through the application of XMSF profiles, and
  recommends additional tasks within these
  activities related to profiles

8
Product Descriptions

• Profile survey
• Other technologies use the concept of profiles to
  tailor their standards
• Several other approaches to profiles were
  investigated to determine if any of their
  approaches or mechanisms might be applicable to
  the XMSF profiles
• Candidate exemplars
• XMSF prototype exemplars that inform the profile
  standard development process
• Analysis of documentation mechanisms
• Need to determine both content and
  structure/format of profiles
• Must support the profile definition
• Must support the roles of the stakeholders
• Since unambiguous interpretation is our first
  objective, focus on technologies that support
  automated methods
• Searching - where is it?
• Composability - what can it do?
• Integration - how do I put the pieces together?
• Open standards are key

9
Product Descriptions

• WE RTI profile prototype
• The SG concluded that substantial progress
  couldnt be made until we attempted to write a
  prototype profile based on our work to date
• The WE RTI exemplar was chosen because it had the
  most complete documentation to date
• WSIM profile prototype
• Web Services Interest Management from XC2I
  project for JFCOM
• Completed and posted to the XMSF web page just as
  the SG was finishing its work

10
Significant Results and Achievements

• Although the SG did not complete all the tasks in
  the TOR, we completed four that resulted in
  several products and clearly defined the
  direction for a future profile standard
• Develop profile definition including objectives
• Develop profile conops
• Identify candidate exemplar test cases
• Survey profiles from other domains
• And made significant progress on three more
• Review exemplar test cases to identify necessary
  interoperability information
• Define XMSF-specific requirements
• Identify applicable documentation mechanisms
• Progress on these seven tasks has allowed us to
  produce two prototype profiles
• Established web site with
• Prototype profiles
• Tutorial on building profiles
• Collaborative community environment for profile
  developers

www.xmsf.org
11
Summary of Technical Findings

• A profile standard that meets all of the
  objectives in the definition is feasible
• Eventual profile standard will be based on XML
  and DocBook at the highest level because
• XMSF must be equally usable by human and software
  agents.
• XMSF must support composable, reusable model
  components.
• The definition objectives must be supported by
  both the structure and the content of the
  profiles
• Profile standard will enable integration of other
  standards into profiles, not recreation of them
• Other metadata standards may impact the profile
  standard, e.g. DDMS, because profiles will have
  to be discoverable in other registries

12
Recommendations for Future SISO Actions The Way
Ahead

• Establish a Standing Study Group
• Work toward completion of remaining tasks from
  original ToR
• Gain more experience from additional prototype
  profiles
• Add tasks for coordination with related efforts
• MS GIG COI Metadata Focus Group
• DoDAF Core Architecture Data Model (CADM)

13
References

• Katherine L. Morse and Robert Lutz, The XMSF
  Profile Overlay to the FEDEP, 2005 Spring
  Simulation Interoperability Workshop, San Diego,
  CA, April 2005, 05S-SIW-005.
• Ryan P.Z. Brunton, Documenting the Web Enabled
  RTI - An XMSF Profile Prototype, 2005 Fall
  Simulation Interoperability Workshop, Orlando,
  FL, September 2005, 05F-SIW-093.
• Curt Blais, "Extensible Modeling and Simulation
  Framework (XMSF) Exemplars in Analytic Combat
  Modeling," 2004 Spring Simulation
  Interoperability Workshop, Crystal City, VA,
  April 2004, 04S-SIW-142.
• Leslie Winters and Andreas Tolk , The
  Integration of Modeling and Simulation with Joint
  Command and Control on the Global Information
  Grid, 2005 Spring Simulation Interoperability
  Workshop, San Diego, CA, April 2005, 05S-SIW-148.
• Andreas Tolk , Metamodels and Mappings Ending
  the Interoperability War, 2004 Fall Simulation
  Interoperability Workshop, Orlando, FL, September
  2005, 04F-SIW-105.

14
Profile Definition and Conops
15
Profile Definition

• XMSF profiles are formal technical specifications
  for application of interoperable web based
  technologies to enabling composable and reusable
  modeling and simulation, and facilitating
  enterprise integration. The objectives of XMSF
  profiles are to
• Provide unambiguous specification of the
  functionality of components, and interfaces among
  components of the framework
• Ensure interoperability between existing and new
  web enabled technologies, both within MS and in
  related domains
• Provide the necessary metadata to facilitate
  composability and reuse of components across
  multiple MS application domains
• Facilitate development of new applications and
  services that are functionally interchangeable
  with existing applications and services
• Enable development of new applications and
  services that readily extend functionality for
  continuous evolution of capabilities

16
Role Relationships in the Profile Conops
Customers
New profiles
Specify the requirement to adhere to specific
profiles
Requirement to adhere to profile(s)
Requirements for new simulation/ systems
Simulation/System Developers
New simulations/systems
Develop/integrate new simulations/ systems
consistent with existing profiles - Identify the
need for new profiles Develop/integrate new
simulations/systems without an existing profile
Develop profiles for new simulations/systems
Provide feedback to Profile Community /Working
Group on effectiveness of profile standard
Provide feedback to Profile Certifying Authority
on accuracy of individual profiles
Feedback on simulations/systems
Feedback on implementation adherence to profiles
New profiles
New simulations/systems
Feedback on profile standard
Profile standard
New profiles
Profile Certifying Authority
Maintain repository and CM of approved profiles
- Develop certification processes and metrics
Assess individual profiles according to the
profile standard, and certification processes and
metrics VV profiles - ensure that profiles
remain consistent with the profile standard
if/when it changes
Profile standard
Recommendations on certification processes and
metrics
Feedback on profile relevance
Updated/aligned profiles
New profiles
17
FEDEP Overlay

• Katherine L. Morse
• Bob Lutz

18
XMSF Profile Overlay Purpose

• One of the key mechanisms for identifying content
  and structure requirements for XMSF profiles is
  to review how profiles will support a concept of
  operations for various simulation stakeholders
• The existing HLA developers and users represent
  an important community of stakeholders.
• Overlays are an existing mechanism for relating
  the FEDEP to other (HLA federation development)
  processes
• Identify FEDEP activities that may be supported
  through the application of XMSF profiles
• Recommend additional tasks within these
  activities related to profiles

19
FEDEP Overview

• Experts in specific disciplines have used FEDEP
  overlays as a means of defining how their
  lowerlevel processes operate within the broader
  end-to-end federation development process
• VVA
• Testing
• Fidelity management
• Case study overlays
• Meant to convey how the FEDEP was implemented on
  a specific project
• Product overlays
• Meant to convey how certain tools or tool classes
  can be used to automate FEDEP activities)

The FEDEP is IEEE 1516.3-2003
20
Step 3 - Design Federation

• 3.1 - Select federates
• The purpose of this activity is to determine the
  suitability of individual simulation systems to
  become members of the federation. This is
  normally driven by the perceived ability of
  potential federation members to represent
  objects, activities, and interactions in the
  federation conceptual model.
• Profiles may be used to identify candidate
  federates. The profiles may be stored in
  registries where tools may support automated
  processes for identifying federates and
  evaluating their applicability to representing
  required entities/object and events.
• 3.2 - Prepare federation design
• Once all federates have been identified, the next
  major activity is to prepare the federation
  design and allocate the responsibility to
  represent the entities and actions in the
  federation conceptual model to the federates.
  This activity will allow for an assessment of
  whether the set of selected federates provides
  the full set of required functionality.
• Profiles may be used to assess what applicable
  functionality individual federates provide.

21
Step 4 - Develop Federation

• 4.2 - Establish federation agreements
• Although the FOM defines and documents the full
  set of data that is exchanged among federates to
  achieve federation objectives, there are other
  operating agreements that must be reached among
  federate developers and management (prior to
  implementation) that are not necessarily
  documented in the FOM. Such agreements are
  necessary to establish a fully consistent,
  interoperable, distributed simulation
  environment.
• Agreements in existing profiles may be
  applicable, and therefore, readily reusable.
• Also, agreements must be reached as to the
  databases and algorithms that must be common (or
  at least consistent) across the federation to
  guarantee valid interactions among all federation
  participants.
• Review and evaluation of existing profiles may
  indicate requirements for new profiles.

22
Step 4 - Develop Federation

• 4.3 Implement federate designs
• The purpose of this activity is to implement
  whatever modifications are necessary to the
  federates to ensure that they can represent
  assigned objects and associated behaviors as
  described in the federation conceptual model.
• Federate modifications may include the addition
  of functionality that should be recorded in the
  federates profile.
• 4.4 - Implement federation infrastructure
• The purpose of this activity is to implement,
  configure, and initialize the infrastructure
  necessary to support the federation and verify
  that it can support the execution and
  intercommunication of all federation components.
  the initialization and configuration of the
  network elements, e.g., routers, bridges and the
  installation and configuration of supporting
  software on all computer systems.
• If existing profiles are used, ensure they are
  adhered to. If the need for new profiles has
  been identified, document the necessary
  information.

23
Step 5 - Plan, integrate, and test federation

• 5.2 - Integrate federation
• The purpose of this activity is to bring all of
  the federation participants into a unifying
  operating environment. This requires that all
  federate hardware and software assets are
  properly installed and interconnected in a
  configuration that can satisfy all FOM data
  interchange requirements and federation
  agreements.
• Integrate existing systems/simulations via
  existing and/or new profiles.

24
Step 7 - Analyze data and evaluate results

• 7.2 - Evaluate and feedback results
• The purpose of this activity is to determine if
  federation objectives have been met and to
  archive reusable federation products.
• Simulation/system developers update profiles as
  necessary.
• the derived results from the previous activity
  are evaluated to determine if all federation
  objectives have been met.
• Simulation/system users provide feedback on
  usability of simulations/systems to simulation/
  system developers.

25
Overlay Summary
Existing profiles and the profile standard may be
affected by activities 4.3 and 7.2.
The FEDEP process is outside the profile process,
but the profiles are applied in 3.1, 3.2, 4.2,
4.4, and 5.2.
26
Profile Mapping to FEDEP
Prior federation decisions
Profiles of candidate federates
Database design information
Algorithms
Capability and functionality documentation
Infrastructure design information
Web server and service requirements
Security requirements and capabilities
Time management capabilities
Updates /extensions to existing profiles
Deficiencies in the profile standard
Execute Federation and Prepare Outputs 6
Analyze Data and Evaluate Results 7
Updated profile standard
Updated profiles
Corrective Actions / Iterative Development
27
Survey of Profiles from Other Domains

• Curt Blais
• Naval Postgraduate School, Introduction to XML,
  1st Quarter 2005

28
VoiceXML, MathML, and CSS

• VoiceXML
• Profiles differentiate implementations for
  platforms, e.g. phones and PDAs
• MathML
• Describes a subset mechanism for the use of XHTML
  MathML SVG in one XML document
• The modularization of SVG 1.1 allows profiles to
  be described by listing the SVG modules they
  allow and possibly a small number of restrictions
  or extensions on the elements provided by those
  modules
• The full profile of SVG 1.1 is the collection of
  all the complete modules listed in this
  specification
• Cascading Style Sheets
• Supports media-specific style sheets so that
  authors may tailor the presentation of their
  documents to visual browsers, aural devices,
  printers, Braille devices, handheld devices, etc.
• It also supports content positioning, table
  layout, features for internationalization and
  some properties related to user interface

29
WS-I and XHTML

• Web Services - Interoperability (WS-I) Basic
  Profile, Simple Soap Binding Profile and
  Attachments Profile
• A set of named Web services specifications at
  specific revision levels, together with a set of
  implementation and interoperability guidelines
  recommending how the specifications may be used
  to develop interoperable Web services
• Allows developers to write applications with
  reasonable granularity to the intended task
• XHTML
• XHTML Mobile Profile Document Type provides an
  authoring language based on XHTML that addresses
  the special requirements of web clients operating
  on resource constrained devices such as mobile
• XHTML Mobile Profile is a strict subset of XHTML
• Extends XHTML Basic to bring enhanced
  functionality application authors, including
  additional presentation elements and support for
  internal style sheets

30
X3D, Security

• X3D
• Profiles are used to create sets of capabilities,
  from very limited minimal visualization that may
  be suitable for small devices such as cell phones
  and PDAs, to full graphical capabilities allowing
  high quality interactive and dynamic animations
• Core
• Interchange
• Interactive
• MPEG-4 Interactive
• Immersive
• Full
• Security (W3C, OASIS, WS-I)
• Profile is a named group of Web services
  specifications at specific version levels, along
  with conventions about how they work together

31
SCORM, SVG

• SCORM
• Application profiles describe the integration of
  the IMS Learning Resource Meta-data Version 1.2
  specification within the ADL environment
• Further define the types of meta-data and how
  they are applied to the content aggregation model
• SCORM Content Aggregation Package Application
  Profile defines a mechanism for packaging
  learning resources
• SVG
• Scalable Vector Graphics is a modularized
  language for describing two-dimensional vector
  and mixed vector/raster graphics in XML
• SVG Mobile Profiles SVG Basic and SVG Tiny are
  targetted to resource-limited devices and are
  part of the 3GPP platform for third generation
  mobile phones

32
RSS, WebCGM

• RDF Site Summary (RSS)
• A set of XML specifications used to provide
  summaries of web sites allowing web applications
  to do automatic checks for the latest updates
• Profiles describe varying levels of information
  provided
• Core
• Basic
• Weblog
• WebCGM (Computer Graphics Metafile)
• Single profile broken down into graphical and
  non-graphical elements

33
GML and SMIL

• Geotech-XML (GML)
• An XML encoding for the transport and storage of
  geographic information, including both the
  spatial and non-spatial properties of geographic
  features
• A profile of GML is a restriction of the basic
  GML descriptive capability
• Synchronized Multimedia Integration Language
  (SMIL)
• W3C language that enables simple authoring of
  interactive audiovisual presentations, typically
  used for "rich media"/multimedia presentations
  that integrate streaming audio and video with
  images, text or any other media type
• Language Profile is broken up into ten functional
  areas
• Timing
• Time Manipulations
• Animation
• Content Control
• Layout
• Linking
• Media Objects
• Metainformation
• Structure
• Transitions

34
XForms

• XForms
• An XML application that represents the next
  generation of forms for the Web the successor to
  HTML forms
• Profiles are used to offer a tradeoff between
  language functionality and the computing
  performance of the host platform
• Basic
• Full

35
Profile Survey Summary and Findings

• Almost all surveyed uses of profiles describe
  subsetting of capabilities for the given
  technology
• XMSF profiles will have to describe multiple
  technologies, not just subsets of an individual
  technology
• However, subsetting may be relevant to some of
  the technologies XMSF profiles have to describe,
  so the profile standard should allow for
  subsetting of a given profile

36
Candidate Exemplars

• WERTI (Web Enabled RTI)
• WSIM (Web Services Interest Management)
• XML Schema Based Binary Compression (XSBC)
• Autonomous Underwater Vehicle (AUV) Workbench
• NSS/CombatXXI web service interface (maybe)
• C2IEDM Data Mediation Service prototype (check
  with VMASC)
• Extensible Battle Management Language (XBML)

37
Documentation Mechanisms

• Katherine L. Morse

38
Documentation Technologies Under Consideration

• XML (obviously)
• Including our own schema for encapsulating
  references to other standards
• Including other namespaces
• Web Services Description Language
• UML
• And XMI for embedding it in the XML
• See following slides for examples of applicable
  diagrams
• Sequence
• Use case
• State machine
• Activity
• Timing
• Class
• Deployment
• RDF and /or OWL
• DocBook
• BPEL4WS

39
Sequence Diagrams

• Captures the behavior of a single scenario shows
  a number of example objects and the messages that
  are passed between these objects within a use
  case
• Good for representing expected/necessary
  interaction between services, e.g. protocol
  representation
• May be used to represent DoDAF OV-6c, SV-5, SV-6,
  and SV-10c

40
Sequence Diagram Example- Role Based Access
Control
VAC1viewer access control
access control server
VV1viewer visualization
WS IM server
User1user
Token for requested authorized role
present list of roles
choose role
role request(token)
verify (token)
authorization
authorization
cache session credential
41
Use Cases

• Describe typical interactions between the users
  of a system and the system itself
• Are these too high level?
• May be used to represent DoDAF OV-5 and SV-4

42
Use Case Example- Exercise Viewer
Issue Commands
View Terrain
Exercise Manager
Trainee
ltltincludegtgt
Change Database
Execute Commands
Change View
ltltincludegtgt
View Entities
Control Entities
Pucker
Observer
43
State Machine Diagrams

• Show the lifetime behavior of a single object
• This would only be applicable to stateful
  services
• May be used to represent DoDAF OV-6b and SV-10b

44
State Machine Diagram Example - HLA Services
Request Attribute Value Update
Wait/Process Other Events
Reflect Attribute Value Update
Validate Desired Result
45
Activity Diagrams

• Describe procedural logic, business process, and
  work flow
• Look a lot like flowcharts
• Better represented by BPEL4WS?
• May be used to represent DoDAF OV-5

46
Activity Diagram Example -Exercise Viewer
Initialization
Launch viewer applet
Retrieve users allowable roles
Retrieve Unit Order of Battle database
Retrieve initial terrain
Launch GUI
Allow user to select interest expression
47
Timing Diagrams

• Focus on timing constraints for a single object
  or a group of objects
• Could be useful for representing time sensitive
  services, e.g. ones that have timeouts
• Example - dead reckoning

gt1 min.
dead reckon
Client
Known
Unknown
loss of connectivity
Current
Server
Online
update
Offline
48
Class Diagrams

• Describe the types of objects in the system and
  the various kinds of static relationships that
  exist among them represents object methods,
  state, inheritance and associations
• Possibly better represented in XMSF by WSDL?
• Or do we need both for different purposes
• Port notation may be useful
• May be used to represent DoDAF OV-7, SV-4, and
  SV-11

49
Class Diagram Example - WMD Service
HPAC Web Service
1
0
getWeatherRequest
IWMDT Service getWeather
NOAA Weather Web Service
Terrain Web Service
0
1..
0
1
getWeatherResponse
0
1..
ESRI Map Web Service
50
WSDL Associated with Class Diagram Example

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltwsdldefinitions targetNamespace"..."gt
• ...
• ltwsdlmessage name"getWeatherRequest"gt
• ltwsdlpart name"in0" type"xsdstring"/gt
• lt/wsdlmessagegt
• ...
• ltwsdlportType name"IWMDT"gt
• ...
• ltwsdloperation name"getWeather"
  parameterOrder"in0"gt
• ltwsdlinput message"implgetWeatherReque
  st" name"getWeatherRequest"/gt
• ltwsdloutput message"implgetWeatherResp
  onse" name"getWeatherResponse"/gt
• ltwsdlfault message"implHPACException"
  name"HPACException"/gt
• lt/wsdloperationgt
• ...
• lt/wsdlportTypegt
• ...
• lt/wsdldefinitionsgt

51
Deployment Diagrams

• Show a systems physical layout
• Which pieces of software run on what pieces of
  hardware
• Maybe not for hardware and OS, but for
  representing physical distribution of services
• May be used to represent DoDAF SV-1

52
Deployment Diagram Example -- C2 Viewer with RBAC
Viewer Client
Access Control Server OSLinux
SOAP/http/Internet
C2IML/SOAP/http/Internet
SOAP/http/Internet
WSIM Server OSLinux
Simulation Gateway Server OSWindows
C2IML/SOAP/http/Internet
53
www.xmsf.org
54
WE RTI Profile Prototype

• See 05F-SIW-093 by
• Ryan P.Z. Brunton