200 likes | 328 Views
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
E N D
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
Outline • Principles • VLAM-G GUI Features • VLAM-G GUI Protocols • VLAM-G GUI Architecture • The GEF Library • VLAM-G GUI components description • Conclusions
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.
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.
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
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, ???
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 )
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
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 idObj0) ( VIMCO FrEnd ) E5,E6. “<sessId>, Request, SaveExpTopology, <ExpTop.xml>” (idObj=0) ( FrEnd VIMCO ) E7.E8.“<sessId>, Response, SaveExpTopology, <ExpTop.xml>” (idObj0) ( 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?
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 )
VLAM-G GUI Architecture Client side Login window Process Flow Template Editor/viewer Experiment Topology Editor/viewer Globus credentials java2XML/Xml2java Xml/https
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
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
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
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.
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
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