SWIM-SUIT: Laying the technological foundation for SWIM

1
SWIM-SUITLaying the technological foundation
for SWIM

• Massimiliano De Angelis

2
Project Details

• Budget
• 11,8 M
• 6,3 M funded by EC

3
Consortium at a Glance

• 10 Countries
• 20 Partners
• 6 Industries
• 1 Airport Managing Company
• 2 Airlines
• 4 ANSPs
• 4 SMEs
• 2 Research Centres
• 1 University

• External support from

4
SWIM-SUIT Objectives
SWIM FEASIBILITY
5
SWIM-SUIT Prototype
6
SWIM-SUIT Prototype
Acquire Data
7
SWIM-SUIT Prototype
Disseminate Data
8
SWIM-SUIT Prototype
ATM Virtual Information Pool AVI POOL
9
WP 2.2 Identification of Technology and of
Services Options (2/3)

• SWIM-SUIT partners have identified the criteria
  as important for selecting the right technologies

Technical knowledge available at partner
Applicability for Wide Area Network (WAN)
Scalability
Robustness
Flexibility
Reliability
Message overhead
Portability
Manageability
Interoperability
Suitability for Near Real Time
COTS selection
Use of standards
Availability of IDE
Support for Security

• The different criteria are grouped by topics
  having different weights
• Network Performance
• e.g. Message overhead
• Efficiency
• e.g. Reliability, Robustness, Scalability
• Maintainability and Management
• e.g. Flexibility, Manageability..
• Stability and Evolutivity
• e.g. Interoperability, Use of Standards ..
• Security
• Support for Security

10
WP 2.2 Identification of Technology and of
Services Options (3/3)

• For each property a value in the range from 0 to
  4 has been assigned

Scalability
Robustness
Use of standard
Message Overhead

0 - Technology does not lean on standard.
1
2 - Technology leans on a new standard (durability not guaranteed)
3
4 - Technology leans on mature and widespread standards.

• The Criteria are divided in two groups the Swim
  Criteria are those that must be considered
  allocated to the SWIM project, while the
  SWIM-SUIT Criteria that are related to
  SWIM-Prototype aiming to more pragmatic issues in
  the short time.

11
Candidate Technologies

• For request/reply pattern

• For publish/subscribe pattern

MOM (JMS)
Web services notification
ESB publish/subscribe
CORBA Notification service
DDS
CORBA
ESB request/reply
Web services (J2EE)

• The criteria Analysis shown that
• in relation to the Request/Reply pattern, the Web
  Services technology has been evaluated as the
  more indicated
• Relatively to the Publish/Subscribe pattern, JMS
  gets the higher score for the SWIM-SUIT Criteria
  while DDS stands out among the selected
  technologies for the SWIM Criteria.

12
Criteria Analysis

• For publish/subscribe pattern
• DDS has been considered more suitable with
  respect to efficiency, network performance group
  criteria (better QoS support, scalability )
• For the prototype implementation a better
  availability of IDE integration and maturity of
  technology leads to experiment both JMS then DDS.

• For request/reply pattern
• Web services (J2EE) and ESB Req/Rep have been
  considered substantially equivalent for the SWIM
  criteria
• For the prototype implementation a better
  knowledge by the partners leads to Web Service
  selection.

13
Criteria Analysis
14
WP 2.3 Information Models and Services
Specification

• Defines the data structure of the ATM Domain
  that will be included in the prototype
  (Information Model)

• Identifies several interaction scenarios between
  ATM Systems on the SWIM network (Service
  specification ). These scenarios are the input
  for the design phases of the SWIM prototype.

15
The ATM Data Domain considered

• The data Domain that will be considered for the
  prototype design and implementation are
• Flight Data. Thanks to the experience of ICOG,
  the Flight Object Server scenarios will be
  analyzed. At the moment the following SWIM
  services are envisaged

create_FO Create (locally) a Flight Object Verify eligibility Assign unique ID Assign ownership
update_FO Enable changes of Flight Object or part of it
handover_FO Allow to take the ownership of Flight Object

• Surveillance Data ( e.g. Asterix )

16
General SWIM-based interaction schema
Publish/subscribe communication pattern
Request/reply communication pattern
17
WP 2.4 SWIM Prototype Architecture Design (1/2)

• Transfers technology and information models into
  an architectural design.
• The early description of the business scenarios
  is leading to the definition of a component model
  for SWIM-SUIT.

• The design phase is trying to define the layers
  that have been highlighted in WP1

18
WP 2.4 SWIM Prototype Architecture Design (2/2)

• For each identified layer, the high level
  architecture foresee different services/modules
• Technical services hiding distribution and
  communication technologies have been placed at
  the lowest level and a technology independence
  layer has been introduced

19
WP 2.4 SWIM-BOX

• The SWIM-BOX composition reflects the previous
  identified layered approach
• A Data Domain level
• A Core Level which in turn is composed by a
  technology independence layer trying to hide the
  actual technology utilized for the Pub/Sub and
  Req/Reply patterns

To/From ATM Stakeholders
To/From DataLink Layer
20
Legacy Systems integration

• SWIM-SUIT prototype will be tested integrating
  different systems provided by SWIM-SUIT partners
  emulating ATM Legacy Systems in operation
  (activity will be carried out during WP 2.5)
• How to connect these systems to SWIM-SUIT?

S E R V I C E I N T E R F A C E
T O T H E N E T W O R K
Gateway /adapter
service request
21
Solutions

• The adapters or the gateways between the ATM
  Legacy Systems and SWIM-BOX as access point
  to/from SWIM-BOX
• To access to data and services of SWIM-BOX
• By subscribing to specific data domains.
• To receive data and service calls from SWIM-BOX
• By registering services and corresponding
  callbacks.