Chapter 5
Application Designer
Designing software applications
In the previous chapters we focus on developing services (building blocks) for the future physics data processing applications. In this chapter we will show how to build ClaRA applications using available services without writing a single line of code.
Graphical interface
The ClaRA designer user interface provides an intuitive experience of visual design and execution of service based PDP applications. The snapshot of the graphical interface is shown below. It consists of three main parts: a) the main tool bar at the top, b) the engine/service tree representation pane on the left, and c) the multipurpose pane on the right that hosts the tabbed pane presenting the Info panel, the service engine Deployer graphical interface and the Editor (an application designer drawing canvas).
Figure 6. ClaRA application designer. This screenshot was taken on MacOSX. Since Java has pluggable look and feel, the look of the designer graphical interface on your platform might be different, but don't worry, the panes and buttons will be in the same position and they would have the same exact functionality.
The shell script (Unix csh) clara-designer, located in the bin directory of the ClaRA distribution will start the user interface.
>bin/clara-designer
Note, that the designer requires that a ClaRA DPE is running on a local node. Any attempt to run a designer without an active DPE will result in a warning dialog message:
In case the ClaRA platform (muster DPE) is running on a remote host, and you wish to run designer locally, you must run local DPE first:
> bin/clara-dpe
Toolbar menus
The toolbar contains three menus:
-
File: controls access to user service engines, deployed services and stored PDP application design drawings. It also allows execution of third party applications like EvIO data browser.
-
Edit: contains menu items that help to graphically design and edit physics data processing applications.
-
Control: deploys and runs service-based applications on a specified ClaRA DPE.
Open menu let’s the user choosing between visualizing
-
available service engines (menu item Engines)
-
ClaRA deployed and active services (menu item Services)
-
saved application design drawings (menu item Applications…)
It also runs an external data browser application (menu Data Viewer).
Figure 7. Open menu.
Engines and services will be visualized in a tree form in the left info pane of the graphical interface. Application design schemas will be shown in the application design drawing canvas (see Figure 6).
The Application… menu item opens a file chooser to help user to navigate the file system and then choose a file representing a specific ClaRA application design (illustrated above).
By default, a file chooser displays the root of the apps directory from the file system pointed by the CLARA environmental variable where ClaRA application design drawings are stored. Selected files from the file chooser will be visualized on the designer canvas and accessed by the Editor tab (see Figure 6).
The Save As… menu item saves a designed ClaRA application representation (as shown in the Editor pane) into the $CLARA_SERVICES/apps directory. Before actual saving, the user will be prompted to provide the name for the created/edited application:
The Exit menu item gracefully exits the ClaRA application designer.
Service deployment
To deploy a user developed PDP engine as a service we first open available engine classes (File-Open- Engines) and compiled shared object files in the engines tree representation pane of the designer (see Figure 8).
Figure 8. Service engines are shown on your left in a tree form. The section on your right shows the Deployer graphical interface of the ClaRA application designer.
Selecting a service engine from the tree will force the designer to switch to the Deployer tab that provides a form to enter the required engine deployment parameters. The engine name text field will be filled automatically. Parameters that wait for a user input are the host name and the container name for the future service. After providing all required parameters click the Ok button to deploy the engine as a service on the required host and container of the ClaRA cloud. The result of the deployment operation will be shown in the text area of the Deployer interface, indicating the date of deployment and a short summary of the operation.
One can also request the newly deployed service to report its functional description. For that we need first to list all the available services actively running on the ClaRA cloud. The File-Open_Services menu combination will show the topology of the ClaRA cloud services in a tree form (as show in the Figure 9). Selecting the service of interest from the tree will initiate a request to the service to report its operational description that will be shown in the Info tab of the designer.
Figure 9. Info tab of the designer shows the operation description of the selected service.
The ClaRA designer Edit menu (see Figure 10) is aimed to help the user to create physics data processing applications based on services that are actively deployed on the ClaRA cloud environment. The Command fields of the Edit menu mainly control the behavior of the Editor canvas of the interface. The Edit menu items operations are described below:
-
Link: graphically links service-representing icons together (draws the line between them). Acceleration: Ctrl^E
-
Boxes: draws a box around a service icon (for visual clarity)
-
Grid: this method involves drawing a grid of equal ratio on the application designer canvas. Sub-menu items provide controls to make visible (Show, acceleration Ctrl^G) and invisible (Hide) the already active grid, as well as enable (On) and disable (Off) the grid. The Align control command will align service icons to the grid. Service representing icons can be placed anywhere on the canvas screen, however if the grid is enabled (Grid-On), the Align menu item action will snap back in neat alignment on the designer canvas.
-
Zoom: Zoom in (In, acceleration Ctrl^I) helps a user to get a close look at select details of the PDP application design diagram. Zoom out (Out, acceleration Ctrl^O) helps user to see the big picture of a particular application design
-
Update (acceleration Ctrl^U): This command will initiate the communication with the ClaRA cloud administrative services to update the states of all services visualized on the designer canvas in terms of their deployment and interaction mechanisms (links).
-
Delete Component (acceleration Ctrl^D): Removes the selected component from the canvas after an additional confirmation dialog.
-
Delete All: Clears the entire designer canvas of the interface in case the user confirms the action.
Figure 10. Edit menu
The Control menu commands (see Figure 11) directly interact (read/write) with the ClaRA cloud administrative services, as opposed to the Edit menu that mostly acts on the ClaRA application designer canvas (with the exception of the Update menu action that does read-only access to the cloud).
Figure 11. Control menu
The application menu accesses prebuilt PDP application orchestrators, both for deployment and running purposes. These orchestrators are located in the bin directory and accessed by the $CLARA_SERVICES environmental variable. Service deployment specific orchestrators are stored in the bin/deploy directory and ClaRA based applications running orchestrators are saved in the bin/run directory. Deploy and Run submenu items of the Application menu open a file chooser to help the user navigate and then choose orchestrators located in the bin/deploy and bin/run directories respectfully.
The rest of the performed operations of the Control menu are described as follows:
-
Link Components (acceleration Ctrl^L): Creates physical data-links between services of a graphically described PDP application. After this operation, connections/links between services (that were previously described as a black, connecting lines) will be drawn as green lines, indicating active data links between cloud deployed ClaRA services.
-
Remove Links: Removes all active links between services shown on the designer canvas. As opposed to the Link menu action, this action will remove links between services that are physically deployed on a ClaRA cloud.
-
Remove Component: Removes a component from the designer canvas and at the same time requests that the services remove its registration and exit from the cloud.
Clas12 PDP engine deployment and testing
The principle functionality of a ClaRA service is to take input data, process it and produce a new output data. So, by design a ClaRA service deals with ClaRA transient data packed in a transient data envelope (see chapter 2) whether the data is coming from or going to a persistent storage or another service. One of the important ClaRA design choices is the separation between persistent and transient data. This design choice is based on the realization that physics data processing applications processing complex data structures, can rapidly become unmaintainable if data access requires knowledge of the details of used persistent data structures. Loose coupling of data storage and data usage was adopted to avoid being locked-in to a single persistency technology whether it was for experimental data storage or for data analyses and visualization. To simplify service engine development and testing, the framework provides persistent data for the ClaRA transient data format convertor services. This allows service engine code to concentrate on expressing its data-handling logic rather than the details of how the data is retrieved or stored. Current Clas12 transient data format is chosen to be EvIO. Before testing any user service engines we need to deploy provided convertor services. Figure 12 shows the deployment process of two persistency convertors (EvIOToEvioReader: EvIO persistent to EvIO transient, and EvioToEvioWriter: EvIO transient to Evio persistent) on a cloud.
Figure 12. EvIO persistent to transient data convertor services deployed.
Let us, for example, consider that we would like to debug and test the performance of the point-hit finder service engine of the Clas12 central tracker. For that we have to deploy the service engine as a service in the ClaRA platform. Figure 13 illustrates the process of deploying the PointHitFinder service engine in the CTTest container.
 Figure 13. Central PointHitFinder service deployment
The final step would be to design a test application based on above described and deployed three services. Before we graphically design the application it is a good idea to directly ask each of the deployed service to report it’s functional description. This way we make sure that first; services are properly deployed and second; that the functional description of a service is consistent with the expected functionality of that particular building block of our future application. To retrieve the description of each interested service we ask the normative registry services to return a list of all deployed services by the following sequence of actions: File-Open-Services.
Figure 14. Description of the EvioToEvioreader service
The description of the selected service from the tree (left pane of the interface) will be shown on the Info panel (see Figure 14). Now we start the graphical design of the PointHitFinder service test application by selecting the Editor designer canvas. Next we drag and drop three selected services: EvioToEvioReader, PointHitFinder, and EvioToEvioWriter (i.e. building blocks of our application) into the designer canvas. It is desirable to position the services in the canvas according to the data flow of the application in mind. This assumes that the PointHitFinder service will get the transient data from the EvioToEvioReader service and send the processed data to the EvioToEvioWriter service. Using the Edit-Link (acceleration Ctrl^E) menu-action sequence we draw the links between services by holding the left mouse-click and moving from the data source service to the data destination service. At the destination service we release the left mouse-click and that will activate the link action confirmation dialog (shown below).
Figure 15. Link confirmation interface
After all the links are drawn we suggest saving this application for future use, by using the File-Save As…(acceleration Ctrl^S) menu action sequence. The graphical representation of the created ClaRA application will be stored in $CLARA_SERVICES/apps directory and can be accessed in the future by the File-Open_Application… menu action sequence.
Figure 16. Deployed PointHitFinder tester application based on three services (the green color of the link between services indicates active data links between service)
The links drawn between services are solely graphical representations of the data flow of the application. In order to physically link services together (deploy an application) we use the Control-Link Components (acceleration Ctrl^L) menu action sequence.
Figure 17. generic-orchestrator is used to run applications that use EvIO as a transient data format
After having the designed application deployed and active we can use the generic orchestrator to test the application. The menu sequence to use is Control-Application-Run (see Figure 17) that opens a file chooser, browsing the $CLARA_SERVICES/bin/run directory.
Figure 18. User interface of the generic orchestrator that is used to run service compositions that use EvIO as transient data format
Choose the generic-orchestrator to open the graphical interface of the generic orchestrator (see Figure 18) that lets the user choose the input and output files to read and write persistent EvIO format files as well as the number of processing events and the number of concurrently running application threads (number of simultaneously running chains of services). Note that ClaRA supports event level parallelization only. After execution of the ClaRA application is complete (shown by the progress bar of the generic orchestrator interface), the Info panel of the ClaRA designer GUI will present details of the application execution including average processing time per event as well as possible error and/or warning messages. The output data can be analyzed using the Data Viewer accessed using the File-Open-Data Viewer menu action combination.
Share with your friends: | 
