Web and XML considerations 3.1 Overview The ambitious nature of the many requirements and challenges of defense M&s requires aggressive reliance on standardized, openly available, legally unencumbered, commercially available technologies. Sufficient support for DoD M&s needs will require active engagement with standards development groups such as Institute of Electrical and Electronics Engineers (IEEE) Internet Engineering Task Force(IETF), International Standards Organization(ISO), Organization for Advancement of Structured Information Standards(OASIS), the Simulation Interoperability Standards Organization(SISO), the World Wide Web Consortium(W3C), and the Web3D Consortium cross-platform capabilities are essenti Public scientific and international needs for M&S means that The diversity of defense, government ial. No single operating system or monolithic hardware architecture can possibly be forced upon so many existing and legacy systems. Cross-platform data interoperability is critically important when considering the plethora of customized tactical systems connecting to worldwide tactical networks A particular strength of an XMSF approach based on web technologies is that the most difficult interoperability challenges are already resolved (or else are being solved)by the development of tightly interdependent and highly complementary Web standards. The w3C and the IETF are the leading drivers in these efforts. Thus it appears that this web-technology strategy for XMSF can provide the most technically robust solutions, with the most reliable future-growth processes and best-case business practices. This is particularly important when viewed from an enterprise-wide (i.e. DoD-wide and coalition-wide) perspective To meet these larger requirements, XMSF systems will employ object-oriented paradigms and validatable structured data in a language-independent and object-system-independent manner Design patterns will unambiguously define programming-language bindings by mapping representations and component models from root XML schemas to multiple programming languages and application programming interface(API) bindings. The Interface Description Language(IDL) provides further good capabilities in this area. Software component functionality and interactions will be further documented using the Unified Modeling Language(UML) XMSF will have a modular framework, with kernel plug-ins to support extensions and modifications to framework layers as low as the network layer. Design patterns for modular tensibility are needed at all levels and across system lifecycles, in order to support future growth and backwards compatibility as well as multiple-system interoperability To support real-world military secure communications systems, XMSF must be compatible with currently fielded wireless, radio and wire military technologies to include data/voice Single Channel Ground and Airborne Radio System(SINCGARS), Ultra High Frequency (UHF)Very Higl Frequency(vhf)radios and Digital Subscriber Network(DSN). Diverse network channels and transport mechanisms will thus drive some application-level design decisions when applying various web technologies 3.2 Functional Requirements Many of the functional requirements described below overlap, complement or build on one another The crux of these requirements is that they are considered the key properties that a framework must have in order for it to be platform-independent, flexible, extensible, secure, distributed and dynamically reconfigurable XMSF Workshop Symposium Report, October 2002 page 12
XMSF Workshop & Symposium Report, October 2002 page 12 3 Web and XML Considerations 3.1 Overview The ambitious nature of the many requirements and challenges of defense M&S requires aggressive reliance on standardized, openly available, legally unencumbered, commercially available technologies. Sufficient support for DoD M&S needs will require active engagement with standards development groups such as Institute of Electrical and Electronics Engineers (IEEE), Internet Engineering Task Force (IETF), International Standards Organization (ISO), Organization for Advancement of Structured Information Standards (OASIS), the Simulation Interoperability Standards Organization (SISO), the World Wide Web Consortium (W3C), and the Web3D Consortium. The diversity of defense, government, public, scientific and international needs for M&S means that cross-platform capabilities are essential. No single operating system or monolithic hardware architecture can possibly be forced upon so many existing and legacy systems. Cross-platform data interoperability is critically important when considering the plethora of customized tactical systems connecting to worldwide tactical networks. A particular strength of an XMSF approach based on web technologies is that the most difficult interoperability challenges are already resolved (or else are being solved) by the development of tightly interdependent and highly complementary Web standards. The W3C and the IETF are the leading drivers in these efforts. Thus it appears that this web-technology strategy for XMSF can provide the most technically robust solutions, with the most reliable future-growth processes and best-case business practices. This is particularly important when viewed from an enterprise-wide (i.e. DoD-wide and coalition-wide) perspective. To meet these larger requirements, XMSF systems will employ object-oriented paradigms and validatable structured data in a language-independent and object-system-independent manner. Design patterns will unambiguously define programming-language bindings by mapping representations and component models from root XML schemas to multiple programming languages and application programming interface (API) bindings. The Interface Description Language (IDL) provides further good capabilities in this area. Software component functionality and interactions will be further documented using the Unified Modeling Language (UML). XMSF will have a modular framework, with kernel plug-ins to support extensions and modifications to framework layers as low as the network layer. Design patterns for modular extensibility are needed at all levels and across system lifecycles, in order to support future growth and backwards compatibility as well as multiple-system interoperability. To support real-world military secure communications systems, XMSF must be compatible with currently fielded wireless, radio and wire military technologies to include data/voice Single Channel Ground and Airborne Radio System (SINCGARS), Ultra High Frequency (UHF)/Very High Frequency (VHF) radios and Digital Subscriber Network (DSN). Diverse network channels and transport mechanisms will thus drive some application-level design decisions when applying various web technologies. 3.2 Functional Requirements Many of the functional requirements described below overlap, complement or build on one another. The crux of these requirements is that they are considered the key properties that a framework must have in order for it to be platform-independent, flexible, extensible, secure, distributed and dynamically reconfigurable
a. Data Representations Data is defined as any information of interest that is to be exchanged between two systems. XMSF will need to be able to represent exchangeable data in a language-independent manner. For troubleshooting and confidence, data must be readable both by humans and by a complete variety of computer languages, e.g. Ada, C++, Java, Perl, Prolog, etc. Such data interchange is typically addressed by using structured text-based standards The logical implication of data being machine-readable is that the data representation will need to be structured and self-defining. For future capabilities, most data representations need to allow for facile extension of the represented data Given the verbose nature of most text-based representations, data representations will also need to support compression schemes, applicable both to documents and streams equally. Default(i.e.run- time replaceable)compression algorithms must be offered, probably as a code component. Of particular note is that compression is closely interrelated to encryption, authentication, composition key management, and completeness of delivery The current state of standards evolution already accounts well for most of these requirements XML is the preferred structured-data standard for platform-independent representation that, when carefully applied, can meet most of these requirements b. Security Considerations KMSF security will encompass identification, authentication, authorization and encryption Functional access restrictions(e. g. role-based permissions )are considered to be the responsibility of It is desirable for a framework such as the XMSF to offer utilities(probably through a code component) that include one or more default encryption algorithms. This can allow applications to interact in a commonly acceptable way if they do not need a specific encryption implementation The framework must also select a standard for signing messages and documents. The existing XML Digital Signature(DS)specification(RFCs 3076 and 3275)is a likely candidate. The signature itself does not provide authentication, but rather associates an identity with data Developments of related interest include industry efforts such as the liberty alliance project (http://www.proiectliberty.organdPassport(http://www.passport.com) Following on from identification the framework must define standards for authentication. As is the case for encryption, it appears preferable that a pre-existing mechanism(outside applications) be made available to provide authentication services. This might be implemented via authentication A requirement that follows from the nature of dynamic reconfiguration is that there needs to be a mechanism for defining groups and group membership. Additionally, the membership of those groups needs to be dynamic. a further consideration is that the groups must be definable in such a way as to apply to either a single service, or span multiple services(as in the case of a distributed multi-application simulation) The increasing focus on security means that XMSF must be underpinned by the strongest and most current web security technologies. These are additional capabilities that can augment military-grade security for classified, unclassified and administrative networked systems. Security is cross-cutting issue that must work sufficiently and simultaneously across all three areas(Web/XML, Internet/networking and M&s)or new vulnerabilities will result XMSF Workshop Symposium Report, October 2002 page 13
XMSF Workshop & Symposium Report, October 2002 page 13 a. Data Representations Data is defined as any information of interest that is to be exchanged between two systems. XMSF will need to be able to represent exchangeable data in a language-independent manner. For troubleshooting and confidence, data must be readable both by humans and by a complete variety of computer languages, e.g. Ada, C++, Java, Perl, Prolog, etc. Such data interchange is typically addressed by using structured text-based standards. The logical implication of data being machine-readable is that the data representation will need to be structured and self-defining. For future capabilities, most data representations need to allow for facile extension of the represented data. Given the verbose nature of most text-based representations, data representations will also need to support compression schemes, applicable both to documents and streams equally. Default (i.e. runtime replaceable) compression algorithms must be offered, probably as a code component. Of particular note is that compression is closely interrelated to encryption, authentication, composition, key management, and completeness of delivery. The current state of standards evolution already accounts well for most of these requirements. XML is the preferred structured-data standard for platform-independent representation that, when carefully applied, can meet most of these requirements. b. Security Considerations XMSF security will encompass identification, authentication, authorization and encryption. Functional access restrictions (e.g. role-based permissions) are considered to be the responsibility of the application, or the application environment. It is desirable for a framework such as the XMSF to offer utilities (probably through a code component) that include one or more default encryption algorithms. This can allow applications to interact in a commonly acceptable way if they do not need a specific encryption implementation. The framework must also select a standard for signing messages and documents. The existing XML Digital Signature (DS) specification (RFCs 3076 and 3275) is a likely candidate. The signature itself does not provide authentication, but rather associates an identity with data. Developments of related interest include industry efforts such as the Liberty Alliance project (http://www.projectliberty.org) and Passport (http://www.passport.com). Following on from identification, the framework must define standards for authentication. As is the case for encryption, it appears preferable that a pre-existing mechanism (outside applications) be made available to provide authentication services. This might be implemented via authentication servers. A requirement that follows from the nature of dynamic reconfiguration is that there needs to be a mechanism for defining groups and group membership. Additionally, the membership of those groups needs to be dynamic. A further consideration is that the groups must be definable in such a way as to apply to either a single service, or span multiple services (as in the case of a distributed multi-application simulation). The increasing focus on security means that XMSF must be underpinned by the strongest and most current web security technologies. These are additional capabilities that can augment military-grade security for classified, unclassified and administrative networked systems. Security is cross-cutting issue that must work sufficiently and simultaneously across all three areas (Web/XML, Internet/networking and M&S) or new vulnerabilities will result
Classified information security systems remain responsible for meeting military security requirements. Web-based content does not replace or jeopardize any of those existing, externally controlled techniques C. Service Descriptions and Bindings Web services typically include a logically coherent set of functions offered for discovery and remote invocation across the internet by a code component. a code component may use many such services The functionality offered by a code component will need to be represented in a language independent manner. This means that for the various programming languages of interest(e.g C++, Java, Fortran, etc. )used to develop the code component, and for the platforms on which the code is deployed, common-denominator representations of the exposed functions and the parameters of those functions(i.e. the interface)will need to be represented consistently. Thus the service description needs to be binding independent. The corollary of that implication is that the service description needs to employ a common binding specification If the underlying mechanism employed for defining APi binding mechanisms is the same as for data representation(e.g. XML), then many of the issues relating to platform independence are resolved d. Graphical User Interface(GUl) Descriptions A Graphical User Interface(GUI)is defined as a man-machine interface of a graphical(as opposed to a textual) nature. Typically these are things like windows, toolbars and dialogs, but 3D virtual environments are also encompassed elements in a computer-independent (language and platform)manner. Further, the e er interface In a similar manner to Service Descriptions, a GuI description will need to represent use will need to define not only the appearance of graphical elements, but also their behavior. In this case behavior is the components response to user stimulus The aim of a GuI description is to define a consistent look and feel across operating systems e. State-Transition Description State transition is defined as the progression of a system through a set of logical states. In effect this can translate to allowable sequences of messages. Some simulation applications may need to share state- transition definitions in order to effectively model certain shared processes Since state transitions deal with the logical domain rather than the physical domain, there are fewer issues of representation. If a workflow representation is simply exchangable between systems, then it suffices to use a computer-independent data representation to address platform independence issues. All that then remains is for syntax to be developed for the workflow representation One interesting requirement is that even though a set of logical state transitions may be published these do not necessarily reveal the actual internal logic (or internal state transitions )of the implementing code component. Published state transitions are the basis for functional interoperability among participating entities, and may be a critical subset of the actual state transitions in each system XMSF Workshop Symposium Report, October 2002 page 14
XMSF Workshop & Symposium Report, October 2002 page 14 Classified information security systems remain responsible for meeting military security requirements. Web-based content does not replace or jeopardize any of those existing, externally controlled techniques. c. Service Descriptions and Bindings Web services typically include a logically coherent set of functions offered for discovery and remote invocation across the internet by a code component. A code component may use many such services. The functionality offered by a code component will need to be represented in a languageindependent manner. This means that for the various programming languages of interest (e.g. C++, Java, Fortran, etc.) used to develop the code component, and for the platforms on which the code is deployed, common-denominator representations of the exposed functions and the parameters of those functions (i.e. the interface) will need to be represented consistently. Thus the service description needs to be binding independent. The corollary of that implication is that the service description needs to employ a common binding specification. If the underlying mechanism employed for defining API binding mechanisms is the same as for data representation (e.g. XML), then many of the issues relating to platform independence are resolved. d. Graphical User Interface (GUI) Descriptions A Graphical User Interface (GUI) is defined as a man-machine interface of a graphical (as opposed to a textual) nature. Typically these are things like windows, toolbars and dialogs, but 3D virtual environments are also encompassed. In a similar manner to Service Descriptions, a GUI description will need to represent user interface elements in a computer-independent (language and platform) manner. Further, the GUI description will need to define not only the appearance of graphical elements, but also their behavior. In this case behavior is the component’s response to user stimulus. The aim of a GUI description is to define a consistent look and feel across operating systems. e. State-Transition Description State transition is defined as the progression of a system through a set of logical states. In effect this can translate to allowable sequences of messages. Some simulation applications may need to share state-transition definitions in order to effectively model certain shared processes. Since state transitions deal with the logical domain rather than the physical domain, there are fewer issues of representation. If a workflow representation is simply exchangable between systems, then it suffices to use a computer-independent data representation to address platform independence issues. All that then remains is for syntax to be developed for the workflow representation. One interesting requirement is that even though a set of logical state transitions may be published, these do not necessarily reveal the actual internal logic (or internal state transitions) of the implementing code component. Published state transitions are the basis for functional interoperability among participating entities, and may be a critical subset of the actual state transitions in each system
f Transactions a transaction is defined as a logical set of changes that must be made as a single activity, e.g.a funds transfer from one account to another must both debit the source account and also credit the destination account, all as a single atomic action A common pattern for such transactions is a 2-phase commit procedure. Unfortunately, this approach can suffer from latency and heavy resource utilization when implemented across the Internet An alternative approach to 2-phase committal is that of adding undo operations to individual atomic actions. The idea is that certain(simpler)actions can be reversed by another action, e.g. the request to be added to a mailing list can be undone by a request to be removed from the mailing list A requirement for the M&s framework is that a transaction pattern(that may encompass more than one application paradigm) needs to be defined and supported. Supported approaches need to allow for both simple request-response situations that do not require the overhead of a 2-phase commit, and also more complex situations that do require more sophisticated 2-phase commit procedures g. Ontologies An ontology is defined as a basis of meaning. This is a fundamentally difficult area that has seen much research progress in recent few years as part of the w3C's Semantic Web The first requirement in the area of ontologies is to allow definition and approval of complementary taxonomies that can be applied across multiple XMsf application domains. This will allow for the consistent classification of data and services via precise vocabularies. XML Schema and XML Namespaces are the primary mechanisms for defining and referring to such vocabularies A subsequent requirement is to establish consensual common meaning. It does not suffice for there to be agreed meaning within a group but to be truly useful, there needs to be a mechanism for defining the equivalence of terms between groups. This will allow for both extensibility and for interoperability. XML Schema annotations and XML Internationalization(118N/XML Localization(lloN) provide the mechanisms for recording and translating accepted meanings in a reviewable fashion An open issue is the establishment of XML schema and ontology repositories for common service representations. The following semantic representations are expected to be of particular interest Resource Description Framework(RDF) DARPA Agent Modeling Language(DAML) and Ontology Integration Language(OIL) NATO-developed Generic Hub information-exchange data model for tactical operations It will be particularly interesting to consider the implications of ontologies like Generic Hub that help to establish commonalities between services and coalition partners. Development of effective ontologies for military operations orders(which contain tactical versions of who, what, when where and how) is a strategically important application area deserving dedicated further work XMSF Workshop Symposium Report, October 2002 page 15
XMSF Workshop & Symposium Report, October 2002 page 15 f. Transactions A transaction is defined as a logical set of changes that must be made as a single activity, e.g. a funds transfer from one account to another must both debit the source account and also credit the destination account, all as a single atomic action. A common pattern for such transactions is a 2-phase commit procedure. Unfortunately, this approach can suffer from latency and heavy resource utilization when implemented across the Internet. An alternative approach to 2-phase committal is that of adding undo operations to individual atomic actions. The idea is that certain (simpler) actions can be reversed by another action, e.g. the request to be added to a mailing list can be undone by a request to be removed from the mailing list. A requirement for the M&S framework is that a transaction pattern (that may encompass more than one application paradigm) needs to be defined and supported. Supported approaches need to allow for both simple request-response situations that do not require the overhead of a 2-phase commit, and also more complex situations that do require more sophisticated 2-phase commit procedures. g. Ontologies An ontology is defined as a basis of meaning. This is a fundamentally difficult area that has seen much research progress in recent few years as part of the W3C’s Semantic Web. The first requirement in the area of ontologies is to allow definition and approval of complementary taxonomies that can be applied across multiple XMSF application domains. This will allow for the consistent classification of data and services via precise vocabularies. XML Schema and XML Namespaces are the primary mechanisms for defining and referring to such vocabularies. A subsequent requirement is to establish consensual common meaning. It does not suffice for there to be agreed meaning within a group, but to be truly useful, there needs to be a mechanism for defining the equivalence of terms between groups. This will allow for both extensibility and for interoperability. XML Schema annotations and XML Internationalization (I18N) / XML Localization (L10N) provide the mechanisms for recording and translating accepted meanings in a reviewable fashion. An open issue is the establishment of XML schema and ontology repositories for common service representations. The following semantic representations are expected to be of particular interest. · Resource Description Framework (RDF) · DARPA Agent Modeling Language (DAML) and Ontology Integration Language (OIL) · NATO-developed Generic Hub information-exchange data model for tactical operations It will be particularly interesting to consider the implications of ontologies like Generic Hub that help to establish commonalities between services and coalition partners. Development of effective ontologies for military operations orders (which contain tactical versions of who, what, when, where and how) is a strategically important application area deserving dedicated further work
Monitories A repository is defined as a logically related collection of information, accessible through a common point of reference. XMSF applications will need numerous repositories across different levels of abstraction, presumably exposed via Web Services. Work is needed to identify potential libraries of components that can be made available to support reusability, encourage interoperability, and reduce user learning curves. Example application-level repositories are likely to include Portable computational models, such as physics of entity and sensor interactions Software-agent templates with requested capabilities Stream-specific adaptors/components Exercise simulation management Operational recording of simulated or actual interactions Order of battle(inventories and functional characteristics of friendly and opposing forces) It appears likely that each logical level of a"XMSF stack"(probably corresponding to ar augmented Web Services stack) may have one or more associated repositories. For the purposes of this report, the requirement for repositories will be assumed to be an implicit requirement for each of the preceding areas discussed a shared requirement necessary for the effective use of repositories is that common interfaces are defined to allow consistent access to contained information by search engines and other interested applications. Universal Description, Discovery and Integration(UDDI) fulfills this need for Web Services, and may be sufficient for XMSF. Registry functionality is intrinsic to the usefulness and growth capabilities of repositories i. Search Engines A search engine is defined as a code component that extracts information matching a specified set of criteria from one or more repositories One of the great challenges of the Internet is locating information. In order for XMSF to not fall prey to the same shortcomings it is important to provide sufficient support for capable search The areas discussed in preceding sections are a good starting point for search topics in the various repositories. Hence common search criteria will likely include topics such as Provider, Type of Service, Name, Quality of Service(QoS), Security and other constraints. It is likely that typical e-commerce web-service descriptions will need to be augmented to fully describe needed functionality pertaining to distributed M&S applications XMSF Workshop Symposium Report, October 2002 page 16
XMSF Workshop & Symposium Report, October 2002 page 16 h. Repositories A repository is defined as a logically related collection of information, accessible through a common point of reference. XMSF applications will need numerous repositories across different levels of abstraction, presumably exposed via Web Services. Work is needed to identify potential libraries of components that can be made available to support reusability, encourage interoperability, and reduce user learning curves. Example application-level repositories are likely to include: · 3D models · Portable computational models, such as physics of entity and sensor interactions · Software-agent templates with requested capabilities · Stream-specific adaptors/components · Exercise simulation management · Operational recording of simulated or actual interactions · Order of battle (inventories and functional characteristics of friendly and opposing forces) It appears likely that each logical level of a “XMSF stack” (probably corresponding to an augmented Web Services stack) may have one or more associated repositories. For the purposes of this report, the requirement for repositories will be assumed to be an implicit requirement for each of the preceding areas discussed. A shared requirement necessary for the effective use of repositories is that common interfaces are defined to allow consistent access to contained information by search engines and other interested applications. Universal Description, Discovery and Integration (UDDI) fulfills this need for Web Services, and may be sufficient for XMSF. Registry functionality is intrinsic to the usefulness and growth capabilities of repositories. i. Search Engines A search engine is defined as a code component that extracts information matching a specified set of criteria from one or more repositories. One of the great challenges of the Internet is locating information. In order for XMSF to not fall prey to the same shortcomings it is important to provide sufficient support for capable search engines. The areas discussed in preceding sections are a good starting point for search topics in the various repositories. Hence common search criteria will likely include topics such as Provider, Type of Service, Name, Quality of Service (QoS), Security and other constraints. It is likely that typical e-commerce web-service descriptions will need to be augmented to fully describe needed functionality pertaining to distributed M&S applications