1. SWIM-SUIT SWIM-SUIT Prototype preliminary architecture Dario Di Crescenzo (Selex SI) 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 1

2. OUTLINE High Level SWIM Prototype Architecture Design Draft Scenarios and UML Model Architecture Hypotheses Technology Independence Scenarios 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 2

3. Global Picture 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 3 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

4. SWIM-SUIT Use cases 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 4

5. Basic patterns The general SWIM-based interaction schema between ATM Systems 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 5

6. The SWIM-BOX An high level view 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 6 To/From ATM Stakeholders To/From DataLink Layer The SWIM-Box high level structure in accordance with a layered approach :

7. The Roles 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 7 SWIM Prototype Co-operative patterns RoleDefinition 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.

8. Basic operations 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 8 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 eligibility  Assign unique ID  Assign ownership update_FOEnable changes of Flight Object or part of it handover_FOAllow 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;

9. Hypothetical scenario - 1/3 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 9 Services would be made available via SWIM from ATM Systems: – e.g. Flight Object server operations: create_FO, update_FO, handover_FO

10. Hypothetical scenario - 2/3 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 10

11. Hypothetical scenario - 3/3 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 11

12. Layers Mapping 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 12 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)

13. OUTLINE SWIM Prototype Architecture Design Draft Scenarios and UML Model Architecture Hypotheses Technology Independence Scenarios 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 13

14. Draft Scenarios and UML Model 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 14 FO Change Proposal Scenario : High Level View

15. Draft Scenarios and UML Model 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 15 FO Change Proposal Scenario : Interaction Diagram (Logical View)

16. Draft Scenarios and UML Model 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 Object 4.ATSU 1,2 and 3 must be authorized to receive a local copy of this Flight Object 5.ATSU 1, must be authorized to propose change on this Flight 6.ATSU 2 and 3, must provide “verify” functionality for this Flight 7.ATSU 2 and 3, must be authorized to verify possible conflicts 8.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_ID 3.ASTU 1 requires to verify its change proposal 4.ASTU 1 requires to update the Flight Object 5.Flight Manager (ATSU 1, in this case) modifies the Flight Object 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 16

17. Draft Scenarios and UML Model 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 17

18. Draft Scenarios and UML Model 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 18 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...

19. Draft Scenarios and UML Model 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 19 Registration of the Service “Modify Flight Object” “Modify Flight Object” Service usage

20. OUTLINE SWIM Prototype Architecture Design Draft Scenarios and UML Model Architecture Hypotheses Technology Independence Scenarios 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 20

21. Flight Data Domain Services Architecture 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 21 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/JMS FDD Facade EJB Stateless SessionBean SWIM Publish Service SWIM Core SWIM-BOX Application EJB Container distribution DDS/JMS SWIM-BOX Application DDS DataReader SWIM-BOX Application DDS DataReader DDS/JMS Flight Object Server Gateway create_FO update_FO handover_FO FOS WEBSERVICEWEBSERVICE SWIM-BOX Application DDS DataReader Roma Fiumicino Rwy 34L Paris Rwy 29T Medit Atr 72-200 …. SOAP request Legacy ATM System

22. Scalability & Performance: The FDD Facade 1/2 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 22 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)

23. Scalability & Performance: The FDD Facade 2/2 14/05/200823 Flight Object Server SOAP request Legacy ATM System FDD Facade SWIM Publish Service SWIM-BOX Application EJB Container WEBSERVICEWEBSERVICE FO_Bean FO_id 1 FO_Bean FO_id2 FO_Bean FO_idn FDD Facade SWIM Core Session Stateless Bean 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

24. High Level View of FDD Architecture: Publishing FO 15/05/200824 Invocation Network Invocation Network Client FDDFacade Session Bean FDDFacade Session Bean FO Entity Bean (FO_ID, FO) FO Entity Bean (FO_ID, FO) FO Entity Bean (FO_ID, FO) FO Entity Bean (FO_ID, FO) FO Entity Bean (FO_ID, FO) FO Entity Bean (FO_ID, FO) FO Entity Bean (FO_ID, FO) FO Entity Bean (FO_ID, FO) Client DDS/JMS Ejb Container DB SWIM Publish Service SWIM Publish Service 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/Pooled Stored (DB) FlightObject lifecycle createFO handoverFO FDDFacade Session Bean FDDFacade Session Bean Loaded from DB when the Publisher is local

25. High Level View of FDD Architecture: Receiving FO 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 25 Invocation Network Invocation Network FO Entity Bean (FO_ID, FO) FO Entity Bean (FO_ID, FO) FO Entity Bean (FO_ID, FO) FO Entity Bean (FO_ID, FO) DDS/JMS DB DDS Listener or MDB DDS Listener or 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 Legacy System Legacy System 4 the request is processed by the Legacy System Ejb Container

26. Some ideas for FDD Design: Facade, DiscoveryPublisher, FO Entity Bean 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 26

27. Some ideas for FDD Design: Looking at the Legacy System 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 27

28. OUTLINE SWIM Prototype Architecture Design Draft Scenarios and UML Model Architecture Hypotheses Technology Independence Scenarios 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 28

29. Publish/Subscribe Protocol 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 29 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

30. Publish/Subscribe Protocol 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 30 DDS and JMS together: – JMS/DDS Bridge – ESB in order to transform protocols (JMS/DDS)

31. Questions? 14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 31