XMSF Profile Study Group Fall 2004 Meeting

1
XMSF Profile Study GroupFall 2004 Meeting

• 23 September 2004
• (Updated 4 October 2004)
• Dr. Katherine L. Morse, SAIC
• Chair
• morsek_at_saic.com

2
Agenda

• 0800-0830 Status Review
• 0830-0845 Assignment of other profile
  definitions for review
• 0845 -1000 Conops Review
• 1000-1030 Break
• 1030-1100 XMSF Specific Requirements
• 1100-1200 Invited Presentations
• Navy Schema Blais
• IDEF Scrudder
• FEDEP Overlay Lutz
• 1200-1330 Lunch
• 1330-1430 Invited Presentations
• UML Examples Gustavson, Morse
• Economics of MS Waite
• 1430-1500 Wrap Up/Action Item Review

Need to make a workable action plan today to
finish items in red.
3
Status Review
4
Process Schedule
5
Continuing SG Status

• Our original TOR planned for us to complete by
  March 2005
• Do we ask SAC for an extension?
• Do we develop a product nomination (PN) to become
  a PDG since were planning to produce a profile
  standard?

6
Assignment of Other Profile Definitions for Review
7
ISO Standards Using Profiles(Most Require
Purchase Does Anyone Have Access to Any of
These?)

• 19774 Extensible 3D Graphics - someone offered
  that they had access to this one
• 9646 Open Systems Interconnection
• Many standards under OSI
• 10608 Connection-mode Transport Service over
  Connectionless-mode Network Service
• 10609 Connection-mode Transport Service over
  connection-mode Network Service
• 10611 Message Handling Systems -- Common
  Messaging
• 10612 Relaying the MAC service using transparent
  bridging
• 10613 Relaying the Connectionless-mode Network
  Service
• 10614 X.25 protocol relaying
• 11188 Common upper layer requirements
• 12067 Relaying the connection-mode Network
  Service
• 12069 Document Filing and Retrieval (DFR)
• 12071 Computer Graphics Metafile interchange
  format
• 14496 MPEG
• 15292 Security techniques

8
W3C Profiles

• XHTML (Extensible HTML)
• SMIL (Synchronized Multimedia Integration
  Language)
• XHTMLSMIL
• Cascading Style Sheets Level 2 for mobile devices
• Scaleable Vector Graphics (SVG)
• XHTML MathML SVG
• WebCGM (Computer Graphics Metafile)
• P3P (Platform for Privacy Preferences) Assurance
  Signature
• And the list goes on

9
European Computer Manufacturers Association
Profile Standards

• 232, 312, 345 Private Integrated Services
  Network (PISN)
• 327 ECMAScript (Javascript) 3rd Edition Compact
  Profile

10
Action Plan for Completion

• Have telecons every 2 weeks starting after WebSim
• Scott Holben to brief IETF RFC 3261 Session
  Initiation Protocol
• Andreas Tolk to brief analysis of GES and
  recommendations for the MS COI

11
Conops Review
12
Profile Conops Stakeholders

• Simulation/system users
• Provide feedback on usefulness and ease of use of
  simulation/system (developed in accordance with
  profile(s))
• Identify new simulation/system requirements
• Simulation/system developers
• Develop/integrate new simulations/systems
  consistent with existing profiles
• Identify compositions of 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

13
Profile Conops Stakeholders

• Profile Community/Working Group
• Develop profile standard
• Update profile standard based on experience of
  simulation/system developers
• Make recommendations to Profile Certifying
  Authority about certification processes and
  metrics
• Profile Certifying Authority
• Maintain repository and CM of approved profiles
• Develop certification processes and metrics
• Ensure accuracy and consistency of the profile
  standard as it evolves
• 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

14
Profile Conops Stakeholders

• Profile Managers - advocate for profiles within a
  domain
• Negotiate alignment of profiles where there is a
  mismatch of nomenclature or functional overlap
• Identify alternative implementations of
  capabilities
• Identify aggregate related dependencies
• Identify missing capabilities
• Recommend foundations and enhancements to the
  profile standard based on user needs
• Identify existing domain standards
• Migrate domain standards into profile
• Implementation Certification Agents
• Certify that a capability implementation is
  consistent with a profile
• Customer - e.g. SPOs and Program Managers
• Specify the requirement to adhere to specific
  profiles

15
Role Relationships in the Profile Conops
New profiles
Requirement to adhere to profile(s)
Feedback on implementation adherence to profiles
New simulations/systems
New profiles
Feedback on profile relevance
Updated/aligned profiles
New profiles
16
Action Plan for Completion

• Katherine L. Morse to update role relationships
  diagram based on discussion at SG meeting
• Scott Holben to start profile lifecycle
• Both for the profile standard and for the
  profiles themselves

17
Break
18
XMSF Specific Requirements
19
How Do We Decide What to Use?

• Need to determine both content and
  structure/format
• Contents of profiles must support the profile
  definition
• Contents of profiles must support the roles of
  the stakeholders
• Since unambiguous interpretation is our first
  objective, focus on technologies that support
  automated methods
• Searching
• Composability
• Integration

20
Derived Technical Requirements

• Provide unambiguous specification of the
  functionality of components, and interfaces among
  components of the framework
• WSDL
• Use formal specification technologies
• UML
• DoDAF
• Ensure interoperability between existing and new
  web enabled technologies, both within MS and in
  related domains
• Define XML schema for tagging standards
  (protocol, data, metadata) and other profiles
• References to Reference FOMs and BOMs
• References to established metadata standards
  (namespace)
• Identify other interoperability technologies and
  standards
• HLA
• Defense Information Standards Repository (DISR)
  replaces the JTA
• SIP (RFC 3261)

21
Derived Technical Requirements

• Provide the necessary metadata to facilitate
  composability and reuse of components across
  multiple MS application domains
• Work with appropriate DoD namespace managers
• Should we define our own metadata tags to support
  searching?
• As extensions to WSDL to support searching?
• For HLA-compliant simulations, should we try to
  codify federation agreements?
• See recommendations of data/metadata subgroup of
  CMSE workshop, 04S-SIW-050, and the RAND report
• BPEL4WS (04S-SIW-009)
• Facilitate development of new applications and
  services that are functionally interchangeable
  with existing applications and services
• WSDL

22
Derived Technical Requirements

• Enable development of new applications and
  services that readily extend functionality for
  continuous evolution of capabilities
• RDF and/or OWL to describe semantics?

23
Action Plan for Completion

• Resend current state of requirements to the
  reflector
• Fill in large gaps via reflector
• Discuss at next telecon

24
Invited Briefings

• Navy Schema Blais
• IDEF Scrudder
• FEDEP Overlay Lutz

25
XMSF Profile FEDEP Overlay

• Bob Lutz

26
Relationship of Profile Conops to FEDEP
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.

• Step 3 - Design federation
• 3.1 - Select federates
• Use profiles to identify federates
• 3.2 - Prepare federation design
• Evaluate applicability of profiles to federation
  design
• Step 4 - Develop federation
• 4.2 - Establish federation agreements
• Apply existing profiles
• Evaluate requirement for new profiles
• 4.3 Implement federate designs
• Update/extend existing profiles
• 4.4 - Implement federation infrastructure
• Ensure that existing profiles are adhered to
• Document new profiles

Existing profiles and the profile standard may be
affected by activities 4.3 and 7.2.
27
Relationship of Profile Conops to FEDEP

• Step 5 - Plan, integrate, and test federation
• 5.2 - Integrate federation
• Integrate existing systems/simulations via
  existing and/or new profiles
• Step 7 - Analyze data and evaluate results
• 7.2 - Evaluate and feedback results
• Simulation/system users provide feedback on
  usability of simulations/systems to
  simulation/system developers
• Simulation/system developers update profiles as
  necessary

28
Lunch

• Reconvene at 1330

29
Invited Briefings

• UML Examples Gustavson, Morse
• Economics of MS Waite

30
UML Definition

• a family of graphical notations, backed by a
  single meta-model, that help in describing and
  designing software systems, particularly software
  systems built using the OO style. - Martin
  Fowler, UML Distilled much of the material in
  this section is drawn from this excellent
  reference
• The UML development community focuses on the
  metamodel
• How can code be generated from the metamodel?
• Structure
• Users (like this group) tend to focus more on
  graphical notations
• How can we increase our understanding of the
  modeled system through the diagrams?
• Behavior

31
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

32
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
33
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

34
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
35
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

36
State Machine Diagram Example - HLA Services
Request Attribute Value Update
Wait/Process Other Events
Reflect Attribute Value Update
Validate Desired Result
37
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

38
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
39
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
40
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

41
Class Diagram Example - WMD Service
HPAC Web Service
1
0
getWeatherRequest
IWMDT Service getWeather
NOAA Weather Web Service
Terrain Web Service
0
1..
1
0
getWeatherResponse
0
1..
ESRI Map Web Service
42
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

43
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

44
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
45
Topics for the Next Meeting

• WSDL and potential extensions - Morse
• RDF and/or OWL - Blais/Vick
• BPEL4WS - Brunton
• Colored UML and Ontologies - Tolk
• Other profile standards - Blais
• VVML - Park/Broyles
• Service specifications for the GIG - Tolk
• Business case - Payne

• Briefings should
• Provide an overview of the technology
• Identify which of the definition objective(s) the
  technology supports
• Describe how the technology supports the roles of
  the stakeholder(s)
• Sketch a brief example of the technologys
  application to XMSF
• Describe the level of automation enabled by the
  technology
• Identify issues and shortcomings

46
Backup Slides
47
XMSF Overview

• The Extensible Modeling and Simulation Framework
  (XMSF) is defined as a set of Web-based
  technologies and services, applied within an
  extensible framework, that enables a new
  generation of modeling simulation (MS)
  applications to emerge, develop and interoperate.
• 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
• Recommendations and guidelines for implementation

48
SG Terms of Reference

• 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

49
SG Process Activity Diagram
Develop definition and objectives
Develop conops and roles and responsibilities
Survey profiles from other domains
Activities in blue are part of the standard refine
ment loop
Define XMSF- specific requirements
Identify necessary interoperability information
Identify candidate exemplars
content
Identify applicable documentation mechanisms
structure
Draft standard
50
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