Transaction-based Definitions and Implementations of - PDF document

Presentation Title 2/4/09 Transaction-based Definitions and Implementations of Community-of-Interest Languages Dr. Andreas Tolk, Old Dominion University Mr. Saikou Diallo, VMASC Thanks for Sponsored Research  US Joint Forces Command  NATO – XC2I Interface – MSG-027 Pathfinder – X-BML – MSG-048 C-BML – JEDIS / JTDS / JRSG  Industry Partners  US Army Test and Evaluation – IBM Command – Raytheon – Data Management – Accenture – Architecture Studies in support of – TEI Net-centric Testing  Academic Partners  US Army PEO Soldier – MOVES/NPS – Model-based selection, composition, – ARL/UT and orchestration  and many more … Page 2 Speaker Name 1

Presentation Title 2/4/09 Outline  Concepts and Background – Community of Interest (COI) Languages – Model Based Data Engineering  Composites and Transactionals – Data Model Theory – Composites and Transactionals  Application Domains – Standardization – Migration and Implementation  Example: C-BML and JC3IEDM – Implementing BML as JC3IEDM Composites – BML Standard and Composites Page 3 Concepts and Background COI Languages Model Based Data Engineering Speaker Name 2

Presentation Title 2/4/09 Community of Interest (COI)  COI is defined as the collection of people that are concerned with the exchange of information in some subject area Scott A. Renner: A Community of Interest Approach to Data Interoperability. Proceedings Federal Database Colloquium ’01  The community is made up of the – users/operators that actually participate in the information exchange – the system builders that develop computer systems for these users – the functional proponents that define requirements and acquire systems on behalf of the users  Renner stresses the importance of COI data panels and their task to support Common Data Representations (CDR) to be used within the COI for data exchange Page 5 Net Enabled C2 Capability Info Capability Sharing Delivery Need Enables Drives Service Service Needed Implementations Drives Enables Community Data Information Exchange Drives Needed Vocabulary Page 6 Speaker Name 3

Presentation Title 2/4/09 Result of the COI work  Agreement on – Common information sharing need – Data needed for implementing services  Common Data Representation – COI specific – Common Core  Challenge – Unambiguously define the information (logically) – Unambiguously identify the representation in the system (physically) Page 7 Data Challenges for System to System Interoperability  Describe data information exchange – Capture what systems can provide (information exchange capability) – Capture what systems can understand (information exchange need) – Capture what is necessary (information exchange requirement)  Support the unambiguous definition of meaning of data – Syntax, semantics, and pragmatics – Gradually enhance and extend the common core  Enable mediation based on these results – Configurable software layers – Minimize programmers interpretation – Maximize documentation for reuse Page 8 Speaker Name 4

Presentation Title 2/4/09 Model-based Data Engineering  Data Administration – Managing the information exchange needs incl. source, format, context of validity, fidelity, and credibility  Data Management – Planning, organizing and managing of data, define and standardize the meaning of data as of their relations  Data Alignment – Ensuring that data to be exchanged exist in all participating systems  Data Transformation – Technical process of mapping data elements  Model-based Data Engineering – Introducing a Common Reference Model for Data Management to capture Standardized Data Elements and Relations Page 9 Composites and Transactionals Data Model Theory Strong and Weak Composites Transactionals Speaker Name 5

Presentation Title 2/4/09 Data Model Theory  Logical Data Model – Capture the business requirements based on conceptual modeling  Physical Data Model Instance – Generated from the Logical Model – Includes additional physical constraints (keys, etc…)  Physical Data Model – The database  Interoperation happens at the physical level, composition at the logical level. Page 11 Composites and Transactionals Logical Logical Model Model CRM Sys A Sys A Logical Model Physical Model Physical Physical Model Model Sys A Sys A Page 12 Speaker Name 6

Presentation Title 2/4/09 Composites and Transactionals Composites Logical Model Physical Model Transactionals Transactionals Page 13 Composited and Transactionals  Standardization happens on the logical level – CRM captured information to be shared between systems – Common language  Understood by the systems  Spoken by the systems  Implementation happens on the physical level – Transactionals capture the system constraints  Accuracy (int16 versus int32 problems)  Mandatory and optional fields (incl. identifiers)  Business objects Page 14 Speaker Name 7

Presentation Title 2/4/09 Application Domains Definition Migration Definition  Unambiguous definition of terms – Composite in the CRM – All properties that are needed to describe the concept represented by the term – Only those properties needed to describe the concept represented by the term  Key questions – What is logically needed to unambiguously identify the type and the item of a represented term (such as a unit) – What is logically sufficient to unambiguously identify the type and the item of a represented term Page 16 Speaker Name 8

Presentation Title 2/4/09 Migration  Migration means: “Make the system speak the COI language” (such as C-BML) – Logical mapping to the CRM – Identify “transactionals” implementing this mapping – Evaluate differences in scope, resolution, and structure (logically) – Evaluate differences in accuracy and obtainability (physically) Model-based Data Engineering was developed to support this application Page 17 Special Case  If we use an existing CRM – JC3IEDM – C2 Common Core / Universal Core this becomes our logical reference  If we implement the infrastructure based on this CRM – JC3IEDM based web services – C2 Common Core SOA – GIG services using DISA Core Models we also have a physical reference  Mapping still is needed on the logical level, the physical reference (transactionals) just serve as the mapping hub Page 18 Speaker Name 9

Presentation Title 2/4/09 Example: C-BML and JC3IEDM Implementing BML as JC3IEDM Composites BML Standard and Composites Overview Slide courtesy of Kevin Gupton from ARL/UT Page 20 Speaker Name 10

Presentation Title 2/4/09 WHO Slide courtesy of Kevin Gupton from ARL/UT Page 21 WHAT-WHEN Slide courtesy of Kevin Gupton from ARL/UT Page 22 Speaker Name 11

Presentation Title 2/4/09 WHERE Slide courtesy of Kevin Gupton from ARL/UT Page 23 Example: WHO  Logical Composite – C L = {Object_Type, Organisation_Type, Government_Organisation_Type, MilitaryOrganisationType, Unit_Type, Object_Item, Organisation, Unit, Object_Item_Status, Organisation_Status}  Physical Composite – Cp = {Object Item, Organization, Unit}  Reference to Existing Who – ID – Name + Index – Owner Page 24 Speaker Name 12

Presentation Title 2/4/09 Where Example  Where – Logical Composite – Location, Point, Absolute Point, Geographic Point – Specified in the logical schema – Other ways of representing location exist – All composites are explicit in the logical specification  Physical Composite – Latitude, Longitude – Specified in the physical data model – The composite is embedded in the implementation Page 25 Who is Where: Static Vs. Dynamic Information  Logical Composite – Static Who Composite, Dynamic Where Composite – C L = {Object_Type, Organisation_Type, Government_Organisation_Type, MilitaryOrganisationType, Unit_Type, Object_Item, Organisation, Unit, Object_Item_Status, Organisation_Status, Object_Item_Location, Location, Point, Absolute_Point, Geographic_Point }  Solution – Reference Who + Initialize {Location, Point, Absolute_Point} + update {Geographic_Point, Object_Item_Location} – Physical Composite {Id + (lat,lon) } Page 26 Speaker Name 13

Presentation Title 2/4/09 References  Andreas Tolk, Saikou Y. Diallo, Robert D. King, Charles D. Turnitsa: “A Layered Approach to Composition and Interoperation in Complex Systems,” in Tolk and Jain (Eds.): Complex Systems in Knowledge based Environments: Theory, Models and Applications, SCI 168, pp. 41-74, Springer, 2009  Andreas Tolk, Saikou Y. Diallo: “Model-based Data Engineering for Web Services,” in Nayak et al. (Eds.): Evolution of the Web in Artificial Intelligence Environment, SCI 130, pp. 137– 161, Springer, 2008  Andreas Tolk, Robert D. Aaron: “Data Engineering for Data-Rich Integration Projects: Case Studies Addressing the Challenges of Knowledge Transfer,” Engineering Management Journal, in press, 2009  Andreas Tolk, Saikou Y. Diallo, Charles D. Turnitsa, Leslie S. Winters: “Composable M&S Web Services for Net-centric Applications,” Journal for Defense Modeling & Simulation (JDMS) , Volume 3 Number 1, pp. 27-44, January 2006  Andreas Tolk, Saikou Diallo: “Model-Based Data Engineering for Web Services,” IEEE Internet Computing Volume 9 Number 4, pp. 65-70, July/August 2005 Page 27 Questions http://www.vmasc.odu.edu Speaker Name 14