1 / 31

SWIM-SUIT SWIM-SUIT Prototype preliminary architecture

SWIM-SUIT SWIM-SUIT Prototype preliminary architecture. Dario Di Crescenzo (Selex SI). OUTLINE. High Level SWIM Prototype Architecture Design Draft Scenarios and UML Model Architecture Hypotheses Technology Independence Scenarios. (Legacy) ATM System A. (Legacy) ATM System B.

mercedes
Download Presentation

SWIM-SUIT SWIM-SUIT Prototype preliminary architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. (Legacy) ATM System A (Legacy) ATM System B SWIM / IOP Mgt SWIM / IOP Mgt SWIM Network Global Picture (Legacy) ATM System C (Legacy) ATM System D SWIM / IOP Mgt SWIM / IOP Mgt AP4/SWIM Technical Interchange Meeting (TIM)

  4. SWIM-SUIT Usecases AP4/SWIM Technical Interchange Meeting (TIM)

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

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

  7. The Roles • SWIM Prototype Co-operative patterns AP4/SWIM Technical Interchange Meeting (TIM)

  8. Basic 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 : • 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; AP4/SWIM Technical Interchange Meeting (TIM)

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

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

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

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

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

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

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

  16. Draft Scenarios and UML Model • FO Change Proposal Scenario, possible details : • The Flight must be created and associated to its ID (planning phase ) • ATSU 1, must know the Flight’s ID (FO_ID) • ATSU 1,2 and 3 must have a local copy of this Flight Object • ATSU 1,2 and 3 must be authorized to receive a local copy of this Flight Object • ATSU 1, must be authorized to propose change on this Flight • ATSU 2 and 3, must provide “verify” functionality for this Flight • ATSU 2 and 3, must be authorized to verify possible conflicts • Only Flight Manager (owner) can modify the Flight Object • FO Change Proposal Scenario, macro steps : • ASTU 1,2 and 3 require subscription on Flight Data Domain ( domain partitions ) • ATSU 2 and 3 Need to be added as a “verify” provider for the flight FO_ID • ASTU 1 requires to verify its change proposal • ASTU 1 requires to update the Flight Object • Flight Manager (ATSU 1, in this case) modifies the Flight Object AP4/SWIM Technical Interchange Meeting (TIM)

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

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

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

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

  21. Legacy ATM System SWIM-BOX Application SWIM-BOX Application SWIM-BOX Application DDS DataReader DDS DataReader DDS DataReader Flight Data Domain ServicesArchitecture 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 • <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> • …. W E B S E R V I C E EJB Stateless SessionBean SOAP request SWIM Core FDD Facade SWIM Publish Service DDS/JMS create_FO update_FO handover_FO Gateway EJB Container distribution SWIM-BOX Application DDS/JMS DDS/JMS FOS Flight Object Server FOS AP4/SWIM Technical Interchange Meeting (TIM)

  22. Scalability & Performance: The 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 statefulsession beans. • Performance An EJB container will never move a stateless session bean from RAM out to a secondary storage (as for a statefulsession bean) AP4/SWIM Technical Interchange Meeting (TIM)

  23. Scalability & Performance:The FDD Facade 2/2 Entity Beans are used to represent Flight Objects in order to have: • Container Managed Persistence • LifeCycle QoS • Business code Flight Object Entity Beans Session Stateless Bean pool W E B S E R V I C E FO_Bean FO_id1 Gateway SWIM Core Legacy ATM System SOAP request FDD Facade FO_Bean FO_id2 SWIM Publish Service FDD Facade FO_Bean FO_idn EJB Container DB SWIM-BOX Application Flight Object Server

  24. High LevelViewof FDD Architecture:Publishing FO 3following 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 Ejb Container FO Entity Bean (FO_ID, FO) 1 create_FO (FO) update_FO (FO_ID, FO,CLUSTER_ID) handover_FO (FO_ID) 2 create/retrieve the EJB with FO_ID as Primary key FDDFacade Session Bean FO Entity Bean (FO_ID, FO) Invocation Network Client DDS/JMS SWIM Publish Service Client FDDFacade Session Bean FO Entity Bean (FO_ID, FO) FlightObject lifecycle FO Entity Bean (FO_ID, FO) Redy/Pooled Loaded from DB when the Publisher is local createFO handoverFO Stored (DB) DB

  25. High LevelViewof FDD Architecture: Receiving FO Ejb Container 3 invoke the ejb_data_available in order to process the FO 2retrieve the EJB with FO_ID as Primary key FO Entity Bean (FO_ID, FO) Invocation Network Legacy System DDS/JMS DDS Listener or MDB 1 on_data_available(..) onMessage(..) 4the request is processed by the Legacy System FO Entity Bean (FO_ID, FO) DB AP4/SWIM Technical Interchange Meeting (TIM)

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

  27. Some ideasfor FDD Design:Looking at the Legacy System AP4/SWIM Technical Interchange Meeting (TIM)

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

  29. Publish/SubscribeProtocol • 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 AP4/SWIM Technical Interchange Meeting (TIM)

  30. Publish/SubscribeProtocol • DDS and JMS together: • JMS/DDS Bridge • ESB in order to transform protocols (JMS/DDS) AP4/SWIM Technical Interchange Meeting (TIM)

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

More Related