# Presentation: 925883

## AIAG’s ATHENA IV&I Validation Pilot

**AIAG’s ATHENA IV&I Validation Pilot**

- Nenad Ivezic
- National Institute of Standards and Technologies

**Notes:**
In this portion of the presentation, we would like to show you the cutting edge research that AIAG is doing in the area of interoperable technologies.

AIAG leads an international consortium that has won a grant from the EU-funded ATHENA project to validate new generation of technologies – the research results of the ATHENA project -  in support of interoperable b2b applications development.

My name is Nenad Ivezic and I work at the National Institute of Standards and Technologies to coordinate the technical work in this portion of the ATHENA project.  I am here with the members of the NIST team, Serm Kulvatunyou, Mark Vujasinovic, and Jungyoub Woo, as well as the other members of the team who are at NIST facilities and in Europe supporting this demo on-line.

## A Vision: Semantic Middleware for Heterogeneous Enterprise Networks

**A Vision: Semantic Middleware for Heterogeneous Enterprise Networks**

**Point-to-Point****:****  n(n-1)**

**Using the Athena tools****:**** 2n**

**Semantic Middleware**

**Using the ****BODs****:**** 2n**

**BODs**

**Homogeneous Enterprise Network**
**(Tightly coupled**
**e.g., RosettaNet, ebXML, OAG)**

**Heterogeneous Enterprise Network**
**(Loosely coupled, flexible, adaptive)**

**Current:**
**Standard Message based Interoperability**

**Future:**
**Semantic Middle -ware based Interoperability**

**Notes:**
Our industrial and academic partners provided this slide to communicate one vision that this project is working towards.

The vision is one of creating semantic middleware for heterogeneous enterprise networks

Today, we use standard message based interoperability approaches to deal with homogeneous enterprise network where the standards interfaces are designed and implemented directly at the implementation artefact/schema level.

Tomorrow, we would like to be able to deal with  the cross-enterprise business processes where standard interfaces will be flexibly defined and implemented at the model-based level using semantic middleware as opposed to implementing the interfaces directly at the implementation artefact/schema level.

## ATHENA Validation Pilot

- Use the eKanban interoperability project to validate ATHENA research results
- Use the model-driven standards development approach
- Identify roles for the ATHENA tools and methods to enable this “to-be” model-driven approach
- Execute test scenarios that compare results with the as-is base case
- evaluate the capability, innovation, and potential impact of the results coming from ATHENA project.

**Notes:**
In the ATHENA validation pilot, we have started a pioneering effort to assess novel model based technologies to standards development and interoperable applications development in real industrial scenarios:

We adopted the eKanban interoperability project as the platform to validate the ATHENA results
We developed a new model-driven standards development approach
We identified roles for ATHENA tools and methods to enable this approach
We defined test scenarios in which to test the ATHENA results and assess their capability and potential impact in the industrial interoperable applications development processes

## As-Is High-Level Integration Approach

- Design-Time Schema
- Definition
- & Mapping

- Business Process Modeling

- IV&I eKanban BODs

- Run-time
- Execution

- IV&I BOD
- interface

- Local
- Interface A

- IV&I BOD
- interface

- Local
- Interface B

- Internet

- Schema A
- Interface

- Schema B
- Interface

- IV&I eKanban Business Process Model

- Manual
- Map

**Notes:**
We start with the current AS-IS integration approach as used by AIAG and other industry consortia.

At this high-level of abstraction, we can identify three essential levels at which this approach unfolds:

First, at the business process modeling level, the consortia members worked to define the IV&I eKanban Business Process Model 
Second, at the next level, the consortia uses best practices in interoperable standards-based development to define design time schema mapping between local application interface shemas and the global eKanban schemas
Third, at the run-time execution level, the local-to-global schema mappings are used to inform the manual mapping to create the IV&I BOD-conformant interface.

The issues that we encounter in the AS-IS approach to standards-based interoperable applications development process are following:

## As-Is High-Level Integration Approach

- Business Process Modeling

- IV&I eKanban BODs

- Run-time
- Execution

- IV&I BOD
- interface

- Local
- Interface A

- IV&I BOD
- interface

- Local
- Interface B

- Internet

- Schema A
- Interface

- Schema B
- Interface

- IV&I eKanban Business Process Model

- Manual
- Map

- Informal, non-computable capture of business process model

- Design-Time Schema
- Definition
- & Mapping

**Notes:**
First, the business process model is captured using informal, non-computable methods – i.e., english text and diagrams.

## As-Is High-Level Integration Approach

- Business Process Modeling

- IV&I eKanban BODs

- Run-time
- Execution

- IV&I BOD
- Represent.

- Local
- Represent.
-  A

- IV&I BOD
- Represent.

- Internet

- Schema A
- Interface

- Schema B
- Interface

- IV&I eKanban Business Process Model

- Manual
- Map

- Inadequate capture of _meaning_ of information (XML Schema) and local-to-global schema mappings

- XML Schema

- Design-Time Schema
- Definition
- & Mapping

- Local
- Represent.
-  B

**Notes:**
First, the business process model is captured using informal, non-computable methods – i.e., english text and diagrams.

Second, the meaning of data and mappings between data elements in local and global interfaces is currently captured imprecisely using XML Schema and other syntactic/data format definition approaches.

## As-Is High-Level Integration Approach

- Business Process Modeling

- IV&I eKanban BODs

- Run-time
- Execution

- Internet

- Schema A
- Interface

- Schema B
- Interface

- IV&I eKanban Business Process Model

- Manual
- Map

- Manual, imprecise mapping to implement standard data exchange interface

- XML Schema

- Design-Time Schema
- Definition
- & Mapping

- IV&I BOD
- Represent.

- Local
- Represent.
-  A

- IV&I BOD
- Represent.

- Local
- Represent.
-  B

**Notes:**
First, the business process model is captured using informal, non-computable methods – i.e., english text and diagrams.

Second, the meaning of data and mappings between data elements in local and global interfaces is currently captured imprecisely using XML Schema and other syntactic/data format definition approaches.

Third, based on the imprecise schema mappings, the actual implementations of standard data exchange interfaces are also imprecise as they are also re-interpreted in a manual process.

## ATHENA Pilot High-Level Architecture

- Semantic Mediation Layer

- Enterprise Modeling, Ontology Modeling  Layer

- IV&I eKanban BODs

- Run-time
- Execution
- Layer

- Internet

- Logic A
- Interface

- Logic B
- Interface

- IV&I eKanban Enterprise/Business Process Model

**Reconc.**
**Rules**

**Reconc.**
**Rules**

- Semantic Reconciliation
- Service

- IV&I eKanban Ontology (Concepts + Relations)

- IV&I BOD
- Represent.

- Local
- Represent.
-  A

- IV&I BOD
- Represent.

- Local
- Represent.
-  B

**Notes:**
The ATHENA-enabled TO-BE integration approach is the validation pilot architecture:

At this high-level of abstraction, we have new objectives for work done at each level (that are mirrored by new names):

First, at the enterprise modeling and ontology modeling  level, the fundamental concepts and relations are captured to devise computational models for the IV&I eKanban Business Process and the exchanged messages. 
Second, at the semantic mediation level, the logic behind the local interfaces and the global schema are exposed and used to define semantic mappings or reconciliation rules between local and global schema
Third, at the run-time execution level, the semantic mappings/reconciliation rules are used to run the semantic reconciliation engine

The advantages of this architecture are following:

## ATHENA Pilot High-Level Architecture

- Semantic Mediation Layer

- Enterprise Modeling, Ontology Modeling Layer

- IV&I eKanban BODs

- Run-time
- Execution
- Layer

- Internet

- Logic A
- Interface

- Logic B
- Interface

- IV&I eKanban Enterprise/Business Process Model

**Reconc.**
**Rules**

**Reconc.**
**Rules**

- Semantic Reconciliation
- Service

- IV&I eKanban Ontology (Concepts + Relations)

- Formal, computable capture of business process model and domain ontology

- IV&I BOD
- Represent.

- Local
- Represent.
-  A

- IV&I BOD
- Represent.

- Local
- Represent.
-  B

**Notes:**
First, formal, computable capture of the business process and the model of application domain are now possible.

## ATHENA Pilot High-Level Architecture

- Semantic Mediation Layer

- Enterprise Modeling, Ontology Modeling Layer

- IV&I eKanban BODs

- Run-time
- Execution
- Layer

- Internet

- Logic A
- Interface

- Logic B
- Interface

- IV&I eKanban Enterprise/Business Process Model

**Reconc.**
**Rules**

**Reconc.**
**Rules**

- Semantic Reconciliation
- Service

- IV&I eKanban Ontology (Concepts + Relations)

- Precise capture of meaning of information (RDFS) and local-to-global schema mappings

- RDF Schema

- IV&I BOD
- Represent.

- Local
- Represent.
-  A

- IV&I BOD
- Represent.

- Local
- Represent.
-  B

**Notes:**
First, formal, computable capture of the business process and the model of application domain are now possible.

Second, precise capture of meaning of information and local-to-global schema mappings are possible.

## ATHENA Pilot High-Level Architecture

- Semantic Mediation Layer

- Enterprise Modeling, Ontology Modeling Layer

- IV&I eKanban BODs

- Run-time
- Execution
- Layer

- Internet

- Logic A
- Interface

- Logic B
- Interface

- IV&I eKanban Enterprise/Business Process Model

**Reconc.**
**Rules**

**Reconc.**
**Rules**

- Semantic Reconciliation
- Service

- IV&I eKanban Ontology (Concepts + Relations)

- Automated, precise interface implementation through logical schema reconciliation

- RDF Schema

- IV&I BOD
- Represent.

- Local
- Represent.
-  A

- IV&I BOD
- Represent.

- Local
- Represent.
-  B

**Notes:**
First, formal, computable capture of the business process and the model of application domain are now possible.

Second, precise capture of meaning of information and local-to-global schema mappings are possible.

Third, automated and precise interface implementation is possible through logical schema reconciliation.

As you can see, the focus in the work that we will demonstrate has shifted to model and design time.  We will be happy to discuss that part of the work with you.  In our demo, however, we will focus on the visible part of the work, the run-time execution part.  

The functional view of the run-time execution layer here is a basis for the demo you will see.

## ATHENA Pilot Demo

- NIST Gateway

**Coordinator**

- ARGOS

- ATHENA WS Engine
- Johnson

- Security
- Service

- Enterprise
- Application

- GM App

- ARTOX

- AXTOR

- Internet

- IV
- Application

- FOS

- ARES

- Authorize
- Kanban

- Authorize
- Kanban

- Demo

**Notes:**
That functional view of the run time execution level is a basis for the architecture of our demo.

The two parts of the demo are functionally similar but they will involve two independently developed applications that send messages using the run time execution components developed in ATHENA and by our consortium.

In the first part, a GM app sends the Authorize Kanban message to the target application – the IV&I test harness.  In the second part, the experimental FOS IV App sends the same message to the test harness.

Both GM and FOS apps use the NIST-developed gateway that contains a number of modules shown here.  In the gateway, we perform transformation functions (from XML to RDF and vice versa), reconciliation function using semantic mediation engine, and WS call using the ATHENA WS engine.  

The ATHENA/AIAG semantic tool suite will demonstrated (1) to be able to handle multiple message formats and ws execution approaches from independent applications and (2) to provide required transformations and model-based reconciliations to result in interoperable messages over the wire.

## ATHENA Pilot Demo

**NIST Gateway**

**Coordinator**

**ATHENA WS  Engine**
**Johnson**

- Security
- Service

- ARTOX

- AXTOR

- ARGOS

- http://txt.it

- http://nist.gov

**Coordinator**

- Enterprise
- Application

- GM App

- http://gm.com

- IV
- Application

- FOS

- http://fon.bg.ac.yu

- RDF over
- WS (SAAJ):
**Authorize **
**Kanban**

- http://nist.gov

- XML over
- WS (AXIS):
**Authorize **
**Kanban**

**Notes:**
A more technical view of the demo is provided also showing the participants and location of the applications on the web.
We accommodate two different formats from the two applications, both of which are incompatible with the target format
The two applications use different implementations of WS to communicate with outside world, both of which are incompatible with the expected WS profile
The respective applications run at gm and fos sites in N. America and Europe respectively
The NIST gateway and the test harness done by Ford are running on the NIST testbed node
The semantic reconciliation engine is running on the nodes in Italy

## ATHENA Pilot Demo

- http://nist.gov

**NIST Gateway**

**Coordinator**

**ATHENA WS  Engine**
**Johnson**

- Security
- Service

- ARTOX

- AXTOR

- ARGOS

- http://txt.it

- http://nist.gov

- Enterprise
- Application

- GM App

- IV
- Application

- FOS

**Coordinator**

- http://gm.com

- http://fon.bg.ac.yu

- RDF over WS
- reconciled:
**Authorize **
**Kanban**

- XML using
- WS BP:
**Authorize **
**Kanban**

- RDF over WS
-  not reconciled:
**Authorize **
**Kanban**

- RDF over WS
- reconciled:
**Authorize **
**Kanban**

- XML over
- WS BP:
**Authorize **
**Kanban **
**IV&I BOD**

- RDF  over
- WS (SAAJ):
**Authorize **
**Kanban**

- XML using
- WS API :
**Authorize **
**Kanban**

- XML over
- WS (AXIS):
**Authorize **
**Kanban**

**Notes:**
In the second part, we send another locally formatted message to the coordinator and, again, we send over the wire an IV&I eKanban conformant BOD.

In both cases, we should see the test harness accept and process the AuthorizeKanban message.

## Semantic & WS Mediation Capability

**(Towards Heterogeneous Network Interoperability)**

|  | GM | ATHENA/
AIAG | Test Harness
(Ford) |
| --- | --- | --- | --- |
|  | FOS |  |  |
| Function | Enterprise App. | Semantic Middleware | Test Harness |
|  | IV App. |  |  |
| Message Format | XML Schema | Input: XML or RDF Schema 
Output: IV&I BOD (XML Schema) | IV&I BOD (XML Schema) |
|  | RDF Schema |  |  |
| WS Execution | WS Sync (AXIS) | WS Asynch BP (RSP) (Johnson+WSS) | WS Asynch BP (RSP) (AXIS) |
|  | WS Sync (SAAJ) |  |  |

- ATHENA/
- AIAG

**Semantic + WS**
**Middleware**

- GM

- FOS

- Ford

**Notes:**
The ATHENA/AIAG semantic middleware suite is demonstrated (1) to be able to handle multiple message formats and ws execution approaches from independent applications and (2) to provide required transformations and model-based reconciliations to result in interoperable messages over the wire.

## GO TO DEMO