Transcript SWIM-SUIT Overview

SWIM-SUpported by Innovative
Technologies
Antonio Strano
[email protected]
14/04/2010
SWIM-SUIT Overview
Outline
• SWIM concept
• SWIM-SUIT project
– Objectives
– Design Principles / requirements
– SWIM-SUIT Prototype
• Architecture overview
– Testing & Validation
2
SWIM concept (simplified)
•
SWIM aims to establish a seamless
interoperability among heterogeneous ATM
stakeholders
– Need for common data representation
– Need for a coherent view on current ATM
information (e.g. Flight Data, Aeronautical
Data, Weather..)
•
It may be seen as a common data/service bus
on which systems having to interoperate are
“connected”
3
SWIM-SUIT project objectives
• Analyse the (SESAR) SWIM concept defining
(high level) requirements
• Identify the right technologies
• Design and Implement the first SWIM prototype
• Validate the SWIM prototype capabilities in order
to demonstrate the feasibility of the SWIM
concept
• Identify the lessons learned to support the
SESAR activities
4
Design Principles / Requirements (1/2)
• Following SESAR definitions the prototype :
– has been designed using a domain based approach (Flight,
Surveillance, etc. – like a data model based systems integration)
– has been implemented using a standard based approach
• Well known data and information models (e.g. ICOG2)
• Standard technologies (Web Services, EJB, DDS)
– decouples external adapters/systems from internal knowledge
about the SWIM implementation
• Accept overheads are due to the use of XML data modelling at the
interface level
• Establish programming language independence
5
Design Principles / Requirements (2/2)
• Request/Reply
– Supported by Web Services (basically a synchronous
access)
• Publish/Subscribe
– Supported by JMS/DDS (asynchronous access)
SWIM Information Pool
1. publish A
1. request
S1
(Legacy)
System I
2. consume A
System I
System II
2. consume A
Client
Application
2. response
3. request
4. response
4. consume B
S2
(Legacy)
System II
5. get X
3. publish B
System III
7. consume C
System IV
6. publish C
6
SWIM-SUIT prototype
•
The prototype (named “SWIM-BOX”) has been conceived as a sort of
“Gateway/Mediator” across legacy applications
AOC
AOC
Flight
Simulator
FMS
ACC/APP
ATM Virtual Information
Pool
ISPOC
Prototype
ACC
ATFCM
(CFMU)
USA SWIM
MXP
AIRPORT
Heathrow
CDM
EAD
7
SWIM-SUIT Prototype architecture 1/3
• The SWIM BOX acts as a
mediator between different legacy
systems
• The Adapter translates
data/services among Legacy and
SWIM-BOX
• Each Adapter in the picture
might be further decomposed in
different adapters dedicated to the
served “Data Domains” (they will
be detailed later)
ATM System
A
ATM System
B
ATM System
N
Adapter A
Adapter B
Adapter N
SWIM-BOX
A
SWIM-BOX
B
SWIM-BOX
N
Data Exchange
Common
Infrastructure
8
SWIM-SUIT Prototype architecture 2/3
LEGACY
RMI / MOM / DB /
other techs
Legacy
Adapter
JBOSS AS
SWIM-BOX
JBOSS AS
Web Services
Web Services
& JMS/DDS
FDD
9
Data Transf. Mng
To/From ATM
Stakeholders
Aeronautical Data Domain
Data Transf. Mng
Authorizati
on Mng.
Authenticat
ion Mng.
Pub/Sub Techn. 2
SWIM Core Middleware
Surveillance Data Domain
Pub/Sub Techn. 1
Data Transf. Mng
To/From
DataLink Layer
Req/Repl Techn
Ownership Mng
Tech. Indep Layer
Flight Data Domain
Pub/Sub Tech. Indep. Layer
SWIM-SUIT Prototype architecture 3/3
10
SWIM Data Domains
•
•
Following SESAR definitions, the prototype provides support (service/data
exchanges) on a “data domain” base
– Offers generic (but “standard”) services for their specific domain and offer some
extra management service
– Defines a “standard” data representation and translate it in a flexible format (XML
in the prototype)
– On a domain basis, manages the roles taking into account a subset of data
– Provides facilities for consuming services exposed by the adapters\legacies
through the SWIM-BOX
For the prototype three Data Domains are implemented:
– FDD (Flight Data Domain)
• ICOG2 data & information standard (providing specific extensions)
– SDD (Surveillance Data Domain)
• ASTERIX Category 62 data standard (binary & XML representations)
– AID (Aeronautical Information Service Domain)
• Aeronautical Information Exchange Model (AIXM)
11
SWIM-BOX Core
• The SWIM-BOX Core has no knowledge of the data
representation it manages
• It provides services for data delivery and QoS
management (in different technologies for each pattern –
pub/sub or req/reply)
• It is loosely impacted by changes in the data
representation and by changes in the services exposed
in the SWIM Data Domains (acts as much as possible as
a transport layer)
• SWIM Data Domain Interfaces and Wire Interfaces
follow established standards
12
SWIM-Box FDD-Adapter communications :
consume service
When Invoking the interface “doSomething”
the actual operation invoked is
“requestFOService(‘doSomething’)”
“VIRTUAL INTERFACE” (APP-ICD)
WS Interface
WS Interface
Technology:
Web Service (SOAP over HTTP[s])
PubSub
Shared
DS
Security
Authentication
FDD
Authorization
JAX-WS
Encryption (XML Encryption)
Technology:
Web Service (SOAP over HTTP[s])
SOAP/HTTP(S)
PubSub
Authentication
Authorization
Decryption
Shared
DS
Security
FDD
JAX-WS
SOAP/HTTP(S)
Technology (Req/Rep):
Web Service (SOAP over HTTP[s])
SOAP/HTTP(S)
13
SWIM-Box FDD-Adapter communications
WS Interface
WS Interface
Technology (Req/Rep):
Web Service (SOAP over HTTP[s])
Decryption
Security
Encryption (XMLEncryption)
Shared
DS
FDD
JAX-WS
SOAP/HTTP(S)
PubSub
PubSub
Shared
DS
Security
FDD
Technology:
JAX-WS
Web Service (SOAP over HTTP[s])
Technology (Pub/Sub):
JMS or DDS
SOAP/HTTP(S)
14
Testing & Validation activities
•
Unit Tests (no data domain components involved)
– Automatic test suite for the SWIM-BOX core components
•
Integration Tests (no Legacy Systems involved)
– Semi-Automatic test suite for each SWIM-BOX data domain components (to test
the data domain capabilities and to evaluate potential data domain components
integration problems)
– LAN & WAN
•
Pseudo Operative Tests (Legacy Systems involved)
– Suite of operative scenarios (e.g. management of the airport arrival sequence) to
validate the prototype capabilities and to demonstrate the feasibility of the SWIM
concept
– WAN
•
Performance Tests (no Legacy Systems involved)
– Automatic test suite to evaluate the prototype behavior (e.g. average response
time, data loss, throughput, etc.) building specific workloads (e.g. service
invocation rate, data publication rate, number of published data, number of flight
data, etc.)
– LAN & WAN
15
http://www.swim-suit.aero/swimsuit/
Questions?
16
Subscribing
AdapterTo
SwimBox
Legacy
SwimBox
SwimBox
AdapterTo
SwimBox
Legacy
subscribe
subscribe
subscribe
subscribe
13/04/2010
SWIM-SUIT Overview
17
Creating FOs – Node A
SB
AdapterTo
SwimBox
Legacy
SB
FDDAdapter
Notification
FOContributor
createFO
createFO
distributeFO
notifyFOSummary
FOManager
notifyFOUpdate
addFlightObject
addFlighObject
13/04/2010
addFlightObject
SWIM-SUIT Overview
18
Creating FOs – Node B
FOContributor
FDDAdapter
Notification
SwimBox
AdapterTo
SwimBox
SwimBox
Legacy
createFO
createFO
distributeFO
notifyFOSummary
addFlightObject
notifyFOUpdate
FOManager
addFlightObject
addFlighObject
13/04/2010
SWIM-SUIT Overview
19
Requesting services – Node B
FOManager
FDDAdapter
SB
SB
Adapter
Messaging
AdapterTo
SwimBox
Legacy
requestFOService
requestFOService
requestFOService
requestFOService
FDDAdapter
Notification
getFlightObject
send
FOContributor
updateFO
distributeFO
notifyFOSummary
addFlightObject
notifyFOUpdate
addFlightObject
13/04/2010
SWIM-SUIT Overview
20
Performing handover – Node A
Legacy
SB
AdapterTo
SwimBox
SB
FDDAdapter
FOContributor
handoverFO
handoverFO
FOManager
requestFOhandover
FOContributor
acceptHandover
getFlightObject
FOManager
addFlightObject
removeFlightObject
addFlightObject
removeFlightObject
13/04/2010
SWIM-SUIT Overview
21
Unsubscribing
AdapterTo
SwimBox
Legacy
SwimBox
AdapterTo
SwimBox
SwimBox
Legacy
unsubscribe
unsubscribe
unsubscribe
unsubscribe
13/04/2010
SWIM-SUIT Overview
22