swim-suit swim-suit prototype preliminary architecture dario di crescenzo (selex si) 14/05/2008...

SWIM-SUIT SWIM-SUIT SWIM-SUIT Prototype SWIM-SUIT Prototype

preliminary architecturepreliminary architectureDario Di Crescenzo (Selex SI)

14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 1

OUTLINEOUTLINE

• High Level SWIM Prototype Architecture Design

• Draft Scenarios and UML Model• Architecture Hypotheses • Technology Independence Scenarios


Global PictureGlobal Picture


SWIM / IOP Mgt

SWIM Network

SWIM / IOP Mgt

(Legacy) ATM System A

(Legacy) ATM System B

SWIM / IOP Mgt

(Legacy) ATM System C

SWIM / IOP Mgt

(Legacy) ATM System D

SWIM-SUIT Use cases


Basic patternsBasic patterns

• The general SWIM-based interaction schema between ATM Systems


sd ATM Systems

System A System B Another System

do_operation(a_param)

«Response»

Publish(some_data)

«Publication»Publish(some_data)

«Publication»

The SWIM-BOXThe SWIM-BOXAn high level viewAn high level view


To/From ATM Stakeholders

To/From DataLink Layer

The SWIM-Box high level structure in accordance with a layered approach :

The RolesThe Roles


• SWIM Prototype Co-operative patternsRole Definition

PUBLISHER -Receives from the Manager the coherent data D-Distributes the coherent data D to the other stakeholders

MANAGER -Collects the partial contribution from the Contributors to compute a coherent data D.-Provides the coherent data D to the Publisher

USER -Subscribes to the published data D or to a part thereof.-Consumes the updates of D

CONTRIBUTOR -Sets the value to a subset (a topic) of the information constituting the data D. The topic may be as large as the whole data when no consolidation and arbitration is required-Passes the new value of a topic of D to the Manager for partial contribution.

System I

System II

System IV

System III

1. publish A 2. consume A

2. consume A

3. publish B 4. consume B

6. publish C

7. consume C

SWIM Information Pool

5. get X

(Legacy) System I S1

(Legacy) System II S2

Client

Application

1. request

2. response

3. request

4. response

Basic operationsBasic operations


• We consider three “generic” operations that systems that

manage the Flight Data Plan, named Flight Object Servers

(FOS), could request to the underlying SWIM infrastructure :

create_FO

Create (locally) a Flight Object:Verify eligibilityAssign unique IDAssign ownership

update_FO Enable changes of Flight Object or part of it

handover_FO Allow to take the ownership of Flight Object

• The SWIM infrastructure tasks can be:– To expose service interface to ATM systems;– To build the service request;– To forward the service request to the proper provider;– To send back the outcomes of operations;– To manage the ownership of the Flight Object;

Hypothetical scenario - Hypothetical scenario - 1/31/3


• Services would be made available via SWIM from ATM Systems:– e.g. Flight Object server operations: create_FO,

update_FO, handover_FO

Hypothetical scenario - Hypothetical scenario - 2/32/3


HypotheticalHypothetical scenario - scenario - 3/33/3


Layers MappingLayers Mapping


• GOALS : To describe in details the business scenarios to detail component model of SWIM - Box

• Business scenarios analyzed :• FO Change Proposal (include “update” and ”publish”

operations)

OUTLINEOUTLINE

• SWIM Prototype Architecture Design• Draft Scenarios and UML Model• Architecture Hypotheses • Technology Independence Scenarios


Draft Scenarios and UML Draft Scenarios and UML ModelModel


• FO Change Proposal Scenario : High Level View

ATSU 1 ATSU 2 ATSU 3

ADES ADEP

SWIM

Segment Approved

“1”-

RB

T S

ub

mission

Pro

vision

al

“2” - RBT Segment Conflict Free“3” - RBT Approved

RBT ProvisionalNote: the numbers show the sequence of actions


ADES ADEP

SWIM

Segment Approved

“1”-

RB

T S

ub

mission

Pro

vision

al


RBT Provisional


ADES ADEP

SWIM

Segment Approved

“1”-

RB

T S

ub

mission

Pro

vision

al


RBT ProvisionalNote: the numbers show the sequence of actions



• FO Change Proposal Scenario : Interaction Diagram (Logical View)ATSU 1ATSU 1 SWIMSWIM ATSU_2ATSU_2 ATSU_3ATSU_3

1: proposeFOModify(FO_ID, FO)

2: verify(FO_ID, FO)

3: isConflictFree()

4: ACK

5: verify(FO_ID, FO)

6: isConflictFree()

7: ACK

8: ACK

9: update(FO_ID, FO)


• FO Change Proposal Scenario, possible details :1. The Flight must be created and associated to its ID (planning phase )2. ATSU 1, must know the Flight’s ID (FO_ID)3. ATSU 1,2 and 3 must have a local copy of this Flight Object4. ATSU 1,2 and 3 must be authorized to receive a local copy of this Flight Object5. ATSU 1, must be authorized to propose change on this Flight 6. ATSU 2 and 3, must provide “verify” functionality for this Flight7. ATSU 2 and 3, must be authorized to verify possible conflicts8. Only Flight Manager (owner) can modify the Flight Object

• FO Change Proposal Scenario, macro steps :1. ASTU 1,2 and 3 require subscription on Flight Data Domain ( domain partitions

)2. ATSU 2 and 3 Need to be added as a “verify” provider for the flight FO_ID3. ASTU 1 requires to verify its change proposal4. ASTU 1 requires to update the Flight Object5. Flight Manager (ATSU 1, in this case) modifies the Flight Object




ServiceProfile

EndPoint

setEndPoint()

DataProfi le

RoleDomainPartitionFilter

setRole(Role)setDomainPartition(DomainPartition)setFilter(Filter)

Registry

addEntry(Data_ID, Profile, Participant_ID)getParticipants(Data_ID, Profile) : Participant_IDsremoveEntry(Data_ID, Profile)getProfile(DATA_ID, Participant_ID)

<<Interface>>

RegistryAsTable

Entries

<<implements>>

Entry

DATA_IDProfile

Profile

DATA_IDParticipant_IDDecsription

setDataID(DATA_ID)setParticipantID(Participant_ID)setDescription(Description)

1 11 1

• The registry could store the information represented by this model

• For each flight, a system may register itself with a particular role; each System provides different services according to the role played for that flight

Role

PUBLISHER

MANAGER

USER

CONTRIBUTOR

Endpoint Examples

http://..

corbaloc

. . .



• Registration of the Service “Modify Flight Object”

• “Modify Flight Object” Service usage

OUTLINEOUTLINE

• SWIM Prototype Architecture Design• Draft Scenarios and UML Model• Architecture Hypotheses • Technology Independence Scenarios


Flight Data Domain Flight Data Domain Services ArchitectureServices Architecture


Front-End Session Bean:Implements the Web Service interface providing the Flight Data Domain Business and Administration Service

DDS: Distributes stringfied XML rapresentation of the Flight Object

DDS/JMSFDD

Facade

EJB StatelessSessionBean

SWIM PublishService

SWIM Core

SWIM-BOX Application

FDD Client

EJB Containerdistribution

DDS/JMS


DDSDataReader


DDSDataReader

DD

S/JM

S

Flight Object Server

Gateway create_FOupdate_FOhandover_FO

FOS

FOS

WEB

SERVICE


DDSDataReader

<Departure-Airport><name>Roma Fiumicino</name><Runway> Rwy 34L <Runway>

</Departure-Airport><Destination-Airport>

<name> Paris</name><Runway> Rwy 29T <Runway>

</Destination-Airport><Aircraft> <name> Medit Atr 72-200 </name> </Aircraft>….

SOAP request

FDD Administrator

Legacy ATM System

Legacy ATM System

Scalability & Scalability & Performance: Performance:

The FDD Facade 1/2The FDD Facade 1/2


• Implemented as Stateless Session Bean in order to have:– No explicit mapping between multiple clients and stateless bean instances– The EJB container is free to serve any client’s request with any available instance

• Stateless session bean beneficial attributes – Bean pooling EJB container pools stateless bean instances and increase

performance.– Scalability Stateless session beans serve multiple clients, they tend to be more

scalable when applications have a large number of clients. Require less instantiation compared to stateful session beans.

– Performance An EJB container will never move a stateless session bean from RAM out to a secondary storage (as for a stateful session bean)

FDDFacade

createFO(FO) : FlightObjectIdupdateFO(FlightObjectID, FOClusterId, FOCluster)handoverFO(FlightObjectId)FDDOperation(...)

Scalability & Scalability & Performance:Performance:

The FDD Facade 2/2The FDD Facade 2/2

14/05/2008 23Flight Object Server

SOAP request

Legacy ATM System

Legacy ATM System FDD

Facade

SWIM Publish Service


EJB Container

WEB

SERVICE

FO_BeanFO_id1

FO_BeanFO_id2

FO_BeanFO_idn

FDDFacade

SWIM Core

Session StatelessBean pool

Flight Object Entity Beans

Gateway

DB

Entity Beans are used to represent Flight Objects in order to have:• Container Managed Persistence• LifeCycle QoS • Business code

High Level View of FDD Architecture:High Level View of FDD Architecture: Publishing FO Publishing FO

15/05/2008 24

InvocationNetwork

InvocationNetwork

ClientClient

FDDFacadeSession

Bean

FDDFacadeSession

Bean

FO EntityBean

(FO_ID, FO)

FO EntityBean

(FO_ID, FO)

FO EntityBean

(FO_ID, FO)

FO EntityBean

(FO_ID, FO)

FO EntityBean

(FO_ID, FO)

FO EntityBean

(FO_ID, FO)

FO EntityBean

(FO_ID, FO)

FO EntityBean

(FO_ID, FO)

ClientClient DDS/JMSDDS/JMS

Ejb Container

DBDB

SWIMPublishService

SWIMPublishService

1 create_FO (FO) update_FO (FO_ID, FO,CLUSTER_ID)handover_FO (FO_ID)

3 following the FDD operation of the state on the EJB, the distribute operation is called (if Manager) or forwarded to the Manager of the current FO_ID

2 create/retrieve the EJB with FO_ID as Primary key

Redy/PooledRedy/Pooled

Stored (DB)Stored (DB)

FlightObjectlifecycle

createFO handoverFO

FDDFacadeSession

Bean

FDDFacadeSession

Bean

Loaded from DBwhen the Publisher is local

High Level View of FDD High Level View of FDD Architecture: Architecture: Receiving FOReceiving FO


InvocationNetwork

InvocationNetwork

FO EntityBean

(FO_ID, FO)

FO EntityBean

(FO_ID, FO)

FO EntityBean

(FO_ID, FO)

FO EntityBean

(FO_ID, FO)

DDS/JMSDDS/JMS

DBDB

DDS Listeneror

MDB

DDS Listeneror

MDB

1 on_data_available(..) onMessage(..)

2 retrieve the EJB with FO_ID as Primary key

3 invoke the ejb_data_available in order to process the FO

LegacySystem

LegacySystem

4 the request is processed by the Legacy System

Ejb Container

Some ideas for FDD Design:Some ideas for FDD Design:Facade, DiscoveryPublisher, FO Entity Facade, DiscoveryPublisher, FO Entity

BeanBean


SessionBean

Registry

addEntry(Data_ID, Profile, ParticipantID)....()

on createFO the ownership is set inside PublisherLookupService and distributed inside the FO to all SWIM-BOXes in order to align all the PublisherLookupServices. The updates on PublisherLookupService for a given FOID will be done by an handoverFO operation

SWIMCoreListener

notify()

updates the manager info

FlightObjectEntityBean

flightObjectString : StringpublisherInBox : BooleanflightObjectId : Integer

isPublisherInBox() : Booleandistribute()setFlightObject(FO : String)setFlightObjectPart(FO : String, clusterId : FOClusterId)onAvailableData(FO : String)

FDDFacade

createFO(FO) : FlightObjectIdupdateFO(FlightObjectID, FOClusterId, FOCluster)handoverFO(FlightObjectId)FDDOperation(...)

implements

manages

PublisherLookupService

amIPublisherForFO(foId : FlightObjectId)getPublisherReferenceForFO(foId : FlightObjectId) : StringupdatePublisherReferenceForFO(foId : FlightObjectId)

uses

implements

uses

uses

Some ideas for FDD Design:Some ideas for FDD Design:Looking at the Legacy SystemLooking at the Legacy System


LegacyCommand

execute()

CommandIf

execute()

when DDS Listener or MDB receives FO, it is forwarded to the right FlightObjectEntityBean

A Command is registered to EntityBean in order to process the legacy and to adapt the FDD reply into the Legacy Protocol

Service used to execute Legacy Commands

LegacyCommandExecutor

registerFDDCommand(command : Command, commandName : String)unRegisterFDDCommand(commandName : String)performCommand(commandName : String)

executes

DataWriter

write()

QueueSender

send()

Adapter for thetechnology independance

FDDFacade

createFO()updateFO()handoverFO()FDDOperation()

SWIMCorePublisher

publish(data)

uses

uses

FlightObjectEntityBean

flightObjectString : StringmanagerInBox : BooleanflightObjectId : Integer

isManagerInBox() : Booleandistribute()setFlightObjectString(FO : String)onAvailableData(FO : String)

managespublishes

MessageDrivenBean

onMessage()

SWIMCoreListener

notify()

notifies

DDSListener

on_data_available()

implements

OUTLINEOUTLINE

• SWIM Prototype Architecture Design• Draft Scenarios and UML Model• Architecture Hypotheses • Technology Independence

Scenarios


Publish/Subscribe Publish/Subscribe ProtocolProtocol


• DDS and JMS exclusive functioning:

–The SWIM-SUIT Prototype shall be started and tested running all the SWIM-

BOXES instances or with DDS or with JMS

Publish/Subscribe Publish/Subscribe ProtocolProtocol


• DDS and JMS together:

– JMS/DDS Bridge

– ESB in order to transform protocols (JMS/DDS)

Questions?Questions?


swim-suit swim-suit prototype preliminary architecture dario di crescenzo (selex si) 14/05/2008...

Documents

flight data plan

underlying swim infrastructure

swim infrastructure

published data d

coherent data ddistributes

flight objectcreate

topic of d

swimbox high level structure