Transaction-based Definitions and Implementations of - - PDF document

transaction based definitions and implementations of
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

Presentation Title 2/4/09 Speaker Name 1

Transaction-based Definitions and Implementations

  • f Community-of-Interest Languages
  • Dr. Andreas Tolk, Old Dominion University
  • Mr. Saikou Diallo, VMASC

Page 2

Thanks for Sponsored Research

 US Joint Forces Command

– XC2I Interface – X-BML – JEDIS / JTDS / JRSG

 US Army Test and Evaluation

Command – Data Management – Architecture Studies in support of

Net-centric Testing

 US Army PEO Soldier

– Model-based selection, composition,

and orchestration

 NATO

– MSG-027 Pathfinder – MSG-048 C-BML

 Industry Partners

– IBM – Raytheon – Accenture – TEI

 Academic Partners

– MOVES/NPS – ARL/UT

 and many more …

slide-2
SLIDE 2

Presentation Title 2/4/09 Speaker Name 2

Page 3

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

Concepts and Background

COI Languages Model Based Data Engineering

slide-3
SLIDE 3

Presentation Title 2/4/09 Speaker Name 3

Page 5

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 6 Drives Enables

Data Needed Service Implementations

Enables

Community Information Exchange Vocabulary

Capability Delivery

Drives

Info Sharing Need

Drives

Service Needed

Net Enabled C2 Capability

slide-4
SLIDE 4

Presentation Title 2/4/09 Speaker Name 4

Page 7

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 8

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

slide-5
SLIDE 5

Presentation Title 2/4/09 Speaker Name 5

Page 9

Model-based Data Engineering

 Data Administration

– Managing the information exchange needs incl. source, format, context

  • f 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

Composites and Transactionals

Data Model Theory Strong and Weak Composites Transactionals

slide-6
SLIDE 6

Presentation Title 2/4/09 Speaker Name 6

Page 11

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 12

Composites and Transactionals Logical Model Physical Model CRM Logical Model Sys A Logical Model Sys A Physical Model Sys A Physical Model Sys A

slide-7
SLIDE 7

Presentation Title 2/4/09 Speaker Name 7

Page 13

Composites and Transactionals Logical Model Physical Model Composites Transactionals Transactionals

Page 14

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

slide-8
SLIDE 8

Presentation Title 2/4/09 Speaker Name 8

Application Domains

Definition Migration

Page 16

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

slide-9
SLIDE 9

Presentation Title 2/4/09 Speaker Name 9

Page 17

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 18

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

slide-10
SLIDE 10

Presentation Title 2/4/09 Speaker Name 10

Example: C-BML and JC3IEDM

Implementing BML as JC3IEDM Composites BML Standard and Composites

Page 20

Overview

Slide courtesy of Kevin Gupton from ARL/UT

slide-11
SLIDE 11

Presentation Title 2/4/09 Speaker Name 11

Page 21

WHO

Slide courtesy of Kevin Gupton from ARL/UT

Page 22

WHAT-WHEN

Slide courtesy of Kevin Gupton from ARL/UT

slide-12
SLIDE 12

Presentation Title 2/4/09 Speaker Name 12

Page 23

WHERE

Slide courtesy of Kevin Gupton from ARL/UT

Page 24

Example: WHO

 Logical Composite

– CL= {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

slide-13
SLIDE 13

Presentation Title 2/4/09 Speaker Name 13

Page 25

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 26

Who is Where: Static Vs. Dynamic Information

 Logical Composite

– Static Who Composite, Dynamic Where Composite – CL= {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) }

slide-14
SLIDE 14

Presentation Title 2/4/09 Speaker Name 14

Page 27

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

http://www.vmasc.odu.edu

Questions