Online Presentation Creator | Create Survey | Create Quiz | Create Lead-form Get access to 1,00,000+ PowerPoint Templates (For SlideServe Users) - Browse Now
Download
swim suit swim suit prototype preliminary architecture n.
Skip this Video
Loading SlideShow in 5 Seconds..
SWIM-SUIT SWIM-SUIT Prototype preliminary architecture PowerPoint Presentation
Download Presentation
SWIM-SUIT SWIM-SUIT Prototype preliminary architecture

share
play prev play next
play fullscreen
1 / 31

SWIM-SUIT SWIM-SUIT Prototype preliminary architecture

244 Views Download Presentation
Download Presentation

SWIM-SUIT SWIM-SUIT Prototype preliminary architecture

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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)