1 / 20

VLAM-G Graphical User Interface

VLAM-G Graphical User Interface. VLAM-G developers team Computer Architecture and Parallel Systems Group Department of Computer Science Universiteit van Amsterdam National Institute for Nuclear and High Energy Physics. Outline. Principles VLAM-G GUI Features VLAM-G GUI Protocols

fathi
Télécharger la présentation

VLAM-G Graphical User Interface

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. VLAM-GGraphical User Interface VLAM-G developers team Computer Architecture and Parallel Systems GroupDepartment of Computer ScienceUniversiteit van Amsterdam National Institute for Nuclear and High Energy Physics

  2. Outline • Principles • VLAM-G GUI Features • VLAM-G GUI Protocols • VLAM-G GUI Architecture • The GEF Library • VLAM-G GUI components description • Conclusions

  3. VLAM-G GUI: Principals • VLAM-G GUI is a client that allows the user to connect to the VLAM-G server side from any computer, provided: • the user provides his credentials • VLAM-G GUI caches a minimal set of information at the client side to reduce the transfer of data to the server • VLAM-G GUI creates a dedicated communication channel to cope with data stream coming from the server side.

  4. VLAM-G GUI: Features • User friendly • based on JAVA Technology • uses the GEF library • Complete control over Modules, Connections and PFTElements. • Creating, Saving and Loading of Topologies, PFTStudies and PFT’s. • Complete overview of data.

  5. VLAM-G GUI: Interaction with VLAM-G Server • How does it interact with VLAM-G Server? • All the interactions with the VLAM-G server side are in XML format over https • The VLAM-G GUI interacts mainly with the Session Manager on the server side using the specific protocol

  6. Login process Protocol(under discussion) Note: FrEnd=VLAM-G GUI • Login process : • User starts VLAM-G home page and clicks on a link to start VLAM-G front-end (Li1W1 and Li1W2). • Or the user may start the front-end directly from Web Start (Li1). • This will bring the Login window (Win 1). • User will fill his login information (Li1) and sends it to the Session Manager Dispatcher (SessMan-Disp) (Li2). • Dispatcher receives the data and checks its authenticity (Li3). • The previously described steps in the Log-on process is a representative of AAA process and do not reflect the actual process. • Dispatcher is informed (Li4 ) that the user is OK. • Dispatcher sends this to FrEnd (Li5). • The user has logged in. SessMan-Disp will handle the calls until the user selects a service. Then depending on the service, SessMan-Disp will connect the user to an active SessMan or will spawn a new one. Messages used in the “Logon to VLAM-G” process: Li3. “<RandNum>, Request, Login, <login.xml>” ( FrEnd  SessMan-Disp ) Li4. “<RandNum>, Request, AAACheck, <???login.xml???>” (SessMan-Disp  AAA ) Li5. “<RandNum>, Response, AAACheck, <SUCCESS/FAILED>” ( AAA  SessMan-Disp ) Li6. “<RandNum>, Response, Login, <dispId>” (SessMan-Disp  FrEnd ) Login.xml: username, password, ???

  7. Service Selection Protocol(under discussion) • Service Selection process : • FrEnd sends a request to SessMan-Disp for available services (Ss1). • The request is sent to VIMCO (Ss2). • VIMCO retrieves : • the available experiments for this user, • the PFTs own by him and/or his group and • their status (active, completed,_______). • This data is sent back to FrEnd via SessMan-Disp (Ss3-Ss4). • The user selects one service and FrEnd requests that from SessMan-Disp. Messages used in the “Service Selection” process: Ss1. “<sessId>, Request, Services” ( FrEnd  SessMan ) Ss2. “<sessId>, Request, Services” ( SessMan  VIMCO ) Ss3. “<sessId>, Response, Services, <Services.xml>” ( VIMCO  SessMan ) Ss4. “<sessId>, Response, Services, <Services.xml>” ( SessMan  FrEnd ) Ss5. “<sessId>, Request, SessMan, <idPFT>” ( FrEnd  SessMan ) SessMan-Disp may start a new SessMan at this point... Ss6. “<sessId>, Response, SessMan, <portSessMan>” ( SessMan  FrEnd )

  8. Start New study Protocol(under discussion) • Start a New Study : • User selects one of the options under “Start a new study” list (Ns1). Hence it has no active SessMan. • SessMan-Disp realizes that the user requested a new study and it starts a new SessMan (Ns2). • SessMan-Disp starts a SessMan and registers itself to SessMan-Disp (Ns3). • FrEnd is reponded with the address to contact (Ns4). • First the active user is set . (Ns5-Ns6). • The PFT is requested from the new SessMan (Ns7). • SessMan send this request to VIMCO (Ns8). • VIMCO sends the requested PFT to SessMan (Ns9). • FrEnd receives this PFT from SessMan (Ns10) and displays it in the PFT editor. • VIMCO does not creates this PFT in the corresponding application database yet. Messages used in the “Start a new Study” process: Ns1. “<sessId>, Request, SessionAddress, <PFT.xml>” ( FrEnd  SessMan ) Ns2. “<dispId>, Request, Register, <sessMan.xml>” ( SessMan  SessMan-Disp) Ns3. “<dispId>, Response, Register, <FAILED/SUCCESS>” ( SessMan-Disp  SessMan ) Ns4. “<sessId>, Response, SessionAddress, <adress.xml>” ( SessMan  FrEnd ) Ns5. “<sessId>, Request, SetUser, <user.xml>” ( FrEnd  SessMan ) Ns6. “<sessId>, Response, SetUser, <user.xml>” ( SessMan  FrEnd ) Ns7. “<sessId>, Request, PFT, <PFT.xml>” ( FrEnd  SessMan ) Ns8. “<sessId>, Request, PFT, <PFT.xml” ( SessMan  VIMCO ) Ns9. “<sessId>, Response, PFT, <PFT.xml>” ( VIMCO SessMan ) Ns10. “<sessId>, Response, PFT, <PFT.xml>” ( SessMan  FrEnd ) <PFT.xml>: idPFT (0 for a new study) NameOfStudy

  9. Execute Experiment Protocol (under discussion) Messages used in the “Executing an Experiment” process: E1,E2. “<sessId>, Request, SavePFT, <PFT.xml>” (where idObj=0) ( FrEnd  VIMCO ) E3,E4. “<sessId>, Response, SavePFT, <PFT.xml>” (where idObj0) ( VIMCO FrEnd ) E5,E6. “<sessId>, Request, SaveExpTopology, <ExpTop.xml>” (idObj=0) ( FrEnd  VIMCO ) E7.E8.“<sessId>, Response, SaveExpTopology, <ExpTop.xml>” (idObj0) ( VIMCO FrEnd ) E9,10. “<sessId>, Request, AvailableMachines” ( FrEnd  RTS ) E11,12. “<sessId>, Response, AvailableMachines, <avaMch.xml>” ( RTS  FrEnd ) E13. “<sessId>, Request, Execution, <pftId>” ( FrEnd  SessMan ) E14. “<sessId>, Request, ExpTopology, <pftId>” (SessMan  VIMCO ) E15. “<sessId>, Response, ExpTopology, <topology.xml>” (VIMCO SessMan ) E16. “<sessId>, Request, Execution, <topology.xml>” ( SessMan  RTS ) E17. “<sessId>, Response, Execution, <execId>” ( RTS SessMan ) E18. “<sessId>, Response, Execution, <execId>” ( SessMan  FrEnd ) E19. “<sessId>, Update, ExecutionId, <execId>” ( RTS SessMan ) E20. “<sessId>, Update, ExecutionId, <SUCCESS/FAILED>” ( SessMan  FrEnd ) Where is the link between the execution job Id and the experiment Id hold?

  10. Logout process Protocol(under discussion) • Logout from a session : • The user has started his jobs and now he wants terminate his session (and go home, probably!!!). This does not imply that the execution of the code has been completed. • When the user selects the Logout option, his request is sent to the SessMan (Lo1). • Remember, session is active as long as its user and/or RTS active… • SessMan sends a message to VIMCO (Lo2) and RTS (Lo3) and resets active user name field from the sessions (SessMan, VIMCO, RTS). • Finally, SessMan response to FrEnd (Lo6) Discussion points: • I suggest we should keep sessions on all 3 sides (SessMan, VIMCO, RTSMan) active as long as there is an active user or process (in RTS). Messages used in the “Logout from a Session” process: Lo1. “<sessId>, Request, Logout” ( FrEnd  SessMan ) Lo2. “<sessId>, Request, Logout” ( SessMan  VIMCO ) Lo3. “<sessId>, Response, Logout, <SUCCESS/FAILED>” ( VIMCO SessMan ) Lo4. “<sessId>, Request, Logout” ( SessMan  RTSMan ) Lo5. “<sessId>, Response, Logout, <SUCCESS/FAILED>” (RTSMan SessMan ) Lo6. “<sessId>, Response, Logout, <SUCCESS/FAILED>” (SessMan FrEnd )

  11. VLAM-G GUI Architecture Client side Login window Process Flow Template Editor/viewer Experiment Topology Editor/viewer Globus credentials java2XML/Xml2java Xml/https

  12. GUI events AddNode AddConnection LoadFromDB StoreInDB PFT Editor/Viewer Experiment Editor ModDeskTop ModManager PFTDeskTop PFTManager ModNode ModFig PFTNode PFTFig DeskTop Manager VLAM-G GUI Library VLE Node Port connection JGraphFrame GEF Library NodeFig NetNode NetPort NetEdge TestVIMCOServer ConnSessionMan GEF Library VLAM-G COM Library

  13. The Gef Library • Features • Node-Port-Edge graph model • Model-View-Controller based on the Swing Java • High-quality user interaction for moving, resizing, reshaping, etc. • Novel inteactions such as the broom alignment tool and the selection-action-buttons • generic properties sheet based on JavaBean introspection • XML-based file format based on PGML. • Open source code library

  14. VLAM-G Experiment Topology Editor/Viewer • Features • load VLAMG Modules using the user profile • load existing VLAM-G topology • allow to instantiate modules via drag-and-drop • create connections between two input and output ports of the same type. • Provide details of any selected module • save the resulting experiment topology into the remote database. • Allow to start the execution of an experiments

  15. Snapshot of the VLAM-G experiment editor/viewer

  16. VLAM-G Process Flow Template Editor/Viewer • Features • Load existing VLAM-G PFTs • Create a new PFT • Create an PFI out of the loaded PFT • Perform queries to the database. • save the resulting PFI into the remote database.

  17. Snapshot of the VLAM-G PFT editor/viewer

  18. Graphical tool for module writer (under development) • Features • Allow the module writer to create an Xml description of the code he wants to add the VLAM-G environment • Can be started as a stand alone application or from within the VLAM-G environment

  19. Module Skeleton generator Utility Module Description Editor Module Body Xml description of the module Source Code Module Skeleton Module skeleton Generator Module Body Note: The module writer still needs to do some minor editing on the generated code to make it real VLAM-G module: add some read and write to ports inside the source code. Gftp server

  20. Conclusions

More Related