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

1. Simulation InteroperabilityStandards Organization XMSF Profile SG Final Report05F-SIW-0132005 Fall SIWSubmitted by:Katherine L. Morse, PhD

2. WAN XMSF Visualization Layer using SOFVIZ Data Storage Layer Terrain & UOB I/F Common Client Side Web I/F Client Platform Server Platform Dynamically Updated Entity Status XML Control Messages Client Federate RTI Terrain & UOB Initialization Data <unit> <pos>32UCD4314311</pos> <type>tank</type> <side>red</side> </unit> RTI Ambassador Stub & Remote Federate Ambassador Federate Ambassador Stub & Remote RTI Ambassador Federate or Federation 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 Terrain Server BEEP Communications BEEP Communications 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 (M&S) 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 Survey profiles from other domains Develop definition and objectives Develop conops and roles and responsibilities 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 couldn’t 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 • M&S 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 M&S and in related domains • Provide the necessary metadata to facilitate composability and reuse of components across multiple M&S 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. Simulation/System Users Profile Community/Working Group + Provide feedback on usefulness and ease of use simulations/systems + Identify new simulations/systems requirements + Develop profile standard + Update profile standard based on experience of simulation/system developers + Make recommendations to Profile Certifying Authority about certification processes and metrics Feedback on profile accuracy Profile Managers Implementation Certification Agents + Negotiate alignment of profiles where there is a mismatch of nomenclature or functional overlap - Identify missing capabilities + Certify that a capability implementation is consistent with a profile 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 + V&V 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 lower–level processes operate within the broader end-to-end federation development process • VV&A • 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 federate’s 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. Prior federation decisions Define Federation Objectives 1 Perform Conceptual Analysis 2 Design Federation 3 Develop Federation 4 Plan, Integrate, and Test Federation 5 Profile Mapping to FEDEP 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 profiles Updated profile standard 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 VAC1:viewer access control :access control server VV1:viewer visualization :WS IM server User1:user 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 <<include>> Execute Commands Change Database Change View <<include>> 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 initial terrain Retrieve user’s allowable roles Retrieve Unit Order of Battle database 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 {>1 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 NOAA Weather Web Service IWMDT Service +getWeather Terrain Web Service 1..* 0 0 1 getWeatherResponse 0 1..* ESRI Map Web Service

50. WSDL Associated with Class Diagram Example <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="..."> ... <wsdl:message name="getWeatherRequest"> <wsdl:part name="in0" type="xsd:string"/> </wsdl:message> ... <wsdl:portType name="IWMDT"> ... <wsdl:operation name="getWeather" parameterOrder="in0"> <wsdl:input message="impl:getWeatherRequest" name="getWeatherRequest"/> <wsdl:output message="impl:getWeatherResponse" name="getWeatherResponse"/> <wsdl:fault message="impl:HPACException" name="HPACException"/> </wsdl:operation> ... </wsdl:portType> ... </wsdl:definitions>